Что проверить в магазине после закрытия критической уязвимости

Уязвимость в Magento закрыли 7 сентября, а 3834 магазина к концу месяца все еще отдавали карты покупателей. Здесь порядок проверки после критического бюллетеня на 1С-Битрикс: команды для поиска измененных файлов, SQL для администраторов и агентов, таблица секретов, которые нужно сменить.

3834 интернет-магазина на Magento и Adobe Commerce оказались взломаны через одну уязвимость, и у многих из них патч к моменту подсчета уже стоял. Исправление вышло 7 сентября 2026 года, атаки начались раньше, а то, что злоумышленники успели оставить на серверах, обновление не удалило. Скиммер на странице оплаты продолжал собирать карты покупателей уже на «обновленных» сайтах.

Вывод из этой истории простой и касается любого магазина, на Битриксе в том числе. Обновление закрывает вход, но не выгоняет того, кто уже вошел. После критической уязвимости, которую успели использовать до патча, магазин нужно проверить в 5 местах: файлы, учетные записи админки и сервера, запланированные задачи, страница оплаты и секреты, то есть пароли, ключи и токены, которые могли украсть. Ниже — порядок этой проверки и то, как она выглядит на 1С-Битрикс.

Что произошло с Magento

5 сентября 2026 года исследователи Sansec описали уязвимость StyleSmuggler (CVE-2026-75650): через нее можно было выполнить код на сервере магазина без авторизации, и ее уже использовали в атаках. 7 сентября Adobe выпустила бюллетень APSB26-146 с исправлением: оценка по CVSS — 10 из 10, уязвимы Magento Open Source и Adobe Commerce версий с 2.4.4 по 2.4.9.

28 сентября Cybernews опубликовал разбор открытого сервера атакующих. По нему видно, что делали после взлома:

• ставили на страницы оформления заказа скиммер, который перехватывал номер карты, CVV, срок действия, имя, адрес, телефон и e-mail покупателя;
• заводили на серверах дополнительные SSH-учетки (исследователи насчитали 12 имен) и новых администраторов в самой Magento;
• запускали скрытый процесс под видом системных (kworker, fc-cache);
• забирали закрытые ключи платежных шлюзов.

Каждый пункт из этого списка переживает установку патча. Патч исправляет код, через который вошли, но не трогает новых пользователей, чужие процессы, вставленный в шаблон скрипт и украденные ключи. Поэтому Adobe вместе с обновлением призвала менять учетные данные, а исследователи — считать затронутые магазины скомпрометированными и перевыпускать все секреты, доступные с сервера.

Почему это касается магазина на Битриксе

Уязвимость в Magento к Битриксу отношения не имеет. Отношение имеет сценарий, и он одинаков для любой CMS: публикация уязвимости, массовые атаки в первые дни, патч, который владельцы ставят через неделю или месяц, и закрепление злоумышленника в этом промежутке.

У 1С-Битрикс критические уязвимости тоже бывают, и их тоже эксплуатируют массово: какие из них закрывать в первую очередь, мы собрали в статье про уязвимости 1С-Битрикс. Если обновление ставилось не в день выхода, а позже, вопрос «был ли взлом в промежутке» остается открытым, пока вы его не проверили.

Отдельно про чужие модули. Сторонние решения из Маркетплейса обновляются не вместе с ядром, и у них свой график исправлений. Если уязвимость была в модуле, «все обновления ядра установлены» ничего не говорит о его состоянии.

Порядок проверки после критической уязвимости

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

1. Снимите копию до любой чистки

Первое действие — полная копия файлов и базы в текущем виде и выгрузка логов веб-сервера за период с даты публикации уязвимости. Это не бэкап для восстановления, а улика: по ней потом выясняют, когда и как вошли, что успели унести и надо ли уведомлять покупателей. Удалив подозрительный файл сразу, вы теряете дату его появления.

