Flame: распространение через MITM-атаку и фальшивый прокси-сервер Windows Update

Вредоносная программа 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.

Публикации на схожие темы

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *