zurück zum Artikel

Code Signing soll sicherstellen, dass niemand den Code manipuliert hat. Daher gefährden Code-Signing-Attacken die gesamte Softwarelieferkette.

Softwarelieferketten sind für moderne Wirtschaftsprozesse von zentraler Bedeutung. Da digitale Verbindungen immer kürzer und Entwicklungszyklen immer schneller werden, muss jedes Glied in der Lieferkette vertrauenswürdig sein, um sicheren Programmcode erstellen und übertragen zu können. Als grundlegender Prozess stellt Code Signing sicher, dass niemand den Code manipuliert hat.

Zum Signieren ihres Programmcodes generieren Developer ein Schlüsselpaar aus privatem und öffentlichem Schlüssel. Die Zertifikatsignierungsanforderung (CSR, Certificate Signing Request) mit den Identitätsinformationen des Unternehmens und einer Kopie des öffentlichen Schlüssels gehen – signiert mit dem privaten Schlüssel – an eine Zertifizierungsstelle (CA). Diese authentifiziert die Identität des Entwicklers oder der Entwicklerin und sendet ein gültiges Code-Signing-Zertifikat mit dem enthaltenen öffentlichen Schlüssel zurück.

Developer setzen ihren privaten Schlüssel zum Signieren des Codes ein, und User verwenden das mit dem öffentlichen Schlüssel versehene Zertifikat, um die Identität des Urhebers und letztlich die Vertrauenswürdigkeit des Codes authentifizieren zu können. Dieser Prozess ist die Basis gegenseitigen Vertrauens in der Softwarelieferkette.

Deshalb haben Code-Signing-Attacken tiefgreifende und weitreichende Auswirkungen, wenn Angreifer unberechtigten Zugriff auf wertvolle Software-Assets bekommen. Nach einem erfolgreichen Einbruch verfügen Hacker über wirkungsvolle Werkzeuge, um nicht nur die direkt betroffenen User, sondern auch nachgelagerte Organisationen und Einzelpersonen zu schädigen, die dem kompromittierten Opfer vertrauen. Ein anschauliches Beispiel für das Ausmaß von Code-Signing-Attacken ist der Computerwurm Stuxnet. Ausgangspunkt war der erfolgreiche Diebstahl von digitalen Zertifikaten bei mehreren Unternehmen aus Taiwan. Damit konnten die Angreifer ihre SCADA-Malware tarnen, um sie in kritische Infrastrukturen im Iran einzuschleusen. Im Ergebnis gelang es, Steuerungssysteme von Industrieanlagen zu sabotieren und außergewöhnliche Störungen im iranischen Atomprogramm herbeizuführen.

Aus der Sicht von Angreifern lohnt es sich, Signaturschlüssel und Zertifikate in den Blick zu nehmen. Damit können Hacker bösartigen Code als vertrauenswürdig ausgeben und als vermeintliches Update eines vertrauenswürdigen Partners in bestehende Supply-Chain-Prozesse einschleusen. Vor kurzem richtete ein Angriff auf Nvidia verheerende Schäden in der gesamten Lieferkette an, als der Grafikkartenriese im Februar 2022 zur Zielscheibe der Lapsus$-Gruppe [1] wurde. Die Hackergruppe erbeutete zahlreiche Informationen, darunter Passwörter der Mitarbeiter und Interna zu Nvidias Technologien. Die wertvollste Beute der kriminellen Angreifer waren zwei abgelaufene Code-Signing-Zertifikate und die dazugehörigen Privatschlüssel.

Einen Monat später entdeckten Sicherheitsforscher Binärdateien mit Schadcode [2], die mit den geraubten Zertifikaten signiert waren und sich als vertrauenswürdige Nvidia-Programme ausgaben. In Wirklichkeit enthielten die Dateien neben Mimikatz-Lateral-Movement-Tools auch Cobalt Strike Beacons sowie Remote Access Trojaner (RATs).

Das eigentlich legitime Sicherheitstool Cobalt Strike verschafft Bedrohungsakteuren Zugang zu Zielorganisationen. Mit Mimikatz lassen sich Anmeldedaten direkt aus dem Arbeitsspeicher auslesen. So konnte sich Lapsus$ über eine VPN- Verbindung im Mobile-Device-Management (MDM) einloggen und Zugangsdaten sowie proprietäre Informationen entwenden und veröffentlichen.

Obwohl beide Zertifikate abgelaufen waren, konnten sie die Microsoft-Sicherheitssysteme täuschen, um Zugriff auf Windows zu erhalten. Der Angriff zielte dem Anschein nach auf Nvidia, aber eventuell war der Grafikkartenhersteller nur indirekt ins Visier geraten, um weitreichendere Effekte zu erreichen. Der Fall verdeutlicht, wie schwerwiegend sich Code-Signing-Angriffe auswirken und wie weit sie sich durch Einbeziehung weiterer Akteure und Organisationen einer IT-Landschaft oder Lieferkette ausbreiten können.

Der Angriff auf Nvidia sorgte für weltweites Aufsehen, ist aber nur ein Beispiel unter vielen vergleichbaren Fällen. Laut einer aktuellen Studie von VirusTotal treten Code-Signing-Angriffe weitaus häufiger auf als allgemein erwartet. Der Report "Deception at Scale: How Malware Abuses Trust" [3] förderte zutage, dass Google Clouds Online-Dienst seit 2021 mehr als eine Million Samples signierter Malware entdeckt hatte. Fast 90 Prozent der Samples waren mit noch gültigen Zertifikaten signiert, als VirusTotal sie aufspürte. Die häufigsten Zertifikatsarten, die zum Signieren der Malware verwendet wurden, stammten von bekannten Unternehmen wie Skype, Adobe und VLC.

Die Fehlerkette beim Code Signing

Unterschiedliche Fehler beim Implementieren von Code Signing ermöglichen solche Angriffe. Viele vergessen, dass es in Fragen der IT-Sicherheit nicht nur darum geht, die richtigen IT-Werkzeuge zu besitzen, sondern diese auch sicherheitskonform einzusetzen. Beispiel SolarWinds: Mehrere Regierungsabteilungen und große Privatunternehmen waren von der Cyberattacke auf Software für das IT- und Netzwerkmanagement betroffen.

Die Angreifer mussten keine Code-Signing-Zertifikate oder -Schlüssel stehlen, sondern fügten bösartigen Code bereits während des Build-Prozesses in SolarWinds-Software ein, die das Unternehmen am Ende der Entwicklung selbst signiert hatte. Die Angreifer profitierten dabei von einer unsicher implementierten Software-Lieferkette. Solche Fehler führen im weiteren Verlauf oft zu größeren Risiken. Code Signing allein reicht nicht aus, sondern der Prozess des digitalen Signierens muss in geschützte Software-Supply-Chain-Prozesse eingebunden sein.

Verwaltung der Signaturschlüssel

Beim Einsatz von Signaturschlüsseln und Zertifikaten fehlen oft die erforderlichen Überwachungsmöglichkeiten über ihre Verteilung und Verwaltung. Ohne eine umfassende Kontrolle können Signaturschlüssel in schlecht gesicherten IT-Umgebungen in die Hände von Angreifern gelangen. Das taiwanesische Computerunternehmen ASUS beispielsweise geriet 2018 [4] in den Fokus von Hackern, die unterschiedliche Code-Signing-Schlüssel von einem ASUS-Webserver stahlen.

Mit den erbeuteten Schlüsseln schleusten die Angreifer Malware in echte ASUS-Update-Paket ein, die über einen Zeitraum von sechs Monaten mehr als eine Million ASUS-Computer in Mitleidenschaft zogen.

Wiederverwendung von Zertifikaten und Schlüsseln

In vielen Fällen verwenden Organisationen dieselben Zertifikate für unterschiedliche Dateien, Produktlinien und Geschäftsfelder. Das ist bequemer als separate Schlüssel und Zertifikate für unterschiedliche Code-Signing-Anwendungsfälle generieren, verteilen und verwenden zu müssen. Das Vorgehen erhöht allerdings das Risiko, dass ein Eindringling auf einen Schlüssel oder ein Zertifikat zugreifen kann, um mit dem vermeintlich vertrauenswürdigen Nachweis im nächsten Schritt essenzielle Komponenten der Softwareprozesskette zu kompromittieren. Folge: Das Vertrauen in signierte Software im produktiven Einsatz sinkt, wenn Zertifikate widerrufen oder Schlüsselpaare geändert werden müssen.

Viele Unternehmen überwachen den Einsatz von Signaturschlüsseln und Zertifikaten nicht. Solche Nachlässigkeiten haben zur Folge, dass sie nicht wissen, wer welchen Schlüssel oder welches Zertifikat einsetzt – geschweige denn, wie und wo das erfolgt. Angesichts blinder Flecken bei der Sicht auf die eigenen IT-Prozesse steigt die Gefahr für Unternehmen, dass Dritte ihre IT-Assets richtlinienwidrig oder sogar unbemerkt nutzen.

Sichere Verwahrung von Code-Signing-Tools

Die privaten Schlüssel der Code-Signing-Zertifikate steuern den Zugriff auf die eigene Software. Falls Angreifer nur einen der Schlüssel in die Hände bekommen, können sie Malware als legitime Software verschleiern. Die Privatschlüssel sind grundlegend zum Absichern des gesamten Prozesses. Unternehmen müssen sie daher äußerst sorgfältig speichern, verwalten und überwachen. Am besten speichert man sie in einem geschützten Hardware-Sicherheitsmodul (Hardware Security Module, HSM) mit Signaturdiensten oder FIPs-fähigen Schlüsselverwaltungsdiensten (Key Management Services, KMS).

Noch sind die Anforderungen für den Schutz von Code-Signing-Schlüsseln zur Organisationsvalidierung (Organizational Validation, OV) weniger strikt als bei Extended-Validation-Zertifikaten. Mit softwarebasierten Ansätzen lässt sich der Schutz von Schlüsseln erhöhen, aber der Einsatz eines Hardware-Sicherheitsmoduls ist stets die bessere Option, da Software sich leichter kompromittieren lässt. Das CA/Browser-Forum wird die Richtlinien für OV-Schlüssel zukünftig ändern und ab Juni 2023 an EV-Zertifikate anpassen. Die Zeit drängt, sich auf die Änderungen vorzubereiten und einen sicheren Schutz für alle privaten Schlüssel der Codesignatur zu implementieren.

Kontrollierter Zugriff

Unternehmen müssen Kontrollrichtlinien für den Zugriff auf private Schlüssel erstellen, die sicherstellen, dass im Bedarfsfall nur autorisierte Parteien die jeweiligen Keys verwenden können. Die Schlüssel lassen sich mit kompatiblen SaaS-Codesignaturanwendungen oder Key-Management-Services (KMS) generieren, um zu verhindern, dass sie geteilt, verloren oder gestohlen werden.

Als Sicherheitsmaßnahme sollte der für die Generierung der Schlüssel verantwortliche Personenkreis von denjenigen Personen getrennt sein, die die Keys verwendet. Multi-Faktor-Authentifizierung (MFA) für die IT-Verantwortlichen, die Schlüssel signieren oder erstellen dürfen, verbessert die Sicherheit zusätzlich. Solche Zugriffsrechte sollten schnell widerrufbar sein, falls die mit dem Unterzeichnen oder dem Generieren von Schlüsseln betrauten Personen das Unternehmen verlassen oder aus anderen Gründen keinen Zugriff mehr benötigen.

Kontinuierlich zu überwachen, wie die Schlüssel verwendet werden, ist eine weitere wichtige Kontrollmaßnahme. Unternehmen sollten vollständig protokollieren, wer wann was unterschreibt, um Sicherheitsverletzungen untersuchen und beheben zu können. Das betrifft gleichermaßen den Einsatz von Schlüsselpaaren: das Generieren, die Zertifikatsoperationen sowie das Zuweisen von Schlüssel- und Signaturzugriff.

Durchsetzen kryptografischer Standards

Kryptografischen Standardverfahren müssen unternehmensweit durchgesetzt werden. Das schreiben die meisten Branchenstandards ohnehin vor. Das CA/Browser-Forum fordert für das RSA-Verfahren eine Schlüssellänge von mindestens 3072 Bit bei öffentlichen Code-Signing- und Zeitstempel-Zertifikaten. Entwicklerinnen und Entwickler mögen diese Anforderungen nicht immer kennen, aber Unternehmen müssen die Branchenstandards und die damit verbundenen kryptografischen Mindestanforderungen für das Erstellen von Schlüsseln und Zertifikaten einhalten.

