DebugBear попросила клиентов удалить её скрипт Real User Monitoring, используемый для отслеживания Core Web Vitals. Компания выпустила эту инструкцию после инцидента безопасности, связанного с её инфраструктурой. SEO-командам следует передать это разработчикам и специалистам по безопасности, которые должны удалить скрипт и проверить несанкционированный доступ или изменения, сделанные за время его активности.
Что произошло
В обновлении от 30 октября DebugBear сообщила, что атакующие скомпрометировали её DNS-записи через регистратора домена. По данным компании, первоначальное расследование показало, что атака была нацелена на сайт одного клиента. DebugBear сообщила, что нет признаков компрометации её внутренних систем. В том же обновлении компания сообщила, что не может получать почту, отправленную на её домен; обновления клиенты могут отслеживать в аккаунте DebugBear в X.
Анализ компании Hudson Rock обнаружил вредоносный JavaScript по URL скрипта DebugBear, который использовал Polymarket, 29 октября. Код искал торговый клиент, уже доступный в браузере авторизованного пользователя. Отчёт Polymarket об инциденте от 30 октября подтвердил, что скрипт продавал позиции и переводил средства с кошельков некоторых пользователей. Он использовал доступ, который уже имел авторизованный посетитель, и не требовал пароля пользователя.
Что делать владельцам сайтов на DebugBear
- Немедленно удалить встраиваемый скрипт DebugBear Real User Monitoring: проверить шаблоны, плагины и менеджеры тегов, очистить кэшированные страницы и убедиться, что скрипт больше не загружается.
- Аннулировать скомпрометированные сессии и сбросить пароли, начиная с администраторов и других привилегированных пользователей, загружавших затронутые страницы; отозвать потенциально скомпрометированные API-учётные данные. Если нельзя установить, какие пользователи системы были затронуты, расширить сброс. Подтвердить, что старые сессии отклоняются, поскольку смена пароля может не аннулировать существующие сессии.
- Проверить несанкционированные изменения и закрепление в системе: создание аккаунтов, изменения разрешений, историю менеджера тегов, шаблоны, плагины и внедрённые скрипты — в сравнении с известной чистой версией. Проверить, не получили ли атакующие доступ к системам и не установили ли бэкдор для последующего доступа. Это проверки, а не подтверждённые находки у других клиентов.
- Найти затронутые аккаунты и отменить несанкционированные изменения: проверить логи на необычные входы, новые аккаунты, изменённые файлы и неожиданные транзакции за время активности скрипта. Использовать индикаторы вредоносного кода из анализа The Layman Security для поиска.
- При подтверждённой компрометации перевести сайт в режим обслуживания: изолировать затронутый сайт и показывать статическую страницу обслуживания с HTTP-ответом 503. Силами команды безопасности очистить сайт или восстановить известную чистую резервную копию и убедиться, что вредоносный код и бэкдоры удалены, прежде чем снова запускать сайт.
Риски для других сайтов
Извлечённая полезная нагрузка была нацелена на торговые аккаунты Polymarket. Атакующие использовали скомпрометированный скрипт DebugBear, чтобы добраться до этой высокоценной цели, и похитили средства. Другие высокоценные сайты также могли быть целями. Пока неясно, получали ли другие клиенты DebugBear вредоносный код.
Удаление тега мониторинга предотвращает новые загрузки, но не отменяет несанкционированные действия и не удаляет то, что атакующий мог уже внедрить.
Источник: https://www.searchenginejournal.com/debugbear-rum-attack-seo-site-owner-actions/595412