Firmas Authenticode: qué se puede verificar sin conexión
Cómo firma Authenticode un archivo PE, qué comprobaciones se pueden hacer solo con el archivo y por qué una firma válida no es una firma de confianza.
En resumen. Una firma Authenticode es un blob PKCS #7 SignedData almacenado en la tabla de certificados del PE. Firma un hash del archivo calculado dejando algunos huecos. Solo con el archivo se puede comprobar que el hash sigue coincidiendo, que los atributos firmados lo cubren y que la firma del firmante es matemáticamente válida. Lo que no se puede saber sin conexión es si el certificado encadena con una raíz de confianza o si ha sido revocado. Una firma correcta demuestra integridad y procedencia, no inocencia.
Dónde se guarda la firma
El directorio de datos 4 (la tabla de certificados) es especial: su «dirección» es un desplazamiento en el archivo, no una RVA, porque la firma no se carga en memoria. Apunta a una o varias estructuras WIN_CERTIFICATE —longitud, revisión 0x0200, tipo 0x0002 (PKCS #7)— que normalmente se añaden tras la última sección. Microsoft documenta el formato en Windows Authenticode Portable Executable Signature Format.
Dentro del SignedData PKCS #7 (RFC 2315):
SpcIndirectDataContentcontiene el algoritmo de resumen y el resumen del archivo;- los certificados incrustados (firmante, intermedios y, a menudo, la autoridad de sellado de tiempo);
- un
SignerInfocon atributos firmados (tipo de contenido,messageDigest, el nombre y la URL opcionales del programa, a veces una fecha de firma) y la firma sobre ellos; - atributos no firmados, normalmente una contrafirma o un sello de tiempo RFC 3161, y posiblemente firmas anidadas (SHA-1 y SHA-256 en paralelo).
Cómo se calcula el hash del archivo
El hash Authenticode cubre todo el archivo excepto:
- el campo
CheckSumde 4 bytes de la cabecera opcional, - la entrada de 8 bytes de la tabla de certificados en los directorios de datos,
- la propia tabla de certificados.
Por eso se puede actualizar la suma de comprobación de un archivo firmado después de firmarlo, y por eso cualquier dato añadido después de la tabla de certificados rompe la coincidencia. Los datos situados entre la última sección y la tabla de certificados —un overlay— sí entran en el hash, así que la carga útil de un instalador firmado queda cubierta.
Las tres comprobaciones sin conexión
PE Parser las realiza en cada archivo firmado:
| Comprobación | Pregunta | Un fallo significa |
|---|---|---|
| Hash del archivo frente al resumen firmado | ¿El archivo no ha cambiado desde la firma? | Parcheado, infectado, truncado o con datos añadidos |
Atributo messageDigest | ¿Los atributos firmados cubren realmente ese resumen? | Estructura de la firma manipulada |
| Firma RSA del firmante | ¿La clave del firmante valida los atributos firmados? | Firma dañada o falsificada |
También muestra el firmante, el emisor, el número de serie, el periodo de validez, el algoritmo de resumen, el nombre del programa, la fecha de firma y de dónde procede esa fecha. Una fecha procedente de una contrafirma o de un token RFC 3161 está avalada por una autoridad de sellado de tiempo; un atributo signingTime sin más lo escribió el propio firmante y demuestra poco. Consulte la entrada del glosario sobre Authenticode.
Lo que queda fuera de alcance sin conexión
- Confianza en la cadena. Que la cadena termine en una raíz de un almacén de confianza de Windows es una propiedad del equipo, no del archivo.
- Revocación. Los certificados usados para firmar malware se revocan con regularidad; esa información reside en las CRL y en los respondedores OCSP.
- Firmas de catálogo. Muchos archivos de sistema de Windows no llevan ninguna firma incrustada: se firman mediante archivos de catálogo
.catpresentes en el sistema. Una DLL deSystem32«sin firmar» copiada de un equipo puede ser perfectamente legítima: verifíquela con los catálogos del sistema de origen. - Políticas. Los requisitos de firma de drivers, WDAC y la reputación de SmartScreen son decisiones de la plataforma.
Cómo interpretar el resultado en una investigación
- Sin firmar: habitual en herramientas internas y de código abierto; por sí solo no significa nada.
- Firmado, el hash coincide, autofirmado: no identifica a nadie; cualquiera puede crear un certificado así. La DLL de ejemplo de PE Parser está firmada así a propósito.
- Firmado, el hash no coincide: el archivo se modificó después de firmarlo. Prioridad alta.
- Firmado por una empresa real, el hash coincide: compruebe si esa empresa desarrolla una herramienta de ese tipo, si el certificado se revocó y si la fecha de firma encaja (marcas de tiempo PE).
Preguntas frecuentes
¿Una firma Authenticode válida significa que un archivo es seguro?
No. Significa que el archivo no ha cambiado desde que alguien en posesión de ese certificado lo firmó. Se ha firmado malware con certificados robados, filtrados u obtenidos de forma fraudulenta, y los certificados autofirmados no identifican a nadie.
¿Qué partes de un archivo PE quedan fuera del hash Authenticode?
El campo CheckSum de la cabecera opcional, la entrada de la tabla de certificados en los directorios de datos y la propia tabla de certificados. Todo lo demás, incluido un overlay situado antes de la tabla de certificados, entra en el hash.
¿Puede PE Parser saber si un certificado es de confianza o está revocado?
No. Verifica la integridad sin conexión: el hash del archivo frente al resumen firmado, los atributos firmados y la firma RSA con el certificado incrustado. La confianza y la revocación requieren un almacén de confianza y datos en línea.