Directory Traversal & PortSwigger Directory Traversal Lab Çözümleri

İlker · 26 Ocak 2024

Directory Traversal & PortSwigger Directory Traversal Lab Çözümleri

Merhaba, serimize directory traversal'dan devam ediyoruz. Eminim ki çoğu ctf'de web tabanlı kategorilerinde veya makinelerde bu zaafiyete rastlamışsınızdır. Esasında yapılması, ortaya çıkması basit bir temele dayansa da kritik verileri ele geçirmeye yarayan bir zaafiyet olduğu aşikar. En basit örnekle root bilgilerini almanızın ne denli hasarlara yol açabileceğini söylememe gerek yok.

Kullanıcının normalde erişemeyeceği dizinlere bu zaafiyet sayesinde ulaşması olarak tanımlayabiliriz. "Mesela "/image?filename=15.jpg" URL böyle bir şeyler dönmüş,
karşımızda jpg uzantılı bir dosya var. Bunu da repeater'a atıp denemeler yapacaksınız. filename'den sonra ../../ gibi parametrelerle alt dizinlere inmenize uygulama şayet izin veriyorsa D. traversal olduğuna kanaat getirebiliyorsunuz zira sizin yetkiniz olmasa dahi alt dizinlere inebiliyor ve bu dizinlere okuma, yazma, silme vd. işlemleri yapabiliyorsunuz. Genelde CTF'lerde 80-443le ayağa kalkan uygulamalarda user-pass bilgisi almak için çok kullanılır. salt dizindeki verileri okumak yerine bunlara gidip içindeki verileri de almak mümkün. cd /etc/passwd & cat /bilmemnedizi gibi.... ya da direkt rm -r ile içeriği de silebilirsiniz.

Bu zaafiyetin büyük şirketlerde, alışveriş sitelerinde olduğunu göz önünde bulundurunca ekonomik olarak yıkıma yol açabileceğini kestirebiliriz. Ya da kritik verilerin bulunduğu kamu tüzel kişiliklerinin uygulamaları gibi gibi....

Buradan Lab'ların tümüne erişebilirsiniz. Başlayalım.

6 tane Labımız var. Her birini ayrı ayrı çözeceğim.

Birincisiyle başlayalım. Anlatımlardan edindiğiniz bilgiler ışığında basic olarak ../../../../etc/passwd parametresi aklınızda yer edinmiştir. Laba girdikten sonra file, dosya bulmam lazım, benim ilgimi burada resimler çekiyor. Herhangi bir resme gidip burple isteği yakalıyorum.

Repeater'ı isteği yollayıp "GET /image?filename=15.jpg HTTP/2" parametredeki 15.jpg'i silip ../../../../../../../../../../../../etc/passwd denemesi yapıyorum ve bingo! İlk labı çözmüş olduk.

Şimdi burada ../../../ parametrelerinin geçmediğini, ....// gibi parametreler kullanmamızı istiyor. En basitiyle siteyi yazan arkadaş WAF'a ../ parametresini engelletirse ben burada at koşturamam. Peki ben ....// yazsam acaba iş yapar mı ? Çünkü salt ../ kısmını engellediği için devamında ../ yine kalmış oluyor ve belki istediğimiz değeri döndürüp zaafiyeti sömürmüş olacağız. Deneyelim.

../../../etc/passwd denediğimde

HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 14

"No such file"

çıktısı alıyorum. peki ....//....//....//....//....//....//etc/passwd denesem ?

Cırt, bunda da 400 aldım. O zaman demek ki ya WAF açık, ya da zaten inmek istediğimiz dizindeyiz. Neticede ../../ parametrelerini /'a ulaşmak için kullanmıyor muyuz ? Belki de oradayızdır ? O zaman salt /etc/passwd giriyorum ve bingo!

Diğer laba geçelim.

Lab açıklamasında ../ kısmının strip edildiğinden bahsediliyor. Yani yukarıda anlattığım yazılımcı gözünden bakış burada geçerli. Aklıma direkt ....//....// geliyor ki strip edildikten sonra geriye ../../ kalsın ve biz de dizine inelim rahatça. laba girip resmin isteğini yakaladım ve repeater'a attım.

Bingo! Dediğim gibi çıktı. ....// yaptığımızda ../ parametresini stripledi ve bize yine ../ kaldı ve zaafiyeti sömürmüş olduk.

Gelelim diğer laba.

