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 parche
MS09-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.
.jpg)
