Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03548.jsonl.gz/2272

Prototype Pollution
Andrea Hauser
So funktioniert Request Smuggling
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.
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.
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 ein Wort der Warnung: 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}
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
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
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:
:zwischen Transfer-Encoding und chunked
: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.
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.
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Andrea Hauser
Andrea Hauser
Andrea Hauser
Andrea Hauser
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv