Через 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-дизайнер-початківець

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

Усі публікації автора