Веб-скимминг с помощью Google Analytics

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

Чтобы сделать отправку данных на сторонний ресурс менее заметной, мошенники часто регистрируют домены, напоминающие имена популярных веб-сервисов, в частности Google Analytics (google-anatytics[.]com, google-analytcsapi[.]com, google-analytc[.]com, google-anaiytlcs[.]com, google-analytics[.]top, google-analytics[.]cm, google-analytics[.]to, google-analytics-js[.]com, googlc-analytics[.]com  и т. п.). Но как удалось установить, в атаках такого рода может быть использован и оригинальный сервис.

Чтобы с помощью Google Analytics собирать данные о посетителях, владелец сайта должен настроить параметры отслеживания в личном кабинете на analytics.google.com, получить код отслеживания (trackingId — строка вида UA-XXXX-Y) и вставить на страницы ресурса трекинг-код с ним. При этом на одном сайте могут уживаться несколько трекинг-кодов, отправляющих данные о посетителях в разные аккаунты «аналитики».

Недавно мы выявили несколько случаев нецелевого использования сервиса Google: атакующий внедрял на сайт вредоносный код, который собирал все данные, вводимые пользователями, и затем отправлял их с помощью протокола «аналитики». В результате атакующий получал доступ к украденным данным в своем личном кабинете Google Analytics. Нами было обнаружено порядка двух десятков зараженных сайтов по всему миру. Среди жертв — магазины из Европы, Северной и Южной Америки, торгующие цифровой техникой, косметикой, продуктами питания и запчастями.

Как выглядит «инфекция», можно увидеть на скриншоте ниже  — вредоносный код с трекинг-кодом и trackingId злоумышленника:

Скриншот 1

Атакующий старается скрыть вредоносную активность с помощью классической техники антиотладки. На скриншоте 2 — проверка, не включен ли в браузере посетителя режим разработчика. Код на скриншоте выше выполнится только в случае, если она пройдена.

Скриншот 2

Любопытно, что злоумышленник оставил себе лазейку — возможность наблюдать работу скрипта в режиме отладки. Если в локальном хранилище браузера (Local Storage) есть значение ‘debug_mode’==’11’, вредоносный код отработает и при открытых инструментах разработчика и даже будет писать в консоль комментарии на корявом (с ошибками) английском языке. На скриншоте 3 строка с проверкой ‘debug_mode’ следует за реализацией алгоритма шифрования RC4 (который используется для шифрования собранных данных перед отправкой).

Скриншот 3

Если антиотладка пройдена, скрипт собирает все введенное пользователем на сайте (а также данные о нем самом, такие как IP-адрес, UserAgent, временная зона пользователя). Собранные данные шифруются и отправляются при помощи протокола измерений Google Analytics (Google Analytics Measurement Protocol). Процесс сбора и отправки отражен на скриншоте 4.

Скриншот 4

Украденные данные отправляются при помощи вызова метода send event в поле ‘eventAction’.

Сигнатура вызова в этом случае:

Это приводит к отправке HTTP-запроса на URL
https[:]//www.google-analytics.com/collect?<параметры>&ea=packed_stolen_data&<параметры>

В описанном выше случае вредоносный код вставлен в один из скриптов зараженного сайта в «читабельном» виде. Однако в других случаях инжект может быть обфусцирован. Также вредоносный код может загружаться со стороннего ресурса. На скриншоте 5 пример обфусцированного варианта. В этом варианте на зараженном сайте вставлен вызов вредоносного скрипта с firebasestorage.googleapis[.]com.

Скриншот 5

После деобфускации мы получаем аналогичный скрипт с теми же характерными комментариями. Часть его кода представлена на скриншоте 6 (используется другой trackingId).

Скриншот 6

В чем опасность

Google Analytics — крайне популярный сервис (по данным BuiltWith, он используется более чем на 29 миллионах сайтов), которому пользователи доверяют: администраторы прописывают *.google-analytics.com в заголовке Content-Security-Policy (служит для перечисления ресурсов, с которых может загружаться сторонний код), разрешая сбор данных этому сервису. Кроме того, атака может быть реализована и без загрузки кода «со стороны».

Как избежать проблем

Пользователям:

• Установите защитное ПО. Защитные решения «Лаборатории Касперского» детектируют вредоносные скрипты, которые используются в подобных атаках, как HEUR:Trojan-PSW.Script.Generic.

Веб-мастерам:

• Не устанавливайте дистрибутивы веб-приложений и компоненты CMS из недоверенных источников.
• Своевременно обновляйте используемое ПО. Следите за новостями об обнаруженных уязвимостях и следуйте рекомендациям по их исправлению.
• Придумайте надежные пароли для учетных записей, которые используются для администрирования.
• Ограничьте права пользователей минимально необходимым набором. Следите за количеством пользователей, имеющих доступ к служебным интерфейсам.
• Фильтруйте вводимые пользователем данные и параметры запросов во избежание внедрения стороннего кода.
• Для ресурсов e-commerce желательно использовать платежные шлюзы, соответствующие требованиям PCI DSS.

IOCs

firebasestorage.googleapis[.]com/v0/b/bragvintage-f929b.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/canature-5fab3.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/ericeirasurfskate-559bf.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/gluten-8e34e.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/laser-43e6f.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/movile-720cd.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/plumb-99e97.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/redfox-64c35.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/tictoc-9677e.appspot.com/o/*