Signatures Authenticode : ce qu'on peut vérifier hors ligne

En bref. Une signature Authenticode est un blob PKCS #7 SignedData stocké dans la table des certificats du PE. Elle signe une empreinte du fichier calculée en laissant quelques trous. À partir du seul fichier, on peut vérifier que l'empreinte correspond toujours, que les attributs signés la couvrent et que la signature du signataire est mathématiquement valide. On ne peut pas savoir, hors ligne, si le certificat remonte à une racine de confiance ou s'il a été révoqué. Une signature correcte prouve l'intégrité et la provenance, pas l'innocence.

Où se trouve la signature

Le répertoire de données 4 (la table des certificats) est particulier : son « adresse » est un offset dans le fichier, et non une RVA, car la signature n'est pas chargée en mémoire. Il pointe vers une ou plusieurs structures WIN_CERTIFICATE — longueur, révision 0x0200, type 0x0002 (PKCS #7) — normalement ajoutées après la dernière section. Microsoft documente ce format dans Windows Authenticode Portable Executable Signature Format.

À l'intérieur du SignedData PKCS #7 (RFC 2315) :

SpcIndirectDataContent contient l'algorithme de hachage et le condensé du fichier ;
les certificats embarqués (signataire, intermédiaires, souvent l'autorité d'horodatage) ;
un SignerInfo avec les attributs signés (type de contenu, messageDigest, le nom et l'URL du programme, facultatifs, parfois une date de signature) et la signature qui les couvre ;
les attributs non signés, généralement une contre-signature ou un horodatage RFC 3161, et éventuellement des signatures imbriquées (SHA-1 et SHA-256 côte à côte).

Comment l'empreinte du fichier est calculée

L'empreinte Authenticode couvre l'ensemble du fichier, à l'exception :

du champ CheckSum de 4 octets de l'en-tête optionnel,
de l'entrée de 8 octets de la table des certificats dans les répertoires de données,
de la table des certificats elle-même.

C'est pourquoi le checksum d'un fichier signé peut être mis à jour après la signature, et pourquoi tout ce qui est ajouté après la table des certificats rompt la correspondance. Les données placées entre la dernière section et la table des certificats — un overlay — sont hachées : la charge utile d'un installeur signé est donc couverte.

Les trois contrôles hors ligne

Le PE Parser les effectue sur chaque fichier signé :

Contrôle	Question	Un échec signifie
Empreinte du fichier vs condensé signé	Le fichier est-il inchangé depuis la signature ?	Fichier patché, infecté, tronqué ou avec des données ajoutées
Attribut `messageDigest`	Les attributs signés couvrent-ils vraiment ce condensé ?	Structure de signature altérée
Signature RSA du signataire	La clé du signataire valide-t-elle les attributs signés ?	Signature endommagée ou falsifiée

Il affiche aussi le signataire, l'émetteur, le numéro de série, la période de validité, l'algorithme de hachage, le nom du programme, la date de signature et la provenance de cette date. Une date issue d'une contre-signature ou d'un jeton RFC 3161 a été garantie par une autorité d'horodatage ; un simple attribut signingTime a été écrit par le signataire et ne prouve pas grand-chose. Voir l'entrée du glossaire sur Authenticode.

Ce qui reste hors de portée hors ligne

Confiance dans la chaîne. Savoir si la chaîne aboutit à une racine d'un magasin de confiance Windows est une propriété de la machine, pas du fichier.
Révocation. Les certificats ayant servi à signer des malwares sont régulièrement révoqués ; cette information se trouve dans les CRL et les répondeurs OCSP.
Signatures par catalogue. De nombreux fichiers système Windows ne portent aucune signature embarquée : ils sont signés via des fichiers catalogue .cat présents sur le système. Une DLL de System32 « non signée » copiée depuis une machine peut être parfaitement légitime — vérifiez-la avec les catalogues du système d'origine.
Politique. Les exigences de signature des pilotes, WDAC et la réputation SmartScreen relèvent de la plateforme.

Interpréter le résultat au cours d'une investigation

Non signé : courant pour les outils internes et open source ; ne signifie rien à lui seul.
Signé, empreinte correcte, auto-signé : n'identifie personne ; n'importe qui peut créer un tel certificat. La DLL d'exemple de PE Parser est volontairement signée de cette façon.
Signé, empreinte incorrecte : le fichier a été modifié après la signature. Priorité haute.
Signé par une vraie entreprise, empreinte correcte : vérifiez si cette entreprise produit ce type d'outil, si le certificat a été révoqué et si la date de signature est cohérente (horodatages PE).

FAQ

Une signature Authenticode valide signifie-t-elle qu'un fichier est sûr ?

Non. Elle signifie que le fichier n'a pas changé depuis qu'un détenteur de ce certificat l'a signé. Des certificats volés, divulgués ou obtenus frauduleusement ont servi à signer des malwares, et un certificat auto-signé n'identifie personne.

Quelles parties d'un fichier PE sont exclues de l'empreinte Authenticode ?

Le champ CheckSum de l'en-tête optionnel, l'entrée de la table des certificats dans les répertoires de données, et la table des certificats elle-même. Tout le reste, y compris un overlay situé avant la table des certificats, est haché.

PE Parser peut-il dire si un certificat est de confiance ou révoqué ?

Non. Il vérifie l'intégrité hors ligne : l'empreinte du fichier par rapport au condensé signé, les attributs signés, et la signature RSA avec le certificat embarqué. La confiance et la révocation nécessitent un magasin de certificats de confiance et des données en ligne.