Mastodon Mastodon Mastodon Mastodon

Як популярне розширення ModHeader стало інструментом для прихованого стеження

Photo of author

CyberSecureFox Editorial Team

Опубліковано:

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 для виявлення цієї активності.

Видалення розширення з магазинів розв’язує проблему конкретного інструмента, але не усуває системний ризик. Цей випадок демонструє конкретну архітектурну загрозу: повністю готовий до роботи збирач даних, що пройшов верифікацію магазину, вбудований у довірений популярний інструмент і спроєктований для активації через звичайне оновлення. Організаціям варто переглянути процедури контролю розширень: перевіряти наявність сплячих шляхів виконання коду, нових кінцевих точок для зв’язку із зовнішніми серверами та можливостей, які рутинне оновлення може додати після зміни власника розширення.


CyberSecureFox Editorial Team

Редакція CyberSecureFox висвітлює новини кібербезпеки, уразливості, malware-кампанії, ransomware-активність, AI security, cloud security та security advisories вендорів. Матеріали готуються на основі official advisories, даних CVE/NVD, сповіщень CISA, публікацій вендорів і відкритих звітів дослідників. Статті перевіряються перед публікацією та оновлюються за появи нових даних.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.