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).
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:
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:
Ein HHO-Angriff könnte wie folgt durchgeführt werden:
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:
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.
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.
