На сайтах с устаревшей CMS Magento проснулся цепкий веб-скиммер

На сайтах с устаревшей CMS Magento проснулся цепкий веб-скиммер

На сайтах с устаревшей CMS Magento проснулся цепкий веб-скиммер

В канун Черной пятницы в 50 крупных магазинах, построенных на платформе Magento, заработал новый зловред, ворующий платежные данные. Избавиться от этого веб-скиммера непросто: взломщики оставили на сайтах бэкдоры и добавили механизм, обеспечивающий повторное инфицирование в случае обнаружения и удаления вредоносного кода.

По свидетельству Sansec, злоумышленники начали готовиться к новой кампании еще в апреле и хорошо позаботились о скрытности операций. Разбор текущих атак показал, что все скомпрометированные сайты используют Magento ветки 2.2, снятой с поддержки в декабре 2019 года. Пользователей еще тогда призывали произвести апгрейд, однако многие этого до сих пор не сделали.

Взлом сайтов в данном случае осуществляется посредством эксплуатации уязвимостей, пропатченных разработчиком в марте прошлого года. Ход атаки при этом выглядит следующим образом:

  1. Получение URL консоли администратора через эксплойт уязвимости раскрытия информации.
  2. Перехват сессионного ключа залогинившегося администратора посредством SQL-инъекции.
  3. Вход в админ-панель и создание пригодного для эксплуатации шаблона email с целью загрузки и исполнения вредоносного PHP-кода.
  4. Установка бэкдора.
  5. Установка веб-скиммера.

При этом внедрять код стилера на забэкдоренный сайт злоумышленники не торопятся.

Веб-скиммер в данном случае разделен на две части — клиентскую и серверную. На стороне клиента вредоносный код внедряется в какой-нибудь статичный JavaScript-файл (например, require.js); в этом виде он может показывать поддельную форму оплаты покупки — для каждого магазина свою. Вводимые покупателем данные скрипт отсылает на сервер для проверки, и такое действие подозрений не вызывает: оно обычно при проведении платежных транзакций.

За сбор и сохранение краденой информации отвечает вторая половина стилера — добавленный на бэкенд-сервер код PHP. Оператор в этом случае получает ворованные данные через запрос HTTP POST.

Бэкдор, установленный посредством PHP-инъекции (PHP Object Injection, POI), злоумышленники активируют вызовом функции сравнения товаров — Product Compare. Один из таких вредоносных объектов вполне тривиален, и его легко обнаружить. Второй более опасен: он добавляет на сервер функцию десериализации PHP — она по стандарту не рекомендуется к использованию, так как позволяет захватить контроль над сервером посредством POI-атаки. К счастью, вызов этой функции всегда можно отследить по журналу событий.

Одновременно на сервере в фоновом режиме запускается сторожевой процесс, отвечающий за сохранность бэкдора. Этот сторож маскируется под легитимные системные процессы — dnsadmin dormant, sshd [net], php-fpm: pool www. Если бэкдор нашли и вычистили, зловредный процесс за пару дней установит новую копию (она вшита в код). Более того, он откатит временные метки всех файлов законного пользователя, чтобы возврат вредоносного кода остался незамеченным.

Присутствие зловредной службы, со слов экспертов, можно обнаружить на TCP-порту 9000 — по всей видимости, это резервный канал связи, по которому операторы могут подавать команды. Наличие стороннего сторожа также выявит поиск по списку запущенных процессов с помощью утилиты командной строки (sudo grep -l Magento.Catalog /proc/*/exe).

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

Государственная компания Венесуэлы приостановила отгрузки из-за кибератаки

Государственная нефтяная компания Венесуэлы Petroleos de Venezuela SA (PDVSA) до сих пор не восстановилась после кибератаки, произошедшей в субботу. Инцидент вывел из строя все административные системы компании и привёл к остановке отгрузки нефти на ключевом терминале Хосе.

Как сообщает агентство Bloomberg со ссылкой на три источника, по состоянию на понедельник восстановительные работы после атаки всё ещё продолжались. Сеть на терминале Хосе оставалась недоступной, из-за чего экспорт нефти был приостановлен.

По данным источников агентства, сотрудникам PDVSA было предписано отключить компьютеры, любое внешнее оборудование, а также разорвать соединение с интернетом, включая Wi-Fi и терминалы Starlink. Кроме того, на объектах компании были усилены меры физической безопасности.

В самой PDVSA в понедельник заявили о нейтрализации «попытки саботажа». В официальном сообщении подчёркивается, что добыча нефти в результате инцидента не пострадала.

Источники Bloomberg отмечают, что атака могла быть связана с эксплуатацией уязвимостей. Из-за американских санкций лицензии на программное обеспечение в компании долгое время не обновлялись. Кроме того, ранее PDVSA не сталкивалась с серьёзными киберинцидентами — атаки, как правило, ограничивались DDoS и попытками дефейса сайтов.

Схожий инцидент в марте был зафиксирован в российской нефтяной компании «Лукойл». По оценкам экспертов, атака, вероятно, была связана с деятельностью программ-вымогателей, за которыми стояли финансово мотивированные группировки вроде LockBit или Black Cat.

RSS: Новости на портале Anti-Malware.ru