Google и Microsoft удалили из своих магазинов расширений популярный инструмент для редактирования HTTP-заголовков ModHeader (около 1,6 млн установок на Chrome и Edge) после того, как исследователи обнаружили в его коде скрытый механизм сбора истории просмотров. По данным исследователей, механизм был неактивен — внутренний список разрешений поставлялся пустым, и доказательств фактической передачи данных не обнаружено. Однако вся инфраструктура для эксфильтрации — шифрование, конечная точка, планировщик — уже присутствовала в подписанном и верифицированном расширении, готовая к активации через обычное обновление без запроса дополнительных разрешений у пользователя. Пользователям рекомендуется немедленно удалить расширение и ротировать любые секреты (API-ключи, токены, куки), которые вводились через него.
Что обнаружено в коде
Анализ выполнила британская компания Stripe OLT, которая проверила код расширения по подписи Chrome Web Store и подтвердила, что скрытый сборщик присутствовал в подлинной версии расширения, а не в подделке. Независимые разборы от HackIndex (версия 7.0.18) и исследователя Yunus Aydin (версия 7.0.17) описывают тот же механизм.
Версия 7.0.18 (идентификатор расширения idgpnmonknjnojddfkpgkljpfnnfcklj) выполняла заявленную функцию редактирования заголовков. Однако в том же минифицированном фоновом коде содержалась вторая система со следующей логикой:
- При первом запуске формировался цифровой отпечаток устройства и загружался жёстко закодированный ключ шифрования.
- При просмотре страниц извлекался домен каждой открытой страницы, шифровался и сохранялся локально — до 1000 уникальных доменов.
- Ежедневный планировщик должен был собирать зашифрованный список вместе с отпечатком устройства, отправлять POST-запрос на
api.stanfordstudies[.]comи очищать локальную копию. - Время отправки смещалось для каждой установки, чтобы расширения на разных машинах не обращались к серверу одновременно.
Ключевой элемент: сборщик запускался только при совпадении браузера с записью во внутреннем списке разрешений, который поставлялся пустым. Проверка всегда завершалась неудачей, и конвейер останавливался до сбора первого домена. Однако заполнение этого списка — минимальное изменение, доставляемое через рутинное обновление без новых разрешений и без действий пользователя.
Активные компоненты
Не всё было неактивным. По данным исследователей, при установке, обновлении и удалении расширение отправляло запрос на домен extensions-hub[.]com с информацией о продукте, версии и браузере. Кроме того, скрипт, выполнявшийся на каждой странице, уже записывал метаданные реальных запросов в локальное хранилище в открытом виде — этот компонент функционировал.
Почему автоматические сканеры не обнаружили угрозу
Как сообщается, автоматические проверки оценивали ModHeader как расширение с низким уровнем риска, некоторые — до 95 баллов из 100. Каждый элемент архитектуры был рассчитан на обход определённого типа проверки: данные зашифрованы — сканер видит только шифротекст; отправка заблокирована — песочница не фиксирует исходящий трафик; вредоносный код минифицирован в легитимную кодовую базу; конечные точки не имели репутации вредоносных; подписанное популярное расширение воспринимается как доверенное. Подпись магазина подтверждает происхождение файла, но не его поведение.
Инфраструктура и контекст
Stripe OLT связала домены с реальной поддерживаемой инфраструктурой. Домен stanfordstudies[.]com не имеет отношения к Стэнфордскому университету — это перепрофилированный старый домен, за которым стоит бэкенд на OpenSearch. Домен extensions-hub[.]com настроен для рекламных целей. На момент анализа оба API-эндпоинта разрешались на один и тот же сервер Amazon.
ModHeader привлекал жалобы пользователей ещё в 2023 году из-за внедрения рекламы в результаты поиска и, как сообщается, перешёл на модель с рекламной поддержкой примерно в тот же период. Кто именно получил контроль над расширением, не подтверждено. При этом собственная страница ModHeader по-прежнему утверждает, что расширение не собирает пользовательские данные — что трудно совместить с наличием встроенного сборщика истории просмотров, даже неактивного.
Этот случай вписывается в паттерн, описанный Брайаном Кребсом ещё в 2021 году: популярные расширения тихо приобретаются и превращаются в каналы сбора данных. Разница в том, что теперь механизм дополнен шифрованием и шлюзом, который скрывает отправку данных от сканеров.
Оценка воздействия
Наибольшему риску подвержены разработчики и специалисты по тестированию — основная аудитория инструментов для редактирования HTTP-заголовков. Эта категория пользователей регулярно работает с API-ключами, токенами авторизации и сессионными куки, которые вводятся непосредственно в расширение. Исследователи обнаружили, что функция истории заголовков ModHeader сохраняла полные HTTP-заголовки на диск, что создаёт риск компрометации секретов даже без активации основного сборщика доменов.
Расширения для редактирования заголовков и управления куки по своей природе требуют широких разрешений для работы. При нарушении доверия радиус поражения оказывается значительным.
Практические рекомендации
Для пользователей
- Удалите ModHeader из Chrome и Edge — браузер мог уже отключить его автоматически.
- Убедитесь, что синхронизация профиля или управляемая политика расширений не восстановит его.
- Если вы вводили через ModHeader API-ключи, bearer-токены или сессионные куки — ротируйте их немедленно.
Для команд защиты
- Заблокируйте и настройте логирование для доменов
stanfordstudies[.]comиextensions-hub[.]comна уровне DNS и прокси. - Выполните поиск в логах по идентификатору расширения
idgpnmonknjnojddfkpgkljpfnnfckljи любым POST-запросам кapi.stanfordstudies[.]com/app/log. - Stripe OLT опубликовала готовые KQL-запросы для Microsoft Defender и Sentinel для обнаружения этой активности.
Удаление расширения из магазинов решает проблему конкретного инструмента, но не устраняет системный риск. Этот случай демонстрирует конкретную архитектурную угрозу: полностью готовый к работе сборщик данных, прошедший верификацию магазина, встроенный в доверенный популярный инструмент и спроектированный для активации через обычное обновление. Организациям стоит пересмотреть процедуры контроля расширений: проверять наличие спящих путей выполнения кода, новых конечных точек для связи с внешними серверами и возможностей, которые рутинное обновление может добавить после смены владельца расширения.
