Управляющее резюме
- Группа Akamai Security Intelligence Group обнаружила кампанию веб-скимминга Magecart, нацеленную на обширный список веб-сайтов, включая крупные организации в пищевой и розничной отраслях.
- Эта кампания выделяется тремя продвинутыми методами сокрытия, один из которых мы никогда раньше не видели, а именно, манипулирование страницей ошибки 404 по умолчанию на веб-сайте для сокрытия вредоносного кода, что создает уникальные проблемы для обнаружения и устранения последствий.
- Два других метода запутывания демонстрируют развивающуюся тактику, которую злоумышленники используют, чтобы избежать обнаружения и удлинить цепочку атак.
- Поскольку веб-скимминг-атаки становятся все более изощренными, организации должны сохранять бдительность и изучать передовые подходы для защиты от этих развивающихся угроз.
Введение
Новая, сложная и скрытая кампания по веб-скиммингу Magecart была нацелена на веб-сайты Magento и WooCommerce. Некоторые из жертв этой кампании связаны с крупными организациями пищевой и розничной торговли.Согласно обнаруженным нами доказательствам, эта кампания действовала уже пару недель, а в некоторых случаях и дольше. Эта кампания сумела удивить нас техникой сокрытия высокого уровня, с которой мы ранее не сталкивались.
Новая кампания
Атаки Magecart обычно начинаются с использования уязвимостей на целевых веб-сайтах или с заражения сторонних сервисов, которые используют эти веб-сайты. В этой кампании все обнаруженные нами веб-сайты-жертвы подвергались непосредственному использованию, поскольку фрагмент вредоносного кода был внедрен в один из их собственных ресурсов.В некоторых случаях вредоносный код был вставлен в HTML-страницы; в других случаях он был скрыт в одном из сторонних скриптов, загруженных как часть веб-сайта.
Как и во многих других кампаниях Magecart, инфраструктура атак этой кампании состоит из трех основных частей: загрузчика, вредоносного кода атаки и кражи данных (рис. 1).
- Загрузчик — короткие, непонятные фрагменты кода JavaScript, отвечающие за загрузку полного вредоносного кода атаки.
- Вредоносный код атаки . Основной код JavaScript, выполняющий атаку; он обнаруживает конфиденциальные входные данные, считывает данные, нарушает процесс оформления заказа и внедряет поддельные формы
- Эксфильтрация данных . Метод, используемый для передачи украденных данных на сервер управления и контроля (C2) злоумышленника.
Рис. 1. Инфраструктура атаки Magecart
Целью разделения атаки на три части является сокрытие атаки таким образом, чтобы ее было сложнее обнаружить. Это позволяет активировать полный поток атаки только на специально предназначенных страницах; то есть из-за мер по запутыванию, использованных злоумышленником, активация полного потока атаки может произойти только там, где злоумышленник намеревался ее выполнить. Это делает атаку более скрытной и ее труднее обнаружить службами безопасности и внешними инструментами сканирования, которые могут быть установлены на целевом веб-сайте.
Хотя большинство кампаний Magecart имеют сходство с точки зрения их хода и этапов, одна кампания отличается от другой различными методами сокрытия, которые используют злоумышленники. Эти методы используются для сокрытия инфраструктуры атаки; скрыть следы; усложнить обнаружение и обратный инжиниринг; и, в конечном итоге, продлить атаку.
3 варианта кампании
Мы обнаружили три различных варианта этой кампании, демонстрирующие эволюцию атаки и улучшения, которые злоумышленники внесли с течением времени, чтобы предотвратить обнаружение и смягчение последствий этой кампании:- Первые две вариации очень похожи, с небольшими различиями в загрузочной части.
- Третья версия уникальна, поскольку злоумышленники использовали стандартную страницу ошибки 404 веб-сайта, чтобы скрыть свой вредоносный код; это творческая техника сокрытия, которую мы никогда раньше не видели.
Вариант первый
Наше исследование началось, когда мы заметили несколько подозрительных фрагментов кода, обнаруженных нашими инструментами мониторинга угроз, на веб-сайте крупной компании. Проанализировав эти фрагменты, мы обнаружили, что это были вредоносно закодированные загрузчики JavaScript, которые все еще присутствовали и были активны на веб-сайте. Это открытие побудило нас провести дальнейшее расследование, раскрыв всю кампанию с ее вариациями и влиянием на многочисленные веб-сайты.Вариант первого погрузчика: верхушка айсберга
Скиммер успешно внедрил на эксплуатируемый веб-сайт искаженный HTML-тег изображения с атрибутом onerror (рис. 2). Этот атрибут содержит запутанный фрагмент вредоносного кода загрузчика в кодировке Base64. Намеренно пустой атрибут src тега изображения предназначен для предотвращения сетевых запросов и запуска выполнения встроенного обратного вызова при ошибке, содержащего запутанный вредоносный фрагмент кода JavaScript.Использование тегов изображений для выполнения кода JavaScript — менее распространенный и более сложный метод. Это может помочь скиммеру обойти такие меры безопасности, как внешние сканеры, которые обычно анализируют сетевой трафик и которые не срабатывают в данном конкретном случае. Запутанный код будет выполняться в контексте страницы и работать так, как если бы это был собственный собственный скрипт, инициированный самой страницей.
Рис. 2. Первый вариант загрузчика — неправильно отформатированный HTML-тег изображения с атрибутом onerror, содержащий вредоносный код загрузчика.
Раскодированный код загрузчика — среда выполнения
Как только запутанный код в кодировке Base64 выполняется во время выполнения, он преобразуется в простой JavaScript и становится ответственным за инициацию канала WebSocket (рис. 3). Этот канал служит двунаправленной связью между браузером и сервером C2 злоумышленника.Использование WebSockets в атаках Magecart наблюдалось в нескольких недавних кампаниях. WebSocket считается более тихим и гибким методом связи, позволяющим злоумышленнику использовать один сетевой канал для различных целей. Это включает в себя отправку различных частей атаки с сервера C2 в браузер (и наоборот), а также облегчение действий по краже данных в определенных сценариях.
Еще один заслуживающий внимания аспект кода — обнаружение ботов, которое проверяет, находится ли пользовательский агент под автоматическим контролем. Если это так, код прекращает свое выполнение. Это умная технология защиты от ботов, направленная на обход внешних сканеров безопасности и песочниц, которые потенциально могут обнаружить атаку.
Рис. 3. Декодированный во время выполнения код JavaScript первого варианта загрузчика.
Поток связи через веб-сокет
Как только канал WebSocket установлен, первое сообщение отправляется с сервера C2 злоумышленника в браузер. Это сообщение передается в виде строки в кодировке Base64, содержащей однострочную команду JavaScript, которая инструктирует браузер отправить обратно текущий URL-адрес страницы.Цель этого шага — позволить серверу C2 определить, является ли текущая страница страницей оформления заказа (конфиденциальной) или любой другой страницей, не связанной с оформлением заказа. Таким образом, злоумышленник может соответствующим образом скорректировать следующие шаги.
Эта простая проверка на стороне сервера позволяет злоумышленнику активировать атаку только на соответствующих целевых страницах, тем самым избегая потенциального воздействия на неконфиденциальные страницы. Это еще один пример, который подчеркивает усилия, которые скиммер предпринимает, чтобы избежать обнаружения службами безопасности и внешними сканерами.
Когда сервер C2 идентифицирует URL-адрес страницы оформления заказа, процесс переходит к следующему этапу. На этом этапе в браузер отправляется еще одно сообщение. Это длинная строка в кодировке Base64, содержащая весь код атаки. После декодирования обнаруживается длинный и запутанный код JavaScript (рис. 4).
Этот код отвечает за выполнение различных вредоносных действий на целевой конфиденциальной странице с целью считывания конфиденциальных личных данных и данных кредитной карты пользователя и их передачи обратно на сервер C2 скиммера.
Последующие запутанные сообщения об утечке данных, содержащие конфиденциальные украденные данные, собранные вредоносным кодом, отправляются из браузера на сервер C2. Как упоминалось ранее, использование одного и того же канала WebSocket как для загрузки всего вредоносного кода, так и для извлечения украденных данных делает процесс более тихим и требует меньше сетевых запросов, чем более традиционные методы связи, такие как XHR, выборка или запросы ресурсов HTML.
Рис. 4. Работа WebSocket на страницах оформления заказа
Вариант второй
Второй вариант погрузчика: Та же дама, в новом платье.
Основное различие между первым и вторым вариантом заключается в компоненте загрузчика. Во втором варианте скиммер вставляет встроенный скрипт с фрагментом кода, который очень похож на фрагмент кода Meta Pixel, известного сервиса отслеживания активности посетителей Facebook, с несколькими дополнительными строками внутри него (рис. 5).Эти добавленные строки являются фактической частью загрузчика, в то время как окружающий их код Meta Pixel является вводящей в заблуждение прикрытием, создающим впечатление, будто это законный и не вызывающий подозрений фрагмент кода.
Этот метод сокрытия, благодаря которому фрагменты вредоносного кода выглядят как известные сервисы, такие как Google Tag Manager или Facebook, приобрел популярность в недавних кампаниях Magecart. Это позволяет скиммерам уклоняться от статического анализа внешними сканерами и исследователями.
Рис. 5. Второй вариант загрузчика — встроенный скрипт, замаскированный под фрагмент кода Meta PIxel, внутри которого находится вредоносный загрузчик.
Запрос изображения
Когда мы внимательно проверили подозрительные строки в поддельном фрагменте кода Meta Pixel, оказалось, что он извлекает изображение PNG из собственного каталога веб-сайта. Сетевой запрос оказался типичным запросом невинного изображения, размещенного на сайте. Однако когда мы рассмотрели фактическое содержание этого изображения, стало ясно, что оно не так безобидно, как казалось (рис. 6).
Вредоносный фрагмент кода JavaScript в двоичном изображении
Двоичные данные изображения PNG содержат строку в кодировке Base64, добавленную в конец двоичного файла изображения (рис. 7). Затем эта строка извлекается, декодируется и выполняется фрагментом кода загрузчика (рис. 8). Декодированная строка представляет собой фрагмент кода JavaScript, идентичный тому, который находится внутри атрибута onerror загрузчика в первом варианте.Последующие этапы потока остаются неизменными. Этот фрагмент кода преобразуется в простой код JavaScript во время выполнения, код инициирует канал WebSocket к серверу C2 злоумышленника, а остальная часть последовательности выполняется, как описано ранее.
Рис. 7. Бинарные данные изображения, содержащего скрытый вредоносный код.
Рис. 8. Вредоносный код, изначально закодированный в Base64 и скрытый внутри изображения, становится видимым после декодирования.
Вариант третий
Теперь поговорим о самом приятном. Хотя мы видели подобные атаки, эта уникальна и очень нас удивила.Третий вариант загрузчика: Тот же, тот же, но совершенно другой.
На первый взгляд этот загрузчик похож на загрузчик из второго варианта, но вы увидите (как и мы), что это совершенно другой сценарий. В некоторых случаях этот загрузчик замаскирован под фрагмент кода Meta Pixel, как показано во втором варианте (рис. 9). Но в других случаях он внедряется в случайные встроенные скрипты на странице (рис. 10).Первым примечательным аспектом этого загрузчика является запрос на выборку по относительному пути, называемому «значки».
Рис. 9. Загрузчик третьего варианта — вредоносный фрагмент кода, скрытый внутри фрагмента кода, имитирующего внешний вид Meta Pixel.
Ошибка 404? Действительно?
После выполнения загрузчика атака отправляет запрос на выборку в /icons , который представляет собой относительный путь, который на самом деле не существует. Этот запрос привел к ошибке «404 Not Found» (рис. 11). Анализ HTML-кода, возвращенного в ответе, показал, что это страница 404 веб-сайта по умолчанию (рис. 12). Это сбивало с толку и заставило нас задуматься, не активен ли скиммер на найденных нами веб-сайтах-жертвах.
Рис. 11. Запрос, инициированный загрузчиком по несуществующему пути, который возвращает ошибку 404.
Рис. 12: HTML-код страницы ошибок по умолчанию
Никогда не недооценивайте погрузчика
Мы сделали шаг назад, повторно проанализировали загрузчик и нашли недостающую часть головоломки. Загрузчик содержал совпадение регулярного выражения для строки «COOKIE_ANNOT», которая должна была быть выполнена на странице с ошибкой 404, возвращенной как часть запроса значков.Итак, мы искали эту строку в возвращенном HTML-коде 404, и вуаля! Мы обнаружили комментарий, спрятанный в конце страницы и содержащий строку «COOKIE_ANNOT» (рис. 14). Рядом с этой строкой была объединена длинная строка в кодировке Base64. Эта закодированная строка представляет собой весь запутанный код атаки JavaScript. Загрузчик извлекает эту строку из комментария, расшифровывает ее и выполняет атаку, призванную украсть введенную пользователем личную информацию.
Мы смоделировали дополнительные запросы к несуществующим путям, и все они вернули одну и ту же страницу с ошибкой 404, содержащую комментарий с закодированным вредоносным кодом. Эти проверки подтверждают, что злоумышленник успешно изменил страницу ошибок по умолчанию для всего сайта и скрыл на ней вредоносный код!
Рис. 13: Вариант загрузчика 3 — совпадение регулярного выражения для строки «COOKIE_ANNOT».
Рис. 14. Вредоносный закодированный комментарий, скрытый в HTML-коде страницы ошибки.
Эксфильтрация данных
Поддельная форма
В отличие от первого и второго вариантов, в третьем варианте злоумышленники использовали другой общий метод кражи данных — внедрение поддельной формы (рис. 15). Этот метод обычно используется, когда у скиммера нет доступа к конфиденциальным данным.Это может произойти, если веб-сайт использует стороннюю платежную службу, которая реализует форму оплаты в стороннем iframe или на внешней странице. Чтобы обойти такие сценарии, злоумышленник создает поддельную форму, очень похожую на исходную форму платежа, и накладывает ее — метод, который набирает все большую популярность. Именно так происходит утечка украденных данных в третьем варианте.
Рис. 15. Поддельная форма, внедренная вредоносным кодом.
Когда пользователь отправляет данные в поддельную форму злоумышленника, появляется ошибка, поддельная форма скрывается, отображается исходная форма платежа, и пользователю предлагается повторно ввести свои платежные данные (рис. 16).
Рис. 16. Поддельная форма скрыта, и пользователю предлагается повторно ввести свои данные.
Запрос изображения с украденными данными
Отправка поддельной формы инициирует сетевой запрос изображения к серверу C2 злоумышленника, передавая всю украденную личную информацию и информацию о кредитной карте в виде строки в кодировке Base64 в параметре запроса (рис. 17). При декодировании эта строка раскрывает истинную цель запроса, и весь ход атаки становится ясным.
I]Рис. 17. Сетевой запрос изображения с украденными данными, включенными в строковый параметр запроса в кодировке Base64.[/I]
Уроки, извлеченные из третьего варианта: случай 404
Эта техника сокрытия является весьма инновационной, чего мы не видели в предыдущих кампаниях Magecart. Идея манипулирования страницей ошибки 404 по умолчанию на целевом веб-сайте может предложить участникам Magecart различные творческие возможности для улучшения сокрытия и уклонения.В некоторых выявленных нами случаях вредоносный загрузчик уже был удален со страниц затронутых веб-сайтов на момент написания статьи. Однако вредоносный комментарий на странице 404 по умолчанию остался, что потенциально позволяет скиммеру легко возобновить атаку. Это подчеркивает сложность обнаружения и важность смягчения последствий такого подхода.
Запрос к первому пути, ведущему на страницу 404, — это еще один метод обхода, который позволяет обходить заголовки политики безопасности контента и другие меры безопасности, которые могут активно анализировать сетевые запросы на странице. Это, несомненно, считается одной из наиболее сложных стратегий Magecart, с которыми мы столкнулись в последнее время.
Защита и соблюдение требований на стороне клиента Akamai в сравнении со скиммером
В рамках исследования этой кампании мы смоделировали работу этого скиммера с помощью Akamai Client-Side Protection & Compliance — нашего решения, которое анализирует поведение выполнения JavaScript во время выполнения для защиты от угроз JavaScript и смягчения последствий атак на стороне клиента.Решение успешно обнаружило сложный скиммер и вызвало событие высокой степени серьезности для немедленного устранения последствий. В реальном сценарии, в котором защита и соответствие требованиям на стороне клиента включены на конкретной веб-странице, на рис. 18 показано предупреждение, которое получит владелец веб-сайта, чтобы он мог быстро исследовать угрозу и отреагировать в режиме реального времени, используя различные варианты смягчения.
Рис. 18. Предупреждение моделирования защиты и соответствия требованиям на стороне клиента после обнаружения скиммера.
Заключение
Эта кампания подтверждает тот факт, что методы веб-скимминга постоянно развиваются. Они становятся все более сложными, что делает обнаружение и устранение последствий с помощью статического анализа и внешнего сканирования все более сложными. Злоумышленники в этой области постоянно находят более эффективные методы, с помощью которых можно скрыть свои атаки на веб-сайтах жертв и обойти различные меры безопасности, которые могут их разоблачить.Уровень сложности, отмеченный в этом исследовании, должен напоминать организациям о необходимости сохранять бдительность и внимание к векторам атак веб-скимминга и активно искать новые и передовые подходы для борьбы с этими типами атак.
МОК
- Pmdresearch[.]com
- Secures-Tool[.]com
- адометрический[.]com
- cngresearch[.]com
(c) Роман Львовский
