Тайна зашифрованного вредоносного функционала Gauss

В истории Gauss и Flame остается много загадок. Например, каким образом происходит заражение вредоносной программой? И каково назначение шрифта с уникальным названием Palida Narrow, устанавливаемого Gauss?

Вероятно, наиболее интригующая тайна – это зашифрованный блок кода Gauss. В состав программы входит модуль под названием Godel, содержащий зашифрованный функционал. Вредоносная программа пытается расшифровать этот функционал, используя несколько строк, взятых из системы, и в случае успеха выполняет расшифрованный код. Как мы ни старались, нам не удалось расшифровать код. Поэтому сегодня мы представляем всю известную нам информацию о зашифрованных данных в надежде, что кто-то найдет решение и сможет раскрыть секрет. Мы просим всех, кто интересуется криптологией и математикой, принять участие в наших усилиях по разгадке этой тайны и расшифровке скрытого вредоносного функционала.

Контейнеры

На зараженных USB-носителях присутствуют два файла, содержащие несколько зашифрованных секций. Файлы, носящие имена System32.dat и System32.bin, являются 32-битной и 64-битной версиями одного и того же кода. Эти файлы загружаются с зараженных носителей с использованием хорошо известного LNK-эксплойта, впервые появившегося в Stuxnet. Их главная задача – добыть как можно больше информации о системе жертвы и сохранить ее на том же носителе в файле под названием .thumbs.db. Несколько известных на сегодняшний день версий этих файлов содержат по три зашифрованных секции (одна секция кода и две секции данных).

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

К слову, в 64-битной версии модуля оставлена часть отладочной информации. Модуль содержит строки, используемые в отладочных сообщениях, и названия модулей:

.loader.cpp
NULL != encSection
Path
NULL != pathVar && curPos < pathVarSize
NULL != progFilesDirs && curPos < progFilesDirsSize
NULL != isExpected
NULL != key
(NULL != result) && (NULL !=str1) && (NULL != str2)
.encryption_funcs.cpp

Данные

Таинственные зашифрованные данные хранятся в трех секциях:

Файлы также содержат зашифрованный ресурс «100», который, скорее всего, и является собственно вредоносным функционалом, учитывая относительно небольшой размер зашифрованных секций. Вероятнее всего, секция .exsdat содержит код, необходимый для расшифровки ресурса и выполнения его содержимого.

Алгоритм

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

Валидация

1. Создать список всех записей из GetEnvironmentPathW(“Path”), используя в качестве разделителя символ «;»
2. Дополнить список всеми записями, возвращаемыми FindFirstFileW / FindNextFileW по маске “%PROGRAMFILES%*”, где cFileName[0] > 0x007A (UNICODE ‘z’)
   Замечание: по сути, это означает конкретную программу, установленную в “%PROGRAMFILES%”, имеющую имя, начинающееся со спецсимвола, такого как “~”, как в нашем примере, или использующее кодовую страницу UNICODE для других языков, скажем, арабского или иврита, где все коды символов больше, чем 0x007A.

3. Составить все возможные пары из элементов полученного списка.
4. Для каждой пары добавить первую заданную соль длиной 16 байтов и вычислить MD5-хеш.

   
   Пример пары строк, вторая из которых начинается с “~dir”, и первой соли

5. Вычислить MD5-хеш от хеша (т.е. hash = md5(hash) ) 10000 раз.
6. Проверить, соответствует ли полученный MD5-хеш заданному значению. Если нет, прекратить выполнение.

Расшифровка

Секции расшифровываются в следующем порядке: .exsdat, .exrdat, .exdat

1. Использовать пару PATH/PROGRAMFILES, использованную для вычисления «правильного» MD5-хеша валидационным кодом выше.
2. Добавить к паре вторую заданную соль длиной 16 байтов и байты 0x15, 0x00

   
   
   Пример пары строк, вторая из которых начинается с “~dir”, и второй соли

3. Вычислить MD5-хеш полученного буфера.
4. Вычислить MD5-хеш хеша (т.е. hash = md5(hash) ) 10000 раз.
5. Вычислить RC4-ключ на основе полученного хеша, используя функцию WinAPI CryptDeriveKey(hProv, CALG_RC4, hBaseData, 0, &hKey).
6. Расшифровать секцию (RC4), используя первый DWORD секции как длину расшифровываемого буфера, при этом зашифрованный буфер начинается со смещения 4 от начала секции.
7. Сравнить DWORD в расшифрованном буфере на позиции 0 или 7 с магическим значением “0x20332137”. Продолжить только в случае, если хотя бы один из DWORD совпадает.
8. Увеличить последний WORD в буфере пара+соль (первоначальное значение 0x0015) на 1.
9. Расшифровать следующую секцию, goto 3.

После расшифровки всех секций: вызвать функцию в начале секции .exsdat.

Пример данных для проверки алгоритма:

Пара строк получается путем их склеивания. Строки и соль в буфере не разделяются какими-либо символами.

Тестовые строки, в Unicode (без кавычек):

• “C:Documents and SettingsjohnLocal SettingsApplication DataGoogleChromeApplication”
• “~dir1”

Первая соль, hex-дамп: 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51
MD5 на шаге 6 валидации: 76405ce7f4e75e352c1cd4d9aeb6be41
Вторая соль, hex-дамп: BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21
MD5 на шаге 5 расшифровки: 00916031b3e9513044436ee42b6aa273

Примите участие в поиске ответа

Мы безуспешно перепробовали миллионы комбинаций известных имен в %PROGRAMFILES% и Path. Наличие проверки первого символа имен файлов в папке %PROGRAMFILES% показывает, что злоумышленники ищут совершенно конкретную программу, имя которой записано в расширенном наборе символов, например, используемом в арабском языке или иврите, или начинается со спецсимвола, например, “~”.

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

Секция ресурсов достаточно велика, чтобы содержать код целевой атаки, подобный примененной в Stuxnet атаке на SCADA-систему, а использованные авторами меры предосторожности свидетельствуют о том, что цель у этой атаки действительно чрезвычайно значимая.

Ниже мы приводим первые 32 байта зашифрованных данных и хеши для известных вариантов модулей. Если вы специалист по криптографии мирового класса или можете помочь нам в расшифровке, пожалуйста, напишите нам на электронный адрес: theflame@kaspersky.com.

Исходные данные

Ниже представлены hex-дампы до 32 первых байтов из начала каждой зашифрованной секции, не считая DWORD, в котором записана длина зашифрованного буфера. Пожалуйста, напишите нам на электронный адрес theflame@kaspersky.com, если вам требуются дополнительные фрагменты зашифрованных данных..