Angriff auf Frontend-Backend-Systeme, der das Einfügen in externe Anfragen ermöglicht

Entdeckt Details zu einer neuen Angriffsmethode auf Websites, die das Frontend-Backend-Modell nutzen, beispielsweise solche, die über Content Delivery Networks, Lastenausgleich oder Proxys arbeiten. Der Angriff ermöglicht es, durch das Senden bestimmter Anfragen in den Inhalt anderer Anfragen einzudringen, die im gleichen Strom zwischen Frontend und Backend verarbeitet werden. Die vorgeschlagene Methode wurde erfolgreich angewendet, um einen Angriff zu organisieren, der es ermöglicht, die Authentifizierungsparameter von Benutzern des PayPal-Dienstes abzufangen, der den Forschern etwa 40.000 US-Dollar im Rahmen seines Programms zur Meldung ungepatchter Schwachstellen ausgezahlt hat. Der Angriff ist auch für Websites anwendbar, die das Content Delivery Network Akamai verwenden.

Das Problem besteht darin, dass Frontends und Backends oft unterschiedliche Unterstützung für das HTTP-Protokoll bieten, dabei aber die Anfragen verschiedener Nutzer über einen gemeinsamen Kanal bündeln. Um eine dauerhafte TCP-Verbindung zwischen dem anfragenden Frontend und dem verarbeitenden Backend herzustellen, werden die Nutzeranfragen nacheinander übermittelt, getrennt durch die Mittel des HTTP-Protokolls. Zur Trennung der Anfragen können die Header „Content-Length“ (definiert die Gesamtgröße der Daten in der Anfrage) undTransfer-Encoding: chunkedverwendet werden (ermöglicht die Übertragung von Daten in Teilen, wobei Blöcke unterschiedlicher Größe im Format „{Größe}\r\n{Block}\r\n{Größe}\r\n{Block}\r\n0“ angegeben werden).

Das Problem tritt auf, wenn das Frontend nur "Content-Length" unterstützt, aber "Transfer-Encoding: chunked" ignoriert (wie es beispielsweise bei Akamai CDN der Fall war) oder umgekehrt. Bei Unterstützung von "Transfer-Encoding: chunked" auf beiden Seiten können für Angriffe Besonderheiten in der Implementierung von HTTP-Header-Parsern ausgenutzt werden (zum Beispiel, wenn das Frontend Zeilen wie "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked", "Transfer-Encoding:[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" oder "Transfer-Encoding : chunked" ignoriert, während das Backend diese erfolgreich verarbeitet).

In diesem Fall kann der Angreifer eine Anfrage senden, in der gleichzeitig die Header "Content-Length" und "Transfer-Encoding: chunked" angegeben sind, aber die Größe in "Content-Length" nicht der Größe der chunked-Kette entspricht, die kleiner ist als der tatsächliche Wert. Wenn das Frontend die Anfrage gemäß "Content-Length" verarbeitet und weiterleitet, während das Backend auf das Ende des Blocks basierend auf "Transfer-Encoding: chunked" wartet, wird das Ende der Daten basierend auf "Transfer-Encoding: chunked" früher bestimmt und der verbleibende Teil der Anfrage des Angreifers wird am Anfang der nächsten Anfrage erscheinen, d.h. der Angreifer erhält die Möglichkeit, beliebige Daten an den Anfang der nachfolgenden Anfrage anzuhängen.

Um das Problem in der verwendeten Frontend-Backend-Kombination zu identifizieren, kann über das Frontend eine Anfrage des folgenden Typs gesendet werden:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Das Problem liegt vor, wenn das Backend die Anfrage nicht sofort verarbeitet und auf den Empfang des finalen nullenden begrenzenden Blocks der chunked-Daten wartet. Für eine umfassendere Überprüfung eine benötigt man ein spezielles Tool, das auch mögliche Methoden testet, um den Header "Transfer-Encoding: chunked" vor dem Frontend zu verbergen.

Die Durchführung eines echten Angriffs hängt von den Möglichkeiten der angegriffenen Website ab. Zum Beispiel kann bei einem Angriff auf die Webanwendung Trello der Beginn der Anfrage manipuliert werden (indem Daten wie „PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake“ eingefügt werden) und eine Nachricht gesendet werden, die die ursprüngliche Anfrage eines anderen Benutzers und die darin enthaltenen Authentifizierungs-Cookies umfasst. Bei einem Angriff auf saas-app.com war es möglich, JavaScript-Code durch Einspeisung in einen der Parameter der Anfrage in die Antwort einzufügen. Für den Angriff auf redhat.com wurde ein interner Handler verwendet, um auf die Website des Angreifers umzuleiten (es wurde eine Anfrage wie „POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1“ eingespeist).

Die Anwendung der Methode für Content Delivery Networks ermöglichte es, die angeforderte Website einfach durch das Ersetzen des Headers „Host:“ zu manipulieren. Der Angriff ist auch anwendbar zur Organisierung der Vergiftung von Caching-Systemen und zum Extrahieren von zwischengespeicherten sensiblen Daten. Der Höhepunkt der Methode war ein Angriff auf PayPal, der es ermöglichte, Passwörter abzufangen, die Benutzer bei der Authentifizierung eingeben (es wurde eine Anfrage für ein iframe geändert, um JavaScript im Kontext der Seite paypal.com/us/gifts auszuführen, für die keine CSP (Content Security Policy) angewendet wurde).

Interessanterweise gab es im Jahr 2005 eine vorgeschlagen ähnliche Technik zur Manipulation von Anfragen, die es ermöglichte, Daten in zwischenspeichernden Proxys (Tomcat, Squid, mod_proxy) zu ersetzen oder Firewalls zu umgehen, indem mehrere „GET“- oder „POST“-Anfragen innerhalb einer HTTP-Sitzung angegeben wurden.

Quelle: opennet.ru