Wichtig ist, nicht nur die Einzelkomponenten beim Code Signing zu schützen und überwachen, sondern den gesamten Prozess sorgfältig zu verwalten. Das kann die Freigabe der einzelnen Schritte ebenso betreffen wie die Genehmigung signierter und vorausgeplanter Releases. Für Code-Commits oder CI/CD-Pipeline-Kick-offs empfiehlt sich ebenfalls die Einführung eines Genehmigungsprozesses.

Automatisiertes Code Signing in SDLC

Das Code Signing sollte ein automatisierter Bestandteil des Software Development Lifecycle (SDLC) sein. Dadurch lassen sich menschliche Fehler während des Code-Signing-Prozesses vermeiden und es lässt sich sicherstellen, dass der Programmcode immer signiert wird.

Organisationen können die eingesetzten Build-Server daraufhin überprüfen, ob es auffällige Diskrepanzen oder potenzielle Anzeichen eines Angriffs gibt. Durch das Signieren der Software und den Vergleich unterschiedlicher Build-Server anhand der erzeugten Hashwerte lassen sich Abweichungen und mögliche Gefahren vor dem Release erkennen. Identische Builds können sicherstellen, dass kein bösartiger Code in die Software gelangt.

Widerruf kompromittierter Zertifikate

Stellt ein Unternehmen fest, dass ein Schlüssel kompromittiert wurde oder signierte Malware vorhanden ist, muss es umgehend die Zertifikate widerrufen und die Zertifizierungsstellen benachrichtigen. Damit verliert die Software ihre Gültigkeit und die Verbreitung von Malware wird unterbunden.

Im Regelfall sind öffentliche Code-Signing-Zertifikate ein bis drei Jahre gültig. Laufen sie ab, verfällt die Gültigkeit der von ihnen signierten Software. Eine Zeitstempelsignatur stellt sicher, dass die Gültigkeitsdauer für einen längeren Zeitraum erhalten bleibt. Im Durchschnitt beträgt sie damit elf Jahre, um Risiken beim Zertifikatswiderruf zu mindern. Müssen Zertifikate widerrufen werden, stellt der Zeitstempel sicher, dass der Widerruf nur die Softwarebestandteile betrifft, die nach dem Datum des Widerrufs veröffentlicht wurden.

Ohne Sicherheit kein Vertrauen

Durch vernetzte Geschäftsabläufe und immer schnellerer Software-Releases ist Code Signing eine unerlässliche Methode, um Digital Trust sicherzustellen. Für vertrauenswürdige Lieferketten ist es notwendig, dass Software und Code auf sichere Weise zwischen unterschiedlichsten Partnern, Benutzern, Kunden und Lieferanten weitergereicht werden kann. Das setzt einen sicheren, integrierten Code-Signing-Prozess voraus.

Können Unternehmen ihre Schlüssel und ihre Code-Signing-Verfahren jedoch nicht überwachen und kontrollieren, setzen sie sich sowie ihre Kunden und Partner schwerwiegenden Bedrohungen aus. Damit drohen Reputationsverlust und technische Störungen bei der Zusammenarbeit mit Vertriebspartnern, Geschäftskunden und Usern.

Dave Roche
ist Senior Product Manager bei DigiCert und verantwortet die Betreuung von Kunden bei Signier- und Schlüsselverwaltungsfragen in DevOps- und CI/CD-Umgebungen. Außerdem beaufsichtigt er die Enterprise-Codesign-Anwendung Secure Software Manager für sichere Code-, App- und Container-Signatur-Workflows, Schlüsselgenerierung und -verwaltung sowie Audit-Protokollierung signierbezogener Aktivitäten. Seit der Übernahme von Symantec Website Security arbeitet Dave Roche bei DigiCert und verfügt über mehr als zehn Jahre PKI-Erfahrung.

(rme [5])

URL dieses Artikels:
https://www.heise.de/-7492293

Links in diesem Artikel:
[1] https://www.heise.de/news/Nvidia-Cyber-Attacke-mit-unbekannten-Folgen-aber-Hersteller-schlaegt-zurueck-6527471.html
[2] https://www.heise.de/news/Nvidias-geleakte-Code-Signing-Zertifikate-missbraucht-6537255.html
[3] https://assets.virustotal.com/reports/2022-deception-at-scale
[4] https://www.heise.de/news/ShadowHammer-ASUS-verteilte-offenbar-Schadcode-an-ueber-1-Million-Nutzer-4348242.html
[5] mailto:rme@ix.de

Copyright © 2023 Heise Medien