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öndermeyi içerir.
Bunun nedeni, yanıt kuyruklarını desenkronize edebileceğimiz ve kurbanın meşru isteğinden gelen yanıtın saldırgana gönderileceği veya kurbanın yanıtına saldırganın kontrolündeki içeriği enjekte ederek yapılmasıdır.
HTTP/1.1, önceki isteklere beklemeden farklı kaynaklar istemeye izin verir. Bu nedenle, eğer bir proxy varsa, proxy'nin görevi, arka uçta gönderilen istekler ile 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şlendiğinde, 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ğin öncesinde 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 başka bir ilginç fark, yaygın bir kaçırma saldırısında hedefin kurbanın isteğinin başlangıcını değiştirmek olduğu, böylece beklenmedik bir eylem gerçekleştirmesidir. HTTP Yanıt kaçırma saldırısında, tam istekler gönderdiğiniz için, bir yükle onlara yanıt verecek onca yanıtı enjekte edebilirsiniz ve bu da desenkronize olan onca kullanıcıya enjekte edilen yanıtları ulaştıracaktır.
Ayrıca, meşru kullanıcılar arasında onca istismarı daha kolay dağıtmanı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ılacak 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 parametreden hemen sonra kuyruğa eklenecektir:
Sonrasında, kurban, uyku halindeki isteğe yanıt alacak ve 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 bir HEAD isteği enjekte ederse, bu görüntülerdeki gibi:
Ardından, mavi isteğe saldırgana yanıt 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 içerikler aslında saldırgan tarafından da enjekte edilen sarı isteğe 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ı depolaması için önbelleğe işaret eden başlığı 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ı, bir öncekiyle benzerlik gösterir, ancak bir 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ğu için, 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)
