HTTP Response Smuggling / Desync
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
Bu gönderinin tekniği videodan alınmıştır: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Öncelikle, bu teknik bir HTTP İstek Kaçırma açığını istismar eder, bu yüzden bunun ne olduğunu bilmelisiniz:
Bu tekniğin ana farkı, yaygın bir HTTP İstek kaçırmadan, kurbanın isteğine bir ön ek ekleyerek saldırmak yerine, kurbanın aldığı yanıtı sızdırmak veya değiştirmek için kullanmamızdır. Bu, HTTP İstek kaçırmayı istismar etmek için 1,5 istek göndermek yerine, proxy yanıt kuyruklarını desenkronize etmek için 2 tam istek göndermemizle yapılır.
Bunun nedeni, yanıt kuyruğunu desenkronize edebilmemizdir, böylece kurbanın meşru isteğinden gelen yanıtın saldırgana gönderilmesi veya kurbanın yanıtına saldırganın kontrolündeki içeriğin enjekte edilmesidir.
HTTP/1.1, önceki isteklere beklemeden farklı kaynaklar istemeye olanak tanır. Bu nedenle, eğer bir proxy varsa, proxy'nin görevi, arka uca gönderilen isteklerin ve ondan gelen yanıtların senkronize bir eşleşmesini korumaktır.
Ancak, yanıt kuyruklarını desenkronize etme konusunda bir sorun vardır. Eğer bir saldırgan bir HTTP Yanıt kaçırma saldırısı gönderirse ve ilk isteğe ve kaçırılan isteğe yanıtlar hemen verilirse, kaçırılan yanıt, kurban yanıtının kuyruğuna eklenmeyecek, bir hata olarak atılacaktır.
Bu nedenle, kaçırılan isteğin arka uç sunucusunda işlenmesi için daha fazla zamana ihtiyacı vardır. Böylece, kaçırılan istek işlenene kadar, saldırganla iletişim sona erecektir.
Eğer bu özel durumda bir kurban bir istek göndermişse ve kaçırılan istek meşru isteğinden önce yanıtlanırsa, kaçırılan yanıt kurbana gönderilecektir. Böylece, saldırgan kurban tarafından "gerçekleştirilen" isteği kontrol edecektir.
Ayrıca, eğer saldırgan bir istek gerçekleştirirse ve kurbanın isteğine verilen meşru yanıt, saldırganın isteğinden önce yanıtlanırsa, kurbanın yanıtı saldırgana gönderilecektir, kurbanın yanıtını çalarak (örneğin, Set-Cookie başlığını içerebilir).
Yaygın HTTP İstek Kaçırma ile bir diğer ilginç fark, yaygın bir kaçırma saldırısında hedefin kurbanın isteğinin başlangıcını değiştirmek olmasıdır, böylece beklenmedik bir eylem gerçekleştirilir. HTTP Yanıt kaçırma saldırısında, tam istekler gönderdiğiniz için, bir yük içinde onlarca yanıt enjekte edebilir ve bu da onlarca kullanıcının enjekte edilen yanıtları almasına neden olacaktır.
Ayrıca, meşru kullanıcılar arasında daha kolay onca istismar dağıtma imkanı sağlamanın yanı sıra, bu aynı zamanda sunucuda bir DoS oluşturmak için de kullanılabilir.
Daha önce açıklandığı gibi, bu tekniği istismar etmek için, sunucuya gönderilen ilk kaçırılan mesajın işlenmesi için çok zaman alması gerekmektedir.
Bu zaman alan istek, sadece kurbanın yanıtını çalmaya çalışmak istiyorsak yeterlidir. Ancak daha karmaşık bir istismar gerçekleştirmek istiyorsanız, bu istismar için yaygın bir yapı olacaktır.
Öncelikle HTTP İstek Kaçırma istismarını kullanarak ilk isteği, ardından zaman alan isteği ve sonra kurbanlara gönderilecek 1 veya daha fazla yük isteği.
HTTP İstek Kaçırma ile bilinen yükler gibi, kurbanın isteğini çalabilirsiniz ama bir önemli farkla: Bu durumda, yanıtın içinde yansıtılan içeriği göndermeniz yeterlidir, kalıcı depolama gerekmez.
Öncelikle, saldırgan, yansıtılan parametre ile son bir POST isteği içeren bir yük gönderir ve büyük bir Content-Length ayarlar.
Ardından, ilk istek (mavi) işlendiğinde ve uyku halindeki istek işlenirken (sarı), bir kurbandan gelen bir sonraki istek, yansıtılan parametrenin hemen ardından kuyruğa eklenecektir:
Sonrasında, kurban, uyku halindeki isteğin yanıtını alacak ve eğer bu arada saldırgan başka bir istek gönderirse, yansıtılan içerik isteğinden gelen yanıt ona gönderilecektir.
Bu noktaya kadar, HTTP İstek Kaçırma saldırılarını nasıl istismar edeceğimizi öğrendik, böylece bir istemcinin alacağı yanıtı kontrol edebiliriz ve ardından kurban için tasarlanmış yanıtı çalabiliriz.
Ancak, yanıtları daha da desenkronize etmek mümkündür.
Yanıt gövdesinde hiçbir içerik olmaması gereken ve GET isteğiymiş gibi Content-Length içermesi gereken HEAD istekleri gibi ilginç istekler vardır.
Bu nedenle, eğer bir saldırgan HEAD isteği enjekte ederse, bu görüntülerdeki gibi:
O zaman, mavi yanıt saldırgana verildiğinde, bir sonraki kurban isteği kuyruğa eklenecektir:
Sonrasında, kurban, HEAD isteğinden gelen yanıtı alacak, bu yanıt bir Content-Length içerecek ama hiç içerik olmayacaktır. Bu nedenle, proxy bu yanıtı kurbana göndermeyecek, ancak bazı içerikler bekleyecektir, bu da aslında saldırgan tarafından enjekte edilen sarı isteğin yanıtı olacaktır:
Önceki örneği takip ederek, kurbanın alacağı yanıtın gövdesini kontrol edebildiğinizi ve HEAD **yanıtının genellikle başlıklarında Content-Type ve Content-Length içerdiğini bilerek, kurbanın XSS oluşturmasına neden olacak aşağıdaki gibi bir istek gönderebilirsiniz:
Daha önce bahsedilen yanıt desenkronizasyonu İçerik Karışıklığı saldırısını istismar ederek, eğer önbellek, kurban tarafından gerçekleştirilen isteğe verilen yanıtı depoluyorsa ve bu yanıt, bir XSS oluşturan enjekte edilmiş bir yanıt ise, o zaman önbellek zehirlenmiştir.
XSS yükünü içeren kötü niyetli istek:
Kurbana, yanıtı önbelleğe alması için başlık içeren kötü niyetli yanıt:
Bu durumda, eğer "kurban" saldırgansa, artık keyfi URL'lerde önbellek zehirlemesi gerçekleştirebilir, çünkü kötü niyetli yanıtla önbelleğe alınacak URL'yi kontrol edebilir.
Bu saldırı, öncekiyle benzer, ancak yükü önbelleğe enjekte etmek yerine, saldırgan kurban bilgilerini önbelleğe alacaktır:
Bu saldırının hedefi, yanıt desenkronizasyonunu tekrar istismar ederek proxy'nin %100 saldırgan tarafından üretilen bir yanıt göndermesini sağlamaktır.
Bunu başarmak için, saldırgan, yanıt içinde bazı değerleri yansıtan bir web uygulaması uç noktası bulmalı ve HEAD yanıtının içerik uzunluğunu bilmelidir.
Bir istismar gönderecektir:
İlk istek çözüldükten ve saldırgana geri gönderildikten sonra, kurbanın isteği kuyruğa eklenir:
Kurban, yanıt olarak HEAD yanıtı + ikinci isteğin yanıtının içeriğini (yansıtılan verilerin bir kısmını içeren) alacaktır:
Ancak, yansıtılan verilerin, yanıt kuyruğunda geçerli bir HTTP yanıtı üreten HEAD yanıtının Content-Length'ine göre bir boyuta sahip olduğunu unutmayın.
Bu nedenle, ikinci kurbanın bir sonraki isteği, saldırgan tarafından tamamen oluşturulmuş bir yanıt alacaktır. Yanıt tamamen saldırgan tarafından oluşturulduğundan, proxy'nin yanıtı önbelleğe almasını da sağlayabilir.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
