Was ist eine Zero-Day-Schwachstelle?

Zero-Day-Schwachstelle, Exploit und Angriff

Die drei Begriffe werden oft synonym verwendet, beschreiben aber Unterschiedliches:

• Zero-Day-Schwachstelle: die Lücke selbst, dem Hersteller unbekannt oder ohne Fix.
• Zero-Day-Exploit: der Code oder die Technik, die die Lücke ausnutzt.
• Zero-Day-Angriff: der Exploit im Einsatz gegen echte Ziele.

Sobald der Hersteller einen Fix ausliefert, ist die Lücke kein Zero-Day mehr, sondern eine bekannte Schwachstelle, oft N-Day genannt. Damit beginnt ein zweites Rennen: Angreifer untersuchen den Patch und suchen nach Systemen, die ihn nicht eingespielt haben, sodass eine bekannte, ungepatchte Schwachstelle ebenso viel Schaden anrichten kann wie der ursprüngliche Zero-Day.

Zero-Days in Ihren Abhängigkeiten

Der Großteil des Codes einer modernen Anwendung stammt aus Open-Source-Paketen, und die meisten davon sind transitive Abhängigkeiten: von anderen Paketen mitgebracht, nicht von Ihrem Team ausgewählt. Ein Zero-Day in einem davon ist ein Zero-Day in Ihrem Produkt.

Log4Shell (CVE-2021-44228) ist das bekannteste Beispiel. Die im Dezember 2021 offengelegte Lücke erlaubte einem Angreifer, der eine geloggte Nachricht kontrollierte, über Apache Log4j 2 beliebigen Code auszuführen, und erreichte den Höchstwert CVSS 10.0. Für die meisten Teams war nicht der Fix das Schwierige, sondern die Frage davor: Welche unserer Anwendungen enthalten log4j-core, und in welchen Versionen? Log4j war meist eine Abhängigkeit einer Abhängigkeit, und viele Teams brauchten Tage, um das herauszufinden.

Zero-Days in der Lieferkette sind nicht immer Bugs. Im März 2024 fand Andres Freund eine Hintertür in den xz-Versionen 5.6.0 und 5.6.1 (CVE-2024-3094), nachdem ihm aufgefallen war, dass SSH-Logins zu viel CPU verbrauchten. Bösartige Paket-Releases, eine häufige Art von Lieferkettenangriff, funktionieren genauso: Die ersten Teams, die eine infizierte Version installieren, wie die vom npm-Wurm Shai-Hulud getroffenen, stehen vor einem Angriff, den noch kein Advisory und kein Scanner kennt.

So reagieren Sie, wenn ein Zero-Day eine Abhängigkeit trifft

1. Finden Sie heraus, wo er steckt. Listen Sie jede Anwendung, jedes Image und jedes Release auf, das die betroffene Komponente enthält, auch als transitive Abhängigkeit. Dafür brauchen Sie für jeden Build eine genaue SBOM. Ein Lockfile übersieht Abhängigkeiten, die außerhalb des Paketmanagers geladen werden, etwa von Install-Skripten heruntergeladenen Code oder die Betriebssystem-Layer eines Container-Images.
2. Ermitteln Sie den Zeitraum der Exposition. Welche Builds haben die verwundbare Version ausgeliefert, und seit wann? Das sagt Ihnen, was Sie untersuchen und was Sie melden müssen.
3. Dämmen Sie ihn ein. Spielen Sie den Fix oder einen Workaround ein, sobald es einen gibt, und verhindern Sie, dass neue Builds die verwundbare Version ausliefern, sobald sie eine CVE hat. Siehe CVE-Behebung.
4. Prüfen Sie auf Ausnutzung. Suchen Sie nach Anzeichen, dass die Lücke während des Zeitraums der Exposition gegen Sie eingesetzt wurde, und rotieren Sie alle Secrets, die sie erreicht haben könnte.

Sind wir betroffen? führt die ersten beiden Schritte im Detail aus.

Können Sie sich gegen einen Zero-Day verteidigen, den niemand kennt?

Nicht durch Patchen und nicht mit Scannern, denn beides setzt voraus, dass die Lücke bekannt ist. Wirksam ist vor der Offenlegung, zu begrenzen, was ein Angreifer mit einer gefundenen Lücke tun kann:

• Least Privilege. Geben Sie jedem System und jedem CI-Job nur den Zugriff und die Secrets, die er braucht.
• Egress-Kontrolle. Blockieren Sie ausgehende Verbindungen zu Hosts, die ein System nicht braucht, damit ein laufender Exploit keine Daten an den Angreifer senden kann. In einem CI-Build ist das eine der wenigen Kontrollen, die selbst dann wirken, wenn Sie das erste Opfer eines neuen bösartigen Pakets sind. Siehe Egress-Richtlinien für GitHub Actions.
• Defense in Depth. Staffeln Sie Kontrollen, damit eine einzelne Lücke nicht alles öffnet.
• Aufzeichnungen, die Sie später durchsuchen können. Wird der Zero-Day offengelegt, hängt die Geschwindigkeit Ihrer Reaktion davon ab, dass Sie wissen, was Sie gebaut und ausgeliefert haben.

Wie CRACI hilft

CRACI führt Ihre GitHub-Actions-Jobs auf eigenen Runnern aus und zeichnet jeden Build während seiner Ausführung auf:

• Build-Time-SBOMs listen die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich der verborgenen Abhängigkeiten, die Lockfile-basierte Tools übersehen. So beantworten Sie die Frage „Wo steckt es?“ anhand dessen, was wirklich gebaut wurde. Siehe Build-Time-SBOMs.
• Die Build-Historie zeigt jeden früheren Build und seine SBOM sowie, welche Builds eine verwundbare Abhängigkeit direkt oder transitiv enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren.
• Policy-Gates können einen Build blockieren, der eine bestimmte CVE enthält, damit ein neuer Build die verwundbare Version nicht erneut ausliefert.
• Eine Default-Deny-Egress-Richtlinie blockiert Verbindungen zu Hosts, die der Build nicht braucht, selbst während eines Angriffs, den noch niemand gesehen hat.

Zero-Day-Schwachstellen: häufig gestellte Fragen

Was ist eine Zero-Day-Schwachstelle?

Eine Sicherheitslücke, die Angreifer kennen oder bereits ausnutzen, bevor der Hersteller oder Maintainer einen Fix veröffentlicht hat. Der Name zählt die Tage, die Verteidiger zum Patchen hatten: null.

Was ist der Unterschied zwischen Zero-Day-Schwachstelle, Exploit und Angriff?

Die Schwachstelle ist die Lücke. Der Exploit ist der Code oder die Technik, die sie ausnutzt. Der Angriff ist der Exploit im Einsatz gegen echte Ziele.

Wann ist ein Zero-Day kein Zero-Day mehr?

Wenn ein Fix verfügbar ist. Von da an ist es eine bekannte Schwachstelle, manchmal N-Day genannt, und das Risiko verlagert sich auf Systeme, die den Fix noch nicht eingespielt haben.

Kann ein Scanner einen Zero-Day erkennen?

Nicht per Abgleich. Schwachstellenscanner gleichen Komponenten mit veröffentlichten Advisories ab, und für einen Zero-Day gibt es noch keines. Was ein Scanner oder eine SBOM Ihnen liefert, ist das Inventar, das Sie in dem Moment durchsuchen können, in dem das Advisory erscheint.

Wie finde ich heraus, ob ein Zero-Day meine Software betrifft?

Durchsuchen Sie ein genaues Inventar dessen, was jeder Build und jedes Release enthält, einschließlich transitiver Abhängigkeiten, nach der betroffenen Komponente und den Versionen. Ermitteln Sie dann, welche Releases sie ausgeliefert haben und seit wann, damit Sie den Zeitraum der Exposition kennen.