Bei Request Smuggling handelt es sich um eine Schwachstelle, die dann auftritt, wenn mehrere Server an der Bearbeitung einer Anfrage beteiligt sind und sich diese Server nicht einig sind, wo der Body der Anfrage beginnt und endet. Beispiele für solche Ketten von Servern sind Reverse-Proxys mit ihrem Back-End oder das vielfach eingesetzte Load-Balancing, in dem ein Front-End die Anfragen entgegennimmt und je nach Auslastung an unterschiedliche Back-End-Server zur Verarbeitung schickt. Die Auswirkungen eines erfolgreichen Request Smuggling Angriffs können verheerend sein, es können sensitive Informationen abgegriffen werden, ansonsten unerreichbare Schwachstellen ausgenutzt werden und die normale Benutzung der Webseite für alle Benutzer beeinflusst werden.

Im Normalfall wird bei HTTP/1.1 zwischen dem Front-End-Server und dem Back-End-Server die Verbindung nicht nach jeder Anfrage beendet und eine neue Verbindung aufgebaut. Dies wird gemacht, um Ressourcen zu sparen, da jeder neue Verbindungsaufbau Zeit braucht. Das heisst, dass das Einzige was in der Queue zwischen Front-End und Back-End die Anfragen voneinander aufteilt, sind die in einer Anfrage angegebenen Grössenangaben.

Content-Length und Transfer-Encoding Header

Es gibt zwei unterschiedliche Arten, wie in einer HTTP/1.1 Anfrage die Grösse des Bodys angegeben werden kann. Dies kann einerseits über den Content-Length Header und andererseits über den Transfer-Encoding Header geschehen. Der Content-Length Header gibt die Grösse des Bodys in Bytes an. Beim Transfer-Encoding Header mit dem Parameter chunked wird in sogenannten Chunks gearbeitet. Beispiel einer solchen Anfrage:

POST /test HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
6
test=1
0

Dabei wird im Body als erstes die Grösse des Chunks in Bytes in Hexadezimal angegeben. Im Fall des Beispiels ist der Body test=1 6 Bytes gross. Ein Body kann grundsätzlich mehrere solche chunks mit ihrer jeweiligen Grössenangabe beinhalten. Ein chunked Request wird mit einem 0 und zwei Zeilenumbrüchen abgeschlossen.

Hauptschwachstellen-Typen Request Smuggling

Eine Request Smuggling-Attacke kann nun ausgeführt werden, indem es gelingt die Server in der Kette dazu zu bringen unterschiedliche Grössenangaben zu verarbeiten. Dabei werden den Servern mehrere Möglichkeiten gegeben Grössenangaben zu identifizieren, indem sowohl Content-Length wie auch Transfer-Encoding Header spezifiziert werden. Es gibt dabei drei unterschiedliche Arten wie Server anfällig sein können auf die Schwachstelle.

Bevor allerdings auf konkrete Angriffsmöglichkeiten eingegangen wird, hier eine Vorwarnung: Das Testen dieser Schwachstellen kann Auswirkungen auf Drittpersonen haben, welche die getestete Webseite zur gleichen Zeit benutzen. Das Testen auf diese Schwachstelle sollte erst dann gegen produktive Umgebungen durchgeführt werden, wenn sich der Tester bereits ausführlich mit der Schwachstelle befasst hat und sich den Auswirkungen eines Request Smuggling bewusst ist. Um ein Gefühl für die Schwachstelle zu bekommen, werden die Labs der Web Security Academy von Portswigger empfohlen. Das Einlesen in dieses Thema ist angeraten, da Request Smuggling weitreichende Folgen haben kann. Im Beispiel von Slack wäre eine Übernahme des Session-Cookies von beliebigen Benutzern und somit das Lesen von beliebigen Nachrichten möglich. Die vollumfängliche Beschreibung dieser Schwachstelle ist in HackerOne Report 737140 zu finden.

Die nun folgenden Definitionen der Schwachstellentypen folgen der folgenden Notation:

{verwendete Grössenangabe Front-End}.{verwendete Grössenangabe Back-End}

Schwachstellentyp CL.TE

Im Fall von CL.TE ist es so, dass das Front-End die Content-Length der Anfrage für die Grössenangabe des Bodys verwendet und den Transfer-Encoding Header ignoriert. Das Back-End nimmt allerdings den Transfer-Encoding Header als Ausgangslage, um die Grösse des Bodys zu berechnen. In einem Beispiel würde dies wie folgt aussehen.

POST /test HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0
--> Back-End liest bis hier aufgrund des 0 Chunks
Injected --> Front-End liest bis hier

In diesem Beispiel kennzeichnen die --> Kommentare und können für die Grössenberechnungen des Bodys ignoriert werden. Die Content-Length von 13 Bytes kommt zustande, da zusätzlich zu den im Beispiel sichtbaren Buchstaben noch die unsichtbaren Zeichen \r und \n für die beiden Zeilenumbrüche genutzt werden.

Da das Back-End die Verarbeitung der Anfrage früher beendet, als was das Front-End gesandt hat, bleibt der Rest der Anfragen in der Pipeline zwischen Front-End und Back-End. Sobald eine nächste Anfrage eintrifft, wird der noch in der Pipline vorhandene Rest der vorherigen Anfrage vor dieser neuen Anfrage hinzugefügt. Eine neue Anfrage würde im Back-End also wie folgt aussehen:

InjectedGET /test HTTP/1.1
Host: example.com

Schwachstellentyp TE.CL

Im Fall von TE.CL nutzt das Front-End den Transfer-Encoding Header und das Back-End verwendet den Content-Length Header. In einem Beispiel sieht das wie folgt aus.

POST /test HTTP/1.1
Host: example.com
Content-Length: 8
Transfer-Encoding: chunked

D
test=Injected --> Back-End liest bis und mit test=
0
--> Front-End liest bis hier

Da das Back-End die Verarbeitung der Anfrage früher beendet, als was das Front-End gesandt hat, bleibt der Rest der Anfrage in der Pipeline zwischen Front-End und Back-End. Sobald eine nächste Anfrage eintrifft, wird der noch in der Pipline vorhandene Rest der vorherigen Anfrage vor dieser neuen Anfrage hinzugefügt. Eine neue Anfrage würde im Back-End also wie folgt aussehen:

Injected
0

GET /test HTTP/1.1
Host: example.com

Schwachstellentyp TE.TE

Im Fall von TE.TE benutzen sowohl das Front-End wie auch das Back-End den Transfer-Encoding Header. Durch eine Manipulation des Transfer-Encoding Headers kann allerdings eines der Systeme dazu gebracht werden, den Header nicht mehr zu erkennen und auf die Content-Length zurückzufallen, während der andere Server dennoch noch den Transfer-Encoding Header benutzt. Je nachdem welches System denn Transfer-Encoding Header nicht mehr verwendet, kommt dann wiederum der Schwachstellentyp CL.TE oder TE.CL zum Einsatz.

Es gibt unzählige Varianten, wie der Transfer-Encoding Header verschleiert werden kann. Zum Beispiel wurde festgestellt, dass gewisse Server im Transfer-Encoding Header nur nach dem String chu suchen, um festzustellen, ob es ein chunked Request ist. Gepaart mit einem System, dass dies nicht so handhabt, führt der Header Transfer-Encoding: chu zu einer Diskrepanz zwischen den beiden Servern und öffnet die Möglichkeit für Request Smuggling-Angriffe. Weitere Beispiele den Transfer-Encoding Header zu verschleiern sind:

• Einfügen eines Leerzeichens zwischen dem : zwischen Transfer-Encoding und chunked
• Beginnen des Headers mit einem Leerzeichen
• Verwenden von zwei Transfer-Encoding Headern, wobei einer einen ungültigen Wert hat
• Einfügen eines Zeilenumbruchs vor dem : zwischen Transfer-Encoding und chunked

Ein Beispiel, wie mit einer Verschleierungstechnik des Transfer-Encoding Headers ein Request Smuggling-Angriff auf eine Webseite des U.S. Departments of Defense durchgeführt werden konnte, ist in HackerOne Report 526880 zu finden.

Weiterführende Angriffe

Bei den drei oben gezeigten Schwachstellentypen handelt es sich um die Haupttypen von Request Smuggling-Angriffen, auf denen weitere Attacken basieren. So wird es durch eine Request Smuggling-Schwachstelle zum Beispiel möglich, weitere Schwachstellen auszunutzen, die ansonsten nicht ausnutzbar wären oder nur eine eingeschränkte Auswirkung haben. Beispiele dafür sind Angriffe, die in Headern stattfinden, die normalerweise nicht von einem Angreifer kontrolliert werden können oder XSS-Schwachstellen, die eigentlich nur einen Bereich betreffen, auf den ein Angreifer im Normalfall keinen Zugriff hat. Im HackerOne Report 955170 wird erläutert, wie eine normalerweise harmlose Verhaltensweise bei einem Redirect im Falle einer Request Smuggling-Schwachstelle zu einem Open Redirect führt und in diesem Fall dann zur Ausführung von vom Researcher kontrollierten JavaScript führte.

Wenn bei einem Request Smuggling-Angriff nicht wie bis anher gezeigt nur ein Teil einer Anfrage in die Pipeline hinzugefügt, sondern eine zweite vollständige, valide Anfrage hinzugefügt wird, ist es sogar möglich, die gesamte Kommunikation zu desynchronisieren. Denn dann denkt das Front-End es hat eine Anfrage weitergeleitet, das Back-End sieht allerdings zwei Anfragen und wird dementsprechend zwei Antworten schicken, damit erhält nun jeder Benutzer nicht die Antwort auf seine Anfragen, sondern die des vorgängigen Benutzers. Dies ist natürlich eine sehr destruktive Vorgehensweise, da damit sämtliche Benutzer dieser Front-End Back-End Verbindung davon betroffen sind.

Mit der Einführung des Protokolls HTTP/2 gibt es bei Protokoll-Downgrades zwischen dem Front-End und dem Back-End Server weitere Angriffsflächen, falls beim Downgrade der Anfrage nicht sauber umgewandelt wird. Darauf wird jedoch in einem eigenen Artikel zu HTTP/2 zu einem spätere Zeitpunkt genauer eingegangen.

Hinweise für Tester

Aufgrund der weitreichenden Möglichkeiten dieser Schwachstelle kann das Testen bei einem Fehler zu Auswirkungen auf die gesamte Umgebung führen, das Testing sollte dementsprechend mit Sorgfalt angegangen werden. Mit einer aktuellen Version von BurpSuite Pro wird bei der Durchführung eines Active Scans bereits auf Request Smuggling geprüft. Dabei wird ein Vorgehen gewählt, bei dem die Auswirkung auf andere Benutzer möglichst klein gehalten wird. Am einfachsten machbar ist dies, in dem mit bewusst ausgelösten Time-Outs gearbeitet wird. Zum Beispiel, wenn eine CL.TE Schwachstelle vorhanden ist, kann mit folgender Anfrage ein Time-Out ausgelöst werden:

POST /test HTTP/1.1
Host: example.com
Content-Length: 9
Transfer-Encoding: chunked

6
x=test --> Front-End liest bis hier
X --> Back-End erwartet einen weiteren Chunk oder den Abschluss der Chunks

Da das Back-End nur den ersten Chunk erhält aber nicht entweder das abschliessende 0 oder einen weiteren Chunk wartet das Back-End auf mehr Inhalt, was zu einem Time-Out führt.

