Frontend-фишинг в качестве начального вектора атаки Lumma Stealer

Злоумышленники различными способами направляли пользователей на созданные/скомпрометированные web-страницы, в которые был внедрен вредоносный js-код. Код может быть внедрен в frontend-приложение после взлома сервера либо в одной из зависимостей js-проекта (supply chain attack).

Скрипт производил редирект пользователя на страницу с поддельной Google reCAPTCHA, которая для доказательства "человечности" просила пользователя открыть утилиту Windows Run 🪟 (Win + R), нажать Ctrl + V и Enter. При этом скрипт записывал в буфер обмена powershell-команду, загружавшую и выполняющую вредоносное ПО 🦠.

Атака основана на том, что js-код активной вкладки браузера может записывать данные в буфер обмена без запроса дополнительных разрешений.

Интересно, что для записи вредоносной команды в буфер обмена злоумышленники использовали не современный Clipboard API, а устаревшую функцию Document.execCommand('copy'), которая до сих пор поддерживается браузерами.

Как FAST-анализатор поможет обнаружить подобные вредоносные действия?

При очередном сканировании 🔎, эмулируя действия пользователя, FAST:

🔹Обнаружит несанкционированное изменение js-кода.
🔹Обнаружит редирект на страницу злоумышленника (сетевой запрос на неразрешенный хост) (в случае если фальшивая капча показывается на внешней странице).
🔹Обнаружит iFrame (если капча показывается во фрейме).
🔹Обнаружит использование неразрешенной WebApi-функции Document.execCommand('copy').
🔹Показ капчи прервет/нарушит выполнение FAST-анализатором сценария сканирования - собранные метрики будут значительно отличаться от предыдущего скана - будет зафиксирована аномалия.
🔹Если вредоносные действия выполнялись только при определенных условиях, будут обнаружены дополнительные вызовы функций определения часового пояса, языка браузера, семейства браузера, размера окна и т.п.

@FrontSecOps

Компрометация библиотеки lottie-player (LottieFiles)

Lottie-player - популярная библиотека и сервис для создания и встраивания на сайты производительных векторных анимаций. Lottie-player загружается из npm-репозитория около 90 000 раз в неделю.

Supply chain attack

Злоумышленники провели фишинговую атаку на одного из разработчиков библиотеки и похитили токен🔑 от npm-репозитория. Далее 30 октября 2024 злоумышленники опубликовали 3 новых версии библиотеки (2.0.5, 2.0.6, 2.0.7) с добавленным вредоносным кодом 🦠. Новые версии закэшировались сторонними CDN и отдавались по URL с тегом latest.

Вредоносный код показывал всплывающее окно 🌐 с предложением подключить криптовалютный кошелек. У пользователей, которые кликали на кнопки и выполняли дальнейшие действия, похищалась криптовалюта, NFT и т.д. 🌐

Первые жалобы появились почти сразу. Разработчики удалили из npm версии либы с вредоносным кодом и выпустили версию 2.0.8 (равную по содержимому 2.0.4), а также обратились в CDN-ы для удаления закэшированных вредоносных версий.

Кто пострадал?
1. Frontend-приложения, в которых библиотека была подключена из сторонних CDN с тегом latest (очень плохая практика⚠️).
2. Приложения, при сборке которых из npm загружалась библиотека версий 2.0.5, 2.0.6, 2.0.7 в период 30-31 октября 2024.

Говорят, у кого-то украли криптовалюту на 723 000 💲

При клике по кнопкам во всплывающем окне устанавливалось соединение WebSocket c хостом wss://castleservices01[.]com/ws

Как можно было обнаружить?

FAST-анализатор
При FAST-анализе🔎 (например, DPA FAST Analyzer), в результате отображенного всплывающего окна, произошло бы нарушение выполнения пользовательского UseCase. Cобранные метрики будут значительно отличаться от предыдущего скана - будет зафиксирована аномалия📈

Frontend Observability Platform (FOP)
Для обнаружения вредоносного поведения кода при нетипичных действиях пользователя (действия, которые невозможно смоделировать на этапе разработки) (например, клики по фишинговому баннеру🤒) используются решения класса FOP (например, DPA Frontend Observability Platform). В данной атаке FOP обнаружил бы в браузерах пользователей соединения WebSocket с неразрешенным хостом🤒

Совместное использование FAST и FOP делает frontend-приложения безопасными на всех этапах ЖЦ✔️

@FrontSecOps

Supply chain attack - solana/web3.js

Клиентская js-библиотека solana/web3.js используется в приложениях Solana dapps, работающих с блокчейном Solana. Библиотека загружается из npm более 300 000 раз в неделю.

Ситуация похожа на компрометацию lottie-player: фишинговая атака🤒 на разработчика 🔜 похищение токена от npm-репозитория 🔜 публикация 2 декабря 2024 года новых версий библиотеки с добавленным вредоносным кодом🦠 (версии 1.95.6, 1.95.7).

Вредоносный код похищал в приложении приватные ключи🔑 и отправлял на хост злоумышленника (https://sol-rpc[.]xyz) с помощью функции fetch()

Версии с вредоносным кодом были доступны в npm около 5 часов (3:20pm UTC - 8:25pm UTC 2 декабря). Разработчики признали факт компрометации и выпустили чистую версию 1.95.8

Сумма похищенных средств оценивается в 160 000💲

Отправка данных на неразрешенный хост - один из наиболее критичных признаков🤒 наличия вредоносного кода в js-зависимостях, выявляемых FAST-анализатором при выполнении поведенческого анализа frontend-приложений🔎

@FrontSecOps

GA на сайтах + РКН

Вчера Алексей Березовой в своем канале Как устроены медиа отметил, что редакциям стали поступать требования от Роскомнадзора об удалении с сайтов Google Analytics.

Дополню. Не только СМИ, но и обычным компаниям. На скрине требование, которое получил интернет-магазин.

Сайты, на которых установлен счетчик, возможно, находит нейронка РКН в автоматическом режиме. К требованию РКН приложен скриншот исходного кода сайта, где Analytics выделен и подчеркнут.

Если сайт попадет под мониторинг Роскомнадзора, то требованием об удалении только одного счетчика, конечно, не ограничатся. Проверят абсолютно все, что касается обработки персональных данных на сайте: политики, согласия, формы.

Отмечу, что за такие истории не всегда сразу штрафуют. Наблюдаю лояльное отношение Роскомнадзора — предоставляется 10-дневный срок для устранения замечаний или выражения несогласия. Главное, не пропустить письмо с уведомлением.

➡️Вот что еще нужно знать про метрики на сайтах

#ПерсональныеДанные #Интернет #СМИ

РКН рассылает компаниям требование удалить с сайтов скрипт Google Analytics из-за незаконной трансграничной передачи персональных данных (ПД) пользователей

С 2023 года трансграничная передача ПД без уведомления Роскомнадзора запрещена⛔️

РКН использует риск-ориентированный подход 🏓 (ПП N1046 от 29.06.2021) при проведении контрольных мероприятий. На уровень риска влияют группы тяжести потенциальных негативных последствий от нарушений.

Что влияет на группу тяжести?
🆘Сбор ПД, с использованием БД, находящихся за пределами РФ.
🆘Сбор ПД, с использованием иностранных программ и сервисов.
🆘Трансграничная передача ПД на территорию иностранных государств.

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

Как проверяют?

Сотрудник РКН открывает сайт компании 🖥, в браузере в DevTools смотрит, какие скрипты размещены на странице, на вкладке Network смотрит, на какие хосты / в какие страны отправляются сетевые запросы. Затем этим данные сверяются с Политикой конфиденциальности📄, размещенной на сайте и всплывающими уведомлениями-согласиями на передачу ПД третьим лицам, трансграничную передачу, перечнем третьих лиц и т.д.

В случае несоответствия компании может быть направлено предостережение/требование, а при неисполнении проведена проверка/штраф🪙 и другие регуляторные риски для бизнеса 🚓. Вероятно, этот процесс уже автоматизирован, поэтому стали рассылать массовые уведомления.

Проблема не только в Google Analytics

Существует множество внешних сервисов/скриптов, используемых на сайтах (Google Tag Manager, Roistat, Criteo, Google Ads и другие), отправляющих данные на зарубежные серверы. По результатам наших аудитов и пилотов FAST-анализатора мы видим, что даже российские системы аналитики иногда передают данные🪪 за пределы РФ.

Это касается только личных кабинетов/интернет-магазинов?

Нет. Даже если на вашем сайте (frontend-приложении) нет ПД в явном виде (ФИО, телефон, данные паспорта и т.д.), цифровой отпечаток браузера, идентификаторы записанные в cookie 👍, профиль поведения пользователя являются сведениями, относящимися к определяемому физическому лицу, и регулятор признает их персональными данными 🪪

Для снижения регуляторных и реальных рисков утечки ПД в компании должны быть внедрены:
1️⃣ Политика безопасности frontend-приложений (сайтов, личных кабинетов и т.д.)
2️⃣ Связка этой политики с Политикой обработки ПД и поддержкой актуальности согласий/политик на сайтах компании.
3️⃣ Процесс управления изменениями (согласование добавления на сайт новых скриптов, систем аналитики, счетчиков и т.д., согласование хостов/стран/получателей данных, отражение их в согласиях, политиках на сайте).
4️⃣ Инструмент для контроля и уведомления об инцидентах. Любые политики бессмысленны без контроля. Ручной анализ frontend-приложений имеет низкую достоверность и является весьма трудозатратным. Для эффективного контроля можно использовать DPA FAST Analyzer.

FAST-анализатор:
✅ Проводит глубокую инвентаризацию всех скриптов/систем аналитик в рантайме браузера 🟡
✅ Отображает историю изменений скриптов для ретроспективного анализа
✅ Обнаруживает все отправки данных на сторонние серверы (системы аналитики и другие)
✅ Применяет к обнаруженным результатам политику по принципу белого списка (все, что не согласовано с ИБ, юристами, комплаенс - является инцидентом). Можно контролировать, на какие хосты/страны отправляются данные
✅ Уведомляет об обнаруженных инцидентах 🆘
✅ Может использоваться как в DevSecOps в качестве Security Gate, так и для сканирования frontend-приложения (сайта, личного кабинета, CRM, HRM и т.п.) в продакшене

Напишите мне 📱, мы проведем для вас пилот DPA FAST Analyzer, покажем всё, что происходит на сайте/frontend-приложении, обнаружим трансграничные передачи данных для предотвращения утечек и штрафов РКН 🛡

@FrontSecOps

Frontend-фишинг с использованием JS Notification / Push API

Эти API предоставляют js-коду 📱 возможность показывать нативные уведомления браузера на устройстве пользователя. Push API (в отличии от Notification API) может показывать уведомления даже при закрытой вкладке браузера ⚠️, а на мобильных устройствах даже при закрытом браузере, поэтому рассмотрим именно его.

Исходные данные

Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).

В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.

Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).

Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт⚠️. Это открывает безграничные возможности для фишинга 🤒

⚠️С вашего счета произведен перевод денег..
⚠️Заказ № 123456 оформлен, сумма 14 793 руб., дата доставки..
⚠️Обнаружен вирус на устройстве, выберите действие..
⚠️Ваш почтовый ящик заблокирован..
⚠️Кто-кто входит в ваш аккаунт..

Далее - кража учетных данных 🪪, загрузка вредоносного вложения с эксплойтом 💣 и т.п.

На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.

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

Злоумышленники "хотят" наш frontend больше 💰, чем мы думаем… А уязвимости браузеров 📱 🌐 делают frontend-приложения идеальной точкой проникновения на устройства пользователей.

Как защититься?

🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование

@FrontSecOps