Хакри зламали DNS DebugBear для поширення шкідливого коду
Головне за 30 секунд
- Компанія DebugBear закликала клієнтів негайно видалити свій скрипт моніторингу Core Web Vitals через інцидент безпеки.
- Атакувальні особи зламали DNS-записи сервісу через реєстратора доменів, що зачепило щонайменше один вебсайт.
- Кібербезпекова фірма Hudson Rock виявила шкідливий JavaScript у скрипті DebugBear на сайті Polymarket 29 жовтня.
- Шкідливий код використовував авторизовану сесію користувача в браузері, щоб продавати позиції та переказувати кошти з гаманців.
- Власникам сайтів рекомендують видалити вбудований код, завершити активні сесії, скинути паролі та перевірити системи на наявність змін.
Злам DNS-записів DebugBear та інцидент із Polymarket
Компанія DebugBear звернулася до власників вебсайтів із вимогою негайно видалити скрипт моніторингу Core Web Vitals через інцидент у системі безпеки. Відповідну інструкцію компанія оприлюднила 29 жовтня. У наступному оновленні DebugBear повідомила, що зловмисники скомпрометували її DNS-записи через реєстратора доменів. Первинне розслідування показало, що атака була спрямована на вебсайт одного з клієнтів, водночас ознак зламу внутрішніх систем компанії зафіксовано не було. Через інцидент сервіс також втратив можливість отримувати електронну пошту на своєму домені.
Аналіз кібербезпекової фірми Hudson Rock виявив наявність шкідливого JavaScript у середовищі скрипта DebugBear, який використовувався платформою Polymarket 29 жовтня. У звіті про інцидент від 30 жовтня Polymarket підтвердила, що цей скрипт здійснював продаж позицій та переказ коштів із гаманців деяких користувачів. Зловмисники задіяли доступ, який авторизований відвідувач уже мав у своєму браузері, без необхідності вводити пароль.
Що робити власникам сайтів, які використовували DebugBear
Розробникам та командам безпеки сайтів, які використовували моніторинг DebugBear, радять виконати низку обов'язкових кроків. Передусім слід негайно видалити вбудований скрипт Real User Monitoring, перевірити шаблони, плагіни та менеджери тегів, очистити кешовані сторінки й переконатися, що код більше не завантажується.
Також необхідно інвалідувати скомпрометовані сесії та скинути паролі, розпочавши з адміністраторів і привілейованих користувачів, які завантажували уражені сторінки. Слід відкликати потенційно небезпечні облікові дані API. Окрім цього, важливо перевірити системи на наявність несанкціонованих змін, переглянути історію створення акаунтів, зміну прав, шаблонів, плагінів та ін'єкцій скриптів, а також перевести уражений сайт у режим обслуговування із відтермінуванням відповіді через HTTP 503 у разі підтвердження зламу.