Für eine TE.CL Schwachstelle würde das Auslösen eines Time-Outs aufgrund einer Request Smuggling-Schwachstelle wie folgt aussehen:

POST /test HTTP/1.1
Host: example.com
Content-Length: 11
Transfer-Encoding: chunked

0 --> Front-End liest bis hier

x=test --> Back-End erwartet aufgrund des Content-Length Headers Inhalt bis hier

Da das Back-End nur den Inhalt bis zum 0 erhält aber eine grössere Content-Length vorgegeben hat, wartet das Back-End auf mehr Inhalt, was zu einem Time-Out führt.

Es ist wichtig die Schwachstellen immer in der Reihenfolge CL.TE und dann TE.CL zu prüfen, da es bei einer vorhandenen CL.TE Schwachstelle mit einem TE.CL Time-Out Anfrage zu einer Störung von anderen Benutzern der Webapplikation kommen kann.

Wenn durch den ActiveScan von Burp oder durch manuelles Testen eine Request Smuggling-Schwachstelle identifiziert wurde, bietet BurpSuite Pro den Turbo Intruder an, mit dem die identifizierten Schwachstellen geskriptet und ausgenutzt werden können. Ein Beispiel dafür ist in HackerOne Report 498052 zu einer CL.TE Schwachstelle in New Relic beziehungsweise F5 zu finden.

Ebenfalls zu beachten ist, dass die Möglichkeit von False-Negatives besteht, wenn man die Schwachstelle auszunutzen versucht, da es sein kann, dass die erhoffte Antwort nicht beim Tester landet, sondern bei einem nichtsahnenden Benutzer der Webseite. Weiter ist zu beachten, dass es auch zu False-Negatives kommen kann, wenn in einer Entwicklungs- oder Testumgebung getestet wird, da diese eventuell nicht hinter dem gleichen Load-Balancing-Setup liegen wie die produktive Umgebung.

Gegenmassnahmen

Es sollte geprüft werden, ob im eingesetzten Produkt diese Schwachstelle bereits bekannt ist und ein Update/Patch dafür zur Verfügung steht. Da Request Smuggling Schwachstellen bei einer unterschiedlichen Interpretation von Request-Grössen zwischen einem Front-End und einem Back-End entstehen, sollte da angesetzt werden. Das Front-End sollte Anfragen normalisieren, die sowohl die Header Content-Length und Transfer-Encoding chunked enthalten, so dass nur noch einer dieser Header verwendet wird. Wenn das Back-End dennoch jemals eine Anfrage erhält, die sowohl Content-Length wie auch Transfer-Encoding chunked Header enthält, sollte die Anfrage verworfen und die TCP-Verbindung geschlossen werden. Falls die Schwachstelle aufgrund eines HTTP/2-Protokoll-Downgrades zustande kam, sollte wo möglich durchgehend nur HTTP/2 verwendet werden, damit es gar nicht erst zu dieser Schwachstelle kommen kann.

Fazit

Bei Request Smuggling handelt es sich um eine sehr mächtige Schwachstelle mit weitreichenden Auswirkungen. Es wird damit möglich sensitive bzw. vertrauliche Informationen abzufangen und Schwachstellen auszunutzen, die ansonsten nicht ausnutzbar wären. Es ist dementsprechend wichtig beim Testen diese Auswirkungen im Hinterkopf zu behalten, denn wenn etwas falsch gemacht wird, können potentiell alle Benutzer der geprüften Webseite betroffen sein. Es sollte zudem beachtet werden, dass ein Test auf Request Smuggling nicht immer eine hundertprozentige Aussage darüber machen kann, ob diese Schwachstelle tatsächlich vorhanden ist oder nicht.

Über die Autorin

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

• https://hackerone.com/reports/498052
• https://hackerone.com/reports/526880
• https://hackerone.com/reports/737140
• https://hackerone.com/reports/955170
• https://portswigger.net/burp/pro
• https://portswigger.net/web-security/all-labs
• https://portswigger.net/web-security/learning-path