El misterio de la “carga útil” codificada de Gauss

Todavía quedan muchos misterios alrededor de Gauss y Flame. ¿Cómo se infecta la gente con este malware? ¿Cuál es el propósito de la fuente “Palida Narrow” que Gauss instala en los equipos infectados?

Pero tal vez uno de los misterios más interesantes es la “carga útil” codificada de Gauss. Gauss contiene un módulo llamado “Godel” con una “carga útil” codificada. El malware trata de decodificar esta carga usando muchas cadenas de caracteres del sistema y, cuando lo logra, la ejecuta. Aunque nos esforzamos, no pudimos romper su codificación. Por eso hoy presentamos toda la información disponible sobre la “carga útil”, con la esperanza de que alguien más pueda encontrar una solución y liberar sus secretos. Pedimos a las personas interesadas en criptografía y matemáticas que se unan para resolver el misterio y extraer la “carga útil” escondida.

Los contenedores

Los dispositivos USB tienen dos archivos con muchas secciones codificadas. Se llaman “System32.dat” y “System32.bin” y son las versiones de 32-bit y 64-bit del mismo código. Estos archivos se cargan desde discos infectados usando el conocido exploit LNK que introdujo Stuxnet. Su meta principal es extraer mucha información sobre el sistema de la víctima y escribirla en un archivo que se guarda en un disco llamado “.thumbs.db”. Muchas versiones conocidas de estos archivos contienen tres secciones codificadas (una sección de códigos y dos de datos).

La llave de decodificación de estas secciones se genera de forma dinámica y depende de las características del sistema de la víctima, para que nadie, excepto los objetivos designados, extraiga los contenidos de las secciones.

Por cierto, a la versión de 64 bits del módulo le queda algo de información de depuración. El módulo contiene cadenas de caracteres de afirmación de depuración y nombres de los módulos:

.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

Los datos

Los misteriosos datos codificados se guardan en tres secciones:

Los archivos también contienen el recurso codificado “100”, que parece ser la “carga útil” en sí, a juzgar por el tamaño relativamente pequeño de las secciones codificadas. Lo más probable es que la sección “.exsdat” contenga el código para decodificar el recurso y ejecutar sus contenidos.

El algoritmo

El código que decodifica las secciones es muy complejo comparado con las rutinas regulares que solemos encontrar en los programas maliciosos. Esta es una descripción breve del algoritmo:

Validación

1. Realiza una lista de todas las entradas desde GetEnvironmentPathW(“Path”), divididas por un separador “;”
2. Anexa la lista con todas las entradas que devuelve FindFirstFileW / FindNextFileW según la máscara “%PROGRAMFILES%*”, donde cFileName[0] > 0x007A (UNICODE ‘z’)
Nota: en esencia, esto significa que el programa específico que se instala en “%PROGRAMFILES%” tiene un nombre que comienza con un carácter especial como “~”, como en nuestro ejemplo, o utiliza una tabla de caracteres especiales UNICODE, como árabe o hebreo, donde todos los caracteres son mayores que 0x007A.
3. Realiza todos los pares posibles con las entradas de la lista resultante.
4. para cada par,anexa la primera sal de 16 bytes en el código fuente (hardcoded) y calcula el hash MD5.

Ejemplo del par de cadenas de caracteres, la segunda cadena comienza en “~dir” y la primera sal.
5. Calcula el MD5 desde el hash (es decir, hash = md5(hash) ), 10.000 veces.
6. Compara si el hash MD5 coincide con el valor hard-coded. Si no, se retira.

Decodificación

Las secciones se decodifican en el siguiente orden: .exsdat, .exrdat, .exdat
1. Utiliza el par PATH/PROGRAMFILES que se usó para generar el hash MD5 previsto en la validación del código de arriba.
2. Anexa el par con la segunda sal hard-coded de 16 bytes y los bytes 0x15 y 0x00

Ejemplo del par de cadenas de caracteres, la segunda cadena comienza en “~dir” y la primera sal.

3. Calcula el hash MD5 desde el búfer resultante.
4. Calcula el hash MD5 desde el hash (es decir, hash = md5(hash) ), 10.000 veces.
5. Deriva la llave RC4 del hash resultante usando el CryptDeriveKey de WinAPI (hProv, CALG_RC4, hBaseData, 0, &hKey).
6. Decodifica la sección (RC4), tratando su primer DWORD como la longitud del búfer a decodificar y el búfer codificado que comienza en offset 4 de la sección.
7. Compara DWORDs en el búfer decodificado en posiciones 0 o 7 con el valor mágico “0x20332137”. Continúan sólo si alguna de las DWORDs coincide.
8. Aumenta 1 a la última WORD en el búfer par+sal (el que al principio se fijó en 0x0015).
9. Decodifica otra sección, ve a 3.
Después de que se decodifican todas las secciones : llama a la función al principio de la sección exsdat.

Datos de muestra para validar el algoritmo:

El par de cadenas de caracteres se crea entrelazando las secuencias. Las secuencias y el búfer sal no están separados por ningún carácter.
Cadena de caracteres de muestra, Unicode (sin comillas):

• “C:Documents and SettingsjohnLocal SettingsApplication DataGoogleChromeApplication”

• “~dir1”

Primera sal, volcado hexadecimal: 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51
MD5 en el paso 6 de validación: 76405ce7f4e75e352c1cd4d9aeb6be41
Segunda sal, volcado hexadecimal: BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21
MD5 en el paso 5 de la decodificación: 00916031b3e9513044436ee42b6aa273

¡Únete a la misión!

Hemos probado millones de combinaciones de nombres conocidos en %PROGRAMFILES% y Path, pero sin éxito. La revisión del primer carácter de la carpeta en %PROGRAMFILES% indica que los atacantes buscan un programa muy específico con el nombre escrito con caracteres extendidos, como árabe o hebreo, o alguno que comience con un símbolo especial como “~”.

Por supuesto, es obvio que no es posible romper la codificación con un simple ataque de fuerza bruta. Pedimos a todos los interesados en romper el código y descubrir la misteriosa “carga útil” que se unan a nosotros.
La sección de recursos es bastante grande como para contener un código de ataque dirigido SCADA como el de Stuxnet, y todas las precauciones que tomaron los autores indican que el objetivo de los ataques es muy importante.

Ofrecemos los primeros 32 bytes de datos codificados y hashes de variantes conocidas de los módulos. Si eres un criptógrafo reconocido mundialmente o puedes ayudarnos a decodificarlos, por favor escríbenos a: theflame@kaspersky.com.

Datos de la fuente

Entregamos hasta 32 bytes del principio de cada sección codificada, excepto el DWORD que contiene la longitud del búfer codificado. Por favor escríbenos a theflame@kaspersky.com si necesitas más datos codificados.