Skip to main content

HTTP/2-Rapid-Reset-Zero-Day-Schwachstelle CVE-2023-44487 finden und beheben

feature http2 vuln

11. Oktober 2023

0 Min. Lesezeit

Forscher und Anbieter haben volumetrische DDoS-Angriffe untersucht, die zwischen August und Oktober 2023 in freier Wildbahn beobachtet wurden. Dabei entdeckten sie eine neuartige „Rapid Reset“-Technik, die Stream-Multiplexing nutzt – eine Funktion des weit verbreiteten HTTP/2-Protokolls.

Die heute offengelegte HTTP/2-Rapid-Reset-Schwachstelle wird unter CVE-2023-44487 geführt und als schwerwiegend eingestuft. Ihr CVSS-Score beträgt 7,5 (von 10).

Es wird davon ausgegangen, dass die Schwachstelle jeden Webserver betrifft, der HTTP/2 implementiert. Wird sie ausgenutzt, kann sie extrem umfangreiche volumetrische DDoS-Angriffe ermöglichen. Wenn Sie von dieser CVE in einem Anwendungs- oder Betriebssystempaket betroffen sind UND dieses Paket in einer Anwendung enthalten ist, die mit Internetzugriff bereitgestellt wird, sollten Sie Folgendes in Betracht ziehen:

  • Wenden Sie sich an Ihren Infrastruktur- und/oder CDN-Anbieter (z. B. Cloudflare, Google Cloud, AWS, Akamai), um sicherzustellen, dass Sie vor dieser Schwachstelle geschützt sind.

  • Aktualisieren Sie das Paket, sofern eine Fehlerbehebung verfügbar ist. Für einige Pakete wurden bereits behobene Versionen veröffentlicht.

Snyk ist von dieser Schwachstelle nicht betroffen

Alle extern zugänglichen Snyk-Dienste sind geschützt. Sie werden entweder hinter Akamai oder Cloud-Load-Balancern gehostet, für die bereits Schutzmaßnahmen umgesetzt wurden.

Schutzmaßnahmen durch Infrastrukturanbieter

Unternehmen sollten zunächst Konfigurationsänderungen und Schutzmaßnahmen über Infrastrukturanbieter und CDNs umsetzen, sofern erforderlich, um die Angriffsfläche für diese neuartige DDoS-Technik zu reduzieren. 

Auch wenn sich die Auswirkungen dieser Schwachstelle durch Infrastrukturanbieter oder Cloud-Load-Balancer erfolgreich eindämmen lassen, sollten Sie nicht dabei stehen bleiben. Beheben Sie die Ursache, indem Sie alle möglicherweise betroffenen Pakete aktualisieren, die von dieser CVE betroffen sein könnten.

Pakete auf behobene Versionen aktualisieren

Als Nächstes sollten Unternehmen prüfen, ob Container-Images oder Open-Source-Ökosysteme betroffen sind, und verfügbare Updates einspielen. Alle Hinweise zu dieser CVE finden Sie in der Snyk Vulnerability Database, indem Sie Ihren Paketmanager bzw. Ihre Container-Distribution auswählen.

Snyk Vulnerability Database, gefiltert nach CVE-2023-44487. Aufgeführt sind ressourcenerschöpfende Schwachstellen mit hohem Schweregrad in betroffenen Paketen.

HTTP/2-Schwachstellen mit Snyk erkennen

Um festzustellen, ob Ihre Projekte oder Anwendungen betroffen sind, können Sie im Bericht Issue Detail nach „CVE-2023-44487“ filtern. So finden Sie die Projekte, die ein Paket mit dieser Schwachstelle enthalten.

Snyk-Dashboard mit Issue-Details, gefiltert nach CVE-2023-44487. Angezeigt werden 32 Issues zu sieben verschiedenen Sicherheitslücken sowie die Anzahl nach Schweregrad.

Projekte mit der Snyk CLI testen

