Duqu , Stuxnet ,Gauss y Flame....¿Inicio de una ciberguerra?

Bueno se preguntaran del porque este post...La verdad  he estado un poco confundido acerca de que temas abordar en mi blog..=).......Por suerte recorde que tenia pensado hablarles acerca de estos "pequeños gusanos"...xDDDDDD ...Y Bueno solo me voy adelantar un poco.....=).....espero que presten atención a este post....=)...Comenzemos!!!!!!!!!

Primeramente para yo poder realizar este pos, he tenido que leer muchos blog de expertos en estos temas relacionados con malwares especializados en Sistemas Scada (Tema tocado en el proximo post),muchos de llos han  publicado acerca de Flame, Duqu, Gauss y Stuxnet........Toda su información  lo he transformado en algo mas entendible para mis lectores........Ante todo agradesco a todos aquellos expertos por haber compartilo su informacion acerca de estos "pequeños" gusanos...xDD!!!!....Bueno dejando todo esto a un lado , creo que es momento de comenzar con el post....xDD!!!!

El gusano Flame (detectado por ESET como Win32/Flamer) es uno de los ataques dirigidos que mayor interés ha despertado durante este año. A pesar de varios artículos que se han publicado, hay algunas cuestiones relacionadas con su módulo principal (mssecmgr.ocx) que no se han tratado. Es precisamente en este post que se quiere dar algunos detalles sobre este componente.

Ya se han tratado temas relacionados con el análisis de Stuxnet y Duqu. El análisis del código del gusano Stuxnet requirió de un gran esfuerzo para entender su funcionamiento. En el caso de Duqu se ha podido determinar que la arquitectura y la aplicación son muy similares a las de Stuxnet, por lo cual su análisis se hizo más fácil .

En el caso de Flame es otra la historia, ya que tiene varios módulos interconectados, como el almacenamiento interno para la información de configuración, y el payload con un formato hasta ahora desconocido. A pesar de estas dificultades, se presentarán algunos detalles interesantes sobre el módulo principal mssecmgr.ocx.

Relación de Flame, Stuxnet y Duqu.

Primeramente Flame es un malware del mismo tipo de Stuxnet y Duqu. Estos códigos maliciosos implementan una lógica bastante compleja, con una elaborada arquitectura y detalles de implementación, que buscan mantener presencia en los sistemas atacados. El estilo orientado a objetos de Flame programado en C++ hace más complejo el análisis de código, ya que el proceso de análisis requiere de la reconstrucción del flujo lógico del gusano y de la lógica del compilador. Por ejemplo, una reconstrucción del método Rc4_GetBufferSize muestra lo siguiente:

En el análisis estático, un problema común es determinar la coincidencia  del valor único que coincida con el valor en VTABLE, el cual es llamado por el apuntador VPTR. En el análisis estático se utilizaron métodos para definir estructura que  emulen objetos de C++. Aunque mssecmgr.ocx hace un uso intensivo de código orientado a objetos . Ahora es muy diferente la programación orientada a objetos que se utiliza en Stuxnet y Duqu.

Al analizar los detalles para ciertos objetos se observa que son significativamente diferentes. Por ejemplo, para los objetos que representan los strings, que son el objeto más frecuente en el malware analizado,  son claramente muy diferentes. Lo mismo ocurre con los métodos de aplicación de estos objetos. En la siguiente gráfica pueden apreciarse las estructuras que describen objetos de Stuxnet y Flame:

Estos objetos son responsables de actividades como el procesamiento de archivos, el mapeo de archivos, sincronización de objetos, buffers de memoria, stream de memoria entre otras; las cuales son diferentes de los aplicados en el Stuxnet.

Otra característica distintiva del código de Flame es el frecuente uso de punteros inteligentes como objetos con el fin de manejar punteros a objetos de diferentes tipos. Siendo este enfoque muy conveniente desde el punto de vista de los desarrolladores, utilizar tantos punteros inteligentes hace más complejo el análisis del código.

Análisis del Módulo Principal de Flame

Flame almacena sus componentes en varios archivos del sistema de archivos de Windows. Utiliza tres esquemas distintos de nomenclatura para almacenar los archivos. Basado en la información de configuración y el entorno en el que se ejecute, el malware elige un esquema específico. La siguiente gráfica contiene información sobre estos sistemas de nomenclatura.

Arranque de Flame

Cuando el malware se instala en el sistema se registra como un paquete de autenticación LSA (Autenticación de la Superficie por Láser) en el registro del sistema. Esto genera que la carga de mssecmmgr.ocx sea parte del proceso lsass.exe durante el arranque del sistema. Curiosamente, los paquetes de autenticación tienen asociadas un conjunto de rutinas como interfaz para la LSA, pero ninguna de estas rutinas de interfaz son ejecutados por el módulo principal de Flame.

Sistemas Operativos que pueden ser afectados

Cuando el módulo principal de este gusano se inicia, realiza algunas comprobaciones para verificar si la versión del sistema operativo es apta para la ejecución del código malicioso y si la máquina se ha cargado en modo seguro:

Este código malicioso no se ejecuta en sistemas operativos de 64 bits, pero se ejecuta en todas las versiones de Windows, superiores a Windows 2000, pero no se incluye Windows 8.}

Existen dos pasos fundamentales para poder expandir los objetivos de flame los cuales son :


1.- Detección

Cuando el módulo principal de Flame se carga verifica cuál es el software de seguridad que está instalado en la máquina infectada. La lista de los programas que se verifican se encuentra guardada en la información de configuración. En las muestras analizadas hay aproximadamente 320 nombres diferentes tipos de software de seguridad. Dependiendo de una serie de condiciones, definidas en la información de configuración el código malicioso puede detener la ejecución del software de seguridad específico si se detecta en el sistema. Los productos detectados se dividen en grupos dependiendo de su funcionalidad: Firewalls Personales, Sistema para la prevención de intrusiones (HIPS), software antivirus, analizadores de paquetes de red, sistemas de control parental, software para el monitoreo del sistema, sistemas DLP, entre otros.


2.- Inyección en procesos


Para poder inyectar código en el espacio de direcciones de otros procesos el malware utiliza cuidadosamente ejecuta estas rutinas de la API estándar:

• VirtualAllocEx – Asigna memoria para el módulo que se inyecta en el proceso de destino.
• WriteProcessMemory\ReadProcessMemory – Inyecta el código.
• CreateRemoteThread\RtlCreateUserThread – Transfiere el control al módulo inyectado.

Como resultado, el espacio de direcciones del proceso de destino se verá así:

Vamo ahora a la parte extraña que hace que Flame sea difícil de detectar mmm....todo se basa en un truco interesante con la librería shell32.dll. Para asignar el espacio del módulo inyectado, Flame lo hace utilizando el módulo shell32.dll. El código responsable de hacer esto se parece a lo siguiente, cuando es descompilado:

Esto da como resultado la creación de todas las estructuras del sistema necesarias para la inyección y como resultado se ve como un módulo se encuentra correctamente cargado.

Ahora cuando todos los datos y el código se escriben en el espacio de direcciones objetivo, Flame crea un hilo de ejecución remoto, mediante la llamada de CreateRemoteThread o RtlCreateUserThread y la creación del Stub 2 como punto de entrada y los datos inyectados como parámetro.

El Stub 2 contiene el código que busca asignar el módulo inyectado en el espacio de direcciones del proceso, siguiendo los siguientes pasos:

• Asignar memoria para la imagen.
• Aplicar los movimientos en el espacio de memoria.
• Inicializar la importación de la tabla de direcciones.
• Llama al punto de entrada.

Ahora los datos inyectados se utilizan como una estructura auxiliar que contiene la dirección de todas las rutinas necesarias y las constantes suplementarias. Una parte del código responsable de la inicialización de esta estructura se ve como se muestra a continuacioón:

Otra cosa que hace el Stub 2 es conectar el punto de entrada, msvcrt.dll, con  el código del Stub 1.
 Tranquilos más adelante se demostrará por qué y cómo se lleva a cabo la conexión.

Ahora hablemos acerca de la principal funcionalidad de código del Stub 1 la cual es llamar al punto de entrada del módulo de inyección cada vez que el punto de entrada de msvcrt.dll se llama. Como resultado, el módulo inyectado es capaz de obtener todos los eventos que msvcrt.dll recibe. Esto permite que el software malicioso emule el entorno de ejecución como lo hace un módulo legítimamente cargado. Flame conecta msvcrt.dll de una manera bastante inusual. En lugar de empalmar el código, sobrescribe el campo correspondiente de la estructura PEB_LDR_DATA en InLoadOrderModuleList que se encuentra en el PEB (Process Environment Block). Después de completada la inyección el código malicioso limpia los rastros de la inserción en el espacio de direcciones del proceso.

Información de configuración

La forma en que Flame almacena la información de configuración es bastante complicada y es muy diferente a nivel de ejecución de lo que es Stuxnet o Duqu. Cuando el código malicioso penetra inicialmente en el sistema, todos los datos de configuración están contenidos dentro de los recursos que pertenecen al módulo principal. En el módulo principal Flame tiene un recurso identificado con el ID 146 en el directorio de recursos. Este es el lugar donde todos los datos de configuración se guardan. Dependiendo de la versión del malware el tamaño del recurso puede variar, normalmente está entre 37 Kb y 3Mb.

 A diferencia de Stuxnet y Duqu, que almacenan datos de configuración en un archivo binario simple, Flame emplea un tipo más sofisticado de almacenamiento que no es fácil de analizar.

Para poder tener acceso a la información de configuración se necesita descifrar el recurso y descomprimir los datos descifrados. El algoritmo de cifrado es bastante simple, tal como se presenta en la siguiente gráfica.

Cuando los datos se descifran, son descomprimidos en paquetes de datos pequeños (menos de un kilobyte cada uno), y utilizando la rutina de API Sleep espera 10 milisegundos entre cada paquete de datos; lo cual hace que el proceso de descompresión sea bastante robusto.

Finalmente, después de la descompresión, del recurso descifrado, Flame aplica sobre este una permutación definida por el siguiente arreglo de bytes:

Todos los datos de configuración de Flame son divididos en bloques con la siguiente estructura:


 0×03

El primer byte describe el tipo de contenido en el bloque. La información puede ser de dos tipos:

• Información suplementaria de los elementos de información de configuración.
• Valores de los elementos de información de configuración.

Los campos de datos para los bloques que contienen información suplementaria están organizados de la siguiente forma:

Es decir, se especifica el offset del bloque con los datos del elemento, el offset del bloque que contiene información adicional sobre la configuración del siguiente elemento de datos, y el nombre del elemento. La raíz se encuentra en la posición 0x1A al inicio de los datos de configuración. En la siguiente figura se puede ver un bloque que describe la configuración del elemento RTS.MEDIA_SETUP.FILES_TO_DELETE:

A diferencia de Stuxnet y Duqu, donde los elementos con información de configuración no tenían nombre, para Flame, nosotros los investigadores (hahahaha) de malware aprovechamos esta característica para facilitar la comprensión de las funcionalidades del malware.

El "truco" se basa en el tipo de datos de los elementos con información de configuración, estos pueden ser determinado por el valor del block byte. A continuación voy a mostrar algunos valores correspondientes a diferentes tipos de elementos:

• 0×08 – DWORD (4-byte integer)
• 0×06 – WORD (2-byte integer)
• 0×09 – QWORD (8-byte integer)
• 0×05 – NULL-terminated Unicode string;
• 0×04 – raw binary data
• 0×03 – item description block (el dibujo anterior)
• 0×02 – root block.

Ahora para poder realizar la infeccion de un sistema , necesariamante debe cumplir una serie de condiciones, por ejemplo:

Si el código malicioso infecta el sistema ,almacena la información de configuración en un archivo con el nombre mscrypt.da0 o wpgfilter.da0, y asi existen diversas mas opciones dependiendo de la plataforme en la que se quiere distribuir el gusano.....=)

Ya saliendo un poco de este tema............Acaso esta es una alarma de que ya se inicio una ciberguerra.......cabe mencionar que muchos paises ya comenzaron a reclutar a sus expertos en seguridad  informática y a respetados hacker para defenderlos en caso reciban un ataque del exterior. Por mi parte espero que mi país que esta algo atrasado en este ambito comienze con un plan para poder estar al menos a un nivel respetuoso en este ambio.....=)

¿Acaso llego la hora de ustedes ....Hackers?...=D

Bueno creo que ya llegamos al final de este post....disculpen si ha sido un poco aburpto ....pero no tenia nada en mente y como justo he estado leyendo acerca de este tipo de "mini gusanos" y Sistemas Scadas.....pense que ya era hora de saltar de una simple web a algo algo mas complejo....=).....Si tienen alguna duba no duden en comentar ...con gusto respondere las preguntas que esten a mi alcanze.....=) .....sin mas que decir me despido y sera hasta la próxima.....Nos vemos...=D




Regalame unos Bitcoins : 16NLuQdv97n8E4fC9Rzqzwj5ciLqcP5kCk






 P.D : Agradesco a esa persona que me ayudo en esos momento muy dificiles por los que estaba pasando........Gracias Peque........por esas palabras de apoyo......=D