StyleSmuggler — активно эксплуатируемая уязвимость Magento, позволяющая без аутентификации захватить сервер и закрепить на нём бэкдор. По данным расследователей, злоумышленники проникали даже в полностью обновлённые магазины. Исправления Adobe на момент публикации не существовало, а личность атакующих установить не удалось.
Проверка Store A сканером eComscan дала чистый результат, поскольку анализировался лишь корневой каталог сайта. Имплант находился в другом месте домашнего каталога учётной записи. Для клиентов Shield версия eComscan 1.9.7 должна была завершать вредоносный процесс, но этот случай показал: проверка document root не исключает компрометацию сервера.
Sansec временно рекомендовал отключить GraphQL. Disrex уточнила, что он необходим headless-магазинам и прогрессивным веб-приложениям, тогда как большинство классических витрин и магазинов на Hyvä обходятся без него. Собственные временные меры также выпустили ProxiBlue и Graycore; дополнительно требовалось усилить PHP и файловую систему.
Правила Disrex для nginx и Apache блокировали замеченные параметры эксплойта в строке запроса. Те же параметры в теле POST и JSON всё равно доходили до PHP: веб-серверные фильтры проверяли только query string. Значит, они останавливали наблюдаемую форму атаки, но не закрывали саму уязвимость.
Основная мера Disrex добавляла проверку запуска из командной строки в три метода сканеров внедрения зависимостей Magento. Условие PHP_SAPI!== 'cli' запрещало их вызов через веб. Ручная правка исчезала после каждого composer install, поэтому Disrex подготовила исходный патч для composer-patches, автоматически применяемый при развёртывании Magento 2.4.6–2.4.9. Совместимость требовала проверки: модуль mageplaza/module-admin-permissions вызывает ClassesScanner.php по HTTP, и защита ломает его административный экран. Перед установкой следовало найти аналогичные обращения в каталоге vendor.
Эту меру проверяли стендом, а не на работающем магазине. Disrex прямо называла её неполной; ни Sansec, ни Adobe не подтвердили, что три сканера находятся в конечной точке цепочки эксплуатации. 5 сентября пользователь GitHub ProxiBlue опубликовал три аналогичных патча. Rick Bouma назвал его разработчиком Magento Lucas van Staden. ProxiBlue и Disrex независимо выбрали те же методы, условие и текст исключения. Disrex затем разместила патчи ProxiBlue у себя с указанием авторства. Варианты эквивалентны, поэтому накладывать их одновременно нельзя.
Graycore, LLC 5 сентября выпустила модуль через GitHub и Packagist. Актуальный код запрещал backend-блоки в директиве почтового шаблона, проверял класс перед построением URL строки таблицы и разрывал открывающие теги PHP в отчётах Web API о фатальных ошибках. Доступная тогда версия Packagist была старее и защищала лишь резолвер PayPal GraphQL, позднее удалённый. README предупреждал: «Это усиление защиты, а не исправление». Другие пути атаки могли сохраниться, а магазин — быть заражённым ещё до установки модуля.
На одном взломанном сервере были отключены четыре из шести PHP-функций, которые пытался вызвать загрузчик. Доступной осталась proc_open, через неё и запустили имплант; ограничение open_basedir не распространялось на дочерний процесс. Disrex советовала прежде всего добавить proc_open в disable_functions, а каталоги /tmp, /var/tmp и /dev/shm монтировать с флагом noexec. Эти меры полезны независимо от точной схемы StyleSmuggler.
Очистку Disrex предлагала начинать с сохранения доказательств. Сначала нужно удалить запись cron и лишь затем завершать процесс, иначе он восстановит задание. Перезагрузка опасна: копия в /proc может оказаться единственным сохранившимся экземпляром бинарного файла. Запуск composer install во время расследования перезапишет ценные временные метки. После локализации следует очистить хранилище сессий, сменить crypt/key в app/etc/env.php, пароли всех администраторов, API-ключи платёжных провайдеров и интеграционные учётные данные из этого файла.
Nexcess и Liquid Web 5 сентября опубликовали одинаковые уведомления: компании проверяли серверные среды и вводили меры предосторожности. Ни одна не заявила о подтверждённом заражении клиента или самостоятельном воспроизведении уязвимости. Disrex тем временем нашла в nginx-логах двух магазинов 26 уникальных исходных адресов: два принадлежали хостинговой инфраструктуре и массово отправляли запросы, остальные напоминали пул резидентских прокси с двумя–шестью запросами на адрес. Первоначальные 28 включали два проверочных сервера Disrex, позднее исключённых. Блокировка единственного IP из бюллетеня Sansec остановила бы менее четверти замеченного трафика.
The Hacker News запросила комментарии у Adobe, Sansec и Graycore и обещала обновить материал после ответов. Публикацию исправили по сведениям Rick Bouma из Disrex Group: были уточнены версии магазинов, статус Shield, время первых контактов, причина промаха eComscan и роль раннего предупреждающего письма, раскрывшего один взлом. Bouma также подтвердил независимую разработку патчей ProxiBlue и их последующее включение в репозиторий Disrex. При StyleSmuggler нельзя полагаться только на обновлённую Magento, URL-фильтры или чистый document root: нужны серверное усиление, поиск импланта во всём домашнем каталоге и полноценное реагирование на инцидент.
Проверка Store A сканером eComscan дала чистый результат, поскольку анализировался лишь корневой каталог сайта. Имплант находился в другом месте домашнего каталога учётной записи. Для клиентов Shield версия eComscan 1.9.7 должна была завершать вредоносный процесс, но этот случай показал: проверка document root не исключает компрометацию сервера.
Sansec временно рекомендовал отключить GraphQL. Disrex уточнила, что он необходим headless-магазинам и прогрессивным веб-приложениям, тогда как большинство классических витрин и магазинов на Hyvä обходятся без него. Собственные временные меры также выпустили ProxiBlue и Graycore; дополнительно требовалось усилить PHP и файловую систему.
Правила Disrex для nginx и Apache блокировали замеченные параметры эксплойта в строке запроса. Те же параметры в теле POST и JSON всё равно доходили до PHP: веб-серверные фильтры проверяли только query string. Значит, они останавливали наблюдаемую форму атаки, но не закрывали саму уязвимость.
Основная мера Disrex добавляла проверку запуска из командной строки в три метода сканеров внедрения зависимостей Magento. Условие PHP_SAPI!== 'cli' запрещало их вызов через веб. Ручная правка исчезала после каждого composer install, поэтому Disrex подготовила исходный патч для composer-patches, автоматически применяемый при развёртывании Magento 2.4.6–2.4.9. Совместимость требовала проверки: модуль mageplaza/module-admin-permissions вызывает ClassesScanner.php по HTTP, и защита ломает его административный экран. Перед установкой следовало найти аналогичные обращения в каталоге vendor.
Эту меру проверяли стендом, а не на работающем магазине. Disrex прямо называла её неполной; ни Sansec, ни Adobe не подтвердили, что три сканера находятся в конечной точке цепочки эксплуатации. 5 сентября пользователь GitHub ProxiBlue опубликовал три аналогичных патча. Rick Bouma назвал его разработчиком Magento Lucas van Staden. ProxiBlue и Disrex независимо выбрали те же методы, условие и текст исключения. Disrex затем разместила патчи ProxiBlue у себя с указанием авторства. Варианты эквивалентны, поэтому накладывать их одновременно нельзя.
Graycore, LLC 5 сентября выпустила модуль через GitHub и Packagist. Актуальный код запрещал backend-блоки в директиве почтового шаблона, проверял класс перед построением URL строки таблицы и разрывал открывающие теги PHP в отчётах Web API о фатальных ошибках. Доступная тогда версия Packagist была старее и защищала лишь резолвер PayPal GraphQL, позднее удалённый. README предупреждал: «Это усиление защиты, а не исправление». Другие пути атаки могли сохраниться, а магазин — быть заражённым ещё до установки модуля.
На одном взломанном сервере были отключены четыре из шести PHP-функций, которые пытался вызвать загрузчик. Доступной осталась proc_open, через неё и запустили имплант; ограничение open_basedir не распространялось на дочерний процесс. Disrex советовала прежде всего добавить proc_open в disable_functions, а каталоги /tmp, /var/tmp и /dev/shm монтировать с флагом noexec. Эти меры полезны независимо от точной схемы StyleSmuggler.
Очистку Disrex предлагала начинать с сохранения доказательств. Сначала нужно удалить запись cron и лишь затем завершать процесс, иначе он восстановит задание. Перезагрузка опасна: копия в /proc может оказаться единственным сохранившимся экземпляром бинарного файла. Запуск composer install во время расследования перезапишет ценные временные метки. После локализации следует очистить хранилище сессий, сменить crypt/key в app/etc/env.php, пароли всех администраторов, API-ключи платёжных провайдеров и интеграционные учётные данные из этого файла.
Nexcess и Liquid Web 5 сентября опубликовали одинаковые уведомления: компании проверяли серверные среды и вводили меры предосторожности. Ни одна не заявила о подтверждённом заражении клиента или самостоятельном воспроизведении уязвимости. Disrex тем временем нашла в nginx-логах двух магазинов 26 уникальных исходных адресов: два принадлежали хостинговой инфраструктуре и массово отправляли запросы, остальные напоминали пул резидентских прокси с двумя–шестью запросами на адрес. Первоначальные 28 включали два проверочных сервера Disrex, позднее исключённых. Блокировка единственного IP из бюллетеня Sansec остановила бы менее четверти замеченного трафика.
The Hacker News запросила комментарии у Adobe, Sansec и Graycore и обещала обновить материал после ответов. Публикацию исправили по сведениям Rick Bouma из Disrex Group: были уточнены версии магазинов, статус Shield, время первых контактов, причина промаха eComscan и роль раннего предупреждающего письма, раскрывшего один взлом. Bouma также подтвердил независимую разработку патчей ProxiBlue и их последующее включение в репозиторий Disrex. При StyleSmuggler нельзя полагаться только на обновлённую Magento, URL-фильтры или чистый document root: нужны серверное усиление, поиск импланта во всём домашнем каталоге и полноценное реагирование на инцидент.