Şimdi öncelikle belirteyim ki labda URL decode yapmamı istiyor. Yani yazılımcı olan arkadaş waf'a ../ parametresini koysa da URL'i encode ederek belki bypass edebiliriz. Burada sizin yaratıcılığınız konuşacak. 1 kere encode ettiğiniz zaman da WAF'a takılabilir, gerekirse 2,3 kere encode etmek de fayda var. Bileşik faiz gibi düşünün, para getiren para. Burada da encode edilen encode edilmiş URL. Açıklayıcı olduğunu düşünüyorum

Peki... CyberChef imdadımıza koşsun. CyberChef, encode/decode yapmanıza yarayan harikulade bir proje. Belirttiğim linkten gidip url encode'u aktif ediyoruz. ../../../../ parametresini encode ediyorum ve istek olarak Burp'te yollayacağım.

yazılımcı arkadaş waf'a URL encode edilmiş halini de eklemiş, şah çekti bize. URL'i tekrar encode edelim.

sonunda etc/passwd ekleyip isteği yolluyorum.

evet! PoC yazıp 500 doları cukkalayabilirsiniz artık

URL encode olayını bu şekilde özetlemiş olduk.

Gelelim diğer labımıza. Burada daha farklı bir senaryo var. Öncelikle herhangi bir resmi burpte yakalayıp Repeater'a atalım.

Şimdi filename='den sonra /etc/passwd & ../../etc/passwd vd. parametrelerle deneme yapıyorum ama her defasında 400 hatası alıyorum. Labın açıklamasında belirli bir path'in validation yani doğrulama yaptığını söylüyor. Bu da demek oluyor ki filename'den sonra bana vereceği path'i kullanmam lazım ki backend tarafı bu algılasın, yoksa path traversal yemiyor illa da validation'ı yapmak zorunda. İşin özünde yapsa da yapmasa da biz zaten kök dizine gideceğiz. Açıkçası saçma, bir o kadar da mantıklı zira otomasyon yapsan filename'den sonra otomatik parametre girersin ama validation olduğunda bunu yapamazsın ya da buna uyarlaman lazım. (bug hunting yapıldığı göz önüne alınarak bu tarz bir yorumda bulundum.) Peki, validation'ı "/var/www/images/" bu path'te yapıyorsa ben de bundan sonra parametre denemesi yapacağım.

Evet, tam da bu şekilde. Validation'ı yaptı, köke indik ve zaafiyeti sömürdük. Soruyu yazan arkadaşın hayal dünyasına selam gönderip diğer Lab'a geçiyorum.

Açıklamada validation'ı dosya uzantısıyla yaptığını söylüyor, yani parametreleri girdikten sonra .jpg'se jpg yoksa diğer uzantıları mutlaka ekleyeceğim yazacağım parametreye. Yoksa zaafiyeti sömüremeyeceğim.

Klasik parametrelerle girişince 400 hatası alıyorum ve Lab'ın son kısmını okuyoruz. "with null byte bypass" bypass edelim biz de. Ondan önce null byte'ın genel mantığını anlatalım.

Bu güzel özet için Mdisec hocama selamlarımı iletiyorum. Null byte'ı injection'ı bilmezseniz bile Bilal'e anlatır gibi öğrenmiş oluyorsunuz. Ben de size anlatacağım şimdi. Öğrenmeyen kalmasın

Şimdi request.get'ten sonra ../../../............. parametresi var. Nullbyte'ı çakana kadar devamını backend'de okuyor ama eğer null byte enjekte edebiliyorsanız devamını okumuyor. Bu da ne demek ? Devamını okumadığında sonuna /etc/passwd yazıp path traversal'ı arka planda koşturabiliriz demek. Bunu da %00 parametresiyle yani null byte'ı enjekte ederek yapacağız gayet tabi. Mantığı özetle bu şekilde.

Meraklısına şu içeriği bırakıyorum:
Null Byte Injection

Şimdi, 45.jpg'ten sonrasına aşağıdaki gibi kodu enjekte ediyorum.

GET /image?filename=../../../../../../../etc/passwd%00.jpg HTTP/2

bingo! null byte'ı enjekte etmenin mantığını anlattım + Lab'ın açıklamasındaki .jpg yani extension validation olayını da gerçekleştirdik. Dosyanın uzantısı neyse (somut duruma göre değişir) ona göre ekleme yapabilirsiniz.

Böylece PortSwigger'daki Directory Traversal'a ait tüm Lab'ları çözmüş olduk ve ekserinde çoğu yöntemi de kullandık. Bugbounty yaparken, CTF çözerken bu yöntemleri, path traversal mantığını göz ardı etmeyin.

Okuduğunuz için teşekkür ederim!

Directory Traversal ile ilgili birtakım içerikler;