In den letzten Jahren sind Angriffe im Zusammenhang mit Cache-Poisoning immer häufiger aufgetreten. Mittlerweile kann man von einem deutlich sichtbaren Trend sprechen. Die Security Community untersucht und findet neue Wege für Attacken.

Im Rahmen der jüngsten Version von Acunetix wurden neue Überprüfungen im Zusammenhang mit Sicherheitslücken bei Cache-Poisoning hinzugefügt und man arbeitet in diesem Bereich weiter daran, die Abdeckung zu verbessern. In diesem Artikel möchte ich Ihnen einige Techniken vorstellen, die sich auf eine der neuen Prüfungen beziehen – Cache Poisoning DoS (CPDoS).

Was ist ein Cache Poisoning Denial-of-Service Attacke?

Im Jahr 2019 veröffentlichten Hoai Viet Nguyen und Luigi Lo Iacono ein Whitepaper zu CPDoS-Angriffen. Sie erklärten verschiedene Angriffstechniken und analysierten mehrere Content Delivery-Netzwerke und Webserver, die von solchen Angriffen betroffen sein könnten.

CPDoS-Angriffe sind möglich, wenn sich zwischen dem Client (dem Benutzer) und dem Webserver (dem Back-End) ein Intermediate-Cache-Proxy-Server befindet, der so konfiguriert ist, dass Antworten mit fehlerbezogenen Statuscodes (z. B. 400 Bad Request) zwischengespeichert werden. Der Angreifer kann HTTP-Requests manipulieren und den Webserver zwingen, mit einem solchen Fehlerstatuscode für eine vorhandene Ressource (Pfad) zu antworten. Anschließend speichert der Proxyserver die Error Response zwischen, und alle anderen Benutzer, die dieselbe Ressource anfordern, erhalten die Error Response vom Cache-Proxy anstelle einer gültigen Antwort.

Das Whitepaper enthält drei Angriffstypen, mit denen der Angreifer eine Webanwendung zwingen kann, einen 400-Statuscode zurückzugeben:

  • HTTP Header Oversize (HHO) – Wenn die Größe eines Headers die maximale Headerlänge überschreitet
  • HTTP Meta Character (HMC) – Wenn der Header der Anfrage des Angreifers ein spezielles „illegales“ Symbol enthält
  • HTTP Method Override (HMO) – Wenn der Header der Anfrage des Angreifers das Verb (die Methode) in ein nicht unterstütztes Verb ändert

Neue HHO-Angriffstricks

 Während wir diese Angriffe analysierten und an dem Projekt für Reverse-Proxys arbeitete, gelang es, einige Tricks zu entwickeln, mit denen ein HHO-Angriff ausgeführt werden kann.

Grundsätzlich ist ein HHO-Angriff möglich, wenn die maximale Headerlänge im Cache-Proxy und auf dem Webserver unterschiedlich definiert ist. Verschiedene Webserver, Cache-Server und Load Balancer haben unterschiedliche Default Limits. Wenn der Cache-Proxy ein maximales Header-Limit hat, das höher ist als das im Webserver definierte Limit, kann eine Anforderung mit einem sehr langen Header über den Cache-Server zum Webserver gehen und den Webserver veranlassen, einen 400-Fehler zurückzugeben (das dann vom Cache-Server zwischengespeichert wird).

Die standardmäßige maximale Headerlänge für CloudFront beträgt beispielsweise 20.480 Byte. Andererseits beträgt die maximale Standardheaderlänge für den Apache-Webserver 8.192 Byte. Wenn ein Angreifer eine Anforderung mit einem Header mit einer Länge von 10.000 Byte sendet und der CloudFront-Cache-Proxy diese an einen Apache-Server weiterleitet, gibt der Apache-Webserver einen 400-Fehler zurück.

Ein HHO-Angriff ist jedoch auch dann möglich, wenn der Cache-Server dieselbe Header-Längenbeschränkung wie der Webserver hat oder eine etwas niedrigere. Dafür gibt es zwei Gründe:

  • Die maximale Länge der Headerlänge des Webservers ist eine maximale Länge der Zeichenfolge. Die getesteten Webserver führen keine Normalisierung durch und analysieren wahrscheinlich nicht einmal den Header, bevor die Längenprüfung angewendet wird.
  • Cache-Proxys senden jedoch korrekte (normalisierte) Header an das Back-End.

Beispiel für einen HHO-Angriff mit gleichem Limit 

Ein HHO-Angriff könnte wie folgt durchgeführt werden: 

  1. Der Angreifer sendet eine Anforderung mit einem Header, der 8192 Byte lang ist (einschließlich \r\n), jedoch kein Leerzeichen zwischen dem Headernamen und dem Wert enthält. Zum Beispiel: Header-name:abcdefgh(…)(Insgesamt 8192 Zeichen)
  2. Der Cache-Proxy überprüft die Länge des Headers und stellt fest, dass er nicht länger als 8192 Zeichen ist. Daher wird der Header analysiert und der fehlende Speicherplatz ignoriert.
  3. Anschließend bereitet der Cache-Proxy die richtige Version des Headers vor, der an den Webserver gesendet werden soll:header-name: abcdefgh(…)(Insgesamt 8193 Zeichen)
  4. Der Cache-Proxy überprüft nicht, ob die endgültige Länge des Headers 8192 Zeichen überschreitet, und sendet den Header an den Webserver.
  5. Der Webserver, der den Header empfängt, stellt fest, dass er das Limit um ein Byte überschreitet, und gibt daher die 400-Fehlerseite zurück.

Beispiel für einen HHO-Angriff mit ähnlicher Grenze 

Wenn die maximale Headerlängenbeschränkung für den Cache-Proxy etwas niedriger als das Web Server Limit ist, können man den oben beschriebenen Trick nicht verwenden (1 Byte reicht nicht aus). In einem solchen Fall kann man jedoch eine andere Funktion missbrauchen. 

Viele Proxyserver fügen Header zu Requests hinzu, die an den Webserver weitergeleitet werden. Zum Beispiel X-Forwarded-For, das die IP-Adresse des Benutzers enthält. Wenn die ursprüngliche Anforderung jedoch auch den X-Forwarded-For Header enthält, verkettet der Proxyserver häufig den ursprünglichen Wert mit dem vom Proxyserver festgelegten Wert (der Benutzer-IP).

Dies ermöglicht es uns, den folgenden Angriff auszuführen: 

  1. Der Angreifer sendet eine Anfrage mit folgendem Header:X-Forwarded-For: abcdefgh(…)(Insgesamt 8192 Zeichen)
  2. Der Proxy verkettet diese Anforderung mit seinem eigenen Wert:X-Forwarded-For: abcdefgh(…)12.34.56.78(Insgesamt 8203 Zeichen)
  3. Der Proxy sendet den Wert an den Webserver, der mit einem Fehlercode antwortet, da der Header zu lang ist.

Abhängig vom Typ eines Proxys und seiner Konfiguration können solche hinzugefügten Header unterschiedlich sein und die Länge der hinzugefügten Werte kann ebenfalls unterschiedlich sein.

Die Auswirkungen von CPDoS-Angriffen

Als wir unser neues CPDoS-Skript auf Bug-Bounty-Sites getestet haben, haben wir festgestellt, dass viele Sites für solche Angriffe anfällig sind. In einigen Fällen sind die Auswirkungen des Angriffs jedoch fraglich. Dies liegt daran, dass einige Cache-Proxys so konfiguriert sind, dass Antworten mit Fehlerstatuscodes nur für einige Sekunden zwischengespeichert werden, was die Ausnutzung erschwert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.