Копию храните отдельно от сервера. Если на нем есть чужой доступ, архив рядом с сайтом тоже под угрозой.

2. Файлы: что изменилось после начала атак

Начинать стоит с файлов, которые менялись после даты публикации уязвимости. Список получается длинным из-за кеша, поэтому системные каталоги кеша исключаем сразу:

# PHP-файлы, измененные после даты публикации уязвимости, без кеша
cd /var/www/example.ru
find . -name "*.php" -newermt "2026-09-04" \
  -not -path "./bitrix/cache/*" \
  -not -path "./bitrix/managed_cache/*" \
  -not -path "./bitrix/stack_cache/*" | sort

# PHP в каталоге загрузок: здесь его быть не должно
find ./upload -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.ph_" \)

В 1С-Битрикс для этого есть 2 штатных инструмента. Контроль целостности (Настройки, Проактивная защита, Контроль целостности) сравнивает файлы с заранее собранным слепком и показывает, что изменилось. Он недоступен в редакции «Старт» и полезен только при условии, что слепок собрали до инцидента. Сканирование файлов в разделе «Поиск троянов» ищет шаблоны вредоносного кода: eval, base64, известные веб-шеллы. Подозрительный файл можно отправить в карантин, сканер переименует .php в .ph_.

Сканеру нельзя верить без проверки ни в одну сторону. Он находит обфусцированный код, но пропускает аккуратную вставку в 2 строки в init.php, и одновременно ругается на легальный код некоторых модулей. Каждое срабатывание смотрит человек, который понимает, что делает этот файл.

3. Учетные записи админки и сервера

Злоумышленник, который получил выполнение кода, почти всегда заводит себе запасной вход. В Битриксе это новый пользователь в группе администраторов, на сервере — новый системный пользователь или чужой SSH-ключ.

-- Все пользователи в группе «Администраторы» (ID группы 1)
SELECT u.ID, u.LOGIN, u.EMAIL, u.DATE_REGISTER, u.LAST_LOGIN
FROM b_user u
JOIN b_user_group g ON g.USER_ID = u.ID
WHERE g.GROUP_ID = 1
ORDER BY u.DATE_REGISTER DESC;

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

На сервере проверяют список пользователей с оболочкой входа, файлы authorized_keys у каждого из них и пользователей с правами sudo. В случае с Magento SSH-учеток было 12, и звались они как служебные: на название «похоже на системное» полагаться нельзя, сверять нужно со списком того, что заводили вы или хостинг.

4. Агенты, cron и процессы

Третье место, где прячется закрепление, — все, что запускается само. В Битриксе это агенты: строки в таблице b_agent, в поле NAME которых записан PHP-код, выполняемый по расписанию. Чужой агент может раз в час восстанавливать удаленный бэкдор, и чистка файлов тогда бесполезна.

-- Агенты: смотреть на незнакомые MODULE_ID и на NAME с eval, base64, curl
SELECT ID, MODULE_ID, NAME, ACTIVE, LAST_EXEC, NEXT_EXEC
FROM b_agent
ORDER BY ID DESC
LIMIT 50;

На сервере смотрят crontab каждого пользователя, системные задания в /etc/cron.d/ и процессы. Процесс с именем kworker в списке — норма для Linux, но настоящие потоки ядра не имеют исполняемого файла на диске. Если у «kworker» есть путь к файлу в домашнем каталоге или в /tmp, это ровно то, что нашли на серверах Magento.

5. Страница оплаты: что видит покупатель

Скиммер — это скрипт, который подгружается на страницу оформления заказа и отправляет введенные данные на чужой адрес. Владелец его не замечает: магазин работает, заказы идут, деньги приходят. Узнают о нем от банка или от покупателей, у которых списали деньги в другом месте.

