Cesar Cerrudo ha presentado un método que podría ser usado para elevar privilegios en Windows de forma relativamente «sencilla«. Solo es necesario realizar un ataque «second-preimage«. O sea, a partir de un fichero de sistema, crear otro con un mismo hash MD5. Veamos exactamente cómo funciona.
Instalaciones en Windows
En los últimos sistemas operativos de Microsoft, el directorio C:\Windows\Installer\ contiene ficheros de instalación de Windows (.msi y .msp). Ahí encontrarás los instaladores de los programas que utilizas en tu sistema. Los nombres son aleatorios.
Ejecutando como usuario normal estos ficheros, comenzará la (re)instalación de los programas… Se puede comprobar como ciertos programas se comportan diferente cuando son lanzados desde esa ruta o cuando son lanzados desde cualquier otra. En algunos paquetes oficiales de Microsoft, el intento de elevación (UAC) aparecerá en diferentes momentos de la instalación y en otros, no aparecerá.
Comprobarlo es sencillo. Basta con ejecutar como usuario cualquier msi mientras se aloja en C:\Windows\Installer\. Luego, lo copiamos en otra localización (por ejemplo F: en la imagen) y lo intentamos lanzar.
Puesto que ocurre con pocos paquetes y el usuario no tiene permisos para escribir ni modificar C:\Windows\Installer\, esto queda como un comportamiento «curioso». Lo peor viene cuando se estudia qué ocurre entre bambalinas en el sistema al lanzar alguno de estos instaladores oficiales de Microsoft. En el ejemplo, he probado con Microsoft Office Publisher MUI (English) 2007.
Parece que este y otros paquetes de este tipo elevan privilegios automáticamente durante unos momentos. Como se aprecia en la imagen, se crea un fichero del tipo Hx#cuatro números aleatorios en hexadecimal#.tmp en el directorio %temp% (o sea, c:\users\sergio\appdata\local\temp en el ejemplo) y además es lanzado por SYSTEM.
Un posible ataque
Si conseguimos recuperar ese fichero temporal (sólo está accesible unos instantes) comprobamos que se trata de una instancia de la librería HXDS.dll. En la imagen se comprueba cómo lo he hecho.
Esta librería la carga msiexec.exe (el instalador de ficheros .msi) cada vez que se lanza un proceso de instalación. A veces la lanza como el usuario y a veces… como SYSTEM, y aquí está el problema. El directorio temporal de cada usuario puede ser modificado por él mismo (tiene permisos totales sobre él). Así que el usuario podría sustituir ese fichero temporal por otro código y se lanzaría como SYSTEM cuando se ejecutase un MSI alojado en C:\Windows\Installer. Ya tenemos la elevación.
La restricción al ataque
Pero en teoría Microsoft lo tiene en cuenta y pone una pequeña restricción: Msiexec.exe en realidad conoce el hash MD5 de HXDS.dll (lo almacena temporalmente en c:\windows\installer\) y lo compara con la copia de la instancia de la DLL creada en el temporal. Si no coincide, no lanzará el instalador y por tanto, la DLL.
El posible ataque
Si se sustituye la DLL oficial con un ejecutable cuyo hash coincida con el hash MD5 que espera msiexec.exe (en principio en mi sistema es 9e7370cc3d6a43942433f85d0e2bbdd8), entonces el ataque será posible y la elevación viable (se ejecutará como SYSTEM si lanzamos el MSI desde c:\windows\installer como usuario).
Por tanto el éxito queda supeditado la dificultad de encontrar un ataque llamado «second-preimage«. Lo que comúnmente se entiende por una colisión MD5 deseada entre dos flujos de datos. Quizás para atacantes «de a pie» no sea posible, pero para otras organizaciones de mayor envergadura, es totalmente viable, puesto que MD5 está roto desde hace tiempo. Si, el mayor problema para el atacante es realizar un ataque second preimage al MD5, solo es necesaria cierta cantidad de tiempo y capacidad de cómputo.
Hay que tener en cuenta que no ocurre con todos los paquetes ejecutables (no en todos crea la copia de la DLL en el directorio temporal y la lanza como SYSTEM). Sólo lo he conseguido por ahora con paquetes de Microsoft Office, que ejecutan varios procesos de msiexec.exe como SYSTEM.
Microsoft, ¿No quedamos en dejar de utilizar MD5?
Ahora que se cumplen 10 años de la Trustworthy Computing, hay que recordar que MD5 está «prohibido» en Microsoft dentro de su Security Development Lifecycle desde 2005. No se deben usar funciones criptográficas consideradas débiles… y no se nos ocurre una función más débil que MD5 como control para restringir una ejecución de código. Veremos por qué en la siguiente entrega.
Más información:
A free Windows Vulnerability for the NSA
Sergio de los Santos
Twitter: @ssantosv
Deja una respuesta