Man
Professional
- Messages
- 2,963
- Reaction score
- 486
- Points
- 83
Когда дело касается безопасности веб-сайта, иногда самые безобидные функции могут стать мощными инструментами в руках злоумышленников. Так было в недавнем инциденте, который мы расследовали, когда злоумышленники использовали скромный файл подкачки для поддержания постоянного скиммера кредитных карт на сайте электронной коммерции Magento. Эта умная тактика позволила вредоносному ПО пережить несколько попыток очистки — то есть, пока наши аналитики не завершили свое расследование.
В этой статье мы подробно рассмотрим эту сложную атаку на электронную коммерцию и предложим ценную информацию о том, как вы можете защитить свой интернет-магазин от подобных угроз.
Давайте посмотрим!
Скрипт имел все обычные индикаторы вредоносного ПО, такие как переменные в кодировке base64 и строки в кодировке hex. Но после декодирования мы увидели некоторые явные индикаторы того, что скрипт отслеживал данные кредитной карты.
После нажатия кнопки оформления заказа скрипт собирает данные, введенные в форму кредитной карты, с помощью функции querySelectorAll, как показано здесь.
Несколько других вариантов функции в других местах скрипта захватывают конфиденциальную информацию, такую как имя, адрес, номер карты и другие данные, необходимые злоумышленникам для использования украденных данных карты. Мы также можем видеть домен, amazon-analytic[.]com, используемый злоумышленниками для получения украденных данных кредитной карты.
![amazon-analytic[.]com использовался злоумышленниками для получения украденных данных кредитной карты](https://blog.sucuri.net/wp-content/uploads/2024/07/amazon-analytic-domain.png "amazon-analytic[.]com использовался злоумышленниками для получения украденных данных кредитной карты")
Этот домен amazon-analytic[.]com был зарегистрирован в феврале 2024 года и также использовался в других предыдущих случаях кражи кредитных карт. Обратите внимание на использование названия бренда; эта тактика использования популярных продуктов и услуг в доменных именах часто используется злоумышленниками в попытке избежать обнаружения.
Расшифровка этого содержимого base64 выявила точный вредоносный скрипт, обнаруженный в исходном коде страницы оформления заказа. Мы также обнаружили функцию curl, которую злоумышленники использовали для вывоза украденных данных на свой внешний домен.
Функция ob_filter_callback используется для добавления скрипта скиммера на веб-страницы, если их URL-адреса содержат ключевое слово «checkout» и страницы были запрошены с использованием метода GET.
После того, как мы заменили файл правильным содержимым, мы заметили, что скрипт все еще загружается в checkout. Не исключено, что файлы могут быть повторно заражены довольно быстро, поэтому мы еще раз проверили bootstrap.php с помощью наших инструментов очистки от вредоносных программ и заметили, что вредоносная программа вернулась.
Особенно странным было то, что когда мы посмотрели файл на сервере напрямую через SSH, он оказался совершенно чистым.
Однако когда мы проверили файловую систему на наличие признаков вредоносного ПО с помощью наших инструментов очистки, вредоносное ПО все равно появилось.
В качестве дальнейшего теста мы скопировали, по-видимому, зараженный файл bootstrap.php в новое имя файла — bootstrap.php.clean — и просмотрели его с помощью наших инструментов очистки от вредоносных программ. Содержимое файла было правильным.
Итак, каким-то образом, файл оказался одновременно и чистым, и зараженным (вредоносная программа Шредингера?).
Это случается нечасто, но иногда вредоносное ПО задерживается в памяти и может вцепиться в данные сеанса файла. Мы перезапустили службы Apache и PHP, а в конечном итоге перезагрузили весь сервер, чтобы попытаться это очистить. Удивительно, но вредоносное ПО все еще было там, и мы явно что-то упускали.
На первый взгляд, на сервере не было файла с таким именем.
Часть имени файла swapme подсказала нам, что где-то может быть застрявший swap. Когда файлы редактируются напрямую через ssh, сервер создаст временную версию «swap» на случай сбоя редактора, что предотвратит потерю всего содержимого.
Хотя мы не смогли увидеть файл ~swapme с помощью команды ls, запуск команды vi на bootstrap.php-swapme для непосредственного редактирования файла подкачки показал, что файл действительно был там, и он содержал точно такое же содержимое, как и зараженная версия bootstrap.php.
Стало очевидно, что злоумышленники использовали файл подкачки, чтобы вредоносное ПО оставалось на сервере и избегало обычных методов обнаружения. Мы удалили этот файл подкачки, снова очистили кэши, и вуаля: исходный код страницы оформления заказа наконец-то был чист.
Источник
В этой статье мы подробно рассмотрим эту сложную атаку на электронную коммерцию и предложим ценную информацию о том, как вы можете защитить свой интернет-магазин от подобных угроз.
Давайте посмотрим!
Проверка вредоносного ПО
При переходе на страницу оформления заказа на взломанном веб-сайте мы увидели интересный скрипт, скрытый глубоко в исходном коде страницы.
Скрипт имел все обычные индикаторы вредоносного ПО, такие как переменные в кодировке base64 и строки в кодировке hex. Но после декодирования мы увидели некоторые явные индикаторы того, что скрипт отслеживал данные кредитной карты.
Вредоносное поведение страницы оформления заказа
Следующий фрагмент кода включает кнопку оформления заказа и добавляет пользовательские привязки к обычной функции нажатия на взломанной странице оформления заказа.
После нажатия кнопки оформления заказа скрипт собирает данные, введенные в форму кредитной карты, с помощью функции querySelectorAll, как показано здесь.
Несколько других вариантов функции в других местах скрипта захватывают конфиденциальную информацию, такую как имя, адрес, номер карты и другие данные, необходимые злоумышленникам для использования украденных данных карты. Мы также можем видеть домен, amazon-analytic[.]com, используемый злоумышленниками для получения украденных данных кредитной карты.
Этот домен amazon-analytic[.]com был зарегистрирован в феврале 2024 года и также использовался в других предыдущих случаях кражи кредитных карт. Обратите внимание на использование названия бренда; эта тактика использования популярных продуктов и услуг в доменных именах часто используется злоумышленниками в попытке избежать обнаружения.
Отслеживание источника до bootstrap.php
После того, как мы расшифровали страницу оформления заказа, пришло время найти источник. Дальнейшее расследование привело нас к файлу Magento app/bootstrap.php, который был полностью заменен из официальной версии.
Расшифровка этого содержимого base64 выявила точный вредоносный скрипт, обнаруженный в исходном коде страницы оформления заказа. Мы также обнаружили функцию curl, которую злоумышленники использовали для вывоза украденных данных на свой внешний домен.
Функция ob_filter_callback используется для добавления скрипта скиммера на веб-страницы, если их URL-адреса содержат ключевое слово «checkout» и страницы были запрошены с использованием метода GET.
Процесс удаления вредоносного ПО
Мы решили, что удаление вредоносного ПО должно быть таким же простым, как замена app/bootstrap.php на правильную версию и последующая очистка кэшей, поскольку мы знаем, что там находится то, что мы видим при оформлении заказа, верно? Ну, не в этом случае.После того, как мы заменили файл правильным содержимым, мы заметили, что скрипт все еще загружается в checkout. Не исключено, что файлы могут быть повторно заражены довольно быстро, поэтому мы еще раз проверили bootstrap.php с помощью наших инструментов очистки от вредоносных программ и заметили, что вредоносная программа вернулась.
Особенно странным было то, что когда мы посмотрели файл на сервере напрямую через SSH, он оказался совершенно чистым.
Однако когда мы проверили файловую систему на наличие признаков вредоносного ПО с помощью наших инструментов очистки, вредоносное ПО все равно появилось.
В качестве дальнейшего теста мы скопировали, по-видимому, зараженный файл bootstrap.php в новое имя файла — bootstrap.php.clean — и просмотрели его с помощью наших инструментов очистки от вредоносных программ. Содержимое файла было правильным.
Итак, каким-то образом, файл оказался одновременно и чистым, и зараженным (вредоносная программа Шредингера?).
Это случается нечасто, но иногда вредоносное ПО задерживается в памяти и может вцепиться в данные сеанса файла. Мы перезапустили службы Apache и PHP, а в конечном итоге перезагрузили весь сервер, чтобы попытаться это очистить. Удивительно, но вредоносное ПО все еще было там, и мы явно что-то упускали.
Возвращаемся к основам: файлы подкачки
Мы вернулись к рассмотрению вредоносного скрипта и файла, в котором он был создан, и заметили кое-что интересное в самом низу.
На первый взгляд, на сервере не было файла с таким именем.
Часть имени файла swapme подсказала нам, что где-то может быть застрявший swap. Когда файлы редактируются напрямую через ssh, сервер создаст временную версию «swap» на случай сбоя редактора, что предотвратит потерю всего содержимого.
Хотя мы не смогли увидеть файл ~swapme с помощью команды ls, запуск команды vi на bootstrap.php-swapme для непосредственного редактирования файла подкачки показал, что файл действительно был там, и он содержал точно такое же содержимое, как и зараженная версия bootstrap.php.
Стало очевидно, что злоумышленники использовали файл подкачки, чтобы вредоносное ПО оставалось на сервере и избегало обычных методов обнаружения. Мы удалили этот файл подкачки, снова очистили кэши, и вуаля: исходный код страницы оформления заказа наконец-то был чист.
Источник
