Чтобы снизить вероятность эксплойта свежей 0-day уязвимости в Internet Explorer, Microsoft предлагает установить новую версию своего инструмента Fix it. Это временное решение распространяется лишь на 32-битные версии IE. Внеочередной патч, закрывающий опасную дыру, планируется выпустить 21 сентября.

Помимо только что найденной уязвимости, которая уже эксплуатируется itw, грядущий пакет обновлений MS12-063 устранит еще 4 критические бреши в IE, связанные с проблемой удаленного выполнения кода. Новую версию Fix it, блокирующую выполнение некоторых скриптов, можно скачать на сайте техподдержки Microsoft. Фикс необязательно удалять после установки полноценной заплатки. Обновление, которому присвоен статус Critical, будет распространяться через Windows Update и другие стандартные каналы.

IE-уязвимость нулевого дня CVE-2012-4969 позволяет злоумышленнику через порчу памяти выполнить произвольный код в контексте текущего пользователя. Эксплойт запускается при заходе на специально сформированную страницу, куда пользователя могут заманить через ссылку в спам-письме или IM-сообщении. Брешь актуальна для Internet Explorer версий 9 и ниже, работающего под Windows XP, 7 или Vista.

О существовании 0-day уязвимости в IE стало известно в минувшие выходные, когда были обнародованы с результаты анализа нового эксплойта, найденного itw. Ввиду серьезности угрозы команда Metasploit поспешила обновить свою коллекцию, отметив, что риску подвержены 41% пользователей Северной Америки и 32% в остальных регионах. В начале недели эксперты AlienVault обнаружили еще несколько аналогичных эксплойтов, запущенных в Сеть.

Инициатором новой 0-day кампании предположительно является та же китайская криминальная группа, которая использовала Java-эксплойт нулевого дня, обнаруженный в конце августа (к CVE-2012-4681). По свидетельству AlienVault, основными мишенями злоумышленников являются предприятия оборонной промышленности США и Великобритании, а также сфера электроэнергетики. При отработке IE-эксплойта на машину пользователя устанавливается компонент удаленного администрирования ― Poison Ivy или PlugX.

Trend Micro опубликовала данные по кибератакам, использующим эксплойт-паки с новым Java-эксплойтом ― к CVE-2012-4681, уязвимости нулевого дня, обнаруженной в конце августа. Период исследования ― первые дни сентября

Эксплойт к CVE-2012-4681 был добавлен в коммерческие версии таких инструментов, как Blackhole, в течение суток после публикации новой опасной бреши в Java. Данная уязвимость связана с некорректной обработкой контроля доступа в рамках «защитных доменов». По оценке израильской security-компании Seculert, включение свежего 0-day эксплойта в состав Blackhole, на долю которого приходится свыше 85% эксплойт-пак площадок в интернете, повысило результативность этого комплекта в 2,5 раза. Патч к опасной бреши Oracle выпустила лишь 30 августа, спустя несколько дней после публикации.

Trend Micro как и ЛК, отслеживает и блокирует попытки эксплуатации CVE-2012-4681 с момента появления первых эксплойтов. В ходе одной из таких кибератак эксперты обнаружили свыше 300 доменов и более 100 серверов, используемых злоумышленниками для размещения страниц с эксплойтами. Около ⅔ этих доменов зарегистрированы в TLD-зонах .com (23%), .org, .net, .info и .ru (9%). Почти половина эксплойт-площадок были обнаружены на территории США, 27% ― в России. При этом ⅔ жертв нового Java-эксплойта ― американцы, остальные проживают, в основном, в странах Западной Европы, в том числе 10% в Германии, 7% в Италии.

По данным Trend Micro, потенциальные жертвы попадают на целевую площадку с набором эксплойтов разными путями: через спам, взломанный сайт-редирект, редирект с порноресурса, внешнюю ссылку или зловредный скрипт в контекстной рекламе. Спам-письма, зафиксированные Trend Micro в начале сентября, имитировали сообщения соцсети LinkedIn, антивируса, онлайн-сервиса eFax или службы денежных переводов Western Union. Все эти фальшивые послания были снабжены ссылками, ведущими на взломанный сайт, который перенаправлял пользователя на целевую страницу. Здесь выполнялся поиск уязвимостей в подключенной системе и, в случае успеха, активация надлежащего эксплойта.

Активное использование эксплойтов 0-day для Java, которое наблюдается и предотвращается нами вот уже целую неделю, чересчур активно и опрометчиво обсуждалось в интернете, а некоторые посты в блогах содержали ссылки на ресурсы, обслуживающие эти эксплойты. В действительности, подобное стремление раньше всех высказать свою точку зрения на проблему безответственно (кстати, уязвимости присвоен номер CVE-2012-4681 – проблема обработки контроля доступа в рамках «защитных доменов»). Скажите, вы бы посоветовали беззащитным прохожим идти по темной улице, на которой, как вы точно знаете, орудуют преступники? Или вы все-таки сообщите «куда следует» о местонахождении опасных элементов и, может быть, даже позаботитесь, чтобы улицы вашего района были хорошо освещены? Ну, или как минимум, вы просто предложите прохожему пойти другим маршрутом? В общем, на этот раз все попытки оказались не вовремя и не к месту…

Но так или иначе, первоначально сайты, на которых размещались эксплойты, были единичны и распространяли уже известные компоненты для APT, в том числе версию Poison Ivy. Ниже представлена карта ранней стадии активности компонента Poison Ivy, несколько удивляющая нас результатами:

А это карта фиксирует первые вспышки заражения Java-эксплойтами посредством веб-страниц и Java-скриптов:

Все вредоносные программы данной тематики, которые мне встречались, были нацелены на Windows. Эскплойты эффективны против Java 7. Со времени первых направленных атак информация об эксплойтах и их экземпляры успели попасть в руки специалистов по IT-безопасности, вот только за дело взялись разработчики Metasploit, которые добавили PoC в свою базу. А авторы BlackHole, в свою очередь, добавили эксплойт в свои пакеты COTS. Таким образом, эти атаки сразу стали распространенным явлением. Первыми жертвами команды Blackhole стали Соединенные Штаты, Россия, Беларусь, Германия, Украина и Молдова. Но, поскольку в пакет от Blackhole входят и разные другие эксплойты, удары по пользователям конкретно с помощью 0-day эксплойтов наносятся не всегда. Чаще всего страдают пользователи Internet Explorer, за ними следуют пользователи Firefox, Chrome и Opera, а замыкают список еще несколько приложений, имеющих дело с URL-ссылками внутри своих файлов и в конечном итоге направляющих вредоносные .jar-файлы в Java-клиенты, например, в Adobe Reader.

Для определения вредоносных сайтов и веб-страниц, кода эксплойта и вредоносного контента, получаемого с таких сайтов, мы используем ряд методик и техник. И хотя конкретно этот 0-day для Java становится повсеместно известным, мы все чаще детектируем и блокируем на системах пользователей и эксплойты постарше, также используемые в пакете Blackhole. Таким образом, пользователи «Лаборатории Касперского» так или иначе защищены от сайтов Blackhole и веб-страниц, обслуживающих 0-day эксплойт для Java, а также от взломанных сайтов, перенаправляющих посетителей на сайты Blackhole; от огромного числа предыдущих эксплойтов Blackhole и их сайтов, и от троянцев, получаемых через эти страницы. Ко всему прочему, модуль Kaspersky Advanced Exploit Prevention создает дополнительный уровень защиты против эксплойтов 0-day с помощью "Exploit.Java.Generic".

Лично для меня это дополнение наиболее интересно – авторы эксплойт-паков всегда концентрировались на улучшении серверного полиморфизма эксплойтов Java, а вышеописанная функция предотвращает эти попытки. Таким образом, доступ наших пользователей к сайтам Blackhole полностью блокируется, а с помощью компонента Advanced Exploit Prevention еще и предотвращаются любые попытки работы эксплойта. Отдельные веб-страницы Blackhole детектируются как "Trojan-Downloader.JS.Agent" в нескольких вариациях, бэкдоры детектируются как "Trojan.Win32.Generic" и т.п. (то есть, 61A3CE517FD8736AA32CAF9081F808B4, DEC9676E97AE998C75A58A02F33A66EA, 175EFFD7546CBC156E59DC42B7B9F969, 0C72DF76E96FA3C2A227F3FE4A9579F3). В свою очередь, Java 0day эксплойт выделяется среди других эксплойтов как "HEUR:Exploit.Java.Agent.gen" (то есть E441CF993D0242187898C192B207DC25, 70C555D2C6A09D208F52ACCC4787A4E2, E646B73C29310C01A097AA0330E24E7B, 353FD052F2211168DDC4586CB3A93D9F, 32A80AAE1E134AFB3D5C651948DCCC7D).

Так что, когда на Virustotal вы встретите неизбежные жалобы, что сканер не может найти часть измененного кода, или неточные выводы вроде «Антивирус неисправен!» или «Антивирус этого не детектирует!», не обращайте внимания. Потому что на самом деле вся эта история с массовыми client-side эксплойтами гораздо сложнее и глубже, чем эти жалобы.

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

Майкрософт выпустил блок из семи бюллетеней, в которых в общей сложности было исправлено 26 программных уязвимостей. Закрыто несколько брешей, которые делают возможным удалённое выполнение кода, но первоочередными являются обновления для Internet Explorer и Remote Desktop Protocol (RDP). Почти половина из 26 уязвимостей, закрытых в этом месяце, присутствуют в Internet Explorer 6, 7, 8 и 9 — и все они исправлены в бюллетене по безопасности MS12-037.

Протокол RDP не включен по умолчанию в системах Windows, однако закрытая в этом месяце уязвимость, которая делает возможным удалённое выполнение кода, является проблемой для многих компаний, подтверждением чего стала недавняя активность червя Morto. Многие компании испытывают необходимость в RPD, но используют его, зачастую не зная как это делать, или просто не утруждая себя тем, чтобы прятать порт за межсетевой экран, или ограничить доступ, или потребовать только VPN-доступ. Ранее вскрытые уязвимости преаутентификации в RPD должны были научить пользователей осторожности, и народ должен понимать, что лучше было бы этот сервис изолировать. В ближайшие недели мы увидим, воспользовался ли кто-нибудь этой уязвимостью. Установка патча MS12-036 является обязательной для всех ОС: от Windows 2003 до Windows Server 2008 R2 SP 1. Обновление имеет рейтинг «критически важный»: большинство версий ОС Windows Server уязвимы не только к DoS-атакам, но и к удаленному выполнению кода.

На большинстве компьютеров лицензионные Windows-системы с включенным обновлением обновились автоматически.

Обновления можно запустить и вручную, найдя в меню «Центр обновления Windows» и нажав кнопку «Проверка обновлений».

Две недели назад, когда мы сообщили об обнаружении шпионской программы Flame, мы говорили о том, что не усматриваем никакого совпадения в её коде или стиле программирования с платформой Tilded, на которой были основаны Stuxnet и Duqu.

Flame и Tilded совершенно разные проекты, основанные на разной архитектуре, и каждая использует свои уникальные трюки. Так, например, во Flame никогда не использовались драйвера, тогда как для Stuxnet и Duqu именно драйвер был основным способом загрузки модулей на исполнение.

Но мы оказались неправы. Неправы в том, что считали Flame и Stuxnet независимыми проектами.

Наше исследование выявило неизвестные ранее факты, которые полностью изменяют существующую на данный момент историю создания Stuxnet.

Flame внутри Stuxnet

Для начала необходимо вспомнить историю Stuxnet. Как считается, всего было создано три варианта этого червя – в июне 2009 года и в марте и апреле 2010.

Вариант от марта 2010 года вызвал наибольшее число заражений и был обнаружен в июне 2010 специалистами белорусской компании «ВирусБлокАда». Именно этот вариант и подвергся наиболее детальному исследованию со стороны антивирусных компаний.

Чуть позднее, когда о Stuxnet уже стало широко известно, были выявлены его файлы, относящиеся к июню 2009 года. Это так называемый Stuxnet.A (1.0), который достаточно сильно отличается от вариантов 2010 года.

Основными отличиями считались:

• Вариант 2009 не использует уязвимость в обработке LNK-файлов (MS10-046).
• В 2009 году Stuxnet содержал только один файл драйвера, в то время как в 2010 их стало два (второй был добавлен именно для распространения при помощи LNK-уязвимости).
• В 2009 году Stuxnet использовал трюк с autorun.inf для заражения USB-дисков.

Все прочие отличия заключались в незначительных изменениях внутренней структуры Stuxnet – некоторые модули были удалены, а их функционал перемещен в другие.

Самым значительным из этих изменений стал ресурс 207, который в версии 2009 года имел размер 520 192 байта и полностью отсутствовал в версии 2010 года.

Список ресурсов в Stuxnet 2010 года

Список ресурсов в Stuxnet 2009 года

Несмотря на то, что Stuxnet был объектом детального исследования многих компаний и экспертов, и об его устройстве написано множество текстов, каким-то образом ресурс 207 от 2009 года остался практически неисследованным. Но именно он и оказался тем самым связующим звеном между, казалось бы, совершенно разными проектами – Flame и Stuxnet.

История Tocy

В октябре 2010 года наша автоматическая система обработки получила из «дикой природы» файл. Он был автоматически проанализирован и классифицирован как новый вариант Stuxnet – Worm.Win32.Stuxnet.s.

Stuxnet в тот момент был громкой темой, и мы посмотрели на файл более внимательно, пытаясь понять, что же это такое. Выяснилось, что он не был похож на Stuxnet от 2010 года, отличия были весьма значительными. Посетовав на «глупую автоматическую систему», мы решили переименовать его в Trojan-Spy.Win32.Tocy.

Когда в 2012 году мы обнаружили Flame, мы стали искать старые экземпляры этого червя, которые могли быть получены нами ранее. Среди файлов, которые выглядели почти идентичными Flame, мы нашли Tocy.

Проверив в логах историю обработки файлов, мы установили, что изначально этот файл был классифицирован как Stuxnet. Мы задумались — как это могло произойти? Почему система думала, что этот образец Flame был связан со Stuxnet? Более детальный анализ логов показал, что Tocy, один из ранних модулей Flame, в действительности очень похож на 207 ресурс из Stuxnet.

Они настолько похожи, что наша автоматическая система посчитала его Stuxnet-ом. Более того, Tocy похож только на Stuxnet — и ни на какой другой файл в нашей коллекции.

Вредоносная программа 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.xml	VISTA_7_VERSION_S
*/version.xml	VISTA_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.

На конференции по безопасности CanSecWes, которая проходила в Ванкувере, Канада, я подменил Костина Райю и сделал доклад о нашем участии в исследовании командных серверов Duqu.

Тем временем, Google Chrome взломали. Опять. Сдаётся мне, что 60 тысяч долларов — не такие уж большие деньги за обнаружение уязвимости нулевого дня в Chrome, даже с учетом обхода песочницы. Вызывает удивление обнаружение сразу нескольких 0-day уязвимостей, особенно учитывая, как хорошо браузер показал себя на состязании хакеров Pwn2Own.

Я также нашёл весьма любопытными ответы Алекса Райса (Alex Rice) из Facebook на вопросы слушателей после презентации. Презентация Алекса была посвящена социальному CAPTCHA-коду — вторичной аутентификации, использующей фотографии френдов, которая начинает действовать, когда система подозревает, что аккаунт пользователя скомпрометирован или захвачен фишерами.

Введение этой системы означает, что массовые фишинг-атаки на Facebook ушли в прошлое — они стали неэффективными. Тем не менее, на презентации было много комментариев по поводу того, как эту систему можно обойти в ходе целевой атаки.

Очевидно, любую систему, которая устраняет целый класс атак, не влияя при этом на удобство пользователей, следует считать большим успехом. Facebook заслуживает похвалы за это решение; однако, компания пока получает в основном критику от пользователей.

Такое количество критики беспокоит: мы не должны отвергать идеи или системы только из-за того, что они оказались не слишком эффективными против целевых атак. Хорошо бы отойти от черно-белой парадигмы восприятия. В конце концов, большая часть (кибер-)преступности не направлена на четко определенные цели. Давайте не будем об этом забывать.

В последние несколько недель мы занимались исследованием инфраструктуры серверов управления, используемых Duqu.

Широко известен факт, что первоначально обнаруженные образцы Duqu использовали C&C в Индии, размещенный на площадке хостинговой компании WebWerks. Впоследствии был выявлен еще один сервер Duqu — базирующийся в Бельгии, у хостера Combell Group Nv.

«Лаборатория Касперского» в настоящий момент обнаружила более 12 различных вариантов Duqu. Среди них есть те, которые соединялись с серверами в Индии, в Бельгии, но также и с другими серверами — двумя во Вьетнаме и одним в Голландии. Кроме них, много других серверов были использованы авторами Duqu в организации всей сетевой инфраструктуры. Некоторые их них использовались как основные прокси-сервера, другие были предназначены для скрытия следов.

В целом, сейчас мы обнаружили более десятка различных серверов Duqu, которые были активны и функционировали на протяжении последних трех лет.

Прежде чем продолжить рассказ, мы должны сказать, что мы все еще не знаем, кто стоит за Duqu и Stuxnet. Хотя нам удалось захватить и проанализировать некоторые из серверов, атакующим удалось замести свои следы достаточно эффективно. 20 октября 2011 года, спустя три дня после публичного оглашения информации об обнаружении Duqu, они провели крупную операцию по «зачистке». Атакующие очистили каждый сервер, который они использовали как минимум с 2009 — в Индии, Вьетнаме, Германии, Великобритании и так далее. Тем не менее, несмотря на эту массовую акцию по скрытию следов, мы все же можем пролить некоторый свет на то, как работала сеть Duqu.

Драйвер

Драйвер является первым компонентом Duqu, который загружается в систему. По нашим данным, драйвер и другие компоненты этой вредоносной программы устанавливаются с помощью дроппера, использующего 0-day уязвимость (CVE-2011-3402). Драйвер прописывается в реестре по следующему пути: HKLM\System\CurrentControlSet\Services\. Конкретное имя ключа реестра отличается в разных версиях драйвера Duqu.

После загрузки драйвер расшифровывает маленький блок, содержащий ключ реестра и имя значения реестра, которое будет считано из этого ключа. Этот блок также содержит имя устройства, которое будет создано драйвером.

Все версии драйвера, которые нам известны, имеют одинаковое имя значения реестра: «FILTER».

Как мы сообщали ранее, в последнее время мы вели исследование ряда инцидентов, связанных с заражением троянцем Duqu. Нам удалось значительно продвинуться в понимании истории Duqu и собрать еще несколько отсутствующих компонентов, без которых понимание происходящего было затруднено.

Прежде всего мы бы хотели выразить огромную благодарность специалистам CERT Sudan. Они оказали неоценимую помощь в нашем расследовании и продемонстрировали профессионализм, полностью отвечающий смыслам и целям любого CERT в мире. Наше сотрудничество с суданским CERT продолжается и будет охватывать еще три инцидента, обнаруженных в данной стране.

Наибольшего же успеха нам удалось добиться в расследовании инцидента под порядковым номером #1, описанным в прошлой публикации. Нам удалось не только обнаружить все недостающие файлы этого варианта Duqu, но также обнаружить источник заражения и сам файл-дроппер, содержащий эксплойт уязвимости в win32k.sys (CVE-2011-3402).

Сопоставляя обнаруженные нами данные с данными, полученными другими исследователями и антивирусными компаниями, мы выявили совпадающие общие черты, которые раскрывают приблизительную хронологию событий и общую схему, по которой действовали создатели Duqu.