Mit Snyk können Sie die HTTP/2-Schwachstelle auf verschiedene Arten erkennen und beheben – kostenlos. Mit der Snyk CLI können Sie Ihre Projekte lokal testen.

Projekte mit Paketmanagern testen

Führen Sie für Anwendungen in der Snyk CLI den Befehl snyk test aus, um die Abhängigkeiten in Ihrem Repository zu prüfen und einzelne Pakete sowie deren Schwachstellen zu erkennen. Mit snyk test --all-projects können Sie alle Projekte testen. Über das Flag --package-manager= geben Sie den Paketmanager an; mit dem Flag --file= können Sie eine nicht standardmäßige Requirements-Datei festlegen.

Zu den derzeit unterstützten Argumenten für das Flag --package-manager= gehören cocoapods, composer, golangdep, maven, npm, pip und weitere (weitere Optionen finden Sie in der CLI).

Mit der CLI C++-Projekte testen

Führen Sie für Anwendungen in der Snyk CLI snyk test --unmanaged aus, um nicht verwaltete Abhängigkeiten in Ihrem Repository zu prüfen und einzelne Pakete sowie deren Schwachstellen zu erkennen.

Container-Images mit der CLI testen

Führen Sie für Container snyk container test aus, um Betriebssystempakete zu erkennen, die von anfälligen HTTP/2-Versionen abhängen. Die besten Ergebnisse erzielen Sie, wenn Sie sowohl den Image-Namen als auch den Pfad zur Dockerfile angeben, mit der das Image erstellt wurde. Zum Beispiel:

snyk container test debian:10 --file=Dockerfile

Projekte über eine Git-/SCM-Integration testen

Wenn Sie Ihr Projekt über eine unserer unterstützten SCM-Integrationen (GitHub, Bitbucket, GitLab, Azure Repos) in Snyk importieren, wird automatisch ein Test gestartet. Anschließend können Sie über die Snyk-Benutzeroberfläche die http/2-Schwachstellen in Ihren Projekten erkennen, priorisieren und beheben, sobald ein Fix verfügbar ist. 

HTTP/2-Schwachstellen beheben

Sobald Sie anfällige Pakete und Container in Ihrer Umgebung identifiziert haben, können Sie sie mit Snyk beheben. Die Methoden sind ähnlich, aber Sie haben mehrere Möglichkeiten.

Für Open-Source-Komponenten

  • Automatische Behebung: Verbinden Sie Snyk mit Ihren Git-Repositories, damit Snyk nach Möglichkeit Pull Requests zur Aktualisierung Ihres Dependency-Graphen erstellen kann. Erstellen Sie anschließend Ihre Anwendung neu.

  • Manuelle Behebung (Option 1): Wenn Sie eine direkte Abhängigkeit von einer Komponente haben, die von der HTTP/2-Schwachstelle betroffen ist, aktualisieren Sie Ihre Dependency-Datei, um die passende behobene Version anzugeben. Erstellen Sie dann Ihre Anwendung neu.

  • Manuelle Behebung (Option 2): Wenn Ihre Anwendung eine von der HTTP/2-Schwachstelle betroffene Komponente als indirekte oder transitive Abhängigkeit verwendet, ermitteln Sie eine Version Ihrer direkten Abhängigkeit, die eine aktualisierte Version der betroffenen Abhängigkeit einbindet. Erstellen Sie anschließend Ihre Anwendung neu. Unterstützt Ihr Paketmanager Overrides, können Sie die Abhängigkeit alternativ als direkte Abhängigkeit behandeln und in Ihrer Requirements-Datei eine behobene Version angeben.

Für Container-Images

  • Automatische Behebung: Verbinden Sie Snyk mit Ihren Git-Repositories, damit Snyk nach Möglichkeit Pull Requests zur Aktualisierung des Basis-Images in Ihrer Dockerfile erstellen kann. Prüfen Sie unter https://snyk.io/test/docker/<image_name> , ob die vorgeschlagene Aktualisierung des Basis-Images weiterhin die Schwachstelle enthält. Erstellen Sie den Container neu, sobald Sie einen geeigneten Upgrade-Pfad gefunden haben.

