На неделе CIO мы объявили об общедоступности нашего продукта для обеспечения безопасности на стороне клиента, Page Shield. Page Shield защищает конечных пользователей веб-сайтов от атак на стороне клиента, нацеленных на уязвимые зависимости JavaScript для запуска вредоносного кода в браузере жертвы. Одной из самых больших угроз на стороне клиента является эксфильтрация конфиденциальных пользовательских данных в домен, контролируемый злоумышленниками (известная как атака в стиле Magecart). Такого рода атаки затронули такие крупные организации, как British Airways и Ticketmaster, что привело к значительным штрафам GDPR в обоих случаях. Сегодня мы делимся подробностями о том, как мы обнаруживаем эти типы атак и как мы собираемся развивать продукт в будущем.
Как работает атака в стиле Mageccart?
Атаки в стиле Mageccart, как правило, довольно просты и включают всего два этапа. Сначала злоумышленник находит способ скомпрометировать один из файлов JavaScript, запущенных на веб-сайте жертвы. Затем злоумышленник вставляет вредоносный код, который считывает информацию, позволяющую установить личность (PII), которую вводят пользователи сайта, и эксфильтрирует ее в домен, контролируемый злоумышленником. Это показано на диаграмме ниже.
Атаки в стиле Magecart вызывают особую озабоченность у интернет-магазинов, где пользователи вводят данные кредитной карты на странице оформления заказа. Формы для онлайн-банкинга также являются важными целями, наряду со страницами входа и везде, где вы вводите личные данные в Интернете.
У злоумышленников есть несколько путей, по которым они могут скомпрометировать популярную библиотеку и запустить свой вредоносный код на веб-сайте неизвестного поставщика, в том числе:
- Компрометация сторонних провайдеров
- Компрометация самого сайта
- Использование уязвимостей
Часто скомпрометированы сами сторонние поставщики, и злоумышленники получают возможность изменять код, который распространяется на ряд веб-сайтов; так было в случае взлома Ibenta, который скомпрометировал Ticketmaster. В качестве альтернативы, если злоумышленники получат административный доступ к самому сайту, они могут изменить один из используемых сценариев и вставить свой вредоносный код, что произошло в 2018 году с British Airways. Библиотеки, срок службы которых истек и которые больше не поддерживаются их создателями, уязвимы для эксплойтов нулевого дня. Было замечено, что автоматизированные атаки компрометируют тысячи страниц оформления заказа за один раз, используя это преимущество.
Что можно с этим сделать?
Поставщики безопасности приложений и группы безопасности могут предоставить владельцам сайтов несколько защитных механизмов, в том числе:
Политики безопасности контента: Page Shield использует политику безопасности контента (CSP), развернутую с директивой только для отчетов, для сбора информации из браузера о сценариях, запущенных в приложении. Это позволяет нам предоставлять владельцам приложений базовую информацию о файлах, работающих на их сайтах.
Статический анализ: Загрузка сценария и выполнение автоматического анализа контента с использованием методов машинного обучения или баз данных рукописных подписей может выявить вредоносные сценарии, которые в противном случае остались бы незамеченными.
Каналы угроз: Базы данных вредоносных имен хостов или URL-адресов эффективно перехватывают известные нам вредоносные программы и дополняют возможности обнаружения, нацеленные на новые атаки.
Проверки целостности подресурсов: Владельцы приложений могут включать криптографический хэш файлов, которые они загружают, в атрибут «целостность» любого скрипта или ссылки. Это эффективно для защиты от неожиданных изменений в источнике злоумышленниками.
Проверка внешнего соединения: Извлечение списка внешних подключений, создаваемых каждым сценарием, и сравнение их с черными и белыми списками может помочь выявить попытки вредоносной эксфильтрации на домены, контролируемые злоумышленниками.
В настоящее время Page Shield использует отчеты CSP, каналы анализа угроз и статический анализ на основе машинного обучения для обнаружения вредоносных скриптов. Мы считаем, что статический анализ играет важную роль в обнаружении угроз на стороне клиента с возможностью обнаружения атак, которые вряд ли будут обнаружены с помощью других механизмов.
Некоторые способы, которыми мы проводим статический анализ
Наша система статического анализа охватывает два сценария:
- Код читабелен, а его функциональность не скрыта
- Функциональность кода скрыта (со злым умыслом или без него)
Это дает четыре категории сценариев для анализа:
- Доброкачественные сценарии
- Вредоносные скрипты
- Обфусцированные или минимизированные безопасные скрипты
- Обфусцированные вредоносные скрипты
Мы разработали отдельные модели для двух упомянутых выше сценариев. Первый нацелен на обнаружение «чистых» скриптов, код которых не скрыт. Второй анализирует запутанные сценарии и различает вредоносный и безопасный контент.
Обнаружение «чистых» вредоносных сценариев основано на анализе свойств потока данных сценария, полученных из представления сценария, называемого абстрактным синтаксическим деревом. Рассмотрим следующий очень простой пример сценария:
С этим сценарием связано абстрактное синтаксическое дерево (AST), графическое представление структуры программы и ключевой инструмент статического анализа вредоносных программ. На приведенной ниже диаграмме показан пример AST из приведенного выше фрагмента кода.
Page Shield использует AST сценария, чтобы определить, произошли ли значительные изменения в структуре программы (инициируя оповещение об изменении), а также для получения соответствующего графа потока данных сценария, который отслеживает поток данных между назначениями переменных и вызовами функций. . На рисунке ниже показан график потока необработанных данных, полученный из AST для нашего простого примера.
Мы разработали модель машинного обучения, способную идентифицировать узлы на графике, которые относятся к чтению PII или краже вредоносных данных, что дает вероятности на графике, показанном ниже. Узлы, выделенные синим цветом, были классифицированы как связанные с PII, а узлы красного цвета — как связанные с эксфильтрацией данных:
Скрипт может быть классифицирован как вредоносный, если связанный путь на графике между узлами, участвующими в чтении PII, и узлами, входящими в состав вызова эксфильтрации данных в контролируемый злоумышленником домен:
Модели, не зависящие от связи между вызовом чтения PII и эксфильтрацией, склонны к ложным срабатываниям в сценариях, где они не связаны. Наш подход, основанный на потоке данных, позволяет нам эффективно обнаруживать атаки, исключая ложные срабатывания из-за отключенной логики.
Злоумышленники, однако, обычно пытаются избежать обнаружения и, чтобы не быть обнаруженными, часто скрывают свои атаки, кодируя и трансформируя контент до неузнаваемости. Наша вторая модель обрабатывает этот тип контента и способна различать доброкачественное и злонамеренное использование обфускации.
В приведенном ниже примере показана атака, скрытая за счет включения строк в шестнадцатеричном кодировании в список. _0xb902 на который впоследствии ссылаются.
Нормализация содержимого путем декодирования шестнадцатеричных цифр в шестнадцатеричных подстроках позволяет выявить ряд ключевых слов JavaScript, используемых в ходе атаки.
Концепция «выявленного риска» — насколько рискован раскрытый контент — составляет основу нашего подхода к разграничению запутанного вредоносного ПО и законного использования кодирования символов или минимизации. Например, обнаружение таких ключевых слов, как «cc_number» и «stringify» в приведенном выше примере дает сильный сигнал о том, что это атака.
Однако анализ выявленного риска работает только в том случае, если вы можете нормализовать контент. Часто злоумышленники выходят далеко за рамки простых схем кодирования символов, чтобы скрыть свой вредоносный код. Обычно во вредоносных скриптах можно увидеть настраиваемые функции обфускации, которые могут применять любую произвольную серию преобразований к входной строке. Например, рассмотрим потенциальную функцию кодирования:
Это преобразует строку document.getElementById
к 646u63756s656t742t676574456r656s656t7442794964.
Функция декодирования, определенная в скрипте, будет следующей:
Нормализация строк, подвергшихся сложным преобразованиям, требует выполнения кода, поэтому, чтобы избежать тривиального обхода схемы кодирования, подобной приведенной выше, наша модель также обнаруживает наличие вредоносных закодированных строк, которые не могут быть нормализованы.
Благодаря нашему подходу к раздельному анализу чистого и запутанного содержимого, поиску связанных путей на графе потоков данных, обнаружению рисков или произвольным преобразованиям строк, мы смогли обнаружить большинство атак, которые мы наблюдали на сегодняшний день. Мы рады видеть, что мы обнаруживаем, поскольку мы привлекаем больше клиентов к Page Shield, и продолжим развивать наши возможности обнаружения с течением времени.
Что дальше?
Мы постоянно совершенствуем наши модели и в ближайшие месяцы будем расширять оценку риска на основе контента, чтобы включить другие типы атак, такие как крипто-майнинг и рекламное ПО. Корпоративные клиенты могут подписаться на корпоративную надстройку Page Shield, которая включает обнаружение атак в стиле Magecart на основе содержимого в зависимостях JavaScript ваших сайтов.
Подпишитесь на Page Shield сегодня, чтобы защитить данные своих клиентов.
