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

Sergio De Los Santos    4 noviembre, 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:windowssystem32xenroll.dll,md5
c:windowssystem32dllcachexenroll.dll,md5
c:windowssystem32dllcachedwil1033.dll,md5
c:windowssystem32dllcachedwil3082.dll,md5
c:windowssystem321033dwintl.dll,md5
c:windowssystem323082dwintl.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:windowsSystem32winload.exe,sha256
c:windowsSystem32winresume.exe,sha256
c:windowsSystem32Bootwinload.exe,sha256
c:windowsSystem32Bootwinresume.exe,sha256

En el caso de Windows 8: Más de 500 binarios firmados con SHA256.
Curiosamente, encontramos algunos drivers firmados con MD5:
c:windowsSystem32DriverStoreFileRepositoryhdxtoshiba.inf_amd64_74bf9f63a1fa6d84MaxxAudioAPO20.dll,md5
c:windowsSystem32DriverStoreFileRepositoryhdxtoshiba.inf_amd64_74bf9f63a1fa6d84MaxxAudioAPOShell64.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

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *