Сетевая служба утилита google chrome что это такое

Обновлено: 04.07.2024

Первый этап в основном связан с переходом на Mojo IPC. Второй этап заключается в полном отделении этого кода от Chrome, чтобы у нас была возможность запускать его в отдельном процессе.

Пожалуйста, не стесняйтесь комментировать или редактировать документ, и я уверен, что мы синхронизируем множество встреч, чтобы обсудить больше.

Джон Абд-Эль-Малек

Райан Сливи

Я не думаю, что документ описывает в достаточной мере то, что вы считаете "сетевой службой", и это затрудняет оценку.

Сеть широко используется в Chrome, и все более и более пористыми слоями, поскольку такие вещи, как URLFetcher, были перемещены в контент, а затем в сеть, а также благодаря развитию таких вещей, как Blimp и ChromeCast, Chromoting, WebPush и многих других интересных , но несвязанные вещи.

Итак, исходя из этого, я могу придумать по крайней мере три возможных определения того, что вы подразумеваете под "сетевой службой":
1) Служба загрузки URL-адресов (по сути, сервисно-ориентированный URLFetcher)
2. ) Монолитная служба, обеспечивающая высокоуровневую реализацию службы для всех многочисленных (не в//сетевых) потребителей сети
3) Служба, которая IPC использует 70% //сетевого API, потребляемого // чистые потребители

У меня есть реальные опасения и возражения против 3, я думаю, что 2 было бы значительно худшим местом для работоспособности кода из-за опасений по поводу многоуровневости и просто "запихивания вещей в //net", а 1 по своей сути не является необоснованным, но также не указано четко.

Кроме того, является ли прямой путь к Mojo лучшим (самым безопасным и продуктивным) путем? В ветке Mojo все еще есть очень реальные вопросы о безопасности и производительности, на которые, похоже, нет ответа. Из обсуждений нового планировщика задач Chromium для //base возникло много реальных вопросов об упорядочении и взаимозависимости сообщений, которые в равной степени применимы к гарантиям Mojo (отсутствию). А из обсуждений Code Yellow о перемещении потока ввода-вывода в IPC vs Networking стало ясно, что существует множество взаимозависимостей, которые необходимо решить. Меня беспокоит то, что «переписать все это в Mojo» просто представит или помешает всем тем же самым проблемам, поэтому было бы полезно знать, как они решаются.

Учитывая, что здесь речь идет о производительности и о том, сколько времени тратится на то, чтобы понять и оптимизировать //чистую производительность, было бы здорово узнать, удалось ли Mojo исправить регрессию производительности, которая возникает при каждой конверсии. с Mojo IPC столкнулся.

Я только что заметил, что в диспетчере задач Chrome запущен дополнительный процесс Chrome. «Утилита: Сетевая служба». Я предполагаю, что это что-то новое в Chrome 72? Что он делает?

Еще одно голосование. Что за чертовщина? Он ведет себя очень странно, и после использования кнопки «Завершить процесс» Chrome получает ошибки сервера даже после выхода из приложения и перезагрузки моей машины.

Я думаю, что это как-то связано с опцией "использовать отдельный процесс для сетевых запросов" во флагах, но это буквально все, что я могу понять об этом.

Я тоже заметил это и хотел бы знать то же самое. Все, что я знаю о нем в настоящее время, это то, что он использовался для взлома веб-логгера uBlock Origin (не уверен, что он все еще работает), и он сразу же запускается, когда я использую кнопку завершения процесса в диспетчере задач Chrome.

Как и выше, логика предполагает, что это как-то связано с опцией "использовать отдельный процесс для сетевых запросов" во флагах, но подробности есть.

У меня тоже. Также еще один называется «аудиосервис».

Оба просто снова открываются, если я выбираю "Завершить задачу".

да, у меня происходит то же самое, несколько месяцев назад это была только утилита: сетевая служба, сегодня появляется звуковая служба, завершение ее задачи снова откроет ее, завершение этой задачи во время просмотра видео на YouTube, это заставит видео на YouTube сломаться. и автоматически обновляется, и аудиосервис снова работает

У меня тоже есть звуковая служба, и я хотел бы узнать, как отключить ее, как я сделал с сетевой службой. Я даже не могу найти сайт, объясняющий, что должен делать аудиосервис.

Я столкнулся с этой службой при использовании Sysinternals TCPView, чтобы выяснить, почему мой компьютер подключался к устройству, которого не должно было быть. Я столкнулся с соединением, делая что-то несвязанное, но использовал команду netstat из cmd.

В диспетчере задач Chrom я закрывал процессы до тех пор, пока подключение к сокету не исчезло из TCPView. Это была «Утилита: Сетевая служба», но я до сих пор не знал, что и почему она подключается к этому устройству.

Я искал в Интернете порт 8009 и Chrome, чтобы узнать, что это такое. Другой форум заявил, что ChromeCast использует этот порт.

Я не знаю всей его функции, но полагаю, что часть ее заключается в сканировании сети на наличие устройств Chrome, таких как, например, ChromeCast. В Chrome я щелкнул "меню с тремя точками в правом верхнем углу" -> Cast.

Я увидел компьютер, связанный с подключением неизвестного устройства и с "Утилита: Сетевая служба".

Компания Google представила изменения в своем браузере Chrome. Это изменение заставляет Audio запускаться в отдельном процессе на Windows и других платформах. Вы можете увидеть и убедиться в этом, найдя «Утилита: аудиосервис» в диспетчере задач Chrome во время воспроизведения аудио- или видеофайла в браузере.

Chrome запускает звук в отдельном процессе

Если вы не в курсе, Utility: Audio Service — это просто служба, которая запускается для воспроизведения звука в браузере. Что-то вроде Утилита: сетевая служба, которая использует отдельные процессы для повышения безопасности. Таким образом, когда происходит сбой вкладки или что-то идет не так, происходит сбой всего браузера.

Ранее аудиопроцесс в Chrome был частью процесса браузера. Таким образом, всякий раз, когда со звуком возникали небольшие сбои или что-то шло не так, вкладка автоматически закрывалась или происходил сбой всего браузера.

С этим новым изменением, если в браузере возникнут какие-либо проблемы с аудиопроцессом, он просто перезапустит процесс, не мешая работе браузера

Чтобы увидеть и проверить это изменение, просто посетите YouTube или другой подобный веб-сайт, открыв его на отдельной вкладке в Chrome.

Затем перейдите в «Меню», выберите «Дополнительные инструменты» и выберите параметр «Диспетчер задач».

Кроме того, вы можете нажать Shift+Esc, чтобы открыть диспетчер задач Chrome. Когда он откроется, найдите Utility: Audio service.

Изменение схемы, то есть перенос аудиоплатформы в отдельный процесс, предназначено для повышения стабильности браузера и обеспечения превосходной производительности за счет изоляции процесса браузера от сбоев аудиодрайвера.

Обновление выпущено для браузера (начиная с Chrome v76). Он должен установиться автоматически.

Если вы его не видите, вы можете принудительно установить его, обновив до последней версии или перейдя в «Меню», выбрав «Справка» и выбрав « О опции Chrome.

Дата: 5 сентября 2019 г. Теги: Chrome пожаловаться на это объявление

[электронная почта защищена]

Хемант, получивший высшее образование в области биотехнологии, переключился на написание статей о технологиях Microsoft и с тех пор является участником TheWindowsClub. Когда он не работает, вы обычно можете застать его путешествующим по разным местам или предающимся просмотру фильмов.

Пользователи доверяют веб-браузерам по своей природе. Они обучены доверять веб-сайтам, которые «имеют замок в адресной строке» и «имеют правильное имя». Это доверие приводит к тому, что пользователи чувствуют себя комфортно, вводя свои конфиденциальные данные на эти веб-сайты. С точки зрения злоумышленников, это доверие — удивительная вещь, поскольку после того, как вы скомпрометировали рабочую станцию пользователя, появляется процесс (с почти нулевой защитой), обрабатывающий относительно большой объем конфиденциальных данных, в то время как пользователь активно использует его. Добавьте менеджеры паролей с расширениями для браузера, и вы получите естественную цель для красных команд. Так что, естественно, когда у меня появилось время на исследовательский проект, я решил потратить его, злоупотребляя этим доверием!

Общий обзор

В качестве целевого браузера я выбрал Google Chrome по той простой причине, что на него приходится почти 70 % рынка браузеров для настольных компьютеров, поэтому он является самым популярным браузером и, следовательно, является очевидным выбором для таргетинга.

Как и большинство браузеров, Chrome использует многопроцессорную архитектуру (как показано ниже):

Причина этого заключается как в обеспечении безопасности, так и в удобстве использования: определенные части браузера (такие как средство визуализации) могут быть помещены в песочницу, в то же время позволяя другим частям браузера работать без ограничений песочницы. Chrome разбит на 7 различных частей, наиболее важными из которых являются сетевая служба, служба хранения и средство визуализации. Сетевая служба делает то, что написано на банке… она обеспечивает связь с Интернетом и, следовательно, гарантированно владеет конфиденциальными данными, которые нам нужны.

Кража данных по старинке

Я знаю, что буду ориентироваться на Chrome, работающий в Windows, а также на то, что в Windows есть собственная библиотека сокетов под названием Winsock.Так что вполне вероятно, что Chrome будет использовать Winsock для своей сетевой связи. Большая часть кода Chrome хранится внутри chrome.dll, поэтому, загрузив его в IDA и просмотрев внешние ссылки на WSASend, я могу подтвердить это предположение.

Единственная проблема заключается в том, что WSASend будет содержать данные в виде открытого текста только тогда, когда пользователь подключается к сайтам без включенного SSL, что вряд ли относится к тем сайтам, с которых мы хотим украсть данные. Итак, как мы можем получить те же данные, только в виде открытого текста, до того, как они будут зашифрованы? Вместо этого давайте просто нацелимся на функции шифрования SSL.

Где-то во время разработки Chrome компания Google решила, что OpenSSL им недостаточно, и создала собственную вилку под названием BoringSSL. Они были достаточно любезны, чтобы сохранить исходные имена основных функций, что означает, например, что SSL_write делает то же самое как в OpenSSL, так и в BoringSSL. Он примет указатель на некоторые данные в виде открытого текста в качестве аргумента buf и запишет его в поток SSL, на который указывает аргумент ssl. Исходный код функции можно увидеть ниже:

Мы можем подтвердить его использование Chrome, выполнив поиск внешних ссылок на строку SSL_write в chrome.dll:

Посмотрев немного, я нашел функцию по смещению 0x0000000182ED03E0 , я переименовал некоторые имена переменных и функций, чтобы было совершенно ясно, что это функция SSL_write:

Теперь, когда у нас есть смещение, мы можем разместить перехватчик, чтобы перенаправить вызов из легитимной функции SSL_write в нашу функцию SSL_write. Я уже делал это в прошлом посте в блоге.

Я написал код для поиска следующего шаблона:

и замените его приведенной ниже функцией, которая просто отобразит текстовое поле с данными запроса внутри.

Я внедрил DLL в сетевую службу и вошел в учетную запись Outlook. Как и ожидалось, у меня появилось два всплывающих окна, одно с заголовками запроса, а другое с телом POST:

Но у всех облаков есть худые стороны, и, по крайней мере, это заставило меня признать тот факт, что Chrome на самом деле поддерживает несколько различных протоколов, и что мне нужно найти более универсальное решение для достижения моих целей.

Кража данных в эпоху мультипротоколов

Теперь вполне возможно просто повторить описанный выше процесс поиска смещений критических функций для каждого протокола, а затем разместить перехватчики. Но это только кажется, что много работы и не особенно элегантный метод. Вместо этого я решил сделать шаг назад и поискать более чистый способ сделать это.

Оглядываясь назад на многопроцессорную архитектуру, которую использует Chrome, я понял, что должен существовать метод, который процесс визуализации использует для передачи запроса сетевой службе и получения ответа. Я нашел это выступление @NedWilliamson, в котором подробно рассказывалось о том, как Chrome использует межпроцессное взаимодействие (IPC) для связи между процессами. Оказалось, что, нацелившись на функции, используемые для IPC между двумя процессами, я теперь смогу красть отправляемые и получаемые данные независимо от протокола.

Я запустил его — было отправлено много нерелевантных данных, поэтому я использовал приведенный ниже фильтр, чтобы отфильтровать только то сообщение, которое хотел видеть:

Вместо того, чтобы передавать запрос напрямую сетевой службе, средство визуализации будет использовать брокера в качестве прокси для этих запросов.

Теперь, когда мы уверены, что данные запроса будут передаваться через IPC, пришло время приступить к краже этих данных! Сделать это на самом деле очень просто, поскольку вам нужно всего лишь перехватить один вызов Windows API, чтобы получить содержимое любых запросов, независимо от протокола, по которому они будут отправлены. Рассмотрим приведенный ниже пример того, как может выглядеть собственный внутренний код Chrome:

Вместо того, чтобы использовать шаблон байта (который может меняться от версии к версии) для поиска HandleMojoData , почему бы просто не указать ReadFile, адрес которого присутствует в PEB и легко доступен через вызов GetProcAddress . Так что давайте сделаем это вместо этого — ниже приведена функция, на которую я собираюсь перенаправить законную функцию ReadFile:

Все, что будет делать эта функция, — это регистрировать данные, которые будут записываться из именованного канала в файл на диске, а затем вызывать исходную функцию ReadFile. Этот код можно найти здесь.

После внедрения перехватывающей DLL и повторного входа в Outlook, немного поискав, я могу найти учетные данные, которые использовал для входа:

Теперь единственная задача состоит в том, чтобы разобрать этот файл и извлечь как можно больше секретов.

YARA, она и синяя, и красная

Мне нужно было написать утилиту для разбора этого файла дампа. Необходимо было иметь возможность сопоставлять и различать несколько разных типов запросов, а затем анализировать такие запросы таким образом, чтобы упростить извлечение секретов внутри запроса. Для этого, используя комбинацию правил YARA и систему плагинов на основе Python, я написал hunt.py .

Синтаксис для использования hunt.py очень прост

Затем он выполнит поиск по дампу и найдет секреты, как показано ниже:

