DebugBear рекомендував клієнтам видалити скрипт Real User Monitoring для відстеження Core Web Vitals після інциденту безпеки. Попередження від 29 жовтня стосується власників сайтів, які використовують цей скрипт.
Компанія повідомила, що зловмисники отримали доступ до її DNS-записів через реєстратора домену. За попередніми результатами розслідування, атака була спрямована на сайт одного клієнта; ознак компрометації внутрішніх систем DebugBear компанія не виявила.
У тому самому оновленні DebugBear повідомив, що не може отримувати листи, надіслані на його домен. Клієнтам запропонували стежити за повідомленнями компанії в X.
Атака на користувачів Polymarket
Фахівці Hudson Rock виявили 29 жовтня шкідливий JavaScript за адресою скрипта DebugBear, який використовував Polymarket. Код шукав торговельний клієнт, доступний у браузері авторизованого користувача.
У звіті від 30 жовтня Polymarket підтвердив, що скрипт продавав позиції та переказував кошти з гаманців деяких користувачів. Він використовував доступ уже авторизованого відвідувача і не потребував його пароля.
Виявлений код був націлений на торговельні акаунти Polymarket. Інші цінні для нападників сайти також могли стати ціллю, але поки неясно, чи отримали шкідливий код інші клієнти DebugBear.
Що рекомендується власникам сайтів
Командам розробки та безпеки слід негайно видалити скрипт DebugBear Real User Monitoring, перевіривши шаблони, плагіни та менеджери тегів. Після очищення кешу сторінок необхідно переконатися, що скрипт більше не завантажується.
Рекомендується завершити потенційно скомпрометовані сеанси та скинути паролі, починаючи з адміністраторів та інших привілейованих користувачів, які відкривали відповідні сторінки. Також слід відкликати потенційно розкриті облікові дані API. Якщо визначити коло зачеплених системних користувачів неможливо, скидання варто поширити ширше. Важливо перевірити, що старі сеанси справді відхиляються: зміна пароля не завжди їх завершує.
Командам слід перевірити створення акаунтів, зміни прав, історію менеджера тегів, шаблони, плагіни та впроваджені скрипти, порівнявши їх із завідомо чистою версією. Потрібно з’ясувати, чи отримали нападники доступ до систем і чи залишили бекдор. Це рекомендації щодо перевірки, а не підтверджені випадки в інших клієнтів.
Для пошуку зачеплених акаунтів і несанкціонованих змін рекомендується вивчити журнали за період активності скрипта: незвичні входи, нові акаунти, змінені файли та несподівані транзакції. Пошук можна спрямувати за допомогою індикаторів шкідливого коду з аналізу The Layman Security. Підозрілу активність слід розслідувати, несанкціонований доступ відкликати, а підтверджені шкідливі зміни скасувати.
Якщо компрометацію сайту підтверджено, його рекомендується ізолювати та перевести в режим обслуговування зі статичною сторінкою і відповіддю HTTP 503. Команда безпеки має очистити сайт або відновити завідомо чисту резервну копію, а перед відновленням роботи переконатися, що шкідливий код і бекдори видалено.
Видалення тега моніторингу запобігає новим завантаженням скрипта, але не скасовує вже вчинених дій і не видаляє код, який нападники могли залишити раніше.
Коментарів поки немає. Почніть обговорення.