REGIÓN CANARIAS, Periódico digital de Canarias: Volver a Stuxnet: el eslabón perdido

Aleks
Kaspersky Lab Expertos
Publicado 11 de junio de las 13:30 GMT
Etiquetas: llama , Cibernética de armas , el espionaje cibernético ,vulnerabilidades y exploits , Stuxnet

0.1

Madrid (España), 11 de junio de 2012 / Seguridad - Internet / Gabinete de Prensa.

Hace dos semanas, cuando se anunció el descubrimiento del malware Llama nos dijo que no veía gran similitud entre su código y el estilo de programación con la de la plataforma Tilded que Stuxnet y Duqu se basan en.

Llama y Tilded son proyectos totalmente diferentes basados en arquitecturas diferentes y cada uno con sus características propias. Por ejemplo, nunca llama utiliza los drivers del sistema, mientras que Stuxnet y el método principal de Duqu de la carga de módulos para la ejecución es a través de un controlador de núcleo.

Pero resulta que estábamos equivocados. Mal, en que creíamos Flame y Stuxnet había dos proyectos no relacionados.

Nuestra investigación descubrió algunos hechos previamente desconocidos que transformar completamente la visión actual de cómo Stuxnet fue creado y su vinculación con la llama.

La llama dentro de Stuxnet

En primer lugar, vamos a recapitular la historia de Stuxnet. Hemos logrado recuperar apenas tres diferentes variantes del gusano, creado en junio de 2009, y en marzo y abril de 2010.

La variante de marzo de 2010 fue responsable del mayor número de infecciones y se detectó en junio de 2010 por especialistas de la empresa VirusBlokAda en Bielorrusia. Esta versión particular, se sometió a un análisis más detallado por antimalware empresas.

Poco tiempo después, cuando la noticia de Stuxnet se había convertido ya muy extendido, los archivos relacionados con su encarnación de junio 2009 se han detectado. Esta versión, la Stuxnet.A llamada (1,0), difiere considerablemente de las 2010 variantes.

Las principales diferencias son:

La variante 2009 no hizo uso de la vulnerabilidad MS10-046 archivo LNK
En 2009, Stuxnet sólo tenía un archivo de controlador, en 2010 hubo dos (el segundo fue agregado específicamente para trabajar con la vulnerabilidad LNK)
En 2009, Stuxnet utiliza un truco especial con el archivo "autorun.inf" para infectar a las unidades USB.

Todas las demás diferencias que implican modificaciones menores a la estructura interna de Stuxnet - algunos módulos se han suprimido y sus funciones transferidas a otros módulos.

El más significativo de los cambios que implica "recurso 207".

De recursos "207" es 520.192 bytes de tamaño y se pueden encontrar en la versión 2009 de Stuxnet. El criterio fue abandonado más tarde por completo en la versión 2010, su código fusionado en otros módulos.

Lista de los recursos en la variante de marzo 2010 Stuxnet

Lista de los recursos en la variante 2009 de Stuxnet

A pesar del hecho de que Stuxnet ha sido objeto de un análisis en profundidad por numerosas empresas y expertos y mucho se ha escrito acerca de su estructura, por alguna razón, el misterioso "recurso 207" a partir de 2009 ha pasado casi desapercibido. Pero resulta que este es el eslabón perdido entre las llamas y Stuxnet, dos proyectos aparentemente sin ninguna relación.

La historia Tocy

En octubre de 2010, nuestro sistema automático de recibir una muestra de la naturaleza. Se analizó el archivo de fondo y la clasificó como una nueva variante de Stuxnet, Worm.Win32.Stuxnet.s.

Con Stuxnet es una cosa tan grande, nos fijamos en la muestra para ver lo que era! Lamentablemente, no se parecía a Stuxnet en absoluto, que era muy diferente. Así que decidimos cambiarle el nombre a Tocy.a y pensé "sistemas automáticos de tontos!".

Cuando la llama fue descubierto en 2012, empezamos a buscar muestras de mayor edad que podría haber recibido. Entre las muestras que parecía casi idéntica a la llama, encontramos Tocy.a .

Pasando por los registros del sistema de procesamiento de muestras, nos dimos cuenta de que fue clasificada originalmente como Stuxnet. Pensamos, ¿cómo era posible? ¿Por qué el sistema de pensar que esta muestra se relaciona con la llama Stuxnet? Comprobación de los registros, se descubrió que el Tocy.a, un módulo inicial de la llama, en realidad era similar a "207 de los recursos" de Stuxnet. En realidad era tan parecido, que hizo que nuestro sistema automático de clasificarlo como Stuxnet. En la práctica, Tocy.a fue similar a Stuxnet solo y sin otra muestra de nuestra colección.