Проверка состоит из 3 действий. Откройте оформление заказа в браузере без авторизации и посмотрите в инструментах разработчика, на какие домены уходят запросы: все, кроме вашего, платежного шлюза, Метрики и известных вам сервисов, требует объяснения. Проверьте шаблоны сайта: header.php и footer.php в /bitrix/templates/ и /local/templates/, файл init.php, шаблоны компонента оформления заказа. Посмотрите настройки, куда можно вставить код без правки файлов: счетчики и произвольный код в настройках сайта и модулей.

Если карту покупатель вводит на странице банка или платежного сервиса, скиммеру сложнее: данных карты на странице магазина нет. Но имя, телефон, адрес и e-mail он соберет и там, а иногда подменяет кнопку оплаты своей формой, похожей на банковскую.

Какие секреты сменить и в каком порядке

Секреты меняют после того, как найдены и закрыты все входы из шагов 2–4. Иначе новый пароль от базы уйдет злоумышленнику так же, как ушел старый. У Magento есть единый ключ шифрования, который Adobe советует сменить первым. В Битриксе такого единого ключа нет, секреты разбросаны по разным местам, и пропустить одно из них легко.

Список кажется длинным, но в среднем магазине, по моей оценке, это 15–25 секретов, и большинство меняется за минуты. Дольше всего занимает поиск: где еще использовался тот же ключ. Поэтому после смены стоит записать, где лежит каждый секрет и у кого есть к нему доступ. О том, как секреты попадают в код и в репозитории, мы писали отдельно — в статье про секреты в коде сайта.

Кого уведомить, если следы взлома нашлись

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

Первое: платежный сервис или банк-эквайер. Им нужно сообщить о возможной компрометации ключей и страницы оплаты: у них есть свои процедуры, и с ними лучше не опаздывать. Второе: Роскомнадзор. По части 3.1 статьи 21 закона 152-ФЗ при неправомерной передаче персональных данных оператор обязан уведомить ведомство в течение 24 ч. с момента выявления инцидента и в течение 72 ч. сообщить результаты внутреннего расследования. Имена, телефоны и адреса покупателей — персональные данные, и скиммер, собиравший их, под эту норму попадает.

Здесь снова пригодится копия из первого шага. Без нее на вопрос «что именно утекло и с какого числа» ответить нечем.

Как сократить окно в следующий раз

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

• Подписка на бюллетени. Новости безопасности 1С-Битрикс и разработчиков установленных модулей должен читать тот, кто ставит обновления, и в тот же день.
• Обновление на копии. Порядок, при котором критическое обновление проверяется на копии и ставится на бой в тот же день, описан в статье об обновлении 1С-Битрикс.
• Слепок целостности заранее. Контроль целостности бесполезен после взлома, если эталона нет. Собрать его нужно сейчас, на чистом сайте, и хранить вне сервера.
• Двухэтапная авторизация. Для всех администраторов, без исключений для «своих».
• Политика загрузки скриптов. Заголовок Content-Security-Policy на страницах оформления заказа ограничивает домены, с которых браузер выполнит скрипт. Скиммер, вставленный ссылкой на чужой домен, с ним просто не загрузится.

Мое мнение: из этих 5 пунктов недооценен третий. Слепок целостности собирается за полчаса, а без него после каждой громкой уязвимости приходится вручную разбирать тысячи файлов и гадать, какой из них изменился. Если сомнения уже есть, начать можно с самостоятельной проверки по статье о том, как проверить сайт на вирусы.

Если коротко: обновление — половина работы

Патч после критической уязвимости обязателен, но он отвечает только на вопрос «можно ли войти сейчас». На вопрос «не вошли ли раньше» отвечает проверка: копия, файлы, учетные записи, агенты и cron, страница оплаты, затем смена секретов. Такую проверку мы в Design Lab проводим для магазинов на 1С-Битрикс после критических бюллетеней. Если магазин обновляли с задержкой, пройдите хотя бы шаги 3 и 5: новые администраторы и чужие скрипты на оформлении заказа находятся быстрее всего и обходятся дороже всего, если их не найти.