Man
Professional
- Messages
- 2,965
- Reaction score
- 488
- Points
- 83
Этот пост начинается так же, как и многие другие в этом блоге, и он будет знаком тем, кто следит за безопасностью веб-сайтов: Клиент пришел к нам, получив уведомление от своего платежного процессора о краже кредитных карт со страницы оформления заказа на его веб-сайте электронной коммерции. Вопрос, конечно, был в том, как? В ходе этого расследования мы обнаружили очень интересный (и на самом деле креативный) способ, которым злоумышленники воровали данные кредитных карт со взломанного веб-сайта.
В этой статье мы расскажем, как мы обнаружили вредоносную инъекцию, проведем анализ нетрадиционных (хотя и не совсем уникальных) способов, которыми злоумышленники скрывали свою инъекцию и полезную нагрузку, как именно это работало, и, как всегда, рассмотрим несколько способов, с помощью которых администраторы сайтов электронной коммерции могут защитить себя от такой атаки.
Давайте начнем!
Важно убедиться, что мы проверяем страницу оформления заказа, поскольку большинство вредоносных программ для кардинга пытаются оставаться скрытыми, появляясь только на URL-адресах, содержащих строку «checkout». Таким образом, вредоносная программа не загружается на каждой странице (ей это не нужно для выполнения того, что она хочет сделать) и ее легче скрыть от владельца веб-сайта и от внешних сканеров. В конце концов, нечасто администратор интернет-магазина будет покупать продукты у себя.
Теперь у нас в корзине есть товар, и мы перешли на страницу, где нам предлагается ввести платежные реквизиты:
На этом этапе нам нужно сделать 2-3 вещи, чтобы проверить, все ли в порядке:
Для тех из вас, кто не знаком, щелкнув правой кнопкой мыши по веб-странице и выбрав пункт «Просмотр исходного кода », вы можете заглянуть «за кулисы» некоторых атрибутов и форматирования, из которых состоит веб-страница, отображаемая в вашем браузере.
В этом случае это был первый шаг к раскрытию того, как воровали карты клиентов клиента. Мы наткнулись на этот сомнительный пункт, прокручивая источник:
Это очень странный на вид код, и на первый взгляд не сразу понятно, что он вообще делает. Обратите внимание на теги <style (а не <script) — об этом позже.
Способ внедрения вредоносного ПО на страницу оформления заказа на самом деле был довольно прост: все, что сделали злоумышленники, — это просто отредактировали исходный код страницы оформления заказа либо из wp-admin (используя взломанную учетную запись администратора), либо напрямую через базу данных:
Это отличное напоминание о том, почему защита вашей панели wp-admin имеет первостепенное значение!
Особого внимания заслуживает вот эта строка, расположенная в центре образца:
Это, конечно, выглядит как полный вздор. Но на самом деле это сильно запутанная строка и ключ к определению того, как это работает. Вредоносная программа использует специальный механизм скремблирования, использующий замену символов и перемешивание.
Используя логику запутывания и запустив ее в обратном порядке, мы можем восстановить исходный порядок символов и получаем следующее:
Ну, ну, ну! Давайте взглянем на этот файл «изображения» и посмотрим, что мы найдем:
Опять же, на первый взгляд, довольно непонятно. Однако, стоит отметить одну важную вещь: кусок данных в самом верху, который, кажется, не соответствует остальному:
Вот как обычно выглядит (реальный) файл изображения, открытый в текстовом редакторе. На самом деле, это были легитимные данные изображения. При открытии этого файла в обычной программе просмотра изображений мы увидели копию пользовательского значка зараженного веб-сайта! Это служит скрытой и важной цели: когда администратор веб-сайта прокручивает свою медиатеку в WordPress, этот файл просто отображается как значок дружественного соседства для своего веб-сайта и не вызывает никаких подозрений. Отдаем должное там, где это необходимо, это приятное внимание к деталям. Хотя, конечно, мы не будем включать сюда значок из соображений конфиденциальности.
credit
expiry
CVV
company
HolderFirst
HolderLast
Name
SendData
GetCCInfo
А также жестко запрограммированные ссылки на платежный процессор, который он имитировал.
Итак, возникает вопрос – зачем злоумышленникам разделять свою полезную нагрузку таким образом? Почему бы просто не поместить поддельный платежный шлюз прямо на страницу оформления заказа WooCommerce? Ну, чтобы оставаться более скрытыми, конечно!
При проверке исходного кода зараженного сайта электронной коммерции некоторые варианты MageCart JavaScript болезненно очевидны для обнаружения. Например, этот код был обнаружен на странице оформления заказа зараженного сайта Magento:
Большие куски сильно запутанного JavaScript, как этот, торчат как больной большой палец, и это на самом деле совсем не трудно обнаружить. Сохраняя свою основную полезную нагрузку изолированной в отдельном файле, скрытом от просмотра, они могут сделать видимую полезную нагрузку в view-source более незаметной и не столь очевидной.
На самом деле, это не первый раз, когда мы это видим. Три года назад мы также публиковали о скиммере кредитных карт, который использовал теги стиля (хотя и другим способом). Но как именно это работает?
Теги стилей обычно используются для включения CSS в HTML-документы, однако они также могут иметь атрибуты событий, такие как onload, что как раз и происходит здесь:
Onload выполнит скрипт, как только веб-страница завершит загрузку всего своего контента. Таким образом, тот факт, что обычные теги <script отсутствуют, не означает, что он не может выполнить JavaScript аналогичным образом в браузере жертвы, когда она вводит данные своей кредитной карты в поддельную платежную форму.
В конечном счете, это была очень хорошо продуманная и детальная атака скимминга. На странице оформления заказа не было явно вредоносных доменов, загружающих скрипты, след на странице оформления заказа был в целом довольно минимальным, а основная полезная нагрузка (в дополнение к расположению файла, скрытому сложной заменой символов) была искусно спрятана за изображением значка веб-сайта.
Источник
В этой статье мы расскажем, как мы обнаружили вредоносную инъекцию, проведем анализ нетрадиционных (хотя и не совсем уникальных) способов, которыми злоумышленники скрывали свою инъекцию и полезную нагрузку, как именно это работало, и, как всегда, рассмотрим несколько способов, с помощью которых администраторы сайтов электронной коммерции могут защитить себя от такой атаки.
Давайте начнем!
Проверка кассы
Одной из первых вещей, которую необходимо сделать при расследовании MageCart, является проверка страницы оформления заказа. Обычно это включает в себя имитацию транзакции на веб-сайте путем добавления товара в корзину, перехода на страницу оформления заказа и проверки кода. Хотя следует отметить, что этот метод работает только для скиммеров на основе JavaScript (а не PHP).Важно убедиться, что мы проверяем страницу оформления заказа, поскольку большинство вредоносных программ для кардинга пытаются оставаться скрытыми, появляясь только на URL-адресах, содержащих строку «checkout». Таким образом, вредоносная программа не загружается на каждой странице (ей это не нужно для выполнения того, что она хочет сделать) и ее легче скрыть от владельца веб-сайта и от внешних сканеров. В конце концов, нечасто администратор интернет-магазина будет покупать продукты у себя.
Теперь у нас в корзине есть товар, и мы перешли на страницу, где нам предлагается ввести платежные реквизиты:
На этом этапе нам нужно сделать 2-3 вещи, чтобы проверить, все ли в порядке:
- Проверьте наличие странной загрузки JavaScript на странице.
- Анализируйте веб-трафик на предмет подозрительных запросов.
- Проверьте исходный код страницы оформления заказа.
Для тех из вас, кто не знаком, щелкнув правой кнопкой мыши по веб-странице и выбрав пункт «Просмотр исходного кода », вы можете заглянуть «за кулисы» некоторых атрибутов и форматирования, из которых состоит веб-страница, отображаемая в вашем браузере.
В этом случае это был первый шаг к раскрытию того, как воровали карты клиентов клиента. Мы наткнулись на этот сомнительный пункт, прокручивая источник:
Это очень странный на вид код, и на первый взгляд не сразу понятно, что он вообще делает. Обратите внимание на теги <style (а не <script) — об этом позже.
Способ внедрения вредоносного ПО на страницу оформления заказа на самом деле был довольно прост: все, что сделали злоумышленники, — это просто отредактировали исходный код страницы оформления заказа либо из wp-admin (используя взломанную учетную запись администратора), либо напрямую через базу данных:
Это отличное напоминание о том, почему защита вашей панели wp-admin имеет первостепенное значение!
Обратный инжиниринг вредоносного ПО
Итак, теперь мы должны спросить: как именно этот бессмысленный код крал данные кредитной карты? Кажется, он не ссылается ни на что, очевидно связанное с кредитными картами (например, на номера, даты истечения срока действия или что-то еще, чего можно было бы ожидать).Особого внимания заслуживает вот эта строка, расположенная в центре образца:
Code:
%/spuenlmrt-rbpotepw.ao-eoo-ee1dukc/tc/cd-ci%leeitilntonpwpxgls-do%Это, конечно, выглядит как полный вздор. Но на самом деле это сильно запутанная строка и ключ к определению того, как это работает. Вредоносная программа использует специальный механизм скремблирования, использующий замену символов и перемешивание.
Используя логику запутывания и запустив ее в обратном порядке, мы можем восстановить исходный порядок символов и получаем следующее:
Code:
/wp-content/uploads/cropped-rec-unlimited-logo-1.webpНу, ну, ну! Давайте взглянем на этот файл «изображения» и посмотрим, что мы найдем:
Опять же, на первый взгляд, довольно непонятно. Однако, стоит отметить одну важную вещь: кусок данных в самом верху, который, кажется, не соответствует остальному:
Вот как обычно выглядит (реальный) файл изображения, открытый в текстовом редакторе. На самом деле, это были легитимные данные изображения. При открытии этого файла в обычной программе просмотра изображений мы увидели копию пользовательского значка зараженного веб-сайта! Это служит скрытой и важной цели: когда администратор веб-сайта прокручивает свою медиатеку в WordPress, этот файл просто отображается как значок дружественного соседства для своего веб-сайта и не вызывает никаких подозрений. Отдаем должное там, где это необходимо, это приятное внимание к деталям. Хотя, конечно, мы не будем включать сюда значок из соображений конфиденциальности.
Поддельный платежный оверлей
Содержимое файла .webp «image» было довольно большим, и там было много запутанного контента для анализа. Однако, чем ближе вы смотрите, тем больше это начинает походить на комплексный платежный портал, хотя и запутанный. Такие строки, как следующие, были даже читаемы в открытом виде:credit
expiry
CVV
company
HolderFirst
HolderLast
Name
SendData
GetCCInfo
А также жестко запрограммированные ссылки на платежный процессор, который он имитировал.
Итак, возникает вопрос – зачем злоумышленникам разделять свою полезную нагрузку таким образом? Почему бы просто не поместить поддельный платежный шлюз прямо на страницу оформления заказа WooCommerce? Ну, чтобы оставаться более скрытыми, конечно!
При проверке исходного кода зараженного сайта электронной коммерции некоторые варианты MageCart JavaScript болезненно очевидны для обнаружения. Например, этот код был обнаружен на странице оформления заказа зараженного сайта Magento:
Большие куски сильно запутанного JavaScript, как этот, торчат как больной большой палец, и это на самом деле совсем не трудно обнаружить. Сохраняя свою основную полезную нагрузку изолированной в отдельном файле, скрытом от просмотра, они могут сделать видимую полезную нагрузку в view-source более незаметной и не столь очевидной.
Теги стиля
Последняя деталь этого вредоносного ПО пока не объяснена: теги <style . Как вредоносное ПО может выполняться как JavaScript без тегов <script ?На самом деле, это не первый раз, когда мы это видим. Три года назад мы также публиковали о скиммере кредитных карт, который использовал теги стиля (хотя и другим способом). Но как именно это работает?
Теги стилей обычно используются для включения CSS в HTML-документы, однако они также могут иметь атрибуты событий, такие как onload, что как раз и происходит здесь:
Code:
<style onload="var _$_a10a=(functionOnload выполнит скрипт, как только веб-страница завершит загрузку всего своего контента. Таким образом, тот факт, что обычные теги <script отсутствуют, не означает, что он не может выполнить JavaScript аналогичным образом в браузере жертвы, когда она вводит данные своей кредитной карты в поддельную платежную форму.
В конечном счете, это была очень хорошо продуманная и детальная атака скимминга. На странице оформления заказа не было явно вредоносных доменов, загружающих скрипты, след на странице оформления заказа был в целом довольно минимальным, а основная полезная нагрузка (в дополнение к расположению файла, скрытому сложной заменой символов) была искусно спрятана за изображением значка веб-сайта.
Источник
