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

Подарочная карта Apple обернулась блокировкой аккаунта на годы работы

Известный разработчик и автор технических книг, посвящённых Apple, Пэрис Баттфилд-Эддисон неожиданно оказался заблокирован в собственном Apple-аккаунте. Это произошло после попытки активировать подарочную карту Apple на $500, которую он купил у крупного и вполне легального ретейлера и собирался использовать для оплаты подписки iCloud+ с хранилищем на 6 ТБ.

Вместо этого — полный цифровой стоп. По словам Баттфилд-Эддисона, он лишился доступа ко всей своей личной и рабочей экосистеме Apple без объяснений и понятного механизма восстановления.

Ситуация выглядит особенно болезненно на фоне его почти 30-летних отношений с компанией: он писал книги по Objective-C и Swift, организовывал конференции и потратил на продукты и сервисы Apple десятки тысяч долларов.

История быстро разошлась по профильным медиа — от AppleInsider до The Register. Казалось бы, при таком внимании проблема должна была решиться оперативно. Представитель Apple действительно связался с разработчиком 14 декабря и пообещал перезвонить на следующий день. Но с тех пор прошло уже несколько дней — и тишина.

Судя по опубликованным деталям, Баттфилд-Эддисон не нарушал правил. Скорее всего, он столкнулся с типичной проблемой: подарочная карта могла быть скомпрометирована ещё до покупки. Apple сама признаёт, что Gift Card часто используются в мошеннических схемах, и рекомендует в таких случаях обращаться в поддержку. Именно это он и сделал — безрезультатно.

Сам кейс вызвал тревогу в сообществе. Если подобное может произойти с известным разработчиком, у которого есть медийная поддержка и контакты внутри Apple, то что говорить об обычных пользователях, у которых нет ни публичности, ни рычагов давления? Автоматические антифрод-системы есть у всех крупных техкомпаний — Apple, Google, Amazon — и они регулярно ошибаются, оставляя людей без доступа к критически важным аккаунтам.

На фоне этой истории в сообществе всё громче звучит простой совет: по возможности избегать Apple Gift Card. Даже если большая часть карт безопасна, риск нарваться на «токсичный» код слишком высок. Подарок может обернуться цифровой катастрофой — как для вас, так и для того, кому вы его вручили.

Чем закончится история Баттфилд-Эддисона, пока неизвестно.

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