Zertifikate und digital signierte Anträge: Ein zweischneidiges Schwert

Windows unterstützt das digitale Signieren von EXE-Dateien und anderen Anwendungsdateien, sodass Sie die Herkunft der Software überprüfen können, bevor sie auf Ihrem System ausgeführt wird. Dies ist ein wichtiges Element bei der Abwehr von Schadsoftware. Wenn ein Softwarehersteller wie Adobe seine Anwendung signiert, verwendet er den privaten Schlüssel, der mit einem Zertifikat verknüpft ist, das er von einer der großen Zertifizierungsstellen wie Verisign erhalten hat.

Wenn Sie später versuchen, ein Programm auszuführen, kann Windows die Signatur der Datei überprüfen und sicherstellen, dass sie von Adobe signiert wurde und dass ihre Teile nicht manipuliert wurden, beispielsweise durch das Einfügen von Schadcode.

Windows erzwingt keine digitalen Signaturen und schränkt nicht standardmäßig ein, welche Programme des Herausgebers ausgeführt werden können. Sie können dies jedoch mit AppLocker aktivieren. So leistungsstark AppLocker möglicherweise auch ist, so kompliziert ist seine Einrichtung, außer in Umgebungen mit einem sehr begrenzten und standardisierten Satz an Anwendungen. Sie müssen Regeln für mindestens jeden Herausgeber erstellen, dessen Code auf Ihrem System ausgeführt wird.

Die gute Nachricht ist jedoch, dass AppLocker auch im Audit-Modus aktiviert werden kann. Und Sie können schnell einen Basissatz an Zulassungsregeln einrichten, indem Sie AppLocker ein Beispielsystem scannen lassen. Die Idee beim Ausführen von AppLocker im Überwachungsmodus besteht darin, dass Sie dann das AppLocker-Ereignisprotokoll auf Warnungen zu Programmen überwachen, die keine der Zulassungsregeln erfüllt haben. Das bedeutet, dass das Programm eine ungültige Signatur hat, von einem Herausgeber signiert wurde, dem Sie nicht vertrauen, oder überhaupt nicht signiert ist. Die Ereignisse, nach denen Sie suchen, sind 8003, 8006, 8021 und 8024. Diese Ereignisse befinden sich in den Protokollen unter AppLocker, wie hier gezeigt:

Wenn Sie AppLocker im Überwachungsmodus zum Erkennen nicht vertrauenswürdiger Software verwenden, denken Sie daran, dass Windows diese Ereignisse auf jedem lokalen System protokolliert. Stellen Sie daher sicher, dass Sie ein SIEM mit einem effizienten Agenten wie EventTracker verwenden, um diese Ereignisse zu erfassen, oder verwenden Sie die Windows-Ereignisweiterleitung.

Besser noch: Wenn Sie EventTracker haben, kümmern Sie sich nicht um AppLocker, sondern nutzen Sie die automatische Funktion „Digital Forensics Incident and Incident Response“ von EventTracker für unbekannte Prozesse. EventTracker überwacht jeden Prozess (und bald auch jede DLL), den Ihre Endpunkte laden, und vergleicht den EXE-Hash mit der lokalen Whitelist Ihrer Umgebung (die EventTracker automatisch erstellen kann). Wenn es dort nicht gefunden wird, vergleicht EventTracker es mit der National Software Reference Library. Wenn die EXE-Datei immer noch nicht als legitim befunden wird, postet EventTracker sie im Dashboard, damit Sie sie überprüfen können. EventTracker stellt automatisch Herausgeberinformationen bereit, wenn die Datei signiert ist, sowie andere forensische Informationen wie Endpunkt, Benutzer und übergeordneter Prozess. Mit einem Klick können Sie den Vorgang anhand von Anti-Malware-Websites wie VirusTotal überprüfen. EventTracker geht in seiner Fähigkeit, verdächtige Software zu erkennen, weit über AppLocker hinaus und stellt die Tools und Informationen bereit, mit denen Sie schnell feststellen können, ob das Programm ein Risiko darstellt oder nicht, einschließlich der Verwendung digitaler Signaturen.

Bei digital signierten Anträgen und Zertifikaten sind jedoch noch einige andere Probleme zu beachten. Zertifikate sind Teil einer sehr komplizierten Technologie namens Public Key Infrastructure (PKI). PKI besteht aus so vielen Komponenten und verbindet so viele verschiedene Parteien miteinander, dass leider viel Spielraum für Fehler besteht. Hier ist eine kurze Liste dessen, was im letzten Jahr bei signierten Anwendungen und der PKI, von der Signaturen abhängen, schief gelaufen ist:

1. Kompromittierter Code-Signatur-Server: Ich habe vorhin gesagt, dass Sie mit der Code-Signierung sicherstellen können, dass ein Programm tatsächlich vom Herausgeber stammt und nicht geändert (manipuliert) wurde. Es hängt jedoch davon ab, wie gut der Herausgeber seinen privaten Schlüssel schützt. Und leider ist Adobe ein typisches Beispiel. Vor einiger Zeit drangen einige Kriminelle in das Netzwerk von Adobe ein und fanden schließlich den Weg zu genau dem Server, den Adobe zum Signieren von Anwendungen wie Acrobat verwendet. Sie luden ihre eigene Malware hoch, signierten sie mit dem privaten Schlüssel des Code Signing-Zertifikats von Adobe und verteilten diese Malware dann auf Zielsystemen, auf denen das Programm freundlicherweise als vertrauenswürdige Adobe-Anwendung ausgeführt wurde. Wie schützen Sie sich vor gehackten Verlagen? Es gibt nur eine begrenzte Menge, die Sie tun können. Sie können strengere Regeln erstellen, die die Ausführung auf bestimmte Versionen bekannter Anwendungen beschränken, aber das macht Ihre Richtlinie natürlich viel anfälliger.
2. Betrügerisch erlangte Zertifikate: In der PKI hängt alles davon ab, dass die Zertifizierungsstelle Zertifikate erst ausstellt, nachdem sie streng überprüft hat, dass der Käufer des Zertifikats wirklich der ist, für den er sich ausgibt. Das funktioniert nicht immer. Ein recht aktuelles Beispiel ist Spymel, eine Malware, die von einem Zertifikat signiert wurde, das DigiCert an ein Unternehmen namens SBO Invest ausgestellt hat. Was kann man hier machen? Nun, die Verwendung von AppLocker, um Software auf bekannte Herausgeber zu beschränken, hilft in diesem Fall. Wenn die Zertifizierungsstelle selbst gehackt wird, können Sie natürlich keinem von ihr ausgestellten Zertifikat vertrauen. Und das bringt uns zum nächsten Punkt.
3. Nicht vertrauenswürdige Zertifizierungsstellen: Ich war immer erstaunt darüber, welchen Zertifizierungsstellen Windows standardmäßig vertraut. Es ist besser als früher, aber ich erinnere mich einmal, dass mein Windows 2000-System automatisch Zertifikaten vertraute, die von einer peruanischen Regierungsbehörde ausgestellt wurden. Aber Sie haben nicht das Vertrauen jeder CA, die Microsoft hat. Vertrauenswürdige CAs werden im Speicher „Vertrauenswürdige Stammzertifizierungsstellen“ im MMC-Snap-In „Zertifikate“ definiert und Sie können den Inhalt dieses Speichers zentral über Gruppenrichtlinien steuern
4. Unsichere CAs von PC-Anbietern: Ende letzten Jahres machte Dell Schlagzeilen, als festgestellt wurde, dass sie PCs mit dem Zertifikat ihrer eigenen CA im Trusted Root Store auslieferten. Dies geschah, damit Treiber und andere von Dell signierte Dateien vertrauenswürdig waren. Das wäre vielleicht in Ordnung gewesen, aber sie haben fälschlicherweise gegen die Regel Nummer Eins in der PKI verstoßen. Sie haben es versäumt, den privaten Schlüssel geheim zu halten. Das ist bei jedem Zertifikat schlecht, ganz zu schweigen vom Stammzertifikat einer Zertifizierungsstelle. Insbesondere hat Dell dem Zertifikat den privaten Schlüssel beigefügt. Dies ermöglichte es jedem, der einen betroffenen Dell-PC kaufte, seine eigene benutzerdefinierte Malware mit dem privaten Schlüssel von Dell zu signieren und sie dann nach der Bereitstellung auf anderen betroffenen Dell-Systemen ungestraft auszuführen, da sie scheinbar legitim war und von Dell stammte.

Zertifikate und Codesignaturen sind also alles andere als perfekt - zeigen Sie mir, welche Sicherheitskontrollen das sind. Ich empfehle Ihnen dringend, AppLocker im Überwachungsmodus auszuprobieren und die ausgegebenen Warnungen zu überwachen. Das Benutzererlebnis wird dadurch nicht beeinträchtigt, die Auswirkungen auf die Leistung sind kaum messbar, und wenn Sie diese Warnungen überwachen, erkennen Sie vielleicht schon bei der ersten Ausführung Malware, statt wie im Durchschnitt etwa sechs Monate.