Authenticode-Signaturen: Was sich offline prüfen lässt

Kurz gesagt. Eine Authenticode-Signatur ist ein PKCS-#7-SignedData-Blob in der Zertifikatstabelle der PE-Datei. Sie signiert einen Hash der Datei, der mit einigen Lücken berechnet wird. Allein anhand der Datei können Sie prüfen, ob der Hash noch stimmt, ob die signierten Attribute ihn abdecken und ob die Signatur des Signierers mathematisch gültig ist. Offline nicht feststellbar ist, ob das Zertifikat zu einer vertrauenswürdigen Root-CA führt oder gesperrt wurde. Eine gültige Signatur belegt Integrität und Herkunft, nicht Harmlosigkeit.

Wo die Signatur liegt

Datenverzeichnis 4 (die Zertifikatstabelle) ist ein Sonderfall: Seine „Adresse“ ist ein Datei-Offset, keine RVA, weil die Signatur nicht in den Speicher geladen wird. Es verweist auf eine oder mehrere WIN_CERTIFICATE-Strukturen – Länge, Revision 0x0200, Typ 0x0002 (PKCS #7) –, die normalerweise hinter der letzten Section angehängt sind. Microsoft dokumentiert das Format in Windows Authenticode Portable Executable Signature Format.

Im PKCS-#7-SignedData (RFC 2315) stehen:

SpcIndirectDataContent mit dem Digest-Algorithmus und dem Datei-Digest;
die eingebetteten Zertifikate (Signierer, Zwischenzertifikate, oft die Zeitstempelstelle);
ein SignerInfo mit signierten Attributen (Content Type, messageDigest, optional Programmname und URL, manchmal eine Signaturzeit) und der Signatur darüber;
nicht signierte Attribute, typischerweise eine Gegensignatur oder ein RFC-3161-Zeitstempel, und eventuell verschachtelte Signaturen (SHA-1 und SHA-256 nebeneinander).

Wie der Datei-Hash berechnet wird

Der Authenticode-Hash umfasst die gesamte Datei außer:

dem 4 Byte großen Feld CheckSum des Optional Header,
dem 8 Byte großen Eintrag der Zertifikatstabelle in den Datenverzeichnissen,
der Zertifikatstabelle selbst.

Deshalb kann die Prüfsumme einer signierten Datei nach dem Signieren aktualisiert werden, und deshalb bricht alles, was hinter der Zertifikatstabelle angehängt wird, die Übereinstimmung. Daten zwischen der letzten Section und der Zertifikatstabelle – ein Overlay – werden gehasht, die Payload eines signierten Installers ist also abgedeckt.

Die drei Offline-Prüfungen

Der PE Parser führt sie bei jeder signierten Datei durch:

Prüfung	Frage	Ein Fehlschlag bedeutet
Datei-Hash vs. signierter Digest	Ist die Datei seit dem Signieren unverändert?	Gepatcht, infiziert, abgeschnitten oder mit angehängten Daten
Attribut `messageDigest`	Decken die signierten Attribute diesen Digest wirklich ab?	Manipulierte Signaturstruktur
RSA-Signatur des Signierers	Bestätigt der Schlüssel des Signierers die signierten Attribute?	Beschädigte oder gefälschte Signatur

Außerdem zeigt er Signierer, Aussteller, Seriennummer, Gültigkeitszeitraum, Digest-Algorithmus, Programmname, die Signaturzeit und deren Quelle. Eine Zeit aus einer Gegensignatur oder einem RFC-3161-Token wurde von einer Zeitstempelstelle bestätigt; ein bloßes signingTime-Attribut hat der Signierer selbst geschrieben, und es beweist wenig. Siehe den Glossareintrag zu Authenticode.

Was offline außer Reichweite bleibt

Vertrauen in die Kette. Ob die Kette bei einer Root-CA in einem Windows-Trust-Store endet, ist eine Eigenschaft des Rechners, nicht der Datei.
Sperrstatus. Zertifikate, mit denen Malware signiert wurde, werden regelmäßig gesperrt; diese Information steckt in CRLs und OCSP-Respondern.
Katalogsignaturen. Viele Windows-Systemdateien tragen gar keine eingebettete Signatur: Sie sind über .cat-Katalogdateien auf dem System signiert. Eine „unsignierte“ System32-DLL, die von einem Rechner kopiert wurde, kann völlig legitim sein – prüfen Sie sie mit den Katalogen auf dem Quellsystem.
Richtlinien. Anforderungen an die Treibersignatur, WDAC und die SmartScreen-Reputation sind Entscheidungen der Plattform.

Das Ergebnis in einer Untersuchung einordnen

Unsigniert: üblich bei internen und Open-Source-Tools; für sich genommen bedeutungslos.
Signiert, Hash stimmt, selbstsigniert: identifiziert niemanden; jeder kann ein solches Zertifikat erstellen. Die Beispiel-DLL im PE Parser ist absichtlich so signiert.
Signiert, Hash stimmt nicht: Die Datei wurde nach dem Signieren verändert. Hohe Priorität.
Von einem echten Unternehmen signiert, Hash stimmt: Prüfen Sie, ob dieses Unternehmen ein solches Tool herstellt, ob das Zertifikat gesperrt wurde und ob die Signaturzeit passt (PE-Zeitstempel).

FAQ

Bedeutet eine gültige Authenticode-Signatur, dass eine Datei sicher ist?

Nein. Sie bedeutet, dass die Datei nicht verändert wurde, seit jemand mit diesem Zertifikat sie signiert hat. Gestohlene, geleakte oder betrügerisch beschaffte Zertifikate wurden bereits zum Signieren von Malware genutzt, und selbstsignierte Zertifikate identifizieren niemanden.

Welche Teile einer PE-Datei sind vom Authenticode-Hash ausgenommen?

Das Feld CheckSum des Optional Header, der Eintrag der Zertifikatstabelle in den Datenverzeichnissen und die Zertifikatstabelle selbst. Alles andere wird gehasht, auch ein Overlay vor der Zertifikatstabelle.

Kann der PE Parser erkennen, ob ein Zertifikat vertrauenswürdig oder gesperrt ist?

Nein. Er prüft die Integrität offline: den Datei-Hash gegen den signierten Digest, die signierten Attribute und die RSA-Signatur mit dem eingebetteten Zertifikat. Vertrauen und Sperrstatus erfordern einen Trust Store und Online-Daten.