Details van de nieuwe aanval op websites die een front-end-back-end model gebruiken, zoals die welke via content delivery netwerken, load balancers of proxies werken. De aanval maakt het mogelijk om via het verzenden van bepaalde verzoeken zich te mengen in de inhoud van andere verzoeken, die in dezelfde stroom tussen de front-end en back-end worden verwerkt. De voorgestelde methode is succesvol toegepast om een aanval te organiseren die het mogelijk maakt om authenticatieparameters van gebruikers van de PayPal-service te onderscheppen, die ongeveer 40.000 dollar aan onderzoekers heeft uitbetaald in het kader van het programma voor het melden van onverholpen kwetsbaarheden. De aanval is ook toepasbaar op websites die gebruik maken van het content delivery netwerk Akamai.
De kern van het probleem is dat front-ends en back-ends vaak een verschillend niveau van ondersteuning voor het HTTP-protocol bieden, terwijl ze tegelijkertijd verzoeken van verschillende gebruikers in een gemeenschappelijke kanaal encapsuleren. Voor de verbinding tussen de verzoekende front-end en de verzoeken verwerkende back-end wordt een langdurige TCP-verbinding tot stand gebracht, waardoor de verzoeken van gebruikers worden doorgestuurd in een keten, één na de ander met scheiding via het HTTP-protocol. Voor het scheiden van verzoeken kunnen de headers "Content-Length" (bepaalt de totale grootte van de gegevens in het verzoek) en "Transfer-Encoding: chunked" worden gebruikt.(stelt in staat om gegevens in delen te verzenden, waarbij blokken van verschillende grootte worden aangegeven in het formaat "{grootte}\r\n{blok}\r\n{grootte}\r\n{blok}\r\n0").
Het probleem ontstaat wanneer de front-end alleen "Content-Length" ondersteunt, maar "Transfer-Encoding: chunked" negeert (bijvoorbeeld, zo handelde CDN Akamai) of vice versa. In het geval dat zowel de front-end als de back-end "Transfer-Encoding: chunked" ondersteunen, kunnen de kenmerken van de implementatie van HTTP-header parsers voor de aanval worden gebruikt (bijvoorbeeld wanneer de front-end regels zoals "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked", "Transfer-Encoding:[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" of "Transfer-Encoding : chunked" negeert, terwijl de back-end deze succesvol verwerkt).
In dit geval kan de aanvaller een verzoek verzenden waarin zowel de headers "Content-Length" als "Transfer-Encoding: chunked" zijn opgegeven, maar de grootte in "Content-Length" niet overeenkomt met de grootte van de chunked-string, die kleiner is dan de feitelijke waarde. Als de frontend het verzoek verwerkt en doorverwijst op basis van "Content-Length", terwijl de backend verwacht dat het blok eindigt op basis van "Transfer-Encoding: chunked", wordt het einde van de gegevens op basis van "Transfer-Encoding: chunked" eerder bepaald en komt de resterende staart van het verzoek van de aanvaller aan het begin van het volgende verzoek terecht, d.w.z. de aanvaller krijgt de mogelijkheid om willekeurige gegevens aan het begin van een ander verzoek te hechten dat volgt.
Om het probleem in de gebruikte frontend-backend combinatie te identificeren, kan via de frontend een verzoek worden verzonden zoals:
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
Het probleem is aanwezig als de backend het verzoek niet onmiddellijk verwerkt en wacht op de aanwezigheid van een finale nulstopblok van chunked-gegevens. Voor een grondigere controle een speciale tool, die ook de mogelijke methoden test om de header "Transfer-Encoding: chunked" voor de frontend te verbergen.
Het uitvoeren van een daadwerkelijke aanval hangt af van de mogelijkheden van de aangevallen website; bijvoorbeeld, bij een aanval op de webapplicatie Trello kan het begin van het verzoek worden vervangen (door gegevens zoals "PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake" in te voegen) en kan een bericht worden verzonden dat het originele verzoek van een andere gebruiker bevat, inclusief de vermelde authenticatiecookies. Voor de aanval op saas-app.com bleek het mogelijk om JavaScript-code in het antwoord in te voegen via een van de parameters van het verzoek. Voor de aanval op redhat.com werd een interne handler gebruikt om door te verwijzen naar de site van de aanvaller (er werd een verzoek zoals "POST /search?dest=..\/assets\/idx?redir=\/\/redhat.com@evil.net\/ HTTP/1.1" ingevoegd).
Het gebruik van de methode voor content delivery-netwerken maakte het mogelijk om eenvoudig de gevraagde website te vervangen door het substitueren van de «Host:»-header. De aanval is ook toepasbaar voor het vervuilen van inhoudsopslag (cache) systemen en het extraheren van gecachte vertrouwelijke gegevens. De hoogtepunt van de toepassing van de methode was de organisatie van een aanval op PayPal, waarmee wachtwoorden konden worden onderschept die gebruikers verzonden tijdens de authenticatie (de wijziging van de iframe-aanroep werd uitgevoerd om JavaScript uit te voeren in de context van de pagina paypal.com/us/gifts, waarvoor geen CSP (Content Security Policy) werd toegepast).
Interessant is dat er in 2005 een vergelijkbare techniek was voor het vervangen van aanvragen, waarmee gegevens in cache proxy's (Tomcat, squid, mod_proxy) konden worden vervangen of blokkades van firewalls konden worden omzeild door meerdere «GET» of «POST» aanvragen binnen één HTTP-sessie op te geven.
Bron: opennet.ru
