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

Los robos de certificados para firmar ejecutables son muy habituales en los últimos años. Opera, Adobe… incluso la propia Microsoft han sufrido este problema. Certificar un ejecutable es importante para darle veracidad. Si además se consigue certificar robando la identidad a otro, la suplantación de identidad es casi perfecta. Authenticode es la tecnología de Microsoft que comprueba la validez de las firmas de los ficheros. Vamos a estudiarla un poco en profundidad, deteniéndonos en sus curiosidades.

Authenticode es un método integrado en Windows para comprobar la firma de un ejecutable: su integridad y origen. Usa criptografía asimétrica y simétrica estándar, además de certificados. Los binarios son comprobados al vuelo en cuanto se ejecutan en cualquier Windows actual. En Vista además se introdujo un código de colores para dar visualmente una mejor impresión de quién firmaba los archivos y su confianza. Pero todo esto ya está muy visto. Veamos otras curiosidades.

Esquema oficial de Authenticode sacado de sus especificaciones

Utiliza SHA-1… pero no del todo

Cuando se firma criptográficamente un flujo de datos, normalmente lo que se hace es calcular su hash y firmar el resultado, por simple cuestión de eficiencia. En Authenticode el hash utilizado es habitualmente SHA-1, aunque soporta todavía MD5. En las especificaciones se puede leer:

“This algorithm [MD5] is supported only for backwards-compatibility requirements and should not be used to sign new content.“

Pero nada de esto es totalmente cierto. Como veremos en la siguiente entrega, no es raro encontrar ficheros en los que se usa MD5 para firmar su contenido. También hay que aclarar que el SHA-1 calculado no se realiza sobre todos los bits del archivo original, sino que se omiten algunas partes en la cabecera porque luego, una vez firmado, cambiarán. Así que el hash original del fichero antes de la firma no es el hash firmado por Authenticode. Según la documentación oficial:

“Hashing the PE Header, omitting the file’s checksum and the Certificate Table entry in Optional Header Data Directories.”

Demostrarlo es fácil. Por ejemplo según la documentación el checksum de la cabecera de un archivo PE no se usa para calcular el hash que será firmado y comprobado por Autenticode. Si tomamos como ejemplo la última versión del ejecutable de Opera firmado, podemos modificar ese pequeño trozo de binario y seguirá siendo válido a ojos de Windows una vez ejecutado.

Se puede realizar la prueba de forma sencilla. Sobre el fichero original, se modifica el checksum con cualquier programa que permita la modificación de cabeceras. El resultado no altera la firma Authenticode.

Se modifica el valor del checksum en la cabecera con cualquier programa:

La firma sigue siendo válida, puesto que se omite ese checksum al calcular el hash. Sin embargo (y evidentemente), cualquier cambio en el binario en sí (por ejemplo la cabecera DOS), hará que se invalide la firma.