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 de 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.