48Bits Blog » Malware Analysis 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 Jugando con Samepage Merging http://blog.48bits.com/2010/03/17/jugando-con-samepage-merging/ http://blog.48bits.com/2010/03/17/jugando-con-samepage-merging/#comments Tue, 16 Mar 2010 22:47:44 +0000 erg0t http://blog.48bits.com/?p=1250 ACTUALIZACIÓN: 1/5/2010 Incluyo un pequeño cambio en el codigo del PoC que había hecho el cual mejora muchisimo los resultados, lamentablemente no tengo tiempo de rehacer las graficas y las conclusiones. Pruebenlo que ahora los resultados son mucho mas notables ;)

Hola audiencia de 48bits, hoy les voy a contar un poco sobre una cualidad que tienen ciertos entornos de virtualizacion, la cual podemos aprovechar para detectar los mismos.

El método que propongo esta basado en timing analysis, pero no sobre el tiempo de ejecución de determinadas instrucciones, sino que sobre los tiempos de acceso a memoria. Se han utilizado técnicas similares para detectar VMMs (incluyendo VT). Un método conocido es medir el tiempo de acceso a memoria con cache on/off, por lo general el VMM no permite desactivar el cache, entonces si ambas mediciones dan resultados similares significa que estamos dentro de un entorno virtual.

A diferencia de esa técnica, la manera que he encontrado no requiere ring0 y además es bastante sencilla. Claro que tiene ciertas limitaciones, no sirve para detectar cualquier VM, solo aquellas que implementen samepage merging (hasta ahora solo hice pruebas con KVM-KSM y VMware).

Supongo que tendré que explicar un poco en que consiste esto del samepage merging (desde ahora SM porque soy vago). El SM esta muy relacionado con el CoW (Copy on Write). Básicamente se trata de un thread que periódicamente recorre la memoria y une todas las páginas cuyo contenido es exactamente el mismo. Una vez unidas las páginas, el resto del proceso es exactamente un CoW, se comparte la misma page frame y se marca la página como read-only, cuando se intenta realizar una escritura, el manejador de excepciones se encarga de asignar una nueva página.

Este tipo de estrategia es bastante costosa por lo que no se suele utilizar sobre toda la memoria del sistema operativo. Sin embargo es muy tentador utilizarla en entornos virtualizados ya que se ahorran cantidades considerables de ram, el beneficio es máximo cuando se corren varios guests simultanea-mente.

En linux disponemos de KSM (Kernel Samepage Merging), este se puede activar y desactivar en el vuelo. Cualquier versión reciente de KVM saca provecho de KSM si se encuentra activado. La idea original sobre este tipo de tecnologías parece pertenecer a VMware y al parecer hubo ciertos problemas de patentes con KSM, lo importante a destacar es que si podemos aprovecharnos de KSM seguramente también podemos hacerlo de VMware.

Ya con todo esto un poco explicado, algunos deben estarse preguntando que pasaría si medimos los tiempos de acceso a memoria antes y después de que el KSM (o VMware) actue sobre la memoria del guest. Es justamente lo que vamos a averiguar ;)

Para logralo he escrito un PoC bastante cutre pero útil a nuestros propósitos. A continuación, el código (que no es muy bonito que digamos), y le sigue su descripción.

Nuevo PoC!

/*
 * smdetect.cpp
 *
 * Created by Daniel Fernandez (soyf...@48bits.com) on 19/03/2010
 *
 * Copyright (c) 2010  48BITS
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * Redistributions of source code must retain the above copyright notice,
 * this list of conditions and the following disclaimer.
 *
 * Redistributions in binary form must reproduce the above copyright
 * notice, this list of conditions and the following disclaimer in the
 * documentation and/or other materials provided with the distribution.
 *
 * Neither the name of the project’s author nor the names of its
 * contributors may be used to endorse or promote products derived from
 * this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */

#include <iostream>
#include <cstdlib>
#include <sys/time.h>
#include <unistd.h>

#ifdef _WIN32
#include <windows.h>
#else
#include <sys/mman.h>
#endif

class Buffer
{
    int *buffer;
    unsigned int size;

    unsigned long long gettime()
    {
        struct timeval tv;

        gettimeofday(&tv, NULL);
        return ((unsigned long long) tv.tv_sec) * 1000000ULL +
                (unsigned long long) tv.tv_usec;
    }

public:

    enum Exceptions
    {
        ALLOC_FAILED,
        LOCK_FAILED,
    };

    Buffer(unsigned int sz, bool locking, unsigned int seconds) : size(sz)
    {
#ifdef _WIN32
        HANDLE hProcess(GetCurrentProcess());
        SIZE_T minws, maxws;

        buffer = (int *) VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);

        if (buffer == NULL)
            throw ALLOC_FAILED;

        if (locking == true)
        {
            GetProcessWorkingSetSize(hProcess, &minws, &maxws);
            SetProcessWorkingSetSize(hProcess, minws + size, maxws + size);

            if (VirtualLock(buffer, size) == 0)
                throw LOCK_FAILED;
        }
#else
        buffer = (int *) mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE |
                              MAP_ANONYMOUS, 0, 0);

        if (buffer == MAP_FAILED)
            throw ALLOC_FAILED;

        if (locking == true && mlock(buffer, size) == -1)
            throw LOCK_FAILED;
#endif
        for (unsigned int x(0); x != size/sizeof(int); ++x)
            buffer[x] = 0x443d3d38;
#ifdef _WIN32
        Sleep(seconds * 1000);
#else
        sleep(seconds);
#endif
    }

    ~Buffer()
    {
#ifdef _WIN32
        VirtualUnlock(buffer, size);
        VirtualFree(buffer, 0, MEM_RELEASE);
#else
        munmap(buffer, size);
#endif
    }

    unsigned long long measureWrite()
    {
        unsigned long long start(gettime());

        for (unsigned int x(0); x != size/sizeof(int); x += 4096/sizeof(int))
            buffer[x] = x;

        return gettime() – start;
    }
};

unsigned long long getTime(unsigned int bsize, bool locking,
                           unsigned int sleep_seconds = 0)
{
    Buffer buf(bsize, locking, sleep_seconds);
    return buf.measureWrite();
}

int main(int argc, char *argv[])
{
    unsigned int buffer_size(15*1024*4096);
    unsigned int sleep_time(60);
    unsigned int threshold(500);
    bool locking(true);
    char c;
   
    while ((c = getopt(argc, argv, "pm:s:t:")) != -1)
    {
        switch(c)
        {
        case ‘p’:
            locking = false;
            break;
        case ‘m’:
            buffer_size = (atoi(optarg) * 1024 * 1024) & ~4095;
            break;
        case ‘s’:
            sleep_time = atoi(optarg);
            break;
        case ‘t’:
            threshold = atoi(optarg);
            break;
        case ‘?’:
            std::cout << "\nOptions:\n"
                    << "-m size\t buffer size in Mb (default 60mb)\n"
                    << "-s time\t sleep time in second (default 60secs)\n"
                    << "-t num\t threshold (default 98)\n"
                    << "-p\t disable locking (default enabled)"
                    << std::endl;
            return -1;
        }
    }

    try
    {
        unsigned long long t1(getTime(buffer_size, locking));
        unsigned long long t2(getTime(buffer_size, locking, sleep_time));

        // avoid division by zero
        if (t1 == 0)
                t1 = 1;
       
        int variation((std::abs((long long)(t2 – t1))*100)/t1);

        std::cout << "First write:  " << t1
                << "\nSecond write: " << t2
                << "\nVariation:    " << variation << "%\n"
                << (variation >= threshold ? "VMM detected!" : "no VMM detected")
                << std::endl;
    }
    catch (Buffer::Exceptions e)
    {
        if (e == Buffer::ALLOC_FAILED)
        {
            std::cout << "Can’t alloc buffer, try with a smaller size (-m)\n"
                    "Or check your capabilities" << std::endl;
        }

        if (e == Buffer::LOCK_FAILED)
        {
            std::cout << "Can’t lock buffer, check your capabilities\n"
                    "Or use -p flag" << std::endl;
        }
    }

    return 0;
}
 

El código puede ser compilado con visual studio, y lo ideal es compilarlo para release.

Ahora se compila con: g++ -O3 smdetect.cpp -o smdetect
Funciona tanto en linux como en windows (mingw).

Ahora unas gráficas con los resultados en distintos entornos:

Las gráficas corresponden a 10 ejecuciones de smdetect por cada entorno. Si todo fuera perfecto deberían ser lineas horizontales, pero factores externos como la carga del sistema hacen variar bastante los resultados.

Se puede apreciar una diferencia notable entre los casos donde no hay VMM y en los que la hay. Un caso curioso se da con OSX, donde la diferencia es apenas un 100% estando más cerca de los resultados donde no hay VMM. Incluso en una prueba llego a dar ~30% lo cual lo hace un target muy dificil de detectar.

Mirando las gráficas y sin considerar OSX, podriamos establecer un umbral de 150% para la detección. Incluyendo los datos de OSX he decidido utilizar un 98%, aún asi pueden darse falsos negativos en OSX y un umbral tan bajo podría llegar a dar falsos positivos si se dan ciertas condiciones.

Conclushion!

Tenemos un nuevo método, que si bien no es 100% confiable, puede ser utilizado de forma práctica y es posible refinarlo mucho más. Una posibilidad es la utilización de heurísticas para ajustar el umbral en función a información sobre la carga del sistema. Otro tema pendiente es la enorme espera que hay que realizar entre mediciones, pero esto no creo que sea un impedimento para muchos autores de malware…

Aqui se acaba :)

PD: lo siento Javi y Marconi por meter otro post en tan poco tiempo (parece ser que siempre ocurre lo mismo, pueden pasar meses sin movimiento y luego abalancha de posts).

]]> http://blog.48bits.com/2010/03/17/jugando-con-samepage-merging/feed/ 84 El caso del patch-downloader http://blog.48bits.com/2006/07/08/el-caso-del-patch-downloader/ http://blog.48bits.com/2006/07/08/el-caso-del-patch-downloader/#comments Sat, 08 Jul 2006 19:27:30 +0000 Mario Ballano http://blog.48bits.com/?p=44 En los tiempos que corren desgraciadamente no es muy dificil toparse con algun que otro esperpento creado especialmente para llenar tu pc de publicidad, casinos, robarte tus claves del messenger o vigilar tus movimientos bancarios y es que realmentebender.jpg hay bastante dinero en juego cuando hablamos de este tipo de malware.

Con este post inauguramos una nueva categoría en 48Bits dedicada al análisis de las técnicas usadas actualmente por malware, si tienes alguna “muestra” que te gustaría analizar o quieres comentar algun caso/código curioso, puedes ponerte en contacto con nosotros a través de correo electrónico, ah y si nos envias muestras que sea en un comprimido con clave ;-) .

El bicho que nos ocupa hoy nos llegó por correo electrónico, parece que alguien pudo “spamearlo” o vete a saber …

Se trata de un ejecutable de unos 21 KB, lo primero que llama la atención de este es que solamente importa dos funciones de librerías del sistema, se trata de GetProcAddress y LoadLibrary, normalmente esto es común en los ficheros empaquetados con algún packer, pero no es este el caso. Lo segundo que llama la atención es que no se aprecia ninguna cadena de texto en el fichero, ¿Como cargará entonces las funciones que necesite?, existen maneras de localizar las funciones recorriendo las exports de las dlls en memoria sin tener que tener estos nombres (usando hashes de ellos por ejemplo), también podría ser que tuviera todos estos nombres encriptados, lo cual es una técnica comunmente usada también, bueno despues de estas suposiciones empezamos a mirar un poco el desensamblado…
IDA1

Como podemos observar aquí (y en el resto del programa) parece que el ejecutable tiene código basura por todos los lados, esto probablemente esté como medida para evitar una detección genérica y como no para dificultar su análisis también, desconozco cómo se ha generado este tipo de junk code, de cualquier manera tampoco es que sea una “maravilla” :-) . Veamos un poco más como queda este “junk code” en lo que parece ser una implementación de “memzero” aunque la verdad es un poco guarra :-) …

IDA3

Seguimos con otro trozo de desensamblado que pertenece a la función “FunnyNames”.
IDA2

Bueno, creo que aquí queda desvelado el misterio de la no existencia de cadenas… el que ha programado esto reconstruye las cadenas de manera desordenada y byte a byte!, curioso… las cadenas están codificadas en instrucciones del propio procesador. En el ejemplo de arriba carga la librería “kernel32.dll”, cosa que por otro lado no hace falta porque ya está importando funciones de ahí ;-) .

Si seguimos mirando el resto del programa vemos que todas las cadenas y los nombres de las funciones que necesita usar están codificados de esta manera. Ahora bien, para enterarnos un poco mejor, con ayuda de algunos breakpoints y demás, dado que esta reconstruccion se hace en la pila del programa en tiempo de ejecución, dumpeando la memoria de la pila a disco obtenemos algo con lo que trabajar … :-)

hiew1.PNG

Bueno con un poco de paciencia y siguiendo el análisis me di cuenta de que lo que hacía este “bicho” es acceder a la siguiente URL:

http://207.226.177.108/BN/QgaHo26bYG

Si os descargaís este fichero (no teneís peligro alguno porque no es un ejecutable), observareís una maraña de datos que parecen estar comprimidos/encriptados … esto realmente es código realocalizable que el bicho inyectará en el contexto del internet explorer, para ello utiliza VirtualAllocEx y CreateRemoteThread además de establecer los privilegios necesarios para poder hacerlo, de esta manera evita firewalls que bloqueen el acceso a internet a determinados procesos, ya que internet explorer suele ser uno de los programas “permitidos”.

Lo interesante de todo esto es que este “parche” se actualiza cada cierto tiempo, supongo que será una nueva generación del mismo, empaquetado de manera diferente, no he analizado este componente porque ya no tenía ganas XD, de cualquier manera podrían cambiar el parche que hay ahí y actualizarlo con una versión nueva o lo que sea en cualquier momento, lo que si que he hecho ha sido sacar un dumpeado de este código una vez ejecutado en el contexto de internet explorer. Y menuda sorpresita… porque hay cosas bastante interesantes… como las siguientes URLs

0000BAD0   0000BAD0      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERE180Sol.UNIQCNTR.html
0000BB56   0000BB56      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERE180sol.UNIQCNTR.html
0000BBDC   0000BBDC      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREADWARE.UNIQCNTR.html
0000BC62   0000BC62      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREAVG.UNIQCNTR.html
0000BCE2   0000BCE2      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREAdware.UNIQCNTR.html
0000BD68   0000BD68      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREAntivir.UNIQCNTR.html
0000BDF0   0000BDF0      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREBDSM.UNIQCNTR.html
0000BE72   0000BE72      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREBlackjack.UNIQCNTR.html
0000BEFE   0000BEFE      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREBlowjob.UNIQCNTR.html
0000BF86   0000BF86      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERECASINO.UNIQCNTR.html
0000C00C   0000C00C      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERECLEAN.UNIQCNTR.html
0000C090   0000C090      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERECasino.UNIQCNTR.html
0000C116   0000C116      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREClaria.UNIQCNTR.html
0000C19C   0000C19C      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREClean.UNIQCNTR.html
0000C220   0000C220      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERECumshot.UNIQCNTR.html
0000C2A8   0000C2A8      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREE-gold.UNIQCNTR.html
0000C32E   0000C32E      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREERROR.UNIQCNTR.html
0000C3B2   0000C3B2      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREEgold.UNIQCNTR.html
0000C436   0000C436      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREError.UNIQCNTR.html
0000C4BA   0000C4BA      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREGATOR.UNIQCNTR.html
0000C53E   0000C53E      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREGator.UNIQCNTR.html
0000C5C2   0000C5C2      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREHYIP.UNIQCNTR.html
0000C644   0000C644      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREHyip.UNIQCNTR.html
0000C6C6   0000C6C6      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREINVESTMENT.UNIQCNTR.html
0000C754   0000C754      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREInvestment.UNIQCNTR.html
0000C7E2   0000C7E2      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREMcAfee.UNIQCNTR.html
0000C868   0000C868      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERENAV.UNIQCNTR.html
0000C8E8   0000C8E8      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERENude.UNIQCNTR.html
0000C96A   0000C96A      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPORN.UNIQCNTR.html
0000C9EC   0000C9EC      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPRIVACY.UNIQCNTR.html
0000CA74   0000CA74      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPissing.UNIQCNTR.html
0000CAFC   0000CAFC      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPoker.UNIQCNTR.html
0000CB80   0000CB80      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPorn.UNIQCNTR.html
0000CC02   0000CC02      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHEREPrivacy.UNIQCNTR.html
0000CC8A   0000CC8A      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERERecover.UNIQCNTR.html
0000CD12   0000CD12      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERERoulette.UNIQCNTR.html
0000CD9C   0000CD9C      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERESPYWARE.UNIQCNTR.html
0000CE24   0000CE24      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERESlots.UNIQCNTR.html
0000CEA8   0000CEA8      0   http://207.226.177.108/G0/WEBMIDHERECOMPIDHERESpybot.UNIQCNTR.html

En esas URLs hay un repositorio de programas maliciosos bastante grande… cuidado con lo que ejecutaís/descargaís de ahí, he publicado estas direcciones porque este tipo de cosas deberían ser denunciadas publicamente.

Un saludo y hasta la próxima!


]]>
			http://blog.48bits.com/2006/07/08/el-caso-del-patch-downloader/feed/
		13