Análisis de Flame parte II. La primera ejecución

Estándar

Hola a tod@s!

En el anterior artículo hablábamos de cómo NO habíamos podido ejecutar la muestra de Flame debido a algún problema técnico. La pregunta que terminé haciéndome era que por qué otros sí habían conseguido ejecutarla y yo no. Tocaba tirar de recursos!

En toda la documentación que he leído, se comenta acerca de los diferentes cifrados que utiliza Flame. Debido a que mis nociones de ingeniería inversa y reversing de Malware son bastante pobres, opté por analizar la información que se encontraba en el momento de la ejecución de Flame. Así que recurrí a la vía forense, y realicé un volcado de memoria segundos después de la carga de Flame a través de rundll32.

Como no quería errar en el intento, provoqué un BSOD en la máquina, a través de la herramienta de SysInternals NotMyFault.

El porqué de utilizar esta herramienta, y no otra, es debido a que quería “simular”, en la medida de lo posible, un error a través de un controlador, y no realizar una petición de volcado directamente desde alguna herramienta forense. Con esta acción, lo que intento es pasar desapercibido ante controles internos monitorizados por el Malware.

Una vez extraído el volcado de memoria, utilicé la archiconocida Volatility, para extraer el contenido de la memoria del proceso RUNDLL32, y rezar para ver algún contenido que me hiciese comprender el porqué de mi error.

Analizando el espacio de memoria utilizado por RUNDLL32, se hizo la luz…..

Parece ser, que en el código de Flame se encuentra una lista de aplicaciones consideradas “peligrosas” para el Malware. Si alguna de estas aplicaciones se encuentra en ejecución en el sistema, éste automáticamente se para.

Este control, parece que se establece a través de varias órdenes. Una de ellas se puede visualizar a través de la siguiente imagen:

Imagen 1.- Código malicioso

Existen otras clases muy interesantes. Algunas de ellas son las siguientes:

  • LUA.CLAN.THREATENING_PROGRAMS
  • HEADACHE.BoostConsumer
  • GADGET.BEETLEJUICE_DATA_COLLECTOR_CONSUMER

La lista de aplicaciones es importante. Como podéis ver en la imagen siguiente, se encuentran numerosas aplicaciones conocidas por analistas y administradores de sistemas.

Imagen 2.- Algunas aplicaciones listadas por Flame

Como curiosidad, en una de las listas aparecen algunas soluciones de Antimalware. Imagino que Flame hace uso de estas rutinas para poder explotar mejor algunas de las vías de infección que utiliza.

Imagen 3.- Soluciones Antimalware listadas por Flame

Qué fallaba al intentar analizar la muestra?. Fallaba en uno de los trucos más viejos utilizado por el Malware, ya que yo tenía corriendo en la máquina Wireshark para capturar paquetes, y Process Monitor (procmon.exe) para monitorizar llamadas de sistema. Todo ello arrancado y esperando a la ejecución de Flame. FAIL!

Por otra parte, si se detecta algo “extraño”, Flame tiene opciones de auto destrucción. Según los analistas, esta clase es ejecutada de forma remota, y se concentra todo en una función llamada SUICIDE, la cual parece que está destinada a parar las acciones del Malware, así como a destruir posibles evidencias futuras.

Imagen 4.- Código SUICIDE

Una vez revisada de nuevo toda la información, me dispuse a renombrar toda aplicación que tuviese en la máquina para monitorizar la muestra, y así sí…. Flame inicia el vuelo sin importarle el idioma ni el sistema operativo.

Una vez arrancado, éste comprueba si existe el directorio MSSecurityMgr, situado en el directorio Program Files\Common Files. Si no existe, crea este directorio.

Imagen 5.- Creación del directorio Shared

Una vez creado el directorio, genera una serie de ficheros, los cuales se muestran en la siguiente imagen:

Imagen 6.- Ficheros generados por Flame

Para poder ver con mayor claridad quien se encuentra tocando estos ficheros, he utilizado la herramienta de Sysinternals Process Explorer, buscando las referencias (handle) al mismo. Para este paso, también se podría haber utilizado la herramienta, también de Sysinternals, Handle.

Imagen 7.- Proceso services.exe con handle a mscrypt.dat

Una vez generado el directorio y los ficheros, se empiezan a generar consultas al árbol de registro HKLM, en concreto a la siguiente clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit

Después de realizar varias consultas, carga bibliotecas específicas relacionadas con la configuración de seguridad del sistema, tales como NTMARTA.DLL y SAMLIB.DLL, y modifica las claves de registro DefaultIdentifier y LastUsedIdentifier.

Imagen 8.- Modificación de la configuración de seguridad

A los pocos minutos de la ejecución, y viendo la cantidad de información que va “depositando” el bicho, intento identificar algunos ficheros generados por Flame, utilizando para ello la herramienta de Sysinternals sigcheck. Un extracto de la salida se puede ver en la siguiente imagen:

Imagen 9.- Verificación de firma con Sigcheck

Durante todo el tiempo que se estuvo ejecutando Flame, éste generó multitud de ficheros temporales en el directorio TEMP del sistema (C:\Windows). Estos ficheros, en un principio, no se encuentran manejados por ningún proceso en particular, y sólo se utilizan en un instante determinado.

Imagen 10.- Creación de ficheros temporales utilizados por Flame

Según el documento inicial de análisis de Flame, uno de los ficheros temporales, concretamente el fichero ~HLV473.tmp, contiene una lista de los procesos que se encuentran en ejecución. En el documento, se muestran secuencias de datos que hacen alusión a un formato de compresión llamado ZLIB.

Analizando este fichero, efectivamente se encuentran este tipo de secuencia de datos, por lo que me pongo a jugar con la biblioteca ZLIB de Python.

A la hora de generar un fichero con ZLIB en python, es posible indicar el grado de compresión con un valor numérico que va desde el 0 al 9. Generando un fichero con el valor 9 (Compresión máxima), las secuencias de datos que se muestran en el nuevo fichero, coinciden con las del fichero ~HLV473.tmp.

Aplicando un sencillo script en Python (En batch no he podido! :P), es posible “ver” ciertos datos almacenados en este fichero.

Imagen 11.- Extracción de información comprimida en ZLIB

La forma de implementarlo ha sido bastante sencilla. Para extraer todas las secuencias de datos que coincidan con ZLIB y los métodos de compresión (Mínimo al Máximo) he implementado un FOR del 0 al 9 y generado 10 ficheros. Una vez realizado este paso, he extraído la secuencia inicial (Magic), y he implementado un cutre-script para poder leerlo. El cutre código, aquí:

#-------------------------------------------------------------------------------
# Name:        Flame Zlib
# Purpose:
#
# Author:      Silverhack
#
# Created:     11/06/2012
# Blog:   http://windowstips.wordpress.com
# Reference: www.crysys.hu/skywiper/skywiper.pdf
#-------------------------------------------------------------------------------
import zlib
import sys
from optparse import OptionParser
from optparse import OptionGroup

magic = ["\x78\x01","\x78\x5e","\x78\xda","\x78\x9c"]
offset = 0

def flame(fich):
    try:
        fread = open(fich,'rb').read()
        for i in reversed(magic):
            try:
                init_offset = offset
                while 1:
                    init_offset+=fread[init_offset:].index(i)

                    if init_offset >=0:
                        try:
                            print zlib.decompress(fread[init_offset:])
                            break
                        except:
                            init_offset+=1
            except:
                pass

    except IOError:
        print "No such file or directory...."
        sys.exit()

def main():
    #set up command-line options
    parser = OptionParser(description="Flame Zlib file read | http://windowstips.wordpress.com", version="FlameZlibRead 0.1")
    StandardExtractGroup = OptionGroup(parser, "Read Section", "Read files and search common ZLIB payloads")
    StandardExtractGroup.add_option("-f","--file",default=False,help="File name to perform search", action="store_true",dest="filename")
    parser.add_option_group(StandardExtractGroup)
    #grab options
    (options, args) = parser.parse_args()
    if options.filename:
        fflame =  args[0]
        flame(fflame)

if __name__ == '__main__':
    main()

Hasta la próxima!
Referencias

http://msdn.microsoft.com/en-us/library/bb499271(v=winembedded.51).aspx

Análisis de Flame parte I. El FAIL

Estándar

Hola a tod@s!

Esta semana dedicaré una serie de entregas al análisis del Malware Flame. Espero que estas engregas sirvan para guiar al analista en su investigación, y que no cometa los mismos errores que estoy cometiendo yo!

Desde principios de este mes se conoce de la existencia de un malware que está ocupando todas las portadas de los blogs más importantes dentro del panorama de la seguridad. Personalmente, me enteré de este “elemento” leyendo una entrada en Hispasec escrita por el genial Sergio de los Santos, y que me mantuvo entretenido buena parte de un trayecto en metro.

Como me picaba la curiosidad, esa misma noche, me puse a buscar alguna muestra del Malware, y fijar algún día en la agenda para “jugar” con la misma.

Antes siquiera de “jugar”, me encuentro con otra interesantísima entrada de Luis Delgado, en la que explica básicamente el funcionamiento del bicho, así como un script en python, el cual determina una infección, en base a consultas al registro, así como a ficheros residuales que deja el propio Malware.

Ese mismo día, y desde el blog de AlienVault, Jaime Blasco nos deleita con una interesantísima entrada, hablando esta vez, de la posible “edad” del Malware. La muestra analizada por Jaime (MD5:bdc9e04388bda8527b398a8c34667e18), coincide con la que me dispongo a utilizar yo.

Días más tarde, me vuelvo a encontrar con otra noticia del mismo elemento, pero esta vez escrita por mi querido y siempre mordaz Yago. En esta entrada, habla de Flame y los certificados digitales, lanzando una primera aproximación acerca de la función principal de esa firma digital.

Una vez leída y releída toda la documentación existente sobre el Malware Flame, me he dispuesto a realizar un pequeño análisis del mismo, sólo por morbosa curiosidad, y de momento, este es el resultado.

Según el documento “oficial”, en el que se explica los entresijos de este bicho, si se desea reproducir la infección en una máquina para su análisis, se pueden realizar dos operaciones, las cuales, ofrecerían el mismo resultado.

La primera, y la más rápida, es ejecutar el fichero a través de línea de comandos, registrando el OCX a través de la herramienta rundll32.

Imagen 1.- Intentando arrancar Flame

La otra manera de arrancar la muestra, es ayudando al Malware a auto-ejecutarse en el próximo reinicio. Para llevar a cabo esta acción, se indica en el documento que Flame se carga como un proveedor de autenticación, tal y como se puede ver en la siguiente imagen:

Imagen 2.- Detalles del Malware Flame

Para realizar esta acción, en el documento se especifica la clave de registro sobre la cual hay que adjuntar la muestra, para su posterior carga.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

La máquina sobre la que me dispongo a realizar las pruebas de infección es un Windows XP Service Pack 3 en español 32 bits. El método de infección que escojo es el primero, es decir, registrando el Malware a través de línea de comandos, a través de rundll32.

Una vez ejecutado el comando, la herramienta rundll32.exe, logra arrancar el OCX. Observando el comportamiento a través de Process Monitor, me encuentro con que la primera acción que realiza el Malware, es establecer un valor aleatorio en la clave SEED de la siguiente ruta de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG

El valor que reside en la clave SEED, es el valor que utiliza la CRYPTO API de Windows, a la hora de generar números aleatorios.

Las siguientes acciones derivan en la consulta de drivers instalados, así como consultas al directorio TEMP del Sistema.

Una vez que realiza todas estas consultas, el Malware genera un Log en el directorio Windows llamado Ef_trace.log. Un aspecto curioso de esta acción, me lo encuentro a la hora de comprobar cómo Flame cambia el Timestamp del fichero, lo que dificultaría su detección en un análisis forense, por ejemplo.

Imagen 3.- Cambio de timestamp de fichero

Acto seguido, realiza operaciones de escritura sobre el mismo, tal y como se puede comprobar en la siguiente imagen:

Imagen 4.- Escritura de fichero Ef_trace.log

A la hora de abrir este fichero, me encuentro con información cifrada, tal y como apuntan varios blogs de seguridad, que hacen mención al fichero en sí.

Imagen 5.- Datos cifrados en Ef_trace.log

El siguiente movimiento de Flame es preguntar por los proveedores de autenticación, fecha y hora del sistema, parámetros relativos al nombre de máquina y configuración de red. Y cuando ha obtenido toda la información…. SE PARA!!

Como os podréis imaginar, mi cara de FAIL era un poema. Así que empiezo a tirar de documentación, para comprobar si había errado en algún movimiento. Las siguientes 3 ejecuciones se comportan de la misma manera a lo descrito en anteriores párrafos.

Analizando cada entrada arrojada por Process Monitor, me encuentro con una que me parece sospechosa, la cual se encuentra ya documentada por anteriores analistas. Cuando se intenta inicializar Flame, éste realiza una consulta a un directorio concreto, para ver si se encuentra un fichero. En la siguiente imagen podréis comprobar cómo la consulta devuelve un resultado de NOT FOUND.

Imagen 6.- Consulta a controlador wavesetup3.drv

Como no sabía por donde tirar, elucubro la posibilidad de que pueda haber alguna incompatibilidad debida al idioma. Si el Malware está diseñado para Windows XP, puede haberla, ya que en versiones anteriores a Windows Vista, el idioma viene integrado en el Kernel.

Instalado el sistema en inglés, y ejecutando la muestra sobre éste, se comporta de la misma manera que el anterior. ¿En qué falla? ¿Qué estoy haciendo mal?

Tras una pausa (en la que me cagué en todo…), tiro de teléfono y llamo a Seifreed, buscando alguna orientación. Aprovecho para darle las gracias desde aquí, ya que en este paso fui mucho más rápido gracias a él.

Marc me comentó que él sí lo había podido lanzar sin ningún problema, y que su máquina de pruebas era un Windows XP SP2 en Spanish, lo cual me dejó totalmente sin ideas. En su ejecución, el malware había realizado conexiones y se había propagado con éxito en el equipo. Ni problema de idioma, ni Service Packs, ni hostias…..

Mañana publicaré la segunda parte de este relato, y descubriremos algunos mecanismos de seguridad que realiza Flame para poder ejecutarse en un entorno “controlado”….

Saludos a tod@s!!

Referencias

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx

www.crysys.hu/skywiper/skywiper.pdf

parseando el fichero consolidated.db

Estándar

Hola a tod@s!

Como ya conoceréis, Iphone, al igual que otros smartphones, guarda información geográfica sobre los puntos en donde ha estado “el móvil”. Entre toda esta información, también se guarda la información de los puntos de acceso WI-FI que se encuentra en “el camino”, incluyendo su MAC.

Imagen 1.- Fichero Consolidated.db

En Seguridad Apple tienen un artículo bastante interesante sobre las aplicaciones existentes en Windows, las cuales extraen esta información y las pintan en Google Maps.

En el curso de Análisis Forense de dispositivos móviles que estamos impartiendo Juan Luis García Rambla y un servidor, y en donde nos estamos peleando con una serie de dispositivos, incluyendo el Iphone, estamos analizando esta información, junto con otras muchas más.

Uno de los puntos que tenemos que tocar, es la creación de herramientas simples que consigan extraer la información necesaria en alguno de los puntos de recogida de información.

Para ello, hemos preparado algunas demos con Python. Una de ellas, es la creación de dos scripts, los cuales extraerán y pintarán en Google Maps la información del fichero Consolidated.db de un Iphone 4.

El script lo único que hace es extraer los campos latitude y longitude de las tablas CellLocation y WifiLocation.

Imagen 2.- Campos WI-FI

Para ello, hemos utilizado un Wrapper llamado PyMaps, el cual pinta el mapa añadiendo las coordenadas extraídas previamente del fichero.

Los scripts no toman ningún parámetro como entrada, y únicamente tendremos que poner en un directorio creado previamente los siguientes ficheros:

Para el script GetCoords.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 3.- Extracción de coordenadas

En el caso del script GetWifi.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 4.- Extracción de coordenadas Wi-Fi

El código de los scripts….

GetCoords.py

#Horrible Script para extraer las coordenadas del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT Latitude,Longitude from CellLocation")
for row in cursor:
 print "La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]))
 </p>
     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[0])
 longitud = str(row[1])

  # Insertamos codigo html
 pointhtml = "I see you..."

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('Coordenadas.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

GetWifi.py


#Horrible Script para extraer las coordenadas WIFI junto con su MAC del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT MAC, Latitude, Longitude from WifiLocation")
for row in cursor:
 print "La MAC es %s, La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]),str(row[2]))
 

     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[1])
 longitud = str(row[2])

  # Insertamos codigo html
 pointhtml = str(row[0])

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('WiFi.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

 Para la ejecución de los scripts, tan sólo tendremos que utilizar Python 2.6 y pysqlite.

Saludos!