En Attack op Front-End-Back-End Systemer déi eis erlaabt an Drëtt Partei Ufroen ze wedge

Entdeckt Detailer vun engem neien Attack op Siten déi e Front-End-Back-End-Modell benotzen, sou wéi déi, déi duerch Inhaltsliwwerungsnetzwierker lafen, Lastbalancer oder Proxyen. D'Attack erlaabt, andeems Dir bestëmmte Ufroe schéckt, an den Inhalt vun aneren Ufroe veraarbecht, déi am selwechte Fuedem tëscht dem Frontend an dem Backend veraarbecht ginn. Déi proposéiert Method gouf erfollegräich benotzt fir en Attack z'organiséieren, deen et méiglech gemaach huet d'Authentifikatiounsparameter vun de Benotzer vum PayPal Service z'ënnerscheeden, déi d'Fuerscher iwwer 40 Tausend Dollar als Deel vun engem Programm bezuelt hunn, fir iwwer d'Präsenz vun onpatchéierte Schwachstelle z'informéieren. D'Attack ass och applicabel fir Siten déi den Akamai Inhalt Liwwerung Netzwierk benotzen.

D'Krux vum Problem ass datt Frontends a Backends dacks verschidden Niveaue vun Ënnerstëtzung fir den HTTP Protokoll ubidden, awer gläichzäiteg Ufroe vu verschiddene Benotzer an e gemeinsame Kanal encapsuléieren. Fir d'Frontend Empfangsufroen an d'Backend Veraarbechtungsufroen ze verbannen, gëtt eng laanglieweg TCP Verbindung etabléiert, duerch déi d'Benotzer Ufroe vermëttelt ginn, laanscht d'Kette een nom aneren iwwerdroen, getrennt duerch HTTP-Protokoll. Fir Ufroen ze trennen, d'Header "Content-Length" (bestëmmt d'Gesamtgréisst vun den Donnéeën an der Ufro) an "Transfer-Kodéierung: chunked"(erlaabt Iech Daten an Deeler ze transferéieren, andeems Dir Blocks vu verschiddene Gréissten am Format "{Gréisst}\r\n{Block}\r\n{Gréisst}\r\n{Block}\r\n0 spezifizéiert".

De Problem entsteet wann de Frontend nëmmen "Content-Length" ënnerstëtzt awer "Transfer-Encoding: chunked" ignoréiert (zum Beispill, Akamai CDN huet dëst gemaach) oder vice versa. Wann Transfer-Encoding: chunked op béide Säiten ënnerstëtzt gëtt, kënnen d'Implementéierungsfeatures vun HTTP Header Parser fir en Attack benotzt ginn (zum Beispill wann de Frontend Linnen ignoréiert wéi "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ", "Transfer-Encoding" :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" oder "Transfer-Encoding: chunked", an de Backend veraarbecht se erfollegräich).

An dësem Fall kann en Ugräifer eng Ufro schécken déi souwuel den "Content-Length" wéi och "Transfer-Encoding: chunked" Header enthält, awer d'Gréisst an "Content-Length" entsprécht net der Gréisst vun der chunked Kette, déi ass méi kleng wéi den eigentleche Wäert. Wann de Frontend d'Ufro no "Content-Length" veraarbecht a weidergeet an de Backend waart bis de Block fäerdeg ass baséiert op "Transfer-Encoding: chunked", da wäert d'Enn vun den Daten baséiert op "Transfer-Encoding: chunked" virdrun bestëmmt ginn an de Rescht Schwäif vun der Demande den Ugräifer am Ufank vun der nächster Demande, i.e. den Ugräifer wäert fäheg sinn arbiträr Daten un den Ufank vun engem aneren seng Demande iwwerdroen nächste.

Fir de Problem an der benotzter Frontend-Backend Kombinatioun ze bestëmmen, kënnt Dir eng Ufro wéi dëst iwwer de Frontend schécken:

POST /iwwer HTTP/1.1
Host: example.com
Transfer-Kodéierung: chunked
Inhalt-Längt: 4

1
Z
Q

De Problem ass präsent wann de Backend net direkt d'Ufro veraarbecht a waart op d'Arrivée vum endgültege Nullgrenzblock vu Stécker Daten. Fir eng méi komplett kontrolléieren virbereet e speziellen Utility deen och méiglech Methoden testt fir den Header "Transfer-Encoding: chunked" vum Frontend ze verstoppen.

D'Ausféierung vun engem richtegen Attack hänkt vun de Fäegkeeten vum attackéierte Site of, zum Beispill, wann Dir d'Trello Webapplikatioun attackéiert, kënnt Dir den Ufank vun der Ufro ersetzen (Ersatzdaten wéi "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake") a schéckt e Message mat der ursprénglecher Ufro vun engem Drëtt-Partei Benotzer an der Authentifikatiouns-Cookie, déi an deem spezifizéiert ass. Fir en Attack op saas-app.com huet sech erausgestallt datt et méiglech ass JavaScript Code an der Äntwert z'ersetzen andeems en an engem vun den Ufroparameter ersat gëtt. Fir den Attack op redhat.com gouf en internen Handler benotzt fir op d'Websäit vum Ugräifer ze redirecten (eng Ufro vun der Form "POST /search?dest=../assets/idx?redir=//[Email geschützt]/ HTTP/1.1").

D'Benotzung vun der Method fir Inhaltsliwwerungsnetzwierker huet et méiglech gemaach fir einfach de gefrote Site ze ersetzen andeems Dir den Header "Host:" ersetzt. D'Attack kann och benotzt ginn fir den Inhalt vun Inhalt Caching Systemer ze vergëften an cache vertraulech Donnéeën ze extrahieren. D'Pinnacle vun der Method war d'Organisatioun vun engem Attack op PayPal, déi et méiglech gemaach huet Passwierder z'ënnerscheeden, déi vun de Benotzer während der Authentifikatioun geschéckt goufen (d'iframe-Ufro gouf geännert fir JavaScript am Kontext vun der paypal.com/us/gifts Säit auszeféieren, fir déi CSP (Content Security Policy) net applizéiert gouf).

Interessanterweis gouf et 2005 proposéiert eng wesentlech ähnlech Ufro-Spoofing-Technik, déi Iech erlaabt Daten an Caching-Proxyen (Tomcat, Squid, mod_proxy) ze spoofen oder Firewall-Blockéierung ëmzegoen andeems Dir e puer "GET" oder "POST" Ufroe bannent enger HTTP-Sessioun spezifizéiert.

Source: opennet.ru