Una mirada técnica (y curiosa) al sistema Authenticode (y III)

lunes, 4 de noviembre de 2013

Hemos venido hablando de cómo se calcula el hash para validar binarios con Authenticode, de cómo "desfirmarlos" y qué algoritmos se utilizan para hacerlo. En esta tercera y última parte, veremos si es muy normal usar MD5, SHA1 o SHA256 para firmar ficheros con Authenticode y qué peligros representa.

Como se anunciaba en la segunda parte, Microsoft recomienda SHA1 (recordemos que no se calcula sobre todo el binario, sino que algunas cabeceras quedan fuera) para el cálculo del hash Authenticode. Sin embargo soporta MD5 y SHA256. Mientras se realizaban las pruebas necesarias para esta entrada, se pudo comprobar que no era raro encontrar programas firmados con MD5. Entre ellos GPG4Win, una suite de seguridad para Windows que ofrece una excelente interfaz gráfica para el uso de GPG y permite el uso de esta criptografía. Este programa, que precisamente debería dar ejemplo este sentido, está firmado con MD5.
gpg4win utiliza MD5 para firmar el binario y validarlo con Authenticode. Arriesgado.
¿Cuál es el problema con MD5?

MD5 es el problema. Se trata de un sistema de hash que ha sido derrotado en numerosas ocasiones desde hace ya muchos años. No solo en fuerza bruta sino en el cálculo de colisiones. Es relativamente sencillo encontrar programas que colisionen (mismo hash). De hecho, MD5 es el culpable de que el malware TheFlame, que consiguió robar un certificado de Microsoft yfirmar un binario con él (el santo Grial del malware), se valió de que Microsoft usó MD5 para calcular el hash del certificado.

Con respecto a Authenticode, Didier Stevens realiza un interesante experimento en este artículo. Simplemente, copia en bruto una firma Authenticode de un binario a otro. Por supuesto a la hora de validar el hash del fichero, cualquier software indicará que no coinciden. ¿Pero qué pasa si los hashes de dos programas coinciden? La copia de firma seguiría siendo válida. Esto se consigue precisamente si Authenticode se sirve de MD5 para identificar el binario.

En resumen, podríamos encontrar un fichero firmado usando MD5 por la compañía X, crear otro con el mismo MD5 y "trasplantar" la firma. Ahora parecería que la compañía X responde por ese binario. Y para encontrar ficheros que, siendo diferentes, tengan mismo MD5, Didier se sirvió de este programa que encuentra colisiones. Dado un hash, calcula un binario diferente con el mismo hash, que puede hacer dos funciones diferentes.

¿Y el propio Windows... lo usa?

La siguiente pregunta que se nos viene a la cabeza es, ¿usa Windows MD5 para firmar con Authenticode  algún programa importante del sistema? Si así fuera, los creadores de TheFlame podrían haber tenido otro vector de ataque incluso más sencillo para conseguir firmar un binario como si fueran Microsoft.

Para saber qué algoritmo se ha usado, normalmente se utiliza botón derecho y propiedades de las firmas digitales. En XP y 7, el dato está aquí:
Algoritmo usado para la firma Authenticode
Mientras que en 8, la han hecho más visible como se observa en la imagen de arriba. Sin embargo, no estamos al tanto de ninguna herramienta que lo muestre por línea de comando de forma automática. Basándome en una clase vista aquí, se creó una pequeña herramienta en C# que permite mostrar el hash.

Pequeña herramienta en C# para mostrar el algoritmo de firma
Con esta información, se aplicó el programa al directorio c:\windows de cada versión de Windows recién instalada.

En el caso de XP SP3: La mayoría, como es de esperar están validados por catálogo (otra forma diferente de validar de la que no hemos hablado). El resto de ficheros firmados, lo están con SHA1. Y curiosamente, encontramos algunos ficheros validados con Authenticode MD5:

c:\windows\system32\xenroll.dll,md5
c:\windows\system32\dllcache\xenroll.dll,md5
c:\windows\system32\dllcache\dwil1033.dll,md5
c:\windows\system32\dllcache\dwil3082.dll,md5
c:\windows\system32\1033\dwintl.dll,md5
c:\windows\system32\3082\dwintl.dll,md5

Estos serían buenos candidatos para "robarles" la firma. Ningún ejecutable o DLL está firmado con SHA256, porque Windows XP no ha soportado este algoritmo hasta el SP3, e incluso no del todo. Si se introduce un fichero firmado con SHA256  en XP, no reconocerá la firma. Se soportó de forma completa en Windows Vista y posteriores.

En el caso de Windows 7: Afortunadamente, no encontramos ninguno firmado con MD5. La mayoría con SHA1. Hasta 26 con sha256. Entre ellos:

c:\windows\System32\winload.exe,sha256
c:\windows\System32\winresume.exe,sha256
c:\windows\System32\Boot\winload.exe,sha256
c:\windows\System32\Boot\winresume.exe,sha256

En el caso de Windows 8: Más de 500 binarios firmados con SHA256. Curiosamente, encontramos algunos drivers firmados con MD5:

c:\windows\System32\DriverStore\FileRepository\hdxtoshiba.inf_amd64_74bf9f63a1fa6d84\MaxxAudioAPO20.dll,md5
c:\windows\System32\DriverStore\FileRepository\hdxtoshiba.inf_amd64_74bf9f63a1fa6d84\MaxxAudioAPOShell64.dll,md5
...

Conclusiones

Hemos observado programas que usan MD5 para firmar, pero también queda alguno por "desterrar" en Windows XP, aunque parece que en posteriores versiones se está mejorando el asunto. 

Aparte de los errores de usar MD5, en rigor, SHA1 también debería estar en "retroceso" (ya en 2010 NIST recomendaba dejar de usarlo), pero sigue siendo amplia mayoría.


Aunque no parece estar muy documentado, Microsoft poco a poco ha desterrado el uso de MD5 a la hora de firmar. La herramienta signtool.exe (en el SDK) ya no lo soporta.

El comando /fd con la opción MD5 no funciona ya. Por defecto usa SHA1 o permite SHA256.
También ha eliminado la opción "wizard" de singtool que permitía el uso de MD5 gráficamente.

 Una mirada técnica (y curiosa) al sistema Authenticode (I)
Una mirada técnica (y curiosa) al sistema Authenticode (II)

Sergio de los Santos
ssantos@11paths.com
@ssantosv


No hay comentarios:

Publicar un comentario