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

Sergio De Los Santos    10 julio, 2013

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

Ante cualquier cambio en el binario
Lógicamente la firma queda invalidada
En la siguiente parte veremos cómo calcular específicamente el hash SHA-1 “especial” y otras curiosidades.

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

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

Director del área de Innovación y Laboratorio en ElevenPaths. Ingeniero técnico en informática de sistemas y máster en ingeniería del software e inteligencia artificial por la universidad de Málaga.

Te puede interesar

Deja un comentario

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