Volviendo a Stuxnet: el eslabón perdido

Hace dos semanas, cuando anunciamos el descubrimiento del malware Flame, dijimos que no habíamos visto ninguna similitud significativa entre su código y estilo de programación con el de la plataforma Tilded en la que están basados Stuxnet y Duqu.

Flame y Tilded son dos proyectos completamente diferentes, basados en arquitecturas distintas, cada cual con sus propias características que los diferencian. Por ejemplo, Flame nunca utiliza controladores del sistema, mientras que el principal método de carga de Stuxnet y Duqu para ejecutar módulos es mediante el driver kernel.

Pero resulta que estábamos equivocados. Nos equivocamos al pensar que Flame y Stuxnet eran dos proyectos que no estaban relacionados.

Nuestra investigación reveló algunos hechos que antes desconocíamos que transforman por completo la visión actual sobre cómo se creó Stuxnet y cuál es su relación con Flame.

La llama dentro de Stuxnet

Antes que nada, repasemos la historia de Stuxnet. Recuperamos sólo tres variantes diferentes del gusano, creadas en junio de 2009 y en marzo y abril de 2010.

La versión de marzo de 2010 fue la causante del mayor número de infecciones, y los especialistas de la compañía bielorrusa VirusBlokAda la detectaron en junio de 2010. Esta versión en particular fue sujeto de los análisis más minuciosos de las compañías antivirus.

Poco después, cuando se comenzaron a esparcir las noticias sobre Stuxnet, se detectaron archivos relacionados con la versión de 2009. Esta versión, llamada Stuxnet.A (1.0), difiere mucho de las variantes de 2010.

Las principales diferencias son:

• La variante de 2009 no utilizaba la vulnerabilidad MS10-046 del archivo LNK
• En 2009, Stuxnet sólo tenía un archivo controlador; en 2010 tenía dos (el segundo se agregó con la idea expresa de que explote la vulnerabilidad LNK)
• En 2009, Stuxnet utilizó un truco especial con el archivo “autorun.inf” para infectar dispositivos USB.

Todas las otras diferencias implican pequeñas modificaciones en la infraestructura interna de Stuxnet; algunos módulos se eliminaron y sus funciones se transfirieron a otros módulos.

El cambio más significativo tiene que ver con “resource 207”.
El recurso “207″ pesa 520.192 bytes y se encuentra en la versión de Stuxnet de 2009. Después se lo abandonó por completo en la versión de 2010, y su código se entremezcló con otros módulos.

A pesar de que Stuxnet ha sido objeto de muchos análisis minuciosos de muchas compañías y expertos y se ha escrito mucho sobre su estructura, por alguna razón, el misterioso “recurso 207” de 2009 ha pasado desapercibido. Pero resulta que es el eslabón perdido entre Flame y Stuxnet, dos proyectos que parecían no estar relacionados.

La historia de Tocy

En octubre de 2010, nuestro sistema automático recibió un ejemplar que se había encontrado rondando en la red. Analizó el archivo a fondo y lo clasificó como una nueva variante de Stuxnet, Worm.Win32.Stuxnet.s.

Como Stuxnet es un programa tan importante, estudiamos el archivo para ver de qué se trataba. Pero no se parecía en nada a Stuxnet, tenían demasiadas diferencias. Por esta razón, decidimos llamarlo Tocy.a y pensamos “¡ridículos sistemas automáticos!”
Cuando se descubrió Flame en 2012, comenzamos a buscar ejemplares más antiguos que podíamos haber recibido. Entre las muestras idénticas a Flame, encontramos Tocy.a.

Al revisar los registros del sistema de procesamiento de muestras, nos dimos cuenta de que al principio se lo había clasificado como Stuxnet. Nos preguntamos, ¿Cómo es posible? ¿Por qué pensó el sistema que el ejemplar de Flame estaba relacionado con Stuxnet? Al revisar los registros, descubrimos que Tocy.a, un módulo antiguo de Flame, era muy parecido al “resource 207” de Stuxnet. De hecho, era tan similar que nuestro sistema automático lo clasificó como Stuxnet. Tocy.a sólo se parecía a Stuxnet, y no a ninguna otra muestra de nuestra colección.

Volviendo a la historia, así es como descubrimos la increíble conexión entre Flame y Stuxnet.

Resource 207

Resource 207 es un archivo DLL codificado que contiene otro archivo PE (351,768 bytes).

Este archivo PE, de 351.768 bytes, en realidad es un complemento de Flame.

Para ser más precisos, un “proto-Flame”, un módulo que obviamente tiene mucho en común con la versión actual de “mssecmgr.ocx” y que ha evolucionado hasta que en 2012 se convirtió en Flame.

Creemos que se puede hablar sobre una plataforma “Flame”, y que este módulo en particular se creó en base a su código fuente.

Hace unos días vi un tweet gracioso que decía que Flame era tan “hardcore” que contenía a Stuxnet completo en sus bases. ¡Resulta que los recursos de Stuxnet de verdad contienen un componente de la plataforma de Flame!

Las correlaciones con las variantes actuales de Flame incluyen lo siguiente:

• Nombres Mutex: TH_POOL_SHD_PQOMGMN_%dSYNCMTX and TH_POOL_SHD_MTX_GMN94XQ_%d
• Algoritmo de decodificación de cadenas de caracteres
• Nombres de clase alterados: ?AVnxys_uwip, etc.
• Nombre similar al de la arquitectura Flame – con archivos –ocx (atmpsvcn.ocx)
  Es más, el archivo contiene características distintivas que antes se consideraban exclusivas de Stuxnet:

• Nombres de archivos “disparadores”: %temp%dat3A.tmp & snsm7551.tm
• Funciones de análisis sintáctico del módulo utilitario y su interrelación y arquitectura
• Principios para ensamblar códigos de retorno de funciones
• Estilo similar de shellcode
• Estructura para describir la versión de los sistemas operativos vulnerables y revisar los algoritmos
• Su propia importación

Este es atmpsvcn.ocx– un módulo de la plataforma Flame dentro de Stuxnet.
Lo interesante es que las variantes actuales de Flame están basadas en el archivo dat3C.tmp, mientras que el módulo Flame de Stuxnet utilizó el archivo “dat3a.tmp” como identificador para etiquetar su presencia en el sistema. Uno se llega a preguntar si en algún momento también hubo un “dat3b.tmp”.

Hay piezas enteras de código del último módulo de Flame que son idénticas al código de atmpvsvcn.ocx. Por supuesto, la similitud más obvia está en los nombres de mutex:

TH_POOL_SHD_PQOMGMN_%dSYNCMTX
TH_POOL_SHD_MTX_GMN94XQ_%d

Es más, se conocen otros módulos de Flame que utilizan TH_POOL_SHD_MTX_FSW95XQ_%d que hemos fechado 2010; por ejemplo, comspol32.ocx.

Las coincidencias son aún más sorprendentes en el nivel del código:

La principal funcionalidad de Resource 207 era asegurarse de que Stuxnet se propague por dispositivos USB removibles mediante autorun.inf y explotar una vulnerabilidad en win32k.sys, que en aquel entonces era desconocida, para escalar los privilegios en el sistema cuando se infectaba el equipo.

La propagación mediante autorun.inf es otro truco que la versión de 2009 de Stuxnet y las variantes actuales de Flame tienen en común. Resource 207 sirve para infectar los dispositivos removibles, copiando el módulo “Flame” como un archivo “autorun.inf” en los dispositivos y agregando un verdadero archivo autorun.inf especial al final del archivo PE. El cuerpo principal de Stuxnet se copiaba al dispositivo USB como un archivo “~XTRVWp.dat”.

El sistema operativo procesa el archivo PE como si fuese un archivo autorun.inf verdadero y, por lo tanto, el módulo se ejecuta cuando se abre un dispositivo infectado.

Después de esto, el módulo Flame carga ~XTRVWp.dat (el cuerpo principal de Stuxnet) desde el controlador USB y lo inyecta al proceso del sistema usando una vulnerabilidad de elevación de privilegios (EoP).

Flame utiliza en la actualidad este código en particular, que concuerda perfectamente con el código en resource 207, y hace que se ejecute el módulo “Autorun_infector”.

Una vieja vulnerabilidad del día cero

El módulo de Flame del Resource 207 de Stuxnet contiene un exploit de elevación de privilegios que se utiliza en la etapa de infección desde controladores USB para inyectar el cuerpo principal de Stuxnet en los procesos del sistema. Esto es muy interesante en sí mismo.

El código exploit en el archivo atmpsvcn.ocx se parece al que nosotros, Kaspersky Lab, encontramos en las versiones de 2010 de Stuxnet y después se solucionó en el parche MS10-073. El estilo del código, su lógica y los detalles de su implementación eran iguales en el código de 2009 y 2010. Es obvio que el mismo programador escribió ambas piezas de código exploit.

Sin embargo, la versión de 2009 de Stuxnet utilizaba un exploit diferente que apuntaba a otra vulnerabilidad, una más vieja y que se parchó en 2010.

Cuando se creó “resource 207” (en febrero de 2009), la vulnerabilidad no era conocida por el público y, por lo tanto, era una vulnerabilidad del día cero.

En esencia, la vulnerabilidad consiste en la ausencia de revisión de datos de ingreso, lo que permite que la función NtUserRegisterClassExWOW() sobrescriba datos WORD más allá del rango de memoria asignado en win32k.

La dirección de la función en la estructura _gpsi se sobreescribe con la dirección del shellcode en dos pasos. Después se invoca la función NtUserMessageCall(), que pasa el control a la shellcode con privilegios a nivel de kernel.

Ninguna función se exporta a modo de usuario, lo que significa que las direcciones y los parámetros para servicios de llamadas directas se pueden encontrar haciendo un análisis sintáctico de los módulos del disco (user32&win32k).

La descripción de esta vulnerabilidad tiene una similitud sorprendente con la de la vulnerabilidad “El kernel de Windows podría permitir la elevación de privilegios (968537)”, que se cerró en junio de 2009 con el parche MS09-025; sin embargo, seguimos analizando el código y todavía no podemos confirmarlo al 100%.

Conclusiones

Nuestro análisis nos ha llevado a sacar varias conclusiones importantes, que resumimos a continuación:

• Cuando se creó Stuxnet (entre enero y junio de 2009), la plataforma Flame ya existía (por el momento creemos que se creó antes de julio de 2008) y ya tenía una estructura modular.
• El código Stuxnet de 2009 utilizaba un módulo construido en la plataforma Flame, que probablemente se creó de forma específica para operar como parte de Stuxnet.
• El módulo se eliminó de Stuxnet en 2010 porque se agregó un nuevo método de propagación (vulnerabilidad MS10-046) para reemplazar al “viejo” autorun.inf.
• El módulo Flame en Stuxnet explotaba una vulnerabilidad que en aquel entonces se desconocía, una verdadera vulnerabilidad del día cero. Esto permitía la elevación de privilegios, posiblemente mediante la explotación de MS09-025.
• Después de 2009, la evolución de la plataforma Flame y la de Stuxnet continuaron desarrollándose por separado.
• Las conclusiones de arriba indican la existencia de dos equipos de desarrolladores independientes, a los que nos podemos referir como “Equipo F” (Flame) y “Equipo D” (Tilded). Cada uno de estos equipos ha estado desarrollando su propia plataforma desde 2007-2008, como mucho.
• En 2009, se usó parte del código de la plataforma Flame en Stuxnet. Creemos que se utilizó el código fuente en vez de módulos binarios completos. Desde 2010, las plataformas se han estado desarrollando por separado, aunque han tenido alguna interacción, al menos al nivel de explotar las mismas vulnerabilidades.