Написать правила и плагины на самом деле очень просто. Для начала вам нужно просмотреть запрос и выбрать строки, которые можно использовать для идентификации запроса правила YARA:

Затем, используя эти строки, можно написать правило YARA, подобное следующему. Правила должны храниться в каталоге rules/:

Давайте посмотрим на наш Chrometap BOF в действии:

Chrome, генератор имплантов Google?

Возможность украсть секреты из запросов — это одно, но как насчет использования Chrome в качестве скрытого метода сохранения? Вот это было бы круто.

Чтобы справиться с этим, нам нужно найти способ просмотра ответов на веб-запросы, но если мы сможем просматривать веб-запросы с помощью перехватчика ReadFile в сетевой службе, мы, безусловно, сможем просматривать ответы на эти запросы. как он записывается обратно в канал с помощью хука на WriteFile? Давайте узнаем.

Я изменил предыдущий код, чтобы вывести содержимое WriteFile вместо ReadFile . Внедрив его в сетевой сервис и проанализировав файл дампа, я ожидал увидеть кучу файлов HTML/CSS/JavaScript, но, к моему удивлению, их не оказалось:

Я был в таком замешательстве. Я предположил, что ошибся в своем предположении и что содержание ответа было передано через другое средство IPC. Я потратил некоторое время на изучение общей памяти (еще один метод IPC, который использует Chrome), но так и не смог найти содержимое ответа.

Расстроенный, я просматривал заголовки запросов, пытаясь найти что-то, что я пропустил. Затем я заметил заголовки кодировки, и все стало понятно:

Я предполагал, что сетевая служба будет просто обрабатывать все и передавать ответы средству рендеринга для рендеринга, но, судя по объему сжатого содержимого в файле дампа, кажется, что процесс рендеринга также будет обрабатывать распаковку:

Извлекая и распаковывая содержимое, сжатое с помощью gzip, мы можем видеть, что это действительно тот веб-контент, который я искал. Наконец-то!

Итак, теперь мы знаем, что, поместив хук в WriteFile и распаковав данные в lpBuffer, мы получим обычный текстовый веб-контент. Круто.

Используя эту симпатичную маленькую библиотеку распаковки gzip, я смог написать замену функции WriteFile, которая распаковывает данные и передает любые данные между HTML-тегами функции шеллкода ExecuteShellcode для выполнения.

ExecuteShellcode не делает ничего особенного, он просто использует Windows API для декодирования base64 шелл-кода, а затем выполняет его. Я оставлю читателю задачу адаптировать это для использования системных вызовов и других более безопасных методов внедрения.

Поскольку теперь у нас есть DLL, внедрение которой заставит Chrome выполнять любой шеллкод между тегами, давайте проверим это:

Если вы зайдете на главную страницу моего блога через браузер с бэкдором, запустится шелл-код:

Скрытый способ сохранить доступ к такой организации — это круто, потому что это не означает, что вам нужно иметь постоянно работающий маяк/имплант. Все, что вам нужно сделать, это предоставить пользователю доступ к веб-ресурсу, содержащему простые текстовые теги шеллкода, будь то ссылка, изображение, iframe и т. д., не имеет значения.

Вы можете использовать любую обычную технику персистентности для повторного внедрения ловушки после каждой перезагрузки.

Развертывание

Наличие этих инструментов в виде DLL полезно, но не очень практично для участия, поскольку мне придется каким-то образом идентифицировать сетевую службу Chrome, а затем внедрить указанную DLL. По этой причине я решил использовать для их развертывания комбинацию файлов объектов маяка sRDI и Cobalt Strikes.

Я написал объектный файл маяка (BoF) для использования прямых системных вызовов. Это стало намного проще благодаря отличной работе @Cneelis над InlineWhispers.

Первая задача — найти сетевую службу Chrome. Он запускается под именем образа chrome.exe, поэтому я использую системный вызов NtQuerySystemInformation с аргументом SystemProcessInformation, чтобы получить указатель на структуру SYSTEM_PROCESSES, содержащую информацию обо всех процессах, запущенных в данный момент на машине.

Затем используйте NextEntryDelta для итерации процессов, пока ProcessName.Buffer не станет chrome.exe .

Как только сетевой процесс будет найден, он будет использовать приведенный ниже код для внедрения в процесс библиотеки DLL, которая теперь благодаря sRDI была преобразована в независимый от позиции шеллкод.

Надеюсь, этот пост был вам полезен, и некоторые из этих методов пригодятся вам. Я планировал также включить подробности о том, как внедрить произвольный JavaScript в веб-страницы, но, к сожалению, у меня просто не хватило времени, и мне пришлось перейти к другим вещам, хотя я скажу, что это вполне возможно сделать, используя комбинацию методов. Я перечислил выше.

Читайте также: