Через DNS DebugBear злоумышленники подменили скрипт мониторинга сайтов

29 октября DebugBear попросила клиентов удалить скрипт Real User Monitoring после атаки на её инфраструктуру. Как пишет Search Engine Journal, злоумышленники изменили DNS-записи компании через регистратора домена, и по адресу скрипта мониторинга оказался доступен вредоносный JavaScript. Предупреждение касается владельцев сайтов, которые подключили DebugBear для отслеживания Core Web Vitals.

Как скрипт мониторинга стал каналом атаки

Real User Monitoring работает через JavaScript, который владелец сайта добавляет на страницу. В примере, приведённом Search Engine Journal, скрипт загружается с cdn.debugbear.com; идентификатор файла зависит от сайта. Пока тег остаётся в шаблоне, плагине или менеджере тегов, браузер посетителя может обратиться за скриптом. Поэтому рекомендация компании — удалить подключение, а не просто перестать смотреть отчёты.

По итогам первоначальной проверки DebugBear сообщила, что атака была направлена на сайт одного клиента. Признаков взлома внутренних систем компания не обнаружила. В том же сообщении она предупредила, что не получает письма, отправленные на её домен; за обновлениями предложила следить через аккаунт DebugBear в X.

О последствиях для одного сайта известно больше. Hudson Rock обнаружила вредоносный JavaScript по адресу скрипта DebugBear, который использовал Polymarket 29 октября. Код искал торговый клиент, уже доступный в браузере вошедшего в аккаунт посетителя. В отчёте Polymarket от 30 октября говорится, что скрипт продал позиции и перевёл средства из кошельков некоторых пользователей. Пароль для этого ему не требовался: он воспользовался доступом, который уже был у авторизованного человека.

Это не означает, что каждый сайт с DebugBear получил тот же код или столкнулся с теми же последствиями. Пока неясно, попадал ли вредоносный JavaScript другим клиентам компании. Найденный вариант был нацелен на торговые аккаунты Polymarket. Но для владельца сайта остаётся вопрос: что сможет сделать подменённый скрипт, если его загрузит посетитель с уже открытой сессией?

Что проверить владельцам сайтов и командам

Первое действие для сайтов с Real User Monitoring от DebugBear — удалить тег. Разработчикам стоит проверить не только код страниц, но и шаблоны, плагины и менеджеры тегов, затем очистить кешированные страницы и убедиться, что браузер больше не загружает скрипт. Маркетологам и SEO-командам, которые следят за показателями скорости, важно передать предупреждение тем, кто отвечает за сайт и его безопасность: одного отключения отчёта в рабочих задачах недостаточно.

Удаление тега останавливает новые загрузки, но не отменяет действия, которые могли произойти раньше. Поэтому следующая задача — выяснить, чьи учётные записи могли оказаться под угрозой, пока скрипт был активен. В первую очередь нужно проверить администраторов и других пользователей с повышенными правами, которые открывали затронутые страницы, завершить потенциально раскрытые сессии, сменить пароли и отозвать учётные данные API, которые могли оказаться под угрозой. Если установить круг затронутых пользователей нельзя, сброс следует расширить. Отдельно надо убедиться, что старые сессии действительно перестали работать: смена пароля сама по себе может их не закрыть.

Дальше — поиск несанкционированных изменений. Командам рекомендуют сверить создание аккаунтов, изменения прав, историю менеджера тегов, шаблоны, плагины и добавленные скрипты с заведомо чистой версией. В журналах нужно искать необычные входы, новые учётные записи, изменения файлов и неожиданные транзакции за период, когда скрипт был подключён. При поиске пригодятся индикаторы вредоносного кода из анализа The Layman Security. Подозрительные действия нужно расследовать, чужой доступ — закрыть, а подтверждённые несанкционированные изменения — отменить. Эти проверки не означают, что на других сайтах уже обнаружены бэкдоры: задача — не пропустить возможное продолжение атаки.

Если компрометация подтверждена, источник советует изолировать сайт и показывать статическую страницу обслуживания с ответом HTTP 503. После этого — удалить вредоносный код или восстановить чистую резервную копию, проверить отсутствие оставленного доступа и лишь затем возвращать сайт в работу. Короткое отключение тега не заменяет расследование, если в журналах уже видны подозрительные действия.

Моё мнение: скрипт для скорости тоже требует внимания

Я привык смотреть на мониторинг как на способ понять, где страница тормозит у реальных людей. Но эта история напоминает: код для измерения скорости всё равно выполняется в браузере посетителя. И если он подменён, аккуратная сетка и хороший показатель Core Web Vitals не помогут человеку, у которого уже открыт аккаунт. Получается довольно злая ирония для инструмента, призванного делать сайт лучше.

Я бы не делал из этого вывод, что от сторонних скриптов нужно отказаться на каждом сайте. Зато при подключении очередного тега хочу яснее понимать, где он прописан и как его быстро убрать отовсюду, включая кеш. А если есть признаки чужих действий, остановиться на фразе «мы удалили скрипт» — примерно как вытереть воду с пола, не проверив, закрыт ли кран.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript via @sejournal, @vahandev www.searchenginejournal.com

Об авторе

Никос П. Георгиу

начинающий UI-дизайнер

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

Все публикации автора