Тема кибероружия сейчас у всех на слуху. Больше всех любят эту тему муссировать эксперты Kaspersky Lab. По их заявлениям все значимые образцы ВПО последних трех лет связаны между собой. Например, Stuxnet и Duqu. Но так ли это на самом деле? Нужно признать, что материал по Stuxnet далеко не полон. Например, отсутствует описание процедуры внедрения Stuxnet на компьютер. Похожа ли она, как заявляют сотрудники Kaspersky Lab, на аналогичную в Duqu? Ответ — не совсем. Но обо все по порядку.
Stuxnet (информация взята из аналитического отчета компании Symantec «W32.Stuxnet Dossier», 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», 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, несуществующей в системе. В обычных условиях (без перехвата) это вызвало бы ошибку. Именно перехватчик и производит загрузку настоящей библиотеки в адресное пространство.
Так же по информации компании 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
