Man
Professional
- Messages
- 2,965
- Reaction score
- 488
- Points
- 83
В ходе недавнего расследования мы обнаружили еще одного скиммера кредитных карт, который использовал соединение через веб-сокет для кражи данных кредитных карт с зараженного сайта PrestaShop.
Хотя PrestaShop и не является самым популярным решением для электронной коммерции в сфере интернет-магазинов, он по-прежнему входит в десятку самых распространенных платформ электронной коммерции, используемых в Интернете, и на его долю приходится чуть более 1% всех веб-сайтов (всего более 60 000).
Злоумышленники не разбираются в платформах, которые они атакуют. Если веб-сайт идентифицирован как потенциальный источник для кражи и продажи данных кредитных карт на черном рынке, то вы можете быть уверены, что этот веб-сайт станет целью.
В этом случае наш клиент получил предупреждение антивируса при доступе к своему веб-сайту (обычный симптом вредоносного ПО Magecart / кражи карт). В частности, вредоносный домен ниже пытался загрузить:
[/CODE]cd[.]iconstaff[.]top[/CODE]
Не потребовалось много времени, чтобы выяснить причину, изучив исходный код, размещенный в самом низу страницы:
Но настоящий вопрос был в следующем: как его туда поместили? Поиск в файлах и базе данных строк типа WebSocket ничего не дал, поэтому это было немного сложнее найти, чем обычно. В этой статье мы рассмотрим веб-сокеты, вредоносное ПО-скиммеры и то, как нам удалось найти источник этой инфекции для кражи карт.
По сути, веб-сокет — это прямое соединение между клиентом и сервером, при котором в обоих направлениях устанавливается непрерывный поток трафика. В отличие от базового http/https-соединения, где есть запрос от клиента, за которым следует ответ от сервера, трафик веб-сокета непрерывен и идет в обоих направлениях одновременно:
Это полезно для таких сервисов, как финансы и онлайн-игры, которые требуют большого объема обмена данными в реальном времени между клиентами и серверами, где устаревшего неуклюжего HTTP-соединения будет недостаточно.
Атакующие также используют веб-сокеты для обфускации. Анализ трафика веб-сокетов сложнее, чем обычного трафика HTTP/HTTPS, и не все инструменты анализа вообще его поддерживают. Для анализа такого трафика требуются специальные инструменты и знания. Они также подходят для кражи данных кредитных карт с зараженных страниц оформления заказа, как мы увидим здесь.
Строки в кодировке Base64 также часто используются злоумышленниками, но даже запрос PHNjcmlw (<scrip в формате base64) оставил нас с пустыми руками. Сделав еще один шаг, думая, что полезная нагрузка была обращена с помощью strrev, поиск wlmcjNHP (та же строка, но в обратном порядке) также ничего не дал.
Итак, мы вернулись к основам. Вредоносное ПО для скимминга кредитных карт нельзя внедрить в любое место на сайте в случайные файлы, его нужно загрузить на странице оформления заказа. По этой причине скиммеры часто внедряются в основные файлы CMS, файлы тем, определенные области базы данных или — в случае сайтов WooCommerce WordPress — вредоносные плагины.
В этом случае проверка файлов темы и расширений дала веб-оболочку:
Удаление этого должно помочь предотвратить повторное заражение, так что мы не совсем с пустыми руками, но это не тот скиммер, который мы искали.
Давайте кратко рассмотрим основные этапы работы сайта PrestaShop и начнем с самого начала.
Различные платформы CMS имеют различные файлы индекса, подходящие для загрузки остальной части основной платформы CMS, и обычно они довольно простые. В случае PrestaShop файл очень прост и загружает файл config.inc.php из соответствующего каталога:
Этот файл намного сложнее предыдущего и включает правила конфигурации, такие как максимально допустимый размер файла, который может быть загружен на веб-сайт. Он также включает/требует другие файлы из среды:
Так почему бы нам не заглянуть внутрь файла autoload.php?
Обратите внимание на номер версии Prestashop. Согласно архиву релизов , версия 1.7.4.2 была выпущена еще в 2018 году. Распространенная глупость владельцев веб-сайтов — «застревать» в старых версиях своей платформы CMS, часто из-за сильно настроенной кодовой базы, которая может быть несовместима с новыми версиями их CMS или даже просто PHP. Неудивительно, что многие из этих веб-сайтов в конечном итоге сталкиваются с проблемами безопасности: одна из самых важных задач администратора веб-сайта — поддержание кодовой базы в актуальном состоянии. Просмотр списка CVE для Prestashop раскрывает богатую и легендарную историю критических уязвимостей безопасности, поэтому воспримите это как урок, чтобы поддерживать свой веб-сайт в актуальном состоянии!
Давайте начнем с удаления шестнадцатеричного кодирования, чтобы получить более читаемый пример для анализа:
Здесь мы видим код JavaScript, который внедряется и выполняется в браузере жертвы во время процесса оформления заказа.
Мы видим, что здесь используется fromCharCode для обфускации этой строки:
Это популярный метод обфускации, особенно любимый злоумышленниками, такими как Balada.
Однако использование обычного деобфускатера на этом просто выводит мусор. Так в чем же тут подвох?
Если вы внимательно посмотрите на конец этой строки на снимке экрана, вы увидите число 42. На самом деле это скрытое значение XOR. XOR — это легкий, простой метод запутывания, который по сути просто сдвигает значения строки. Когда мы применяем значение XOR 42 к приведенной выше строке, мы получаем следующее:
Который, когда мы пропускаем через старый добрый деобфускатор fromCharCode дядюшки Джима, мы получаем полезную нагрузку нашего веб-сокета:
Источник
Хотя PrestaShop и не является самым популярным решением для электронной коммерции в сфере интернет-магазинов, он по-прежнему входит в десятку самых распространенных платформ электронной коммерции, используемых в Интернете, и на его долю приходится чуть более 1% всех веб-сайтов (всего более 60 000).
Злоумышленники не разбираются в платформах, которые они атакуют. Если веб-сайт идентифицирован как потенциальный источник для кражи и продажи данных кредитных карт на черном рынке, то вы можете быть уверены, что этот веб-сайт станет целью.
В этом случае наш клиент получил предупреждение антивируса при доступе к своему веб-сайту (обычный симптом вредоносного ПО Magecart / кражи карт). В частности, вредоносный домен ниже пытался загрузить:
[/CODE]cd[.]iconstaff[.]top[/CODE]
Не потребовалось много времени, чтобы выяснить причину, изучив исходный код, размещенный в самом низу страницы:
Но настоящий вопрос был в следующем: как его туда поместили? Поиск в файлах и базе данных строк типа WebSocket ничего не дал, поэтому это было немного сложнее найти, чем обычно. В этой статье мы рассмотрим веб-сокеты, вредоносное ПО-скиммеры и то, как нам удалось найти источник этой инфекции для кражи карт.
Что такое веб-сокет?
Прежде чем приступить к расследованию, давайте сначала быстро рассмотрим веб-сокеты, что они собой представляют и почему злоумышленники используют их в кардинг-атаках. Предыдущая запись в этом блоге содержит более подробную информацию, если вы хотите узнать больше!По сути, веб-сокет — это прямое соединение между клиентом и сервером, при котором в обоих направлениях устанавливается непрерывный поток трафика. В отличие от базового http/https-соединения, где есть запрос от клиента, за которым следует ответ от сервера, трафик веб-сокета непрерывен и идет в обоих направлениях одновременно:
Это полезно для таких сервисов, как финансы и онлайн-игры, которые требуют большого объема обмена данными в реальном времени между клиентами и серверами, где устаревшего неуклюжего HTTP-соединения будет недостаточно.
Атакующие также используют веб-сокеты для обфускации. Анализ трафика веб-сокетов сложнее, чем обычного трафика HTTP/HTTPS, и не все инструменты анализа вообще его поддерживают. Для анализа такого трафика требуются специальные инструменты и знания. Они также подходят для кражи данных кредитных карт с зараженных страниц оформления заказа, как мы увидим здесь.
Расследование
Как я уже упоминал ранее, поиск строк того, что мы видели в view-source, ничего не дал. Многие скиммеры кредитных карт можно легко найти в зараженной базе данных, просто выполнив поиск по таким вещам, как <script или другим частям инъекции простого текста.Строки в кодировке Base64 также часто используются злоумышленниками, но даже запрос PHNjcmlw (<scrip в формате base64) оставил нас с пустыми руками. Сделав еще один шаг, думая, что полезная нагрузка была обращена с помощью strrev, поиск wlmcjNHP (та же строка, но в обратном порядке) также ничего не дал.
Итак, мы вернулись к основам. Вредоносное ПО для скимминга кредитных карт нельзя внедрить в любое место на сайте в случайные файлы, его нужно загрузить на странице оформления заказа. По этой причине скиммеры часто внедряются в основные файлы CMS, файлы тем, определенные области базы данных или — в случае сайтов WooCommerce WordPress — вредоносные плагины.
В этом случае проверка файлов темы и расширений дала веб-оболочку:
Удаление этого должно помочь предотвратить повторное заражение, так что мы не совсем с пустыми руками, но это не тот скиммер, который мы искали.
Давайте кратко рассмотрим основные этапы работы сайта PrestaShop и начнем с самого начала.
1. index.php
Первый файл, который загружается на любом веб-сайте на основе PHP, — это основной файл index.php в каталоге docroot:
Code:
./index.phpРазличные платформы CMS имеют различные файлы индекса, подходящие для загрузки остальной части основной платформы CMS, и обычно они довольно простые. В случае PrestaShop файл очень прост и загружает файл config.inc.php из соответствующего каталога:
2. config.inc.php
Далее у нас есть файл config.inc.php, расположенный в подкаталоге config.
Code:
./config/config.inc.phpЭтот файл намного сложнее предыдущего и включает правила конфигурации, такие как максимально допустимый размер файла, который может быть загружен на веб-сайт. Он также включает/требует другие файлы из среды:
Так почему бы нам не заглянуть внутрь файла autoload.php?
3. autoload.php
Конечно же, в самом низу этого файла оказался наш скиммер:
Code:
./config/autoload.phpОбратите внимание на номер версии Prestashop. Согласно архиву релизов , версия 1.7.4.2 была выпущена еще в 2018 году. Распространенная глупость владельцев веб-сайтов — «застревать» в старых версиях своей платформы CMS, часто из-за сильно настроенной кодовой базы, которая может быть несовместима с новыми версиями их CMS или даже просто PHP. Неудивительно, что многие из этих веб-сайтов в конечном итоге сталкиваются с проблемами безопасности: одна из самых важных задач администратора веб-сайта — поддержание кодовой базы в актуальном состоянии. Просмотр списка CVE для Prestashop раскрывает богатую и легендарную историю критических уязвимостей безопасности, поэтому воспримите это как урок, чтобы поддерживать свой веб-сайт в актуальном состоянии!
Анализ вредоносного ПО
А теперь самое интересное: давайте разберем эту вредоносную программу и посмотрим, как она работает!Давайте начнем с удаления шестнадцатеричного кодирования, чтобы получить более читаемый пример для анализа:
Здесь мы видим код JavaScript, который внедряется и выполняется в браузере жертвы во время процесса оформления заказа.
Мы видим, что здесь используется fromCharCode для обфускации этой строки:
Code:
93,89,89,16,5,5,73,78,4,67,73,69,68,89,94,75,76,76,4,94,69,90,5,71,21,89,69,95,88,73,79,23Это популярный метод обфускации, особенно любимый злоумышленниками, такими как Balada.
Однако использование обычного деобфускатера на этом просто выводит мусор. Так в чем же тут подвох?
Если вы внимательно посмотрите на конец этой строки на снимке экрана, вы увидите число 42. На самом деле это скрытое значение XOR. XOR — это легкий, простой метод запутывания, который по сути просто сдвигает значения строки. Когда мы применяем значение XOR 42 к приведенной выше строке, мы получаем следующее:
Code:
119, 115, 115, 58, 47, 47, 99, 100, 46, 105, 99, 111, 110, 115, 116, 97, 102, 102, 46, 116, 111, 112, 47, 109, 63, 115, 111, 117, 114, 99, 101, 61Который, когда мы пропускаем через старый добрый деобфускатор fromCharCode дядюшки Джима, мы получаем полезную нагрузку нашего веб-сокета:
Code:
wss://cd[.]iconstaff[.]top/m?source=Источник