Volviendo a la historia, esta es la forma en que descubrió el vínculo increíble entre la llama y Stuxnet.

Recursos 207

Recursos 207 es un archivo DLL de cifrado que contiene otra dentro de un archivo PE (351,768 bytes).

La información sobre la fecha de creación del módulo

La información sobre el archivo en el 207 de los recursos

Este archivo PE, 351,768 bytes de tamaño, es en realidad un plugin de la llama .

O, para ser más precisos, "proto-Flame" - un módulo que, obviamente, tiene mucho en común con la versión actual de "mssecmgr.ocx" y que había evolucionado hasta convertirse en la llama para el año 2012.

Creemos que es realmente posible hablar de una "Llama la plataforma, y que este módulo en particular fue creado sobre la base de su código fuente.

Hace unos días en Twitter vi un tweet que decía algo chistoso llama era tan "hardcore" que Stuxnet todo estaba contenida en sus bases. Resulta que los recursos Stuxnet en realidad contienen un componente de plataforma de la llama!

Las correlaciones con las variaciones de corriente de la llama son los siguientes:

Mutex nombres: TH_POOL_SHD_PQOMGMN_% dSYNCMTX yTH_POOL_SHD_MTX_GMN94XQ_% d
Cadena algoritmo de descifrado
Nombre clases mangling: ? AVnxys_uwip y así sucesivamente.
Nombre similar a la utilizada en la arquitectura de la llama -. Con el ocx ( atmpsvcn.ocx )

Por otra parte, el archivo contiene características que se consideraron antes exclusivo de Stuxnet:

Los nombres de "disparar" los archivos: % temp% \ dat3A.tmp y snsm7551.tmp
Utilitarias funciones del módulo de análisis y su interrelación y la arquitectura
Principios para el montaje de los códigos de devolución de funciones
Similar al estilo shellcode
Estructura para describir la versión de los sistemas operativos vulnerables y comprobando algoritmo
Su propia importación

Esto es atmpsvcn.ocx - un módulo de plataforma de la llama dentro de Stuxnet.

Interesantemente, las variantes actuales de la llama se basan en el archivo dat3C.tmp , mientras que el módulo de la llama dentro de Stuxnet utiliza la "dat3a.tmp" archivo como un identificador para marcar su presencia en el sistema. Uno puede preguntarse si no había también un "dat3b.tmp" en algún lugar en el tiempo.

Trozos enteros de código de los módulos Latest Flame son idénticos a los de código en atmpvsvcn.ocx.Por supuesto, la similitud más evidente es los nombres mutex:

TH_POOL_SHD_PQOMGMN_% dSYNCMTX
TH_POOL_SHD_MTX_GMN94XQ_% d

Por otra parte, hay otros conocidos módulos de llama que utilizan mutex TH_POOL_SHD_MTX_FSW95XQ_% d, que hemos fechado en 2010, por ejemplo, comspol32.ocx.

Los partidos son aún más impresionantes a nivel de código:

getdecrypted función de los recursos 207

getdecrypted función de mssecmgr.ocx

DecrypString función de los recursos 207

DecryptString función de mssecmgr.ocx

DecryptString función de browse32.ocx (el módulo de desinstalación de la llama que circula en mayo-junio de 2012)

Mutex utiliza en los recursos 207

Mutex utiliza en mssecmgr.ocx

Funcionalidad principal de recursos de 207 fue para garantizar la propagación de Stuxnet unidades extraíbles USB a través de autorun.inf, así como para aprovechar una vulnerabilidad entonces desconocido en win32k.sys para escalar privilegios en el sistema en la etapa de la infección desde la unidad USB.

Mapa de recursos en 2009 Stuxnet

Difundir a través de autorun.inf es otro truco que el Stuxnet versión 2009 y las variantes actuales de la llama que tienen en común. Recursos 207 funciona como un infector de las unidades extraíbles, copiar "la llama" módulo como " autorun.inf "archivo de medios extraíbles y la adición de un archivo especial autorun.inf reales al final del archivo PE. El cuerpo principal de Stuxnet copia en la unidad USB como " ~ XTRVWp.dat "archivo.
El archivo PE está correctamente procesada por el sistema operativo como autorun.inf real y por lo tanto, el módulo se ejecuta cuando un dispositivo infectado que se accede.

Después de esto, las cargas del módulo de llama ~ XTRVWp.dat (cuerpo principal Stuxnet) desde la unidad USB y la inyecta al sistema a través de proceso de uso de la vulnerabilidad de EOP .

Este código particular, que coincide exactamente con el código en recurso 207, es utilizado actualmente por la llama, en el que es ejecutado por el "Autorun_infector" módulo.

Un viejo 0-day

El Stuxnet Resouce 207 Llama-módulo contiene una escalada de privilegios de la hazaña y lo está usando en la etapa de la infección desde la unidad USB para inyectar el cuerpo principal de Stuxnet los procesos del sistema. Esto es de interés por derecho propio.

El código de explotación en el atmpsvcn.ocx archivo es similar a la que nosotros, Kaspersky Lab, que se encuentra en las versiones 2010 de Stuxnet y que fue dirigida posteriormente por el parche MS10-073.El estilo del código, la lógica y detalles de su implementación son los mismos en el 2009 y el código de 2010. Es evidente que estas dos piezas de código de explotación fueron escritos por el mismo programador.

Sin embargo, un exploit de una vulnerabilidad diferente orientación diferente, que era mayor y fue parcheado para el año 2010, se utilizó en la versión 2009 de Stuxnet.

En el momento de "recurso 207" fue creado (febrero de 2009), la vulnerabilidad no era de conocimiento público y, por tanto, se trataba de una verdadera vulnerabilidad 0-day.

En esencia, la vulnerabilidad consiste en la ausencia de datos de entrada de control, permitiendo que el NtUserRegisterClassExWOW () para sobrescribir una palabra de datos más allá del rango de memoria asignada en win32k.

La dirección de la función en la estructura _gpsi se sobrescribe con la dirección de la shellcode en dos pasos. A continuación, el NtUserMessageCall () se llama, que pasa el control al código shell con privilegios a nivel de kernel.

Ninguno de ellos se exporta a modo de usuario, lo que significa que las direcciones y los parámetros para llamar a los servicios directamente se encuentran analizando los módulos en el disco (user32 y win32k).

Esta descripción de la vulnerabilidad es muy similar a la de la vulnerabilidad "del kernel de Windows podrían permitir la elevación de privilegios (968537)", que se cerró en junio de 2009 con el parcheMS09-025 , sin embargo, todavía estamos analizando el código y no puede proporcionar un 100 % de confirmación de la presente todavía.

La función principal de la explotación de la vulnerabilidad en el EOP Stuxnet 2009

La función principal de la explotación de la vulnerabilidad en el EOP Stuxnet 2010

Código utilizado para llamar a las funciones reguladas en la vulnerabilidad de 2009

Código utilizado para llamar a las funciones reguladas en la vulnerabilidad de MS010-073

Conclusiones

Nuestro análisis sugiere varias conclusiones importantes, que resumimos a continuación:

En el momento en que Stuxnet fue creado (en enero-junio de 2009), la plataforma de la llama ya existía (por el momento la fecha de su creación a más tardar en el verano de 2008) y ya tenían una estructura modular.
El código de Stuxnet de 2009 utilizó un módulo construido en la plataforma de la llama, probablemente creado específicamente para operar como parte de Stuxnet.
El módulo fue removido de Stuxnet en 2010 debido a la adición de un nuevo método de propagación (la vulnerabilidad MS10-046) en lugar de la "vieja" autorun.inf
El módulo de la llama en el Stuxnet explota una vulnerabilidad que no se conocía en ese momento, un verdadero 0-day. Esto permitió una escalada de privilegios, es de suponer la explotación de MS09-025
Después de 2009, la evolución de la plataforma de la llama continuó con independencia de Stuxnet.

Las conclusiones punto por encima de la existencia de dos equipos de desarrolladores independientes, que se puede denominar como "F Team" (Llama) y "Equipo D" (Tilded). Cada uno de estos equipos se ha venido desarrollando su propia plataforma desde 2007-2008 a más tardar.

En 2009, parte del código de la plataforma se usó el Flame de Stuxnet. Creemos que el código fuente se utilizó, en lugar de completos módulos binarios. Desde 2010, las plataformas se han desarrollado independientemente uno de otro, aunque ha habido interacción por lo menos a nivel de la explotación de las mismas vulnerabilidades.

3 comentarios

El más antiguo primero

Lo nuevo primero

Vista Encadenada

Vista de tabla