Stuxnet и Duqu — есть ли связь?

Тема кибероружия сейчас у всех на слуху. Больше всех любят эту тему муссировать эксперты Kaspersky Lab. По их заявлениям все значимые образцы ВПО последних трех лет связаны между собой. Например, Stuxnet и Duqu. Но так ли это на самом деле? Нужно признать, что материал по Stuxnet ^[1] далеко не полон. Например, отсутствует описание процедуры внедрения Stuxnet на компьютер. Похожа ли она, как заявляют сотрудники Kaspersky Lab, на аналогичную в Duqu? Ответ — не совсем. Но обо все по порядку.

Stuxnet (информация взята из аналитического отчета компании Symantec «W32.Stuxnet Dossier» ^[2], version 1.4, February 2011, pdf):

основной модуль представляет собой dll;
в dll содержится несколько ресурсов, в том числе два подписанных файла — драйвер автозагрузки и руткит для сокрытия факта заражения USB Flash носителя;
присутствует блок данных конфигурации (первая его половина зашифрована при помощи операции XOR 0xFF, вторая — другим способом).
При инсталляции основной модуль и подписанные файлы сохранялись на диск под именами, заданными в блоке данных конфигурации.
Для автозапуска создавалась служба, которая использовала подписанный драйвер.
В реестре по адресу 'HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMrxCls' в ключе 'Data' в зашифрованном виде сохранялись имена целевых процессов (services.exe, S7tgtopx.exe, CCProjectMgr.exe), в которые производился инжект.

Duqu (информация взята из аналитического отчета компании Symantec «W32.Duqu The precursor to the next Stuxnet» ^[3], version 1.4, November 2011, pdf):

инсталлятор представляет собой dll;
в dll содержится три блока данных, содержащих подписанный драйвер, основной модуль и данные конфигурации инсталлятора;
блок данных конфигурации инсталлятора зашифрован при помощи 7-байтового ключа (0x2b 0x72 0x73 0x34 0x99 0x71 0x98).
При инсталляции основной модуль и подписанные драйвера сохранялись на диск под именами, заданными в блоке данных конфигурации.
Для автозапуска создавалась служба, которая использовала подписанный драйвер.
В реестре по адресу 'HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesJmiNET3' в ключе 'FILTER' в зашифрованном виде сохранялись имя целевого процесса (services.exe), в который производился инжект.

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

Stuxnet и Duqu используют для вызова функции библиотек dll одинаковую методику, направленную на обход мониторинга средствами антивирусной защиты использования LoadLibrary. Для Ntdll.dll устанавливается перехватчик (hook) функций:
ZwMapViewOfSection;
ZwCreateSection;
ZwOpenFile;
ZwCloseFile;
ZwQueryAttributesFile;
ZwQuerySection.
Далее производится вызов LoadLibrary по специально выбранному имени библиотеки dll, несуществующей в системе. В обычных условиях (без перехвата) это вызвало бы ошибку. Именно перехватчик и производит загрузку настоящей библиотеки в адресное пространство.

Так же по информации ^[4] компании Eset, Stuxnet и Duqu используют одинаковую систему межпроцессорного взаимодействия (RPC), предназначенную для обновления компонентов ВПО в локальной сети.

Являются ли указанные факты явным доказательством связи Stuxnet и Duqu между собой? По-видимому, нет. Вышеописанное вполне может быть результатом заимствования метода внедрения в систему или кода процедуры RPC.

Теперь что касается драйверов. В Stuxnet использовался драйвер mrxcls.sys, подписанный сертификатом Realtek. Чуть позже был обнаружен другой драйвер, jmidebs.sys, подписанный JMicron. Последний везде был анонсирован как очередной драйвер Stuxnet, однако основной модуль с таким драйвером так и не был найден. Также были другие расхождения, драйвер mrxcls.sys использовал прямой вызов функций API по именам, драйвер jmidebs.sys — искал функции по их хэшам. Для внедрения основного модуля mrxcls.sys создавал файл-заглушку (exe) размером 6332 байта, jmidebs.sys — размером 7061 байта. Необычно то, что для расшифровки строк в реестре mrxcls.sys и jmidebs.sys использовали одинаковый ключ — 0xAE240682, который, впрочем, в других версиях Duqu был уже другим. Один из драйверов Duqu имел идентичные jmidebs.sys характеристики (размер файла-заглушки и ключ расшифровки). Таким образом, можно утверждать, что jmidebs.sys, ранее связываемый со Stuxnet, на самом деле — часть Duqu. Есть еще косвенный признак — для ветки Duqu название параметра в реестре набрано заглавными буквами — 'IDE' и 'FILTER', а у ветки Stuxnet — нет ('Data', 'Config' и 'Action'). Специалисты Dell SecureWorks считают, что сходство некоторых элементов обеих вредоносных программ является случайностью. Например, аналогичные методики применяются в других образцах ВПО. Использование имен рабочих файлов, начинающихся с символа '~', также не свидетельство родства. Не стоит также сбрасывать со счетов такую вещь, как подражательство. Исходя из временных отметок компиляции отдельных частей Duqu, его разработка могла относиться к началу 2007 года. Наиболее раннее его проявление в «диком» виде относится к 28 ноября 2008 года. Stuxnet, таким образом, был создан позже, с использованием нескольких технологий Duqu, либо их разработчики черпали информацию (или исходный код) из одного источника. Так что утверждение Микко Хиппонен из F-Secure: «Сходство кодов Duqu и Stuxnet очевидно. Драйвер ядра Duqu (jminet7.sys) настолько схож с драйвером Stuxnet (mrxcls.sys), что наши системы решили, что это и есть Stuxnet» — не совсем соответствует действительности (jminet7.sys и cmi4432.sys — драйвера Duqu, обнаруженные в Венгрии сотрудниками лаборатории CrySyS).

P.S. С целью повышения качества материала, приветствуется указание толковых источников информации на русском и английском языках по данной тематике в комментариях. На их основе будут дорабатываться существующие материалы. Так, в данный момент готовится статья непосредственно о Duqu, а так же дополнение информации о Stuxnet.

Автор: nuklearlord

Источник ^[5]