На сайтах с устаревшей 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-код, способный на лету воровать пароли администратора и отсылать их на сторонний коллектор. Если доступ к взломанному серверу потерян и сторожевой процесс прибит, у злоумышленников останутся ключи, с помощью которых можно будет вернуть утраченные позиции.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

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