Autores
Mientras analizábamos los componentes de Duqu, descubrimos una anomalía interesante en el componente principal que se ocupa de la lógica de su negocio, el Payload DLL. Nos gustaría compartir nuestros descubrimientos y pedir ayuda para identificar el código.
Diseño del código
A primera vista, el Payload DLL parece un archivo Windows PE DLL común, compilado con Microsoft Visual Studio 2008 (versión de vinculador 9.0). El código del punto de entrada es totalmente estándar y tiene una función exportada por el número ordinal 1 que también se parece a MSVC++. Esta función se llama desde el PNF DLL y es la función “principal” que implementa todas las lógicas para contactar a servidores C&C, recibir módulos adicionales de ataque y ejecutarlos. Lo más interesante es cómo se programó esta lógica y las herramientas que se usaron para hacerlo.
La sección de códigos de Payload DLL es común para un binario conformado por varias piezas de código. Consiste en “trozos” de código que al principio pueden haber estado compilados en archivos de objetos separados, antes de unirse en un DLL único. La mayoría se puede encontrar en cualquier programa C++, como las funciones de la Biblioteca Estándar de Patrones (STL), las funciones de la biblioteca run-time y el código escrito por el usuario, a excepción del trozo más grande que contiene la mayor parte del código de interacción C&C.
Distribución de la sección del código del archivo Payload DLL
Estea trozo es diferente a los demás porque no se compiló con fuentes C++. No contiene referencias a ninguna función C++ estándar o escrita por usuarios, pero sin duda está orientada a objetos. La llamamos “infraestructura Duqu”.
La infraestructura
Características
El código que implementa la infraestructura Duqu tiene varias propiedades particulares:
- Todo está envuelto en objetos
- La tabla de funciones se ubica directo en la instancia de clase y se puede modificar después de la construcción
- No hay distinción entre clases de utilidades (listas vinculadas, hashes) y códigos escritos por el usuario
- Los objetos se comunican mediante llamadas de método, listas postergadas de espera de ejecución y llamadas de retorno motivadas por acontecimientos específicos
- No hay referencia a funciones de la biblioteca run-time, en su lugar se utiliza Windows API
Objetos
Todos los objetos son ejemplos de alguna clase, hemos identificado 60 clases diferentes. Cada objeto se construye con una función “constructora” que distribuye la memoria, llena la tabla de funciones e inicializa los miembros.
Función constructora de la clase de lista vinculada
La distribución de cada objeto depende de su clase. Algunas clases parecen tener tablas de funciones binarias compatibles pero no hay nada que indique que tengan ninguna clase en común (como en otros lenguajes OO). Además, la ubicación de la tabla de funciones no es fija: algunas clases tienen la instancia en 0, pero otras no.
Distribución del objeto de lista vinculado. Los primeros 10 campos dirigen a funciones de miembros
.
Los objetos se destruyen con funciones “destructoras”. Estas funciones por lo general destruyen todos los objetos a los que se hace referencia en los campos de miembros y liberan la memoria que ocupaban.
Las funciones de los miembros se pueden referenciar con la tabla de funciones del objeto (como las funciones “virtuales” en C++) o se pueden invocar de forma directa. En la mayoría de los lenguajes orientados a objetos, las funciones del miembro reciben el parámetro “this”, que hace referencia a la instancia del objeto, y hay una convención de solicitud que define la ubicación del parámetro – ya sea en un registro o en una pila. Este no es el caso de las clases Duqu Framework que pueden recibir el parámetro “this” en cualquier registro o pila.
La función de miembros de la lista vinculada recibe el parámetro “this” en la pila
Infraestructura basada en eventos
No cabe duda de que la distribución e implementación de objetos en la infraestructura Duqu no es propia de C++, que se utilizó para programar el resto del troyano. La infraestructura tiene una característica aún más interesante que se usa de forma extensiva a lo largo de todo el código: está basada en los sucesos.
Hay objetos especiales que implementan el modelo basado en sucesos:
- Objetos de sucesos, basados en controladores de Windows API
- Objetos de contexto de hilos que guardan las listas de sucesos y listas postergadas de espera de ejecución
- Objetos de devolución de llamada que están ligados a sucesos
- Monitores de sucesos, creados por cada contexto de hilo para monitorizar sucesos y ejecutar devolución de llamadas a objetos
- El almacenamiento de contextos de hilo gestiona la lista de hilos activos y provee acceso a contextos de objetos por cada hilo
Este modelo basado en sucesos se parece a Objective C y sus características de transferencia de mensajes, pero el código no tiene ninguna referencia directa al lenguaje, ni parece haber sido compilado con compiladores de Objective C conocidos.
Modelo basado en sucesos de la infraestructura de Duqu
Cada contexto de hilo puede iniciar un “main loop” (bucle principal) que busca y procesa nuevos ítems en las listas. La mayor parte del código Duqu sigue el mismo principio: crea un objeto, conecta varias devoluciones de llamada a sucesos internos o externos, y regresa. El objeto monitor de sucesos que se crea en cada contexto de hilo ejecuta entonces los controladores de devolución de llamadas.
Este es un ejemplo de pseudocódigo de un objeto “socket”:
NativeSocket = socket();
SocketEvent = new MonitoredEvent(NativeSocket);
SocketObjectCallback = new ObjectCallback(this, SocketEvent, OnCallbackFunc);
connect(NativeSocket, …);
}
OnCallbackFunc {
switch(GetType(Event)) {
case Connected: …
case ReadData: …
…}
}
Conclusiones
- Parece que la infraestructura Duqu se escribió en un lenguaje de programación desconocido.
- A diferencia del resto del cuerpo de Duqu, no es C++ y no está compilado con Visual C++ 2008 de Microsoft.
- La arquitectura fuertemente basada en los sucesos hace que el código esté diseñado para que se use en casi cualquier tipo de condiciones, incluyendo conmutaciones asíncrónicas.
- Dado el tamaño del proyecto Duqu, es posible que dos equipos diferentes se hayan encargado de la infraestructura y de los controladores, infección de sistemas y exploits.
- El misterioso lenguaje de programación sin duda NO es C++, Objective C, Java, Python, Ada, Lua ni ninguno de los muchos lenguajes que revisamos.
- A comparación de Stuxnet (que está escrito en MSVC++ en su totalidad), esta es una de las particularidades que define la infraestructura Duqu.
La infraestructura Duqu: ¿qué fue?
Después de incontables horas de análisis, estamos 100% seguros de que la infraestructura Duqu no está programada con Visual C++. Es posible que sus autores hayan utilizado una infraestructura interna para generar un código C intermediario, o tal vez usaron un lenguaje de programación completamente diferente.
Queremos hacer una llamada a la comunidad de programadores para pedirles que se pongan en contacto con nosotros o comenten en esta entrada del blog si reconocen la infraestructura, herramientas o el lenguaje de programación que puede generar construcciones de código similares. Estamos seguros de que, con vuestra ayuda, podremos solucionar este gran misterio de Duqu.
Autores
De los mismos autores
En la misma categoría
El misterio de la infraestructura de Duqu