Snyk-Projekt-Dashboard mit Empfehlungen für Upgrades des Basis-Images, Anzahl der Schwachstellen, Schweregrade und einer Schaltfläche „Fix-PR öffnen“.
  • Manuelle Behebung: Enthält Ihr Image eine anfällige Version der betroffenen Pakete und ist ein Upgrade des Basis-Images nicht verfügbar oder erwünscht, können Sie das Paket mithilfe der Behebungsempfehlungen von Snyk Container selbst aktualisieren. 

Falls noch kein Fix verfügbar ist

Wenn sich ein bestimmtes Paket oder ein Container nicht aktualisieren lässt, kann diese Schwachstelle wie oben beschrieben vor dem Aufrufpfad eingedämmt werden. Ist beispielsweise ein bestimmter Dienst betroffen und über einen Cloud-Load-Balancer mit dem Internet verbunden, besteht kein Risiko, da alle großen Cloud-Anbieter die Gefahr bereits auf ihrer Ebene eingedämmt haben.

Wie lässt sich die Priorität dieser Schwachstelle mithilfe benutzerdefinierter Richtlinien ändern?

Wenn Sie die Priorität der HTTP/2-Schwachstelle erhöhen möchten, um sie sichtbarer zu machen, können Sie die benutzerdefinierten Richtlinien von Snyk nutzen. Damit lässt sich die Priorität dieser Schwachstellen ändern. Der CVE ist derzeit der Schweregrad „High“ zugewiesen. Wenn Sie diese Priorität ändern möchten, können Sie eine Richtlinie erstellen, die sich auf CVE-2023-44487 auswirkt und den Schweregrad auf Critical setzt.

Sicherheitsregel-Oberfläche, die zeigt, wie CVE-2023-44487 eine Änderung des Schweregrads auf „Kritisch“ auslöst

Wenn Sie das Risiko auf andere Weise eingedämmt haben, können Sie den Schweregrad alternativ auf „Low“ setzen, damit er in Ihren Berichten korrekt dargestellt wird. 

Nach dem Hinzufügen benutzerdefinierter Schweregrad-Richtlinien erneut testen

Nach dem Hinzufügen einer benutzerdefinierten Schweregrad-Richtlinie müssen Projekte erneut getestet werden, damit die geänderten Schweregrade erneut angezeigt werden.

Nächste Schritte zur Reaktion auf die HTTP/2-Schwachstellen

  1. Setzen Sie Konfigurationsänderungen und Schutzmaßnahmen über Infrastrukturanbieter und CDNs um, um die Angriffsfläche für diese neuartige DDoS-Technik zu reduzieren. 

  2. Testen Sie Ihre Projekte mit Snyk mithilfe der in diesem Artikel beschriebenen Methoden. Registrieren Sie sich für ein kostenloses Snyk-Konto, um loszulegen, und importieren und scannen Sie anschließend alle möglicherweise betroffenen Projekte über den Import-Assistenten.

  3. Spielen Sie verfügbare Fixes ein, indem Sie betroffene Bibliotheken auf behobene Versionen aktualisieren und neue Container-Images mit behobenen Basis-Images erstellen.

  4. Beobachten Sie die weitere Entwicklung, folgen Sie uns auf Twitter/X (@snyksec) und informieren Sie sich im Snyk Blog über Neuigkeiten. Die Sicherheitsteams von Snyk aktualisieren unsere Ressourcen regelmäßig mit den neuesten Informationen.

Starten Sie mit Capture-the-Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.

Weiterlesen

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSec: Sicherheit, die mit der KI-Entwicklung Schritt hält

KI-gestützte Entwicklung überholt herkömmliche Security-Workflows. Snyk Agentic AppSec setzt Security-Agenten ein, die Schwachstellen kontinuierlich finden, beheben und überprüfen – während Menschen die Maßstäbe festlegen.

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.