Пользователь
0,0
рейтинг
5 мая 2012 в 13:18

Разработка → О детектировании атак типа drive-by download и новых векторах распространения вредоносного ПО через Flash-баннеры

Сегодня мы хотим рассказать вам о новом виде drive-by download атаки с помощью Flash-баннеров, и о том, как с ним бороться. Такая атака позволяет злоумышленникам распространять вирусы через сайт, не взламывая его. Вредоносное ПО распространяется через рекламные Flash-баннеры, с помощью которых веб-мастера хотят монетизировать свой сайт. При этом они сами могут не подозревать, что установленный на веб-странице баннер сделал их портал частью сети распространения вирусов.

Вредоносный код
Выполнение вредоносного JavaScript-кода, например, в контексте веб-браузера, возможно благодаря принадлежащего классу ExternalInterface методу call(), который появился в версии ActionScript 3.0. Процесс выполнения JavaScript-кода в контексте веб-браузеров, поддерживающих возможность работы с ActiveX, реализуется через компонент ActiveX для Shockwave Flash. А для веб-браузеров без такой возможности используется плагин для Shockwave Flash. Компонент ActiveX или плагин разбирает байткод переданного ему на обработку Flash-файла и формирует JavaScript-код, который будет выполнен в контексте веб-браузера, если во Flash-файле присутствует такой функционал. После того как JavaScript-код сформирован, происходит его дальнейшая передача на обработку через функции JavaScript, заранее заложенные в компоненте ActiveX или плагине для Shockwave Flash. На рисунке 1 показан список таких функций.

image

Рис.1 – JavaScript-функции, с использованием которых происходит формирование и дальнейшее выполнение кода, переданного в ExcternalInterface.call()

Ниже показан безвредный JavaScript-код тестового Flash-баннера, сформированный для выполнения в контексте веб-браузера компонентом ActiveX или плагином для Shockwave Flash.




Посмотреть на Яндекс.Фотках

Рис.2 – JavaScript-код переданного в ExcternalInterface.call() тестового Flash-баннера, который сформирован компонентом ActiveX или плагином для Shockwave Flash


Посмотреть на Яндекс.Фотках

Рис.3 – Результат выполнения ExcternalInterface.call() из тестового Flash-баннера

На рисунке 3 показано окно плагина FireBug для браузера Firefox с результатом отображения тестового Flash-баннера и вызовом заготовленного JavaScript-кода, не совершающего вредоносных действий. Таким образом, используя метод call() принадлежащий классу ExternalInterface, можно вызвать любую функцию на языке JavaScript. Это позволяет злоумышленникам выполнять вредоносные действия.


Посмотреть на Яндекс.Фотках

Рис.4 – Вызов ExcternalInterface.call() из Flash-баннера для использования на HTML-странице внешнего JavaScript-сценария


Посмотреть на Яндекс.Фотках

Рис.5 – Вызов ExcternalInterface.call() из Flash-баннера для похищения сессионных данных с использованием JavaScript

Есть ряд ограничений для успешного выполнения JavaScript-кода из Flash-баннера, которые применимы к среде выполнения Flash-файла и описаны на официальной странице справочника для функции fscommand() из пакета flash.system и применимы для ExcternalInterface.call(). Такие ограничения применяются в зависимости от внешних параметров. А именно, если свойство allowScriptAccess имеет значение:

• sameDomain (по умолчанию) — работа со сценариями разрешена только для SWF-файлов, находящихся в том же домене, что и web-страница;
• always — SWF может обращаться к HTML-странице, в которую он встроен, даже если он находится на другом домене;
• never — SWF-файл не может обращаться ни к каким HTML-страницам.

Cистема выявления вредоносного контента на веб-страницах, разработанная Яндексом, впервые обнаружила использование данного метода выполнения вредоносного JavaScript-кода в декабре 2010 года.

На 24.04.2012 данный файл детектировался только одним антивирусом из 42, представленных на сервисе VirusTotal. А именно антивирусом Sophos с вердиктом Troj/SWFDlr-AB.
Хеш-суммы вредоносного SWF-файла:

• MD5: fd588c260cf38be7a7259c195da5b023
• SHA-1: 9db53d82392c85451e99cb7736ba7b30498e1624
• SHA-256: e15758a2f0ec5b6cb3203ee42d0454ffc7830a2026bcc3eebfdfa9bd0017c965

image

Рис.6 – Вредоносный Flash-баннер, детектируемый как Troj/SWFDlr-AB по классификации Sophos

Данный вредоносный SWF-файл содержит в своем теле ActionScript-код, который показан на рисунке ниже.


Посмотреть на Яндекс.Фотках

Рис.7 – Вредоносный код, передаваемый в метод ExcternalInterface.call() во Flash-баннере Troj/SWFDlr-AB

Как видно из этого рисунка, выполняется проверка значения поля User-Agent, переданного в HTTP-заголовке. В случае, если браузер не принадлежит семейству Chromium, и при этом обращение к данному Flash-приложению произошло с нужного адреса, указанного как во фрагменте кода на рисунке, на странице создается невидимый элемент, который подгружает вредоносный JavaScript-код по адресу hxxp://66.199.232.59/workarounds.js. На момент распространения вредоносного кода cкрипт из файла workarounds.js содержал функцию counts(). После выполнения эта функция создавала на странице скрытый элемент DIV, а внутри него — скрытый IFRAME. В атрибуте SRC последнего содержался адрес hxxp://nnuled.co.cc/in.cgi?3 — для перехода на TDS Sutra.


Посмотреть на Яндекс.Фотках

Рис.8 – Часть вредоносного кода функции counts() из файла workarounds.js

Далее с адреса hxxp://nnuled.co.cc/in.cgi?3 происходил переход на BlackHole Exploit Pack, располагавшегося по адресу hxxp://ds3c.co.cc/index.php?tp=50afe4b907e38c82. Оттуда уже и происходило распространение вредоносного ПО.

С момента первого обнаружения данного семейства вредоносных Flash-баннеров злоумышленники стали усложнять возможность детектирования вредоносных вызовов и вредоносного кода. Об этом свидетельствует вредоносный Flash-баннер, распространение которого было зафиксировано нами в середине апреля 2012 года. На тот момент обнаруженный файл не считал вредоносным ни один из антивирусов, представленных на сервисе VirusTotal.

Хеш-суммы вредоносного SWF-файла:
• MD5: 6daa91ce91eee37be0d89e351a7e3a3e
• SHA-1: bccc85031396e9c14911ed1c5e6829087eeb9893
• SHA-256: 92395014ac2a8a9e35eaf17f6e73b4fdd643538afbff0bf50afb80f0c6dfccfb

image

Рис.9 – Вредоносный Flash-баннер, зафиксированный в середине апреля 2012 года

По внешнему виду это обычный рекламный Flash-баннер, но в содержимом данного SWF-файла присутствует еще один SWF-файл.

image

Рис.10 – Flash-баннер, содержащий внутри себя еще один SWF-файл

Данный SWF-файл подгружается из бинарного массива с использованием ActionScript-кода, как показано на рисунке 11.


Посмотреть на Яндекс.Фотках

Рис.11 – Подгрузка SWF-файла из бинарного массива

Спрятанный ActionScript-код сильно обфусцирован. Для затруднения анализа кода используются мусорные инструкции, ложные трассы и зарезервированные слова (if, for, do, each и т.п.) в качестве имен методов и переменных, а также проверка — откуда было произведено обращение к Flash-баннеру и находится ли на данный момент приложение под отладкой. После деобфускации большие целочисленные двумерные массивы внутри ActionScript-кода преобразовываются в строки:

• superfoo
• file://
• StandAlone
• sendtoas
• en
• ru
• Rambler
• Mail.Ru
• YB
• Yx
• Ya
• Begun
• Google
• Bot
• bot
• GTB
• vkontakte
• mail.ru
• bing
• yahoo
• google
• yandex
• rambler
• Windows
• MSIE
• Explorer
• Firefox
• Opera

Вредоносный код проверяет значение поля User-Agent, переданного в HTTP-заголовке. Если оно не совпадает с одним из указанных в списке выше популярных браузеров или содержит подстроки, указывающие на то, что посетитель сайта — это поисковый робот, то вредоносный код прекращает свою работу. Также проверяется значение поля Referer переданного в HTTP-заголовке на предмет перехода со страницы поисковой выдачи или крупных порталов. Если все описанные выше условия выполняются, то происходит подгрузка JavaScript-кода, который хранится внутри вредоносного баннера в обфуcцированном виде. Ниже приведена часть деобфусцированного вредоносного JavaScript-кода, отображающая основную функцию его выполнения. Для того, чтобы вредоносный код было сложнее детектировать, после выполнения основного JavaScript-кода, выполняется код, который убирает следы вредоносной активности.

image

Рис.12 – JavaScript-код, убирающий следы вредоносной активности


Посмотреть на Яндекс.Фотках

Рис.13 – Деобфусцированный вредоносный JavaScript-код из SWF-файла

Вредоносный код создаёт на веб-странице невидимый контейнер, который подгружает вредоносный скрипт с ресурса <SUB>yadro-yadro.com, где <SUB> — случайное целое число. Оттуда происходит перенаправление на вредоносный хост в доменной зоне .cx, на котором на момент распространения вредоносного кода располагался Nuclear Exploit Pack.

Распространение вредоносного кода данным способом фиксируется поведенческим анализатором Яндекса достаточно редко, 1-2 раза за квартал. Но так как при этом вредоносные Flash-баннеры загружаются в основном со страниц известных порталов, ежедневно посещаемых большим количеством пользователей, количество заражённых компьютеров получается весьма существенным.

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

В частности, для распространения вредоносного кода чаще всего используются CMS, интегрированные с OpenX Ad Server. OpenX Ad Server — популярная система для управления рекламой на своем сайте, количеством её показов с указанием цены за клики и т.п. Злоумышленники выбирают именно те сайты, которые её используют, потому что в ней для созданного Flash-объекта параметр allowScriptAccess устанавливается в значение «always». После того как сайт, который использует для ротации рекламных баннеров OpenX Ad Server, найден (что несложно — данная система очень популярна), злоумышленникам остаётся только договориться о размещении на нём вредоносного Flash-объекта.


Посмотреть на Яндекс.Фотках

Рис.14 – JavaScript-код создания нового Flash-объекта в OpenX Ad Server

Заключение
Вероятно, через некоторое время подобные вредоносные Flash-приложения станут надёжно детектироваться обычными антивирусами, а уязвимости, которые они используют, будут закрыты. Но до тех пор, чтобы обеспечить безопасность пользователей своего сайта и стабильный трафик на него (заражение существенно снижает посещаемость), рекомендуем вам:

• Для запрета выполнения JavaScript-кода из Flash-приложений задать параметру allowScriptAccess значение «never». Также для запрета вызовов navigateToURL(), fscommand(), ExternalInterface.call() можно установить параметру allowNetworking значение «none» или «internal». К сожалению, это связано c необходимостью уменьшить функциональность Flash-приложений.
• Чтобы необходимый рекламным приложениям метод navigateToURL() смог работать, а опасный ExternalInterface.call() не смог, разместите Flash-баннеры на отдельном домене или поддомене, после чего установите параметру allowScriptAccess значение «sameDomain», а параметру allowNetworking – значение «all».
• Если для работы Flash-приложению необходимы максимальные полномочия – получите его исходный код, тщательно проверьте и скомпилируйте самостоятельно. Если при проверке найдёте методы navigateToURL(), fscommand(), ExternalInterface.call(), а также ExternalInterface.addCallback(), обфусцированный код и большие массивы данных — это повод обратиться за разъяснениями к тем, кто предложил вам разместить данное приложение на своём сайте.
• В качестве альтернативной технологии для анимированных интерактивных рекламных блоков можно использовать HTML5.

Более подробно об ограничениях, которые можно использовать, мы рекомендуем вам ознакомиться на официальной странице безопасности компании Adobe, а также на странице «Ограничение API-интерфейсов сетевого подключения».

Если у вас есть подозрения, что ваш сайт заражен или вы не хотите допустить его заражения, то вы можете воспользоваться рекомендациями по обеспечению безопасности сайта. О том, как обезопасить свой сайт от распространения с него вредоносного ПО, можно узнать из текста доклада команды безопасного поиска Яндекса на РИТ 2012.

Кроме того, мы регулярно публикуем исследования и аналитику в блоге Безопасного поиска Яндекса, следите за обновлениями.

Команда Безопасного поиска Яндекса
Тири @t1r1
карма
14,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (14)

  • +9
    allowScriptAccess устанавливается в значение «always» ага, это уязвимость флеша.
  • +1
    У нормальных антивирусов/файрволов те конечные адреса с эксплойтами и их сигнатуры должны быть в базах, поэтому все предыдущие манипуляции выглядят не опаснее пользователя, жмущего на сомнительные ссылки.
    • 0
      Адреса можно очень бодро менять и никакие антивирусы не угонятся.
      • +1
        Контент во флешке тоже можно шифровать так что не угонишься. Можно вообще полиморфную(не совсем честно конечно) флешку написать чтоб с сервера каждый раз разная флешка отдавалась и криптовалась на лету. Можно интерпритатор брейнфак машины прицепить и логику на брейнфаке сделать.
        • 0
          можно, но зачем?
          • +1
            Это к тому что я не понимаю зачем нужны антивирусы, и как они могут спасать от новых атак. Спасают только от старых. А если браузер запущен не от админа, а флешки пускаются без разрешения на модификацию страницы, то и бояться нечего.
            • 0
              Понятно, я удивился решению с привлечением брейнфака, сомнительно что это потребуется. На клиентской стороне вряд ли браузеры будут декомпилить код баннеров когда-либо. А на стороне сервера проблема имеет значительно более легкое решение описанное в коментах выше. allowScriptAccess = none, все.
        • 0
          Это повлияет только на сигнатуры, но не спасет от поведенческого анализа.
  • +1
    Надо 1й комментарий вынести в 1й абзац… Ппц жути навели…
    • 0
      Жуть состоит исключительно в том, что очень многие о значениях allowScriptAccess, да и других параметров, не задумываются, как баннерокрутилка ставит по умолчанию – так и оставляют. И уверены, что с ними такое никогда не случится, а потом, оставшись без трафика, пишут гневные письма в тех. поддержку. А ещё обфускация и защита от анализа довольно сильные.

      Впрочем, если загружать заражённый Flash-баннер с того же домена, что в большинстве случаев и делают, то для работы вредоносного кода достаточно и значения по умолчанию, «sameDomain». В документации Adobe написано, что Flash-баннеры сторонних производителей нужно размещать на отдельных поддоменах, но её мало кто читает.
      • 0
        Так вот зловредным ПО надо считать такие баннерокрутилки, где по дефолту разрешён allowScriptAccess
        • 0
          Такие баннерокрутилки являются уязвимыми, равно как браузер и его соответствующий компонент. То, что уязвимость является обратной стороной простоты, функциональности и «работы из коробки без проблем», сути не меняет. А вредоносным является код, который использует данные уязвимости.
          • 0
            Согласен, код который это использует вредоносен, т.е. вредоносен баннер. И сеть крутилок уязвима из-за неграмотной настройки. Флеш тут не причём совершенно.
  • 0
    Как для OpenX поставить allowScriptAccess = never?
    Нас, похоже, хакнули…

    Спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.