ABUSING HTTP MISCONFIGURATIONS (HTTP YANLIŞ YAPILANDIRMALARININ KÖTÜYE KULLANILMASI)

ABUSING HTTP MISCONFIGURATIONS (HTTP YANLIŞ YAPILANDIRMALARININ KÖTÜYE KULLANILMASI)

Bu yazımızda, modern web uygulamalarında yaygın olarak görülen üç HTTP saldırısını ele alacağız. Bu saldırıları, bu tür saldırıların nasıl tespit edileceği, istismar edileceği ve önleneceği de dahil olmak üzere ayrıntılı olarak tartışacağız.

Çok sayıda kullanıcı tarafından kullanılan web hizmetleri, web sunucusu üzerindeki yükü azaltarak performansı artırmak için web cache’lerden (ön bellek) yararlanır. Web önbellekleri client ile web sunucusu arasında yer alır. Kaynakları web sunucusundan aldıktan sonra yerel olarak depolarlar, böylece aynı kaynak tekrar talep edilirse yerel depolamadan sunabilirler. Böylece kaynakların web sunucusundan talep edilmesine gerek kalmaz ve web sunucusu üzerindeki yük azalır. Web sunucuları web cache kullandığında ortaya çıkabilecek güvenlik açıkları ele alınacaktır.

HTTP Host başlığı, HTTP/1.1'den bu yana tüm HTTP isteklerinde bulunur. İsteğin gönderildiği sunucunun host adını ve potansiyel olarak bağlantı noktasını belirtir. Web sunucuları birden fazla web uygulaması barındırdığında, host başlığı isteğin hangi web uygulamasını hedeflediğini belirlemek için kullanılır ve yanıt buna göre sunulur. Bu yazımızda, web uygulamasında host başlığının yanlış işlenmesinden kaynaklanabilecek güvenlik açıklarını tartışacağız.

HTTP durum bilgisi olmayan bir protokol olduğundan, isteklere yönelik içerik sağlamak için Oturum (Session) gereklidir. Örneğin, HTTP oturumları her istekte kimlik bilgilerini göndermek zorunda kalmadan kimliği doğrulanmış eylemleri gerçekleştirmek için kullanılır. Web uygulaması genellikle kullanıcıyı, kullanıcının çoğu durumda bir oturum cookie’sinde sağladığı oturum ID’si ile tanımlar. Sunucu tarafında, kullanıcı hakkındaki bilgiler ilgili oturum kimliği ile ilişkili oturum değişkenlerinde saklanır. Bu yazımızın son bölümü, oturum değişkenlerinin uygunsuz kullanımından kaynaklanan güvenlik açıklarına odaklanmaktadır.

Web Cache Poisoning

Bu yazımızda ele alınan ilk HTTP saldırısı Web Cache Poisoning’ dir. Bu saldırı, bilmeyen kullanıcıları hedef almak için temel web uygulamasındaki diğer güvenlik açıklarıyla birlikte web önbelleklerindeki yanlış yapılandırmalardan yararlanır. Belirli bir güvenlik açığına bağlı olarak, bir kurbanın istismar edilmek üzere hedeflenen web sitesine erişmesi yeterli olabilir. Web önbellek zehirlenmesi, başka türlü istismar edilemeyecek güvenlik açıklarının çok sayıda potansiyel kurbanı hedef almak üzere silah haline getirilmesine de yol açabilir.

Host Header Attacks

Bu yazımızda ele alınan ikinci saldırı türü Host Header Attacks. HTTP host başlığı, erişilen domainin host’unu içerir ve sunucuya kullanıcının hangi domain’e erişmek istediğini söylemek için kullanılır. Bu, sunucunun hedeflenen uygulamayı tanımlayabilmesi için tek bir sunucunun birden fazla domain veya alt domain’e hizmet verdiği durumlar için gereklidir. Host başlığı saldırıları, host başlığının işlenmesindeki güvenlik açıklarından faydalanır. Daha spesifik olarak, bir web uygulaması host başlığını yetkilendirme kontrolleri için veya mutlak bağlantılar oluşturmak için kullanıyorsa, bir saldırgan bu kontrolleri atlamak veya kötü amaçlı bağlantılar oluşturmaya zorlamak için host başlığını manipüle edebilir.

Session Puzzling

Bu yazımızda ele alınan üçüncü ve son saldırı Session Puzzling’dir. HTTP durum bilgisi olmayan bir protokol olduğundan, kimlik doğrulama da dahil olmak üzere web uygulamalarında yaygın olarak gerçekleştirilen çok çeşitli eylemleri takip etmek için oturum değişkenleri gereklidir. Session puzzling, oturum değişkenlerinin yanlış kullanımından kaynaklanan bir güvenlik açığıdır ve kimlik doğrulama atlamalarına veya hesapların ele geçirilmesine yol açabilir. Session puzzling, özellikle aynı oturum değişkeninin farklı süreçlerde yeniden kullanılması, oturum değişkenlerinin zamanından önce kullanılması ya da oturum değişkenleri için güvenli olmayan varsayılan değerlerin kullanılması sonucu ortaya çıkabilir.

Web cache zehirlenmesi, bir web cache’i savunmasız siteyi ziyaret eden şüphesiz kullanıcılara kötü niyetli içerik sunmaya zorlayan gelişmiş bir saldırı vektörüdür. Web önbellekleri, web sunucusu üzerindeki yükü azalttıkları için performans nedenleriyle web uygulamalarının dağıtımında sıklıkla kullanılır. Bir saldırgan web önbellek zehirlenmesinden faydalanarak çok sayıda kullanıcıya kötü amaçlı içerik sunabilir. Web önbelleği zehirlenmesi, web uygulamasındaki güvenlik açıklarının şiddetini artırmak için de kullanılabilir. Örneğin, web sitesini ziyaret eden tüm kullanıcılara reflected XSS payload’ları sunmak için kullanılabilir, böylece genellikle reflected XSS güvenlik açıklarından yararlanmak için gerekli olan kullanıcı etkileşimi ihtiyacını ortadan kaldırır.

Yaygın olarak kullanılan web önbellekleri arasında Apache, Nginx ve Squid bulunur.

Caching’in Faydaları

Çok sayıda kullanıcı tarafından kullanılan bir web hizmeti sağlarken ölçeklenebilirlik önemlidir. Hizmeti ne kadar çok kullanıcı kullanırsa, web sunucusu üzerinde o kadar fazla yük oluşur. Web sunucusu yükünü azaltmak ve kullanıcıları yedekli web sunucuları arasında dağıtmak için Content Delivery Networks (CDN'ler) ve ters proxy'ler kullanılabilir.

Web önbellekleri bu performans artırıcı altyapının bir parçasıdır. Client ve sunucu arasında yer alırlar ve içeriği web sunucusundan talep etmek yerine kendi yerel depolama alanlarından sunarlar. Bir istemci web önbelleğinde saklanmayan bir kaynak talep ederse, kaynak web sunucusundan talep edilir. Web önbelleği daha sonra kaynağı yerel olarak depolar ve böylece web sunucusundan talep etmeden bu kaynak için gelecekteki tüm taleplere yanıt verebilir. Web önbellekleri, önbellek yenilendikten sonra değişikliklerin yayılmasına izin vermek için genellikle kaynakları sınırlı bir zaman aralığı için saklar.

Web Önbellekleri nasıl çalışır?

Yukarıda tartışıldığı gibi, web önbellekleri web sunucusu üzerindeki yükü azaltmak için kaynakları depolar. Bunlar stil sayfaları veya komut dosyaları gibi statik kaynaklar olabileceği gibi, arama sorguları gibi kullanıcı tarafından sağlanan verilere dayalı olarak web sunucusu tarafından oluşturulan dinamik yanıtlar da olabilir. Önbelleğe alınan kaynakları sunmak için web önbelleğinin, iki isteğe aynı önbellek yanıtının sunulup sunulamayacağını ya da web sunucusundan yeni bir yanıt alınması gerekip gerekmediğini belirlemek üzere istekleri birbirinden ayırt edebilmesi gerekir.

Farklı tarayıcılar, User-Agent başlığı gibi yanıtı doğrudan etkilemeyen farklı başlıklar gönderdiğinden, aynı yanıtın sunulup sunulmayacağını belirlemek için yalnızca istekleri bayt bayt karşılaştırmak oldukça verimsizdir. Ayrıca, web tarayıcıları genellikle bir kaynağın nereden talep edildiğini web sunucusuna bildirmek için Referer başlığını doldurur, ancak çoğu durumda bu da yanıtı doğrudan etkilemez.

Bu sorunları aşmak için web önbellekleri, iki isteğe aynı yanıtın sunulup sunulmayacağını belirlemek için yalnızca tüm istek parametrelerinin bir alt kümesini kullanır. Bu alt kümeye Cache Key adı verilir. Çoğu varsayılan yapılandırmada bu, istek yolunu, GET parametrelerini ve Host başlığını içerir. Ancak, önbellek anahtarları, belirli bir web uygulaması için en iyi şekilde çalışmak üzere herhangi bir HTTP parametresini veya başlığını içerecek veya hariç tutacak şekilde ayrı ayrı yapılandırılabilir.

Bir örneğe göz atalım. Web önbelleğinin önbellek anahtarı olarak istek yolu, GET parametreleri ve host başlığının varsayılan yapılandırmasını kullanacak şekilde yapılandırıldığını varsayarsak, aşağıdaki iki isteğe aynı yanıt sunulur.

İkinci istek aynı önbellek anahtarına sahiptir ve bu nedenle aynı yanıtı alır. İstekler, farklı işletim sistemleri nedeniyle User-Agent başlığında farklılık gösterir ve farklı bir Accept başlığı da içerir.

Ancak, üçüncü bir kullanıcı aynı sayfayı GET parametresi language aracılığıyla farklı bir dilde talep ederse, önbellek anahtarı farklı olur (GET parametreleri önbellek anahtarının bir parçası olduğundan), dolayısıyla web önbelleği farklı bir yanıt sunar. Bu açıkça amaçlanan davranıştır, aksi takdirde tüm kullanıcılara aynı dilde aynı önbellek yanıtı sunulur ve language parametresi işe yaramaz hale gelir:

Keyed parametreler ve unkeyed parametreler arasında ayrım yaparız. Önbellek anahtarının bir parçası olan tüm parametreler keyed(anahtarlı) olarak adlandırılırken, diğer tüm parametreler unkeyed(anahtarsız) olarak adlandırılır. Örneğin, yukarıdaki örnekte User-Agent ve Accept başlıkları anahtarsızdır.

Bu bölümü sonlandırmak için, basit bir web önbelleğini yapılandıran örnek bir Nginx yapılandırma dosyasına göz atalım:

Burada parametrelerin kısa bir açıklaması yer almaktadır, daha ayrıntılı bir genel bakış için buradaki Nginx belgelerine göz atın:

Şimdi aynı kaynağı iki kez talep edersek, ilk yanıtın önbelleğe alınmadığını, ikinci yanıtın ise yanıttaki X-Cache-Status başlığında belirtildiği gibi önbellekten sunulduğunu görebiliriz:

Önbellek anahtarı, yapılandırma aşağıdaki gibi değiştirilerek yalnızca belirli GET parametrelerini içerecek şekilde yapılandırılabilir:

Bu yapılandırmayla, yalnızca language parametresi anahtarlanırken diğer tüm GET parametreleri anahtarlanmaz. Bu, /index.html?language=de&timestamp=1 ve /index.html?language=de&timestamp=2 adreslerine yapılan iki isteğin önbellekten aynı yanıtı almasına neden olur. Bu, örneğin zaman damgası gibi tüm parametreler yanıtın kendisini etkilemiyorsa mantıklıdır.

Bir web önbelleği zehirleme saldırısında, web önbelleğini diğer kullanıcılara kötü amaçlı içerik sunmaya zorlamak isteriz. Bunu yapmak için, yanıta kötü amaçlı bir payload enjekte etmek için kullanabileceğimiz anahtarlanmamış parametreleri belirlememiz gerekir. Anahtarlı parametrelerin kurban kaynağa eriştiğinde aynı olması gerektiğinden, payload’u gönderecek parametre anahtarlanmamış olmalıdır. Bu, kurbanın kötü niyetli payload’u kendisinin göndermesi gerektiği anlamına gelir ve reflected XSS’ye benzer bir senaryoyla sonuçlanır.

Örnek olarak, ref parametresi aracılığıyla reflected XSS'ye karşı savunmasız olan bir web uygulamasını ele alalım. Ayrıca bir language parametresinde birden fazla dili desteklemektedir. Ayrıca ref parametresinin anahtarsız, language parametresinin ise anahtarlı olduğunu varsayalım. Bu durumda, /index.php?language=en&ref="><script>alert(1)</script> URL'sini kullanarak payload'u iletebiliriz. Web önbelleği yanıtı depolarsa, önbelleği başarıyla zehirlemiş oluruz, yani /index.php?language =en kaynağını talep eden sonraki tüm kullanıcılara XSS payload'umuz sunulur. Eğer ref parametresi anahtarlı olsaydı, kurbanın isteği farklı bir önbellek anahtarıyla sonuçlanırdı, böylece web önbelleği zehirli yanıtı sunmazdı.

Bu nedenle, web cache poisoning güvenlik açıklarını belirlemenin ilk adımı, anahtarlanmamış parametreleri belirlemektir. Bir diğer önemli çıkarım ise web önbelleği zehirlemenin çoğu durumda yalnızca altta yatan web uygulamasında halihazırda mevcut olan reflected XSS veya host başlığı güvenlik açıkları gibi diğer güvenlik açıklarının istismarını kolaylaştırmaya yardımcı olduğudur. Ancak bazı durumlarda web önbelleği zehirlenmesi, varsayılan/düz web sunucusu ortamında istismar edilemeyen sorunları istismar edilebilir güvenlik açıklarına dönüştürebilir.

Anahtarlanmamış (unkeyed) istek parametreleri, bize önbelleğe alınmış ya da yeni bir yanıt sunulup sunulmadığına bakılarak tespit edilebilir. Daha önce tartışıldığı gibi, istek parametreleri yolu, GET parametrelerini ve HTTP başlıklarını içerir. Bir yanıtın önbelleğe alınıp alınmadığını belirlemek zor olabilir. Laboratuvarımızda, sunucu bize X-Cache-Status başlığı aracılığıyla bunu söyler, ancak gerçek dünya ortamında durum böyle olmayabilir. Bunun yerine, parametreleri değiştirerek ve yanıtı dikkatlice gözlemleyerek bunu manuel olarak başarabiliriz. Örneğin, bir parametre değerini değiştirirsek ve yanıt aynı kalırsa, bu parametrenin anahtarlanmamış olduğunu ve aynı önbelleğe alınmış yanıtın iki kez sunulduğunu gösterir. Temel bir önbellek zehirleme senaryosunu göstermek için basit bir örnekle başlayalım.

Web uygulamamız, bazı metinleri görüntüleyen ve kendi metnimizi yerleştirmemize izin veren basit bir sitedir:

Web uygulaması GET parametresinin language'e ayarlar ve içeriğimiz content parametresi aracılığıyla gömülür. Bu parametrelerden herhangi birinin anahtarlanmamış olup olmadığını araştıralım. Bunu yapmak için, önce yalnızca Language parametresiyle bir ilk istek göndeririz. İlk istek bir önbellek ıskalamasına neden olurken, ikinci yanıt önbelleğe alınmıştır (yanıttaki X-Cache-Status üstbilgisi ile belirtildiği gibi):

Şimdi language parametresinde farklı bir değer gönderdiğimizde, yanıtın farklı olduğunu ve bir cache ıskası (MISS) aldığımızı görebiliriz. Bu nedenle, language parametresi keyed olmalıdır:

Aynı mantığı content parametresine de uygulayabiliriz. Aşağıdaki istek serisini gönderdiğimizde aşağıdaki davranışı gözlemleyebiliriz:

Üçüncü istek bir önbellek ıskalama işlemini tetiklediğinden, önbellek anahtarının ilk iki istekten farklı olduğu sonucuna varabiliriz. Ancak, yalnızca content parametresi farklı olduğu için anahtarlanmış olması gerekir. Bu nedenle, hem language hem de content parametreleri anahtarlıdır, yani burada şansımız yok.

Web uygulamasını biraz daha incelediğimizde, yönetici paneline erişmeye çalışmanın ve geri dönmek için bağlantıyı kullanmanın ref adlı üçüncü bir parametre ayarladığını görüyoruz. Bu parametrenin anahtarlı mı yoksa anahtarsız mı olduğunu bulmak için testimizi tekrar uygulayalım. Aşağıdaki davranışı gözlemleyebiliriz:

Bu kez, üçüncü istek de bir önbellek isabetini tetikler. Ancak ref parametresi farklı olduğu için bunun anahtarlanmamış olması gerektiğini biliyoruz. Şimdi ref parametresi aracılığıyla kötü amaçlı bir payload enjekte edip edemeyeceğimizi bulmamız gerekiyor.

Devam etmeden önce, bu anahtarlı ve anahtarsız parametreleri belirleme tekniği hakkında birkaç açıklama yapacağız. Bu, test ortamımızda iyi çalışmaktadır, ancak testimiz sırasında hedef siteye potansiyel olarak çok sayıda kullanıcının eriştiği gerçek bir etkileşimde, anahtarlanmamış bir parametre nedeniyle önbelleğe alınmış bir yanıt alıp almadığımızı veya başka bir kullanıcının isteğinin yanıtın önbelleğe alınmasına neden olup olmadığını belirlemek neredeyse imkansızdır. Bu nedenle Cache Busters 'ı her zaman gerçek dünya etkileşiminde kullanmalıyız, bunu daha sonraki bir bölümde tartışacağız.

Şimdi, ref parametresinin istismar edilebilir olup olmadığını belirlemek için, bu parametrenin yanıt içeriğini nasıl etkilediğini belirlememiz gerekir. Değerinin gönderim formuna yansıtıldığını görebiliriz:

Herhangi bir sanitizasyon uygulanmadığından, HTML öğesinden kolayca çıkabilir ve aşağıdaki gibi reflekted bir XSS tetikleyebiliriz:

Not: Önbelleğe alınmış bir yanıt almamak için language parametresi için daha önce hiç kullanılmamış bir değer kullanmayı unutmayın.

Bu, sayfayı hedeflediğimiz dilde tarayan herhangi bir kullanıcı için önbelleği zehirlememizi sağlar. Amacımız bir yönetici kullanıcıyı /admin.php?reveal_flag=1 isteğinde bulunarak bayrağı göstermeye zorlamaktır ki bunu yapmaya yetkimiz yoktur. Burada XSS payload'u hakkında ayrıntıya girmiyoruz, ancak bunu aşağıdakine benzer bir payload ile başarabiliriz.

Bu, kurbanımızın siteyi language=de parametresiyle ziyaret ettiğini varsayarsak (XSS enjeksiyonu için "> ekledikten sonra) aşağıdaki önbellek zehirleme isteğiyle sonuçlanır:

Önbelleği zehirledikten ve bir süre bekledikten sonra, yönetici siteyi ziyaret etmeli, XSS payload’ımızı tetiklemeli ve bayrağı bizim için ortaya çıkarmalıdır.

Anahtarlanmamış GET parametrelerine benzer şekilde, web sunucusunun yanıtını etkileyen anahtarlanmamış HTTP başlıkları bulmak oldukça yaygındır. Mevcut web uygulamasında, bir debug scriptinin yüklendiği konumu etkileyen artık bir debug başlığı gibi görünen özel HTTP başlığı X-Backend-Server 'ı bulduğumuzu varsayalım:

Bu başlığın anahtarlanmamış olduğunu belirlemek için daha önceki metodolojinin aynısını uygulayabiliriz. Bu başlık sterilize edilmeden yansıtıldığından, bunu bir XSS açığından yararlanmak için de kullanabiliriz. Bu nedenle, aşağıdaki istekle daha önce olduğu gibi aynı payload’u iletmek için başlığı kullanabiliriz:

Makina Çözümü 1 :

Soru : Önbelleği zehirlemek ve admin kullanıcısını bayrağı göstermeye zorlamak için bu bölümde öğrendiklerinizi kullanmaya çalışın.

Cevap :

1- Deneme yanılma yoluyla content parametresini değiştirdiğimiz halde HIT değerini alıyoruz. Burdan anlayacağımız content parametresi unkeyed.

2 — Payloadımızı url encode edelim ve enjekte edelim . İpucu’da yazan ifadeye göre admin langue=de parametresini kullanıyormuş . Bu durumda bizde ona göre ayarlayalım isteğimizi.

3 — Son olarak flag.php sayfasına gidelim ve bayrağımızı alalım .

Web Cache Poisoning Attacks

Web önbellek zehirlenmesi genellikle web uygulamasındaki farklı bir temel güvenlik açığını çok sayıda kullanıcıya dağıtmak için kullanılır. Bu da web önbellek zehirlenmesinin istismarını belirli bir web uygulamasına çok bağımlı hale getirir. Ayrıca, önbelleği zehirlemek genellikle önemsiz değildir. Gerçek dünya senaryolarında, birçok kullanıcı web uygulamasına bizimle aynı anda erişmektedir. Bu nedenle, bir sayfa istediğimizde büyük olasılıkla zaten önbelleğe alınmıştır ve bize yalnızca önbelleğe alınmış yanıt sunulur. Bu durumlarda, web önbelleğinin yanıtı depolamasını sağlamak için kötü niyetli isteğimizi tam olarak önbelleğin süresinin dolduğu zamanda göndermemiz gerekir. Bu zamanlamayı doğru yapmak çok fazla deneme yanılma gerektirir. Ancak, web sunucusu önbelleğin sona erme süresi hakkında bilgi verirse bu çok daha kolay olabilir.

Web Cache Poisoning’in Exploitation & Etkisi

XSS

Web cache poisoning’in istismarı, web uygulamasının kendisindeki temel soruna bağlıdır. Önceki bölümde, anahtarlanmamış bir GET parametresi kullanarak web önbelleği zehirlemenin, kullanıcı etkileşimi ihtiyacını ortadan kaldırarak reflected XSS güvenlik açıklarını bilmeyen kullanıcılara dağıtmak için nasıl kullanılabileceğinin bir örneğini gördük. Ayrıca, kendi başına exploit edilemeyen unkeyed HTTP başlığı aracılığıyla bir XSS güvenlik açığının web cache poisoning yardımıyla silah haline getirilebileceğini gördük. XSS, web önbellek zehirlenmesini istismar etmenin en yaygın yollarından biridir, ancak başka yollar da vardır.

Unkeyed Cookies (Anahtarlanmamış Cookies)

Bir başka örnek de anahtarlanmamış cookie’lerin istismarıdır. Bir web uygulaması belirli kullanıcı seçimlerini hatırlamak için bir kullanıcı cookie’si kullanıyorsa ve bu cookie anahtarlanmamışsa, önbelleği zehirlemek ve bu seçimleri diğer kullanıcılara zorlamak için kullanılabilir. Örneğin, kullanıcının sayfada görüntülenen bir şeye onay verip vermediğini hatırlamak için onay cookie’sinin kullanıldığını varsayalım. Bu cookie anahtarlanmamışsa, bir saldırgan aşağıdaki isteği gönderebilir:

Yanıt cache’lenirse, web sitesini ziyaret eden tüm kullanıcılara içerik sanki önceden onay vermişler gibi sunulur. Web uygulaması, örneğin color=blue cookie’sinde uygulamanın düzenini veya language=en cookie’sinde uygulamanın dilini belirlemek için anahtarlanmamış cookie’ler kullanıyorsa benzer saldırılar mümkündür. Bu tür önbellek zehirlenmesi güvenlik açıkları meydana gelse de, önbellek web sitesiyle normal etkileşim sırasında zehirlendiği için genellikle web sitesi bakımcıları tarafından nispeten hızlı bir şekilde yakalanırlar. Örneğin, bir kullanıcı color=blue cookie’si aracılığıyla düzeni mavi olarak ayarlarsa ve yanıt önbelleğe alınırsa, farklı bir renk seçen diğer kullanıcılar tarafından yapılan sonraki tüm isteklere mavi düzen sunulmaya devam edecektir. Bu nedenle, bu durumlarda bir şeylerin doğru çalışmadığını fark etmek oldukça açıktır.

Denial-of-Service

Web cache poisoning güvenlik açığının bir başka türü de host header etrafında dönmektedir. Gelecek bölümde host başlığı saldırıları hakkında daha fazla ayrıntıya gireceğiz, bu nedenle burada ayrıntılı olarak tartışmıyoruz. Ancak, web cache poisoning’in bir Denial-of-Service (DoS) saldırısına yol açabileceği bir senaryo düşünebiliriz. Host başlığını cache anahtarına dahil eden ancak portu sıyırarak cache’lemeden önce normalleştirme uygulayan hatalı bir web cache’inin kullanıldığı bir ortamı düşünün. Altta yatan web uygulaması daha sonra bir yönlendirme için mutlak bir URL oluşturmak üzere host başlığını kullanır. Buna benzer bir istek:

bunun gibi bir yanıtla sonuçlanacaktır:

Bağlantı noktası yanıtta mevcut olsa da, web önbelleğinin hatalı davranışı nedeniyle önbellek anahtarının bir parçası olarak kabul edilmez. Bu, aşağıdaki gibi bir istek göndererek bir DoS elde edebileceğimiz anlamına gelir:

Yanıt önbelleğe alınırsa, siteye erişmeye çalışan tüm kullanıcılar 1337 numaralı bağlantı noktasına yönlendirilir. Ancak web uygulaması 80 numaralı bağlantı noktasında çalıştığından, kullanıcılar siteye erişemez.

Açıklamalar

Web önbellek zehirlenmesinin en zor kısımlarından biri, bir yanıtın önbelleğe alınmasını sağlamaktır. Birçok kullanıcı bir web sitesini kullandığında, kötü amaçlı payload’umuzu gönderdiğimizde önbelleğin boş olması pek olası değildir, yani bize zaten önbelleğe alınmış bir yanıt sunulur ve isteğimiz web sunucusuna asla ulaşmaz.

İsteğimizde Cache-Control: no-cache başlığını ayarlayarak web önbelleğini atlamayı deneyebiliriz. Çoğu önbellek varsayılan yapılandırmada bu başlığa saygı gösterecek ve bize yanıtı sunmadan önce web sunucusuyla kontrol edecektir. Bu, aynı önbellek anahtarına sahip önbelleğe alınmış bir girdi olsa bile isteğimizi web sunucusuna göndermeye zorlayabileceğimiz anlamına gelir. Bu işe yaramazsa, kullanımdan kaldırılmış Pragma: no-cache başlığını da deneyebiliriz.

Ancak, bu başlıklar web önbelleğini saklanan kopyayı yenilemeye zorlamak için kullanılamaz. Zehirli yanıtımızı önbelleğe almaya zorlamak için, mevcut önbelleğin süresinin dolmasını beklememiz ve ardından isteğimizi önbelleğe alınması için doğru zamanlamamız gerekir. Bu çok fazla tahmin gerektirir. Ancak bazı durumlarda sunucu, önbelleğe alınan bir kaynağın ne kadar süreyle taze kabul edileceği konusunda bizi bilgilendirir. Yanıtın kaç saniye taze kaldığını kontrol etmek için yanıtta Cache-Control başlığına bakabiliriz.

Etki

Web önbellek zehirlenmesinin etkisini genel olarak ifade etmek zordur. Büyük ölçüde dağıtılabilen güvenlik açığına, saldırganın önbelleği ne kadar güvenilir bir şekilde zehirleyebileceğine, payload’un ne kadar süreyle önbelleğe alındığına ve bu zaman diliminde kaç potansiyel kurbanın sayfaya eriştiğine bağlıdır.

Etki ayrıca önbellek yapılandırmasına da bağlı olabilir. User-Agent gibi belirli HTTP üstbilgileri önbellek anahtarına dahil edilirse, web önbelleği farklı User-Agent’lar için farklı önbellek yanıtları sunacağından, saldırganın her hedef grup için önbelleği ayrı ayrı zehirlemesi gerekir.

Önbellek Avcıları

Gerçek dünya senaryolarında, zehirli yanıtımızın web uygulamasının gerçek kullanıcılarına sunulmadığından emin olmamız gerekir. Bunu, tüm isteklerimize bir cache buster ekleyerek başarabiliriz. Cache buster, benzersiz bir cache anahtarını garanti etmek için yalnızca bizim kullandığımız benzersiz bir parametre değeridir. Benzersiz bir önbellek anahtarına sahip olduğumuz için, zehirli yanıt yalnızca bize sunulur ve hiçbir gerçek kullanıcı bundan etkilenmez.

Örnek olarak, önceki bölümdeki web uygulamasını tekrar ziyaret edelim. Admin kullanıcısının German olduğunu ve bu nedenle web sitesini language=de parametresini kullanarak ziyaret ettiğini biliyoruz. Payload’umuzu tamamlayana kadar kendisine zehirli bir yanıt sunulmadığından emin olmak için, yönetici kullanıcıyı etkilemediğimizi garanti etmek amacıyla dil parametresinde bir cache buster kullanmalıyız. Örneğin, ref parametresinin anahtarlanmamış olduğunu belirlediğimizde, XSS için bir kavram kanıtı oluşturduk. Bunu aşağıdaki isteği kullanarak yaptık:

Dil parametresinde gönderdiğimiz değer, hiçbir gerçek kullanıcının ayarlamayacağı benzersiz bir değer olduğundan, bu bizim önbellek kırıcımızdır.

Bir sonraki istekte farklı bir cache buster kullanmamız gerektiğini unutmayın, çünkü language=unusedvalue parametresine sahip cache anahtarı önceki isteğimiz nedeniyle zaten mevcuttur. Dolayısıyla, yeni bir benzersiz ve kullanılmamış önbellek anahtarı elde etmek için dil parametresinin değerini biraz değiştirmemiz gerekecektir.

Advanced Cache Poisoning Teknikleri

Bu bölümde, web sunucusundaki yanlış yapılandırmalardan yararlanarak güvenli yapılandırmaları savunmasız hale getiren iki gelişmiş web önbelleği zehirleme tekniğini tartışacağız.

Fat GET

Fat GET istekleri, bir request body içeren HTTP GET istekleridir. GET parametreleri spesifikasyon gereği sorgu dizesinin bir parçası olarak gönderildiğinden, GET isteklerinin bir istek gövdesi içerebileceğini düşünmek garip olabilir. Ancak, yöntem ne olursa olsun, herhangi bir HTTP isteği bir istek gövdesi içerebilir. Bir GET isteği söz konusu olduğunda, mesaj gövdesinin hiçbir anlamı yoktur, bu yüzden asla kullanılmaz. Bunu, bölüm 4.3.1'de belirtilen RFC 7231'de doğrulayabiliriz:

Bu nedenle, bir request body’ye açıkça izin verilir, ancak herhangi bir etkisi olmamalıdır. Bu nedenle, aşağıdaki iki GET isteği anlamsal olarak eşdeğerdir, çünkü gövde ikincisinde ihmal edilmelidir:

Web sunucusu yanlış yapılandırılmış veya yanlış uygulanmışsa, GET isteklerinin istek gövdesindeki parametreleri ayrıştırabilir, bu da aksi takdirde istismar edilemeyecek olan web önbelleği zehirleme saldırı vektörlerine yol açabilir.

Örnek web uygulamamıza bir göz atalım. Bu, önceki bölümdeki web uygulamasının aynısıdır, ancak bu kez ref GET parametresi anahtarlanmıştır, bu nedenle daha önce olduğu gibi aynı web önbelleği zehirleme saldırısını gerçekleştiremeyiz. Web sunucusunun fat GET isteklerini destekleyip desteklemediğini araştıralım. Bunu yapmak için aşağıdakine benzer bir istek gönderebiliriz:

Language GET parametresi İngilizce olarak ayarlanmıştır, bu nedenle sayfanın İngilizce metin görüntülemesini bekleriz. Ancak, incelendiğinde yanıtın Almanca metin içerdiği görülüyor. Yani web sunucusu fat GET isteklerini destekliyor gibi görünüyor ve hatta istek gövdesinde gönderilen parametreyi gerçek GET parametresine tercih ediyor. Şimdi bunun web önbelleği ile web sunucusu arasında bir tutarsızlık yaratıp yaratmadığını doğrulamamız gerekiyor. Bunu yapmak için aşağıdaki isteği gönderebiliriz:

Şimdi bir önbellek isabeti almalıyız ve web önbelleği, dil parametresini İngilizce olarak ayarlamamıza rağmen Almanca sayfayı döndürür. Bu, ilk isteğimizin enjekte ettiğimiz fat GET parametresiyle önbelleği zehirlediği, ancak web önbelleğinin önbellek anahtarını belirlemek için URL’deki GET parametresini doğru şekilde kullandığı anlamına gelir. Web sunucusundaki bu açığı kullanarak web önbellek zehirlenmesinden bir kez daha faydalanabiliriz.

Ref parametresindeki reflected XSS açığının hala mevcut olduğunu doğruladıktan sonra, web cache poisoning’i kullanarak bunu, önceki bölümde yaptığımız gibi, yönetici kullanıcıyı bayrağı bizim için ifşa etmeye zorlayan stored XSS açığına dönüştürebiliriz. ref parametresi artık anahtarlı olduğu için, aşağıdaki istekle fat GET isteğinde ayarlamamız gerekir:

Bu bizim için önbelleği zehirlemelidir. Aşağıdaki isteği göndererek bunu doğrulayabiliriz. Bir önbellek isabeti aldığımızı ve yanıtın zehirli payload’umuzu içerdiğini görebiliriz:

Bir süre bekledikten sonra, yönetici kullanıcı sayfaya erişmeli, enjekte ettiğimiz XSS payload’umuzu çalıştırmalı ve bizim için bayrağı ortaya çıkarmalıdır.

Not: fat GET istekleri genellikle web uygulamasının kendisinde değil, web sunucusu yazılımındaki bir yanlış yapılandırmadır.

Parametre Gizleme

Bir sistemin web önbellek zehirlenmesine karşı savunmasız olmasına yol açabilecek bir başka yanlış yapılandırma türü de parametre gizlemedir. Tıpkı fat GET isteklerinde olduğu gibi, amaç web sunucusu ile web önbelleği arasında, web önbelleğinin yanıt sunmak için kullandığından farklı bir önbellek anahtarı parametresi kullanacağı şekilde bir tutarsızlık yaratmaktır. Dolayısıyla fikir, fat GET istekleriyle aynıdır.

Parametre gizleme özelliğinden faydalanmak için web önbelleğinin parametreleri web sunucusundan farklı bir şekilde ayrıştırması gerekir. Aşağıda, Python web framework Bottle’da CVE-2020–28473 altında ifşa edilen gerçek dünyadaki bir güvenlik açığına göz atacağız. Güvenlik açığı açıklamasından da görebileceğimiz gibi Bottle, farklı URL parametreleri arasında ayrım yapmak için noktalı virgül kullanılmasına izin vermektedir. Örnek olarak, /test?a=1;b=2 adresine yapılan bir GET isteğini ele alalım. Bottle noktalı virgülü bir ayırma karakteri olarak ele aldığından, iki GET parametresi görür: 1 değerine sahip a (a=1) ve 2 değerine sahip b (b=2). Öte yandan web önbelleği yalnızca 1;b=2 değerine sahip bir GET parametresi a görür. Şimdi web önbelleğini zehirlemek için bundan nasıl yararlanabileceğimize bir göz atalım.

Web uygulamasını başlatırken, bunun fat GET istekleriyle istismar ettiğimiz web uygulamasının aynısı olduğunu ancak Python Bottle’a dönüştürüldüğünü görebiliriz. Aşağıdaki kilit noktaları belirlemek için önceki bölümlerdeki bilgileri uygulayabiliriz:

Şimdi yukarıda tartışılan güvenlik açığından yararlanarak web önbelleği ve web sunucusu arasında bir tutarsızlık yaratalım. Bunu yapmak için anahtarlanmamış bir parametreye ihtiyacımız var. Bu durumda, a parametresinin daha önce tartışılan metodoloji ile anahtarlanmamış olduğunu varsayabiliriz, bu yüzden bu parametreyi kullanacağız. Aşağıdaki istek ile bir proof of concept oluşturabiliriz:

Request language=en parametresini içermesine rağmen yanıtta Almanca metin görüntüleniyor. Bunun neden olduğunu araştıralım. Web önbelleği iki GET parametresi görür: en değerine sahip language (language=en) ve b değerine sahip a;language=de. Öte yandan, Bottle üç parametre görür: en değerine sahip language, b değerine sahip a ve de değerine sahip language. Bottle her parametrenin son oluşumunu tercih ettiğinden, de değeri dil parametresinin değerini geçersiz kılar. Böylece Bottle, Almanca metni içeren yanıtı sunar. a parametresi anahtarsız olduğundan, web önbelleği bu yanıtı önbellek anahtarı language=en için saklar. Önbelleğin zehirlendiğini doğrulamak için aşağıdaki takip isteğini gönderebiliriz:

Yanıt artık bir önbellek isabeti olmalı ve Almanca metni içermelidir. Böylece, önbelleği başarıyla zehirledik.

Not: Önbelleği parametre gizleme ile zehirlemek için, gizlenmiş parametreyi anahtarlanmamış bir parametreye ekleyerek önbellek anahtarından “gizlememiz” gerekir.

Şimdi, daha önce yaptığımız gibi, yönetici kullanıcıyı bizim için bayrağı ortaya çıkarmaya zorlayan bir XSS istismarı oluşturalım. Bottle noktalı virgülü bir ayırma karakteri olarak ele aldığından, payload’umuzdaki tüm noktalı virgül oluşumlarını URL ile kodlamamız gerekir:

Bu isteği gönderdikten ve /?language=de URL’si için yükümüzün önbelleğe alındığını onayladıktan sonra, yönetici istismarımızı tetiklemeli ve bayrak birkaç saniye sonra ortaya çıkmalıdır.

Makina Çözümü 2 :

Soru : Bu bölümde öğrendiklerinizi fatget.wcp.htb vhost’unda fat GET isteklerinden yararlanarak önbelleği zehirlemek ve yönetici kullanıcıyı bayrağı göstermeye zorlamak için kullanmaya çalışın.

Cevap :

1- Öncelikle vhostlarımızı /etc/hosts dosyamıza ekleyelim .

2- Get isteğinin body bölgesine isteğimizi yerleştiriyoruz. language parametresi body bölgesindeki isteği ilk kabul ettiği için payloadımızı enjekte ettik .

Not : Hedef stabil değil onun için GET parametresinde diğer parametrelerin olmaması lazım . Content , ref gibi yani sadece language parametresine cache poising uyguluyoruz.

3- Son olarak flag.php adresine gidelim ve bayrağımızı alalım.

Makine Çözümü 3 :

Soru : Bu bölümde öğrendiklerinizi cloak.wcp.htb vhost’unda parametre gizleme özelliğini kullanarak önbelleği zehirlemek ve yönetici kullanıcıyı bayrağı göstermeye zorlamak için kullanmaya çalışın.

Cevap :

1- vhost server’ımızı /etc/host dosyasına attıktan sonra isteğimizi şu şekilde düzenleyelim . Buradaki amaç language parametremizi zehirlemek .

Not : value=” ”> parametresinden çıkmak için scriptimizin başına “> ekleyemeyi unutmayalım .

Tools of the Trade

Web önbellek zehirlenmesi güvenlik açıklarını ararken en önemli görevlerden biri, bir isteğin hangi parametrelerinin anahtarlı ve hangilerinin anahtarsız olduğunu belirlemektir. Web önbellek zehirlenmesi güvenlik açıklarını belirlememize yardımcı olması için Web-Cache-Vulnerability-Scanner’ı (WCVS) kullanabiliriz. Araç GitHub sürüm sayfasından indirilebilir. Daha sonra, paketi açmamız ve ikili dosyayı çalıştırmamız gerekir:

WCVS, anahtarlı/anahtarsız parametreleri bulmak için kullandığı bir header ve parametre kelime listesi ile birlikte gelir. Araç ayrıca her isteğe otomatik olarak bir cache buster ekler, böylece diğer kullanıcıların yanıtlarını yanlışlıkla zehirleme konusunda endişelenmemize gerek kalmaz. URL’yi -u parametresinde belirterek bir web uygulamasının basit bir taramasını çalıştırabiliriz. Web uygulaması bizi yönlendirdiği ve GET parametresini language=en olarak ayarladığı için, bu GET parametresini de -sp bayrağıyla belirtmemiz gerekir. Son olarak, WCVS’ye -gr bayrağı ile yapmasını söyleyebileceğimiz bir rapor oluşturmak istiyoruz:

Aracın ref sorgu parametresi ile bir web önbellek zehirlenmesi tespit ettiğini görebiliriz. WCVS’nin bizim için oluşturduğu json raporuna bakarsak, proof of concept isteğini görebiliriz:

Bu tool ayrıca fat GET isteklerinin veya parametre gizlemenin istismarını gerektiren daha gelişmiş web önbellek zehirlenmesi güvenlik açıklarını belirlememize de yardımcı olabilir:

Bu kez WCVS, bir HTTP başlığı aracılığıyla web önbelleği zehirlenmesi güvenlik açığının yanı sıra bir fat GET önbellek zehirlenmesi güvenlik açığı tespit etti.

Web Önbelleği Zehirlenmesini Önleme

Karmaşık yapıları nedeniyle, web önbelleği zehirlenmesi güvenlik açıklarını önlemek kolay bir iş değildir. Bazı ortamlarda, backend geliştiricileri gerçek dağıtım ortamında web sunucusunun önünde bir web önbelleği olduğunun farkında olmayabilir. Ayrıca, web önbelleğini ve önbellek anahtarını yapılandıran yöneticiler backend geliştiricilerinden farklı kişiler olabilir. Bu durum, web uygulamasının yanıtı değiştirmek için kullandığı gizli anahtarlanmamış parametreleri ortaya çıkararak potansiyel web önbelleği zehirleme vektörlerine yol açabilir.

Web önbelleğinin doğru şekilde yapılandırılması büyük ölçüde birlikte kullanıldığı web sunucusuna ve web uygulamasına bağlıdır. Bu nedenle, aşağıdaki hususları sağlamamız gerekir:

Ayrıca, yöneticiler önbelleğe almanın gerekli olup olmadığını değerlendirmelidir. Elbette, web önbellekleri birçok durum için önemlidir, ancak gerekli olmadığı ve yalnızca dağıtım karmaşıklığını artırdığı başka durumlar da olabilir. Daha az sert bir başka yaklaşım da önbelleğe almayı yalnızca stil sayfaları ve komut dosyaları gibi statik kaynaklarla sınırlamak olabilir. Bu, web önbelleği zehirlenmesini tamamen ortadan kaldırır. Yine de bir saldırgan web önbelleğini kandırarak aslında statik olmayan bir kaynağı önbelleğe almasını sağlayabilirse yeni sorunlar yaratabilir.

Makine Çözümü 4

Soru : Sağlanan web uygulamasında web önbellek zehirlenmesine karşı savunmasız bir HTTP başlığını tanımlamak için WCVS kullanın.

Cevap : X-Filename

1- WCVS kullanalım.