Вредоносная программа Flame использует для своего распространения несколько различных методов. Наиболее интересный – использование службы Microsoft Windows Update. Этот метод реализован в модулях SNACK, MUNCH и GADGET, входящих в состав Flame. Будучи составными частями Flame, эти модули легко поддаются перенастройке. Поведением этих модулей управляет глобальный реестр Flame – база данных, содержащая тысячи вариантов настроек.
SNACK: подмена NBNS
Модуль SNACK создает сетевой RAW-сокет для всех или предопределенных сетевых интерфейсов, после чего начинает получать все сетевые пакеты. Он ищет пакеты NBNS, посылаемые другими машинами, которые ищут в локальной сети компьютеры с определенными именами. При получении такого пакета он записывается в зашифрованный файл («%windir%temp~DEB93D.tmp») и передается на дальнейшую обработку.
Когда имя в запросе NBNS имеет вид «wpad*» или «MSHOME-F3BE293C», модуль SNACK отвечает отправкой IP-адреса компьютера, на котором он установлен. Если для переменной SNACK.USE_ATTACK_LIST установлено значение «True», то модуль также проверяет, какие из пакетов отправлены с IP-адресов, указанных в его списке SNACK.ATTACK_LIST, и отвечает тем машинам, адреса которых найдены в списке.
Wpad – это имя, используемое для автоматического обнаружения прокси-сервера. Отвечая на запросы «wpad» собственным IP-адресом, модуль SNACK объявляет зараженную машину прокси-сервером в локальной сети.
Модули SNACK и MUNCH также обмениваются данными с модулем GADGET, обеспечивающим обработку различных событий, приходящих из других модулей. Реестр Flame содержит модули, написанные на языке Lua, для обработки таких событий, как «MUNCH_ATTACKED», «SNACK_ENTITY.ATTACK_NOW».
MUNCH: поддельный прокси-сервер и перехват запросов в службу Windows Update
«MUNCH» – имя модуля Flame, выполняющего функции HTTP-сервера. Модуль запускается, только если переменная MUNCH.SHOULD_RUN установлена в значение «True» и не выполняются никакие программы, способные оповестить жертву о заражении. Эти программы (антивирусы, сетевые экраны, сетевые снифферы и т.д.) определены в реестре Flame в списке под названием «SECURITY.BAD_PROGRAMS»
При запуске модуля MUNCH он считывает буфер из переменной MUNCH.WPAD_DATA, заменяет шаблон «%%DEFAULT%%» IP-адресом наилучшего подходящего сетевого интерфейса и ожидает HTTP-запросов.
Содержимое переменной MUNCH.WPAD_DATAБуфер MUNCH.WPAD_DATA – это фактически WPAD-файл, запрашиваемый сетевыми клиентами, в которых включено автоматическое обнаружение прокси-сервера. Код в файле WPAD сопоставляет MD5-хеш имени хоста, с которым соединяется клиент, с собственным списком и, если значение хеша найдено в списке, предлагает себя в качестве HTTP прокси-сервера. Нам удалось определить имена, соответствующие хешам:
download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com
Таким образом, когда компьютер, на котором настроено автоматическое определение прокси-сервера, пытается установить соединение с одним из серверов Windows Update, он получает от модуля SNACK IP-адрес зараженной машины, а затем получает IP-адрес той же машины в качестве прокси-сервера из файла wpad.dat, выданного модулем MUNCH. С этого момента все запросы в службу Windows Update проходят через сервер, поднятый модулем MUNCH.
Когда сетевой клиент устанавливает соединение с сервером MUNCH и запрашивает URI, отличающийся от «/wpad.dat» и «/view.php», сервер:
1) Запускает «MUNCH.SHOULD_ATTACK_SCRIPT» – скрипт на Lua, проверяющий, соответствует ли заголовок User-Agent хотя бы одному из шаблонов, указанных в «MUNCH.USER_AGENTS.CAB_PATTERN_*». В имеющихся у нас файлах реестра Flame содержатся следующие шаблоны:
MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*
2) Проверяет, соответствуют ли запрашиваемые URI какому-нибудь из шаблонов, указанных в списке строк под названием «MUNCH.GENERIC_BUFFERS.*.data.PATTERN». Если одно из выражений соответствует запрашиваемому, сервер получает буфер, указанный в соответствующем значении «MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA», считывает значение имени вредоносного модуля в переменной «MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA» и отправляет соответствующий вредоносный модуль клиенту.
Все вредоносные модули перечислены в реестре Flame под именами, начинающимися с «MUNCH.GENERIC_BUFFERS_CONTENT.payload_name», и зашифрованы с помощью алгоритма RC4 с фиксированным 104-байтным ключом.
Шаблон URI | Имя вредоносного модуля |
*v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab* |
WUREDIR*/v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab*
WUSETUP
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab*XP_WUIDENT*v5/redir/wuredir.cab*XP_WUREDIR*download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/
AU/x86/XP/en/wusetup.cab*XP_WUSETUP*muauth.cab*MUAUTH*muredir.cab*MUREDIR*muident.cab*MUIDENT*/version_s.xmlVISTA_7_VERSION_S*/version.xmlVISTA_7_VERSION*v9/windowsupdate/redir/muv4wuredir.cab*
*v8/windowsupdate/redir/muv3wuredir.cab*
*v7/windowsupdate/redir/wuredir.cab*
*v6/windowsupdate/redir/wuredir.cab*
*ws03sp1/windowsupdate/redir/wuredir.cab*VISTA_7_WUREDIR*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab*VISTA_7_WUSETUPHANDLER*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab*VISTA_7_WUCLIENT*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab*VISTA_7_WSUS3SETUP*v9/windowsupdate/selfupdate/wuident.cab*VISTA_7_WUIDENT
Большинство вредоносных модулей представляют собой подписанные CAB-архивы. Архивы, содержащие вредоносный код, подписаны «MS» в декабре 2010 и ноябре 2011 года, в то время как остальные архивы, по-видимому, действительно взяты из настоящей службы Windows Update и подписаны «Microsoft Corporation».
Имена вредоносных модулей | Содержимое | Подпись |
WUREDIR_VISTA_7_WUREDIR_ | wuredir.xml | Microsoft Corporation_01 июля 2009 г. |
WUSETUP | Default/wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _Default/wuconf.ini _Default/wusetup.ocx _wsus3setup.cat _wsus3setup.inf _wuapplet2.ocx _wuaucom.dat _wuauinfo.ocx _wuconf.ini _wups2.cab _wups2.cat _wusetup.cat _wusetup.inf _wusetup.ocx_ |
MS
10 ноября 2011 г. |
XP_WUIDENT | wuident.txt | Microsoft Corporation 25 мая 2005 г. |
XP_WUREDIR | wuredir.xml | Microsoft Corporation 16 июня 2005 г. |
XP_WUSETUP | Default/ wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _wups2.cab _wusetup.cat _wusetup.inf _wusetup.ocx_ |
MS 28 декабря 2010 г. |
MUAUTH | authorization.xml | Microsoft Corporation 05 июня 2008 г. |
MUREDIR | wuredir.xml | «Microsoft Corporation 01 июля 2009 г. |
MUIDENT | muident.txt | MS 28 декабря 2010 г. |
VISTA_7_VERSION_S | отсутствует | не подписано |
VISTA_7_VERSION | 92 bytes, not a CAB file | не подписано |
VISTA_7_WUSETUPHANDLER | WuSetupV.exe | MS 28 декабря 2010 г. |
VISTA_7_WUCLIENT | update.cat _update.mum_ |
MS 28 декабря 2010 г. |
VISTA_7_WSUS3SETUP | WUClient-SelfUpdate- ActiveX~31bf3856ad364e35~x86~ ~7.0.6000.381.mum _WuPackages.xml_ |
MS 28 декабря 2010 г. |
VISTA_7_WUIDENT | wuident.txt | MS 28 декабря 2010 г. |
Поскольку CAB-файлы имеют действительные подписи (на данный момент отозванные Microsoft), служба Windows Update принимает и обрабатывает их как обычные обновления Windows. Они загружаются и устанавливаются, что приводит к выполнению вредоносного модуля.
Основной вредоносный модуль, содержащийся в этих CAB-файлах, представляет собой компонент-загрузчик под названием «Wusetup.ocx» или «WuSetupV.exe». Он собирает общие данные о компьютере, в т.ч. информацию о часовом поясе, и пытается обратиться к «http://MSHOME-F3BE293C/view.php», причем к URI в запросе добавляется информация о хосте. Поскольку имя «MSHOME-F3BE293C» обрабатывается модулем SNACK, URL указывает на действующий сервер MUNCH, который обслуживается главным модулем Flame «mssecmgr.ocx».
WuSetupV загружает этот файл, сохраняет его в «%windir%Temp~ZFF042.tmp», загружает его как DLL и запускает его функцию «DDEnumCallback», представляющую собой процедуру установки Flame. Таким образом, еще один компьютер оказывается заражен.
Даже «лучше», чем эксплойт нулевого дня
Сразу же после того, как мы обнаружили Flame, мы принялись искать в его коде хотя бы один эксплойт, использующих уязвимость нулевого дня для распространения Flame и заражения других машин в локальной сети. Учитывая сложность программы и тот факт, что она заражала машины, работающие под управлением Windows 7 с установленными необходимыми обновлениями, такой эксплойт должен был присутствовать. То, что мы обнаружили, даже «лучше» любого эксплойта нулевого дня. Это, скорее, напоминает чит-код в компьютерной игре, который включает «режим бога» – код, подписанный сертификатами, которые изначально были выписаны Microsoft. Цифровая подпись была обнаружена и немедленно отозвана Microsoft, после чего компания сразу же опубликовала информационное сообщение об угрозе (security advisory) и выпустила обновление KB2718704.
Flame: распространение через MITM-атаку и фальшивый прокси-сервер Windows Update