Eigenheiten im Umgang mit signiertem Code
Im ersten Teil wurde erklärt, wie man Makros und PowerShell-Skripte per Policy einschränken kann, sodass nur noch signierter Code ausgeführt wird.
Im folgenden zweiten Teil erläutere ich die Eigenheiten im Umgang mit signiertem Code näher. Dabei wird davon ausgegangen, dass die Einstellungen per GPO für Office und PowerShell entsprechend der Beschreibungen im ersten Teil übernommen wurden.
Signatur mit CA-signiertem Zertifikat
Ein Code-Signing-Zertifikat kann von einer internen oder externen Zertifizierungsstelle (Certificate Authority, CA) signiert und im Certificate Manager im Trusted-Publishers-Speicher hinterlegt werden, was jedoch nicht zwingend erforderlich ist. Beides hat Auswirkungen auf das Verhalten von PowerShell-Skripten und Office-Makros.
Beginnen wir mit der CA: Ein Makro oder ein Skript, das mit einem Zertifikat signiert wurde, welches wiederum von einer im Unternehmen akzeptierten CA ausgestellt wurde, wird grundsätzlich ausgeführt. Dabei fragt Office nach, ob der Benutzer die Makros ausführen möchte:
Bei der Ausführung eines PowerShell-Skripts fragt auch PowerShell nach, ob das entsprechende Skript ausgeführt werden soll:
Dabei sollte man verstehen, was die einzelnen Wahlmöglichkeiten bewirken:
- V – Never run: Dabei wird das entsprechende Zertifikat aus der Signatur ausgelesen und für den Benutzer im Untrusted-Certificates-Speicher abgelegt. Das bedeutet, der Benutzer kann kein weiteres Skript, aber auch keine Makros mehr ausführen, die mit dem entsprechenden Zertifikat signiert wurden. In einem Unternehmen kann dies zu Supportfällen führen, wenn Benutzer aus Versehen oder bewusst aus Vorsicht diese Option wählen. Wird das Zertifikat bei dem Benutzer aus dem Untrusted-Certificates-Speicher gelöscht, können Skripte wieder ausgeführt werden.
- D – Do not run: Das Skript wird nicht ausgeführt. Bei weiteren Versuchen wird die Frage jedoch erneut gestellt.
- R – Run once: Das Skript wird einmalig ausgeführt. Bei weiteren Versuchen wird die Frage jedoch erneut gestellt.
- A – Always run: Dabei wird das Zertifikat aus der Signatur ausgelesen und für den Benutzer im Trusted-Publishers-Speicher abgelegt. Weitere Skripte, aber auch Makros, werden danach kommentarlos ausgeführt, wenn sie mit dem entsprechenden Zertifikat signiert wurden.
Signatur mit Zertifikat im Trusted-Publishers-Speicher
So weit, so gut. Es geht jedoch auch noch anders. Wenn das entsprechende Zertifikat, das zum Signieren verwendet wird, im Trusted-Publishers-Speicher des Windows Certificate Manager abgelegt wird, führen Office und PowerShell das Makro bzw. das Skript ohne Nachfrage aus. Dies erreicht man am besten per Gruppenrichtlinienobjekten (Group Policy Objects, kurz GPO), wie ich es im ersten Teil beschrieben hatte.
Die Vorteile liegen auf der Hand: So wird bei PowerShell verhindert, dass sich Administratoren und Poweruser mit der Nachfrage befassen müssen und Zertifikate plötzlich im Untrusted-Certificates-Speicher landen. Bei Office werden die Mitarbeiter ebenfalls nicht mit Nachfragen zum Ausführen von Makros aufgehalten. Dadurch wird der Benutzer nicht darauf konditioniert, die «Enable»-Schaltfläche anzuklicken und merkt auf, sollte der gelbe Balken trotzdem einmal erscheinen. Es ist eine Chance, die Awareness zu steigern und solche Vorfälle melden zu lassen, die dann nicht mehr standardmässig als False Positives einzustufen sind.
Für Unternehmen, die eigene Makros und PowerShell-Skripte signieren, ist es von Vorteil, wenn die Zertifikate per GPO auf allen Geräten im Trusted-Publishers-Speicher hinterlegt werden. Leider sehe ich ohne Third-Party-Tools oder andere Umwege keine Möglichkeit, diese beim Ausstellen per Windows-CA direkt für die Verteilung in den Trusted-Publishers-Speicher zu hinterlegen. Die Zertifikate müssen einzeln eingepflegt werden.
Signatur mit selbst signiertem Zertifikat
Während PowerShell und Office sich bei Signaturen mit Zertifikaten einer vertrauenswürdigen CA in etwa gleich verhalten, ist dies bei Signaturen mit selbst signierten Zertifikaten unterschiedlich. Office führt Makros mit vorangehender Warnung und «Enable»-Schaltfläche aus – jedoch nur, wenn der Benutzer selbst bereits im Besitz des entsprechenden Zertifikats ist.
Sollte ein anderer das Makro signiert haben, wird die Ausführung, beispielsweise in Word, verhindert. Dies sollte vor allem beim Testen der einzelnen Situationen im Hinterkopf bewahrt werden, falls Sie die Szenarien selbst durchspielen wollen.
PowerShell hingegen verweigert die Ausführung von Skripten, die in der Signatur keine vertrauenswürdige CA vorweisen können. Die oben genannte Auswahlmöglichkeit fällt weg.
Es gibt lediglich folgende Fehlermeldung:
Bei Office sowie bei PowerShell spielt es keine Rolle, ob das selbst signierte Zertifikat in den Trusted-Publishers-Speicher aufgenommen wird oder nicht. Solange keine vertrauenswürdige CA dahintersteht, werden Makros und Skripte nicht ausgeführt.
Wird das Zertifikat jedoch mit dem Certificate Manager in den Trusted-Root-Certification-Authorities-Speicher aufgenommen, werden Makros und Skripte wieder mit der Warnmeldung erlaubt. Dazu sind keine administrativen Berechtigungen nötig. Der Benutzer kann das Zertifikat auch in den persönlichen Trusted-Root-Certification-Authorities-Speicher laden. Denn im Certificate Manager wird zwischen Benutzer und Computer unterschieden; nur für den Computer-Teil, der für alle am Gerät angemeldeten Benutzer gilt, sind erweiterte Rechte nötig.
Fazit
Sie kennen nun die verschiedenen Kombinationen aus Trusted-Publishers-Speicher, CA und selbst signierten Zertifikaten sowie deren Auswirkungen im Zusammenhang mit Makros in Office und mit Skripten in PowerShell.
Warnhinweise sollten nun besser interpretiert und Anfragen an den Support oder die interne IT schneller erledigt werden können.
Für Unternehmen mit Windows-Domäne und mehr als 20 Mitarbeitern ergibt es Sinn, die Code-Signing-Zertifikate per GPO in den Trusted-Publishers-Speicher auf alle Geräte zu verteilen.
Auf selbst signierte Zertifikate sollte zumindest im produktiven Umfeld verzichtet werden.
Über den Autor
Marco Wohler ist seit November 2014 für den reibungslosen Betrieb der unternehmensinternen IT-Infrastruktur der Oneconsult verantwortlich. Er leitet seit Oktober 2016 das IT-Team. In dieser Funktion konzipierte und implementierte Marco Wohler mit seinem Team die verschiedenen Generationen der IT-Infrastruktur. In Kundenprojekten und intern sammelte er umfassende Erfahrungen in der Verteidigung von Systemen und Unternehmen. Als Gegenpol zu den Penetration Testing Teams, die sich auf Angriffsszenarien ausrichten, ist Marco Wohler ein gefragter Spezialist für die Absicherung von IT-Systemen. Er ist GIAC Certified Enterprise Defender (GCED) und zertifizierter OSSTMM Professional Security Tester (OPST).
Über Oneconsult
Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cybersecurity Services Partner mit Büros in der Schweiz und Deutschland und 2000+ weltweit durchgeführten Security-Projekten.
Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 40+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Ethical Hacker / Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM, GNFA), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Digital Forensics & Incident Response (DFIR) Expertenteams von Oneconsult zählen.
