Back to Stuxnet: пропущенное звено

Две недели назад, когда мы сообщили об обнаружении шпионской программы 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 — и ни на какой другой файл в нашей коллекции.

Ресурс 207

На самом деле ресурс 207 представляет собой зашифрованный файл, который содержит еще один PE-файл (351 768 байт).

Информация о дате создания ресурса 207

Информация о файлеЭто и есть Flame. Точнее, это proto-Flame – модуль, который однозначно имеет много общего с тем mssecmgr.ocx, в который превратился Flame к 2012 году. Мы считаем, что можно говорить о целой платформе «Flame», на исходных кодах которой был создан данный модуль.

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

Совпадения модуля с известными образцами модулей Flame заключаются в следующем:

• Имена мьютексов: TH_POOL_SHD_PQOMGMN_%dSYNCMTX and TH_POOL_SHD_MTX_GMN94XQ_%d
• Алгоритм дешифровки строк
• Манглинг имен классов:?AVnxys_uwip и т.п
• Имя модуля схоже с используемой во Flame схеме с .ocx (atmpsvcn.ocx)

Кроме того, этот файл содержит в себе признаки, которые ранее считались принадлежащими исключительно Stuxnet:

• Имена файлов-триггеров: %temp%dat3A.tmp & snsm7551.tmp
• Утилитарные функции парсинга модулей и их взаимосвязь и архитектура
• Принципы формирования кодов возврата функций
• Схожий шеллкод
• Структуры, описывающие версии уязвимых ОС и алгоритм проверки
• Собственный импорт

Итак, это atmpsvcn.ocx – и это платформа Flame внутри Stuxnet.

Интересно, что известные на сегодняшний день варианты Flame прямо обращаются к файлу dat3C.tmp – в то время как Flame-модуль внутри Stuxnet использовал файл «dat3a.tmp» в качестве идентификатора присутствия в системе.

Целые куски кода из современных модулей Flame целиком идентичны коду из atmpvsvcn.ocx.
Конечно, наиболее явным визуальным сходством являются имена мьютексов:

TH_POOL_SHD_PQOMGMN_%dSYNCMTX
TH_POOL_SHD_MTX_GMN94XQ_%d

Кроме того, известны модули Flame, использующие мьютекс TH_POOL_SHD_MTX_FSW95XQ_%d, которые мы датируем 2010 годом — например, comspol32.ocx.

На уровне кода совпадения еще более впечатляющие:

getdecrypted function из 207 ресурса

getdecrypted function из mssecmgr.ocx

DecrypString function из Resource 207

DecryptString function из mssecmgr.ocx

DecryptString function из browse32.ocx (модуль деинсталлятора Flame, распространялся в мае-июне 2012 года)

Использование мьютексов в Resource 207

Использование мьютексов в mssecmgr.ocxОсновным функционалом этого модуля является обеспечение распространения Stuxnet при помощи autorun.inf на съемные USB-диски, а также эксплуатация ранее неотмеченной уязвимости в win32k.sys для повышения привилегий в системе на стадии заражения с USB-диска.

Ресурсы и их назначение в Stuxnet 2009 годаРаспространение при помощи autorun.inf – еще один трюк, который объединяет Stuxnet 2009 года и актуальные варианты Flame.

207 ресурс выполняет функцию инфектора съемных дисков, копируя на них модуль Flame под именем «autorun.inf», и добавляет настоящий autorun.inf в конец своего файла. Основное тело Stuxnet также копируется на USB-диск под именем «~XTRVWp.dat».

Исполняемый файл «autorun.inf» обрабатывается ОС как обычный autorun.inf и автоматически выполняется при обращении к зараженному USB-устройству (при включенной функции AutoPlay).

После этого модуль Flame загружает ~XTRVWp.dat (основное тело Stuxnet) с USB-диска и внедряет его в системные процессы, используя эксплойт к уязвимости для повышения привилегий.

Схема распространения через USB-дискиИменно этот код, один в один совпадающий с имеющимся в 207 ресурсе, используется Flame в настоящее время. Там он выполняется модулем «Autorun_infector».

Старый 0day

Отдельный интерес представляет уязвимость повышения привилегий.

Код эксплойта, содержащийся в atmpsvcn.ocx, написан аналогично коду, который был обнаружен нами в Stuxnet в варианте 2010 года (эксплуатируемая им уязвимость была исправлена патчем MS10-073). Стиль, логика и детали реализации идентичны в 2009 и в 2010 году — очевидно, оба кода были реализованы одним и тем же программистом.

Однако в Stuxnet 2009 использован другой эксплойт для другой уязвимости — более старой и уже исправленной к 2010 году. На время создания ресурса 207 (в феврале 2009) эта уязвимость еще не была публично известна и являлась 0day.

Суть уязвимости заключается в отсутствии проверки входных данных, что позволяет функции NtUserRegisterClassExWOW() перезаписать WORD за пределами предусмотренного диапазона в win32k.

В два приема перезаписывается адрес функции в структуре _gpsi на адрес шеллкода. Затем вызывается NtUserMessageCall(), которая и передаёт управление шеллкоду с привилегиями ядра.
Обе функции в usermode не экспортируются, поэтому адреса и параметры для непосредственного вызова сервисов находятся парсингом модулей на диске (user32&win32k).

Данное описание уязвимости весьма схоже с описанием уязвимости «Windows Kernel Could Allow Elevation of Privilege (968537)», исправленной в июне 2009 года патчем MS09-025, однако у нас пока нет 100% подтверждения, что в Stuxnet 2009 эксплуатировалась именно MS09-025.

Основная функция эксплуатации EoP уязвимости в Stuxnet 2009

Основная функция эксплуатации EoP уязвимости в Stuxnet 2010

Код вызова управляемых функций в уязвимости 2009 года

Код вызова управляемых функций в уязвимости в уязвимости 2010-073
Выводы

Наше исследование приводит нас к нескольким важным выводам, обобщенным ниже:

• К моменту создания Stuxnet (в январе-июне 2009) платформа Flame уже существовала (в настоящее время мы относим её создание как минимум к лету 2008 года) и уже тогда обладала модульной структурой.
• В коде Stuxnet 2009 года использовался модуль, относящийся к платформе Flame, вероятно созданный специально для работы в составе Stuxnet.
• Этот модуль был удален из Stuxnet в 2010 году по причине добавления использования нового способа распространения (уязвимость MS10-046) вместо «старого» autorun.inf.
• Модуль Flame в Stuxnet содержал эксплойт к неизвестной на тот момент уязвимости для повышения привилегий, предположительно MS09-025.
• В 2009-2012 годах развитие платформы Flame продолжалось независимо от Stuxnet.

Выводы свидетельствует о существовании двух независимых команд разработчиков, которые условно можно назвать Team F (Flame) и Team D (Tilded). Каждая из этих команд как минимум с 2007-2008 годов вела разработку собственных платформ.

В 2009 году часть кода платформы Flame была использована в Stuxnet. По нашему мнению, использовались именно исходные коды, а не готовые бинарные модули. С 2010 года платформы продолжали развиваться независимо друг от друга, однако взаимодействуя друг с другом как минимум на уровне использования одних и тех же уязвимостей.