El MD5 está “prohibido” en Microsoft dentro de su Security Development Lifecycle, por estar considerada una función criptográfica débil

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.

http://3.bp.blogspot.com/-QmzSZaZcJwQ/TyJ8XQKskfI/AAAAAAAAAPE/Fyq5X-mFFeY/s1600/ins1.jpg

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.

http://4.bp.blogspot.com/-v0kdFQETbPM/TyJ8mJzUVdI/AAAAAAAAAPM/3lV7aWGRqJo/s1600/ins2.jpg

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.

http://1.bp.blogspot.com/-bKc6jsElpCs/TyJ8wpKeOuI/AAAAAAAAAPU/qioTb_XkDyo/s1600/ins4.jpg

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.

http://2.bp.blogspot.com/-DJZP1qH-clE/TyJ-Fc-u1ZI/AAAAAAAAAPk/GD4MtlNQazc/s1600/ins5.jpg

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 ataque queda bajo 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 encontrar una colisión
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.

 Fuente

Más información:

A free Windows Vulnerability for the NSA
http://blog.ioactive.com/2012/01/free-windows-vulnerability-for-nsa.html?m=1