PORTSWIGGER WEB SECURITY - INFORMATION DISCLOSURE LAB ÇÖZÜMLERİ
Information Disclosure - Bilgi Sızıntısı olarak tanımlanan güvenlik zafiyeti, bir web uygulamasında kullanıcılara istemsiz bir şekilde hassas bilgilerin görüntülenmesi veya sızdırılması olarak açıklanabilir. Web sayfaları içeriğe bağlı olarak, kullanıcı adları, finansal bilgiler, ticari iş verileri, web sayfası hakkında teknik detaylar gibi birçok bilginin ifşa edilmesine neden olabilir.
Bir web sayfasının ne tür verileri sızdırdığına yönelik bazı başlıklar şu şekildedir:
- robots.txt dosyası veya dizin listeleri
- Kaynak kodlarına erişim sağlamaya olanak tanıyan hassas bilgiler
- Hata mesajlarında veritabanı tablosunun veya sütun adlarının açıkça belirtilmesi
- Kredi kartı bilgileri gibi son derece önemli verileri gereksiz yere ifşa etmek
- API anahtarları, IP adresleri, veritabanı kimlik bilgileri vb.
Bilgi sızıntısına yönelik birçok recon-exploit yöntemini öğrenmek ve detaylı bilgi edinmek için https://portswigger.net/web-security/information-disclosure/exploiting adresini ziyaret edebilirsiniz.
Bu çalışmada bahsedilen Information Disclosure zafiyeti için tüm laboratuvar çözümleri ele alınmıştır. Keyifli okumalar..
Lab 1: Information disclosure in error messages
Web sayfalarına gönderilen istekler sonucunda bazen hata mesajları alıyoruz ve bu hata mesajları bazen oldukça detaylı olup web sayfası tarafından kullanılan farklı teknolojiler hakkında bilgi sağlayabilirler. Örneğin, bir web sayfasının veritabanı türünü veya sunucuyu sürüm numarasıyla birlikte açıkça kullanıcıya sunabilirler. Bu bilgiler saldırgan için yararlı olmaktadır çünkü bu sürüm için mevcut zafiyetler tespit edilip istismar yöntemleri uygulanabilir.
Bu laboratuvarda, sayfaya gönderilen istek sonrasında dönen hata mesajı içerisinde bir sürüm bilgisinin yer aldığını keşfedeceğiz.
Sayfa üzerinde herhangi bir ürüne ‘View details’ tıklayarak isteği burp suite aracıyla yakalayalım ve isteği repeatera gönderelim.
İstek üzerinde, değeri 3 olan productId değerine bir tamsayı değilde random bir string değeri (arif) verdiğimizde hata mesajı almaktayız. Bu hata mesajı detaylı incelendiğinde en alt tarafta web sayfasının güvenlik zafiyeti bulunan Apache Struts 2 2.3.31 sürümünü kullandığı görülmektedir. Sayfa teknolojisi hakkında bir bilgi ifşası söz konusudur.
Submit solution sekmesinden kullanılan sürüm numarası 2 2.3.31 doğrulandıktan sonra laboratuvarı çözmüş olacağız.
Lab 2: Information disclosure on debug page
Çoğu web sayfası, uygulamanın davranışlarıyla alakalı bilgi içeren özel hata mesajları ve günlükler oluşturmaktadır. Bu bilgiler uygulamayı geliştirme sırasında her ne kadar faydalı olsa da, saldırgan için son derece yararlı bilgiler olabilmektedir. Debugging (hata ayıklama) bilgileri bazen ayrı bir dosyaya kaydedilebilir. Saldırgan bu dosyaya erişebilirse, uygulamanın çalışma mantığı ve çalışma zamanı hakkında bilgi sahibi olabilir ve saldırı gerçekleştirebilir.
Bu laboratuvarda uygulamayla ilgili hassas bilgileri açıklayan bir debugging sayfası mevcuttur. Bu debugging sayfası içerisinde yer alan SECRET_KEY değerini öğreneceğiz.
Burp aracı aktifken sayfayı yenileyelim. Trafiği incelemek ve içerik keşfi yapabilmek için sırasıyla “Target > Site map” adımlarını izleyelim. Ardından ilgili isteği incelersek /cgi-bin/phpinfo.php adlı bir debugging sayfasının var olduğunu göreceğiz. Bu sayfaya ait isteği repeatera gönderip send edelim.
Response’u incelediğimizde bir SECRET_KEY değerinin mevcut olduğunu göreceğiz. Bu değeri Submit solutions sekmesinde doğrulattıktan sonra laboratuvarı çözmüş olacağız.
NOT: SECRET_KEY, imzalı verilerin güvenliğini sağlamak için kullanılan bir anahtardır. Bu anahtarın güvende tutulması oldukça önem taşımaktadır, aksi takdirde saldırganlar bunu kendi imzalı değerlerini oluşturmak için kullanabilir.
Lab 3: Source code disclosure via backup files
Hassas veriler bazen kaynak kodun içinde sabit bir şekilde kodlanmaktadır. Bu veriler arka uç bileşenlerine erişmek için API anahtarlarını ve kimlik bilgilerini içerebilir. Bir sunucu .php gibi belirli bir uzantıya sahip dosyaları işlediği zaman, istemciye metin olarak göndermek yerine genellikle kodu yürütmektedir. Fakat bazı durumlarda web sayfasının kaynak kodu içeriğini döndürmesi sağlanabilir.
Bu web sayfası, gizlenmiş bir dizin ve bu dizin içinde yedekleme dosyaları barındırmaktadır. Kaynak kodunu görüntülemek için bu yedekleme dosyalarını kullanacağız.
Web sayfasında /robots.txt dosyasına açık bir şekilde erişim sağlanabilmektedir. Sayfa üzerinde /robots.txt dosyası görüntülendiğinde bir /backup dizinin varlığı keşfedilecektir.
Ardından URL üzerinden /backup dizinine gidildiğinde ProductTemplate.java.bak adlı bir dosyanın mevcut olduğunu göreceğiz.
Bu dosyanın varlığı farklı olarak “Target > Site map” adımları izlendikten sonra backup dizini altında da keşfedilebilir.
ProductTemplate.java.bak dosyası web sayfasının kaynak kodunu barındırmaktadır. Bu dosyayı tarayıcı üzerinden görüntülediğimizde Postgresql veritabanı için sabit olarak kodlanmış bir parola içerdiğini görmekteyiz. Bu parola bilgisini Submit solutions sekmesinde doğrulattıktan sonra laboratuvarı çözmüş olacağız.
Lab 4: Authentication bypass via information disclosure
Bazı web sayfaları hatalı yapılandırıldıkları için bilgilerinin ifşa edilmesine neden olabilmektedir. Developerlar geliştirme aşamasında çeşitli debugging (hata ayıklama) seçeneklerini devre dışı bırakmayı unutabilir. Örneğin, HTTP TRACE yöntemi tanılama amacıyla tasarlanmıştır. Eğer TRACE yöntemi aktifse, bu yöntemi kullanan kullanıcılara web sunucusu, alınan isteği yanıtta tam bir şekilde yansıtmaktadır. Bu yöntemin kullanılması genellikle sıkıntı oluşturmaz fakat bazen proxy araçları kullanılarak isteklere eklenebilecek değerler ile bazı bilgilerin açığa çıkması söz konusudur.
Bu laboratuvarda kimlik doğrulama yöntemini, gönderilen isteğin yanıtında dönen bir bilgiyi kullanarak bypass edeceğiz.
URL üzerinden admin dizinine gidildiğinde, yönetici arayüzüne yalnızca yerel kullanıcıların kullanabileceğini bildiren bir yazı ile karşılaşmaktayız.
Burp suite ile isteği incelediğimizde /admin paneline yapılan bu isteğin GET formatında olduğu görülecektir.
GET isteğini TRACE olarak değişip isteği yeniden send ettiğimizde dönen response üzerinde ip adresimizi içeren X-Custom-IP-Authorization başlığının eklendiğini gözlemliyoruz. Bu başlık, isteğin localde ana bilgisayarın ip adresiyle gelip gelmediğini belirlemek için kullanılmaktadır. Bu başlığa local ip adresini tanımladığımız zaman admin paneline erişim sağlayabilmekteyiz.
Bunun için sırasıyla “Proxy > Options > Match and Replace > Add” adımlarını izleyelim. Ardından X-Custom-IP-Authorization başlığını, değeri localhost ip adresi olacak şekilde tanımlayalım. Bundan sonrası için gönderilen her istekte bu başlık X-Custom-IP-Authorization:127.0.0.1 şeklinde eklenecektir.
Tarayıcı üzerinden sayfayı yenilediğimizde Admin paneline erişim sağlayabildiğimizi göreceğiz.
Admin panelinde aktif kullanıcılar mevcuttur. Laboratuvarın çözümü için carlos kullanıcısını delete etmemiz yeterli olacaktır.
Lab 5: Information disclosure in version control history
Web sayfalarının birçoğu, Git gibi bir tür sürüm kontrol sistemi kullanılarak geliştirilmektedir. Git projesi, tüm sürüm kontrol verilerini default olarak .git adlı bir klasörde depolar. Bu klasör kaydedilmiş değişiklikleri ve diğer birçok bilgiyi barındıran günlükleri içerebilir. Bazı web sayfaları .git klasörünü üretim ortamında gösterdiği için kullanıcı sadece /.git dizinine giderek erişim sağlayabilir. Dolayısıyla içerisindeki hassas veriler ifşa edilebilir ve saldırılar gerçekleştirilebilir.
Bu web sayfasında sürüm denetim verilerine /.git dizini altında açık bir şekilde erişim sağlanabilmektedir. Bu veriler sayesinde administrator kullanıcısının parolasını öğreneceğiz.
URL üzerinde ./git dizinine gidildiğinde birden fazla dosya ve klasörün olduğu görülecektir. Bu dizin sürüm kontrol verilerini içermektedir.
wget aracıyla bu verilerin kopyasını -r parametresiyle sayfa üzerindeki url’i belirterek linux makinemize indirebiliriz. Windows için alternatif bir yöntem kullanılabilir yada Cygwin gibi UNIX benzeri bir sistem kurularak indirilebilir.
./git dizinindeki verileri Masaüstüne indirdik. ac561f211fa8a2f6c0d33c7e007d00c5.web-security-academy.net dizinine gidip klasörleri listelediğimizde boş olduğu görülecektir. Aslında boş değildir ./git klasörü özel bir klasör olduğu için ls -a komutunu kullanarak görebiliriz.
./git dizininde bir HEAD dosyası mevcuttur. Önce bu dosyayı ardından referans olarak gösterilen master dosyasını görüntüleyelim. Elde edilen git nesnesinin içeriğini görüntülemek için de cat-file -p komutunu kullanıyoruz. Ayrıca çıktının son satırında ‘Remove admin password from config’ iletisi görülmektedir. Devam edelim.
git cat-file -p komut satırını kullanarak sırasıyla parent nesnesini ve ardından admin panelini görebilmek için çıktıda yer alan tree nesnesini görüntüleyelim. admin.conf dosyası, bir yönetici parolası nesnesine referans olmaktadır. Bu nesneyi görüntülediğimizde, sabit kodlanmış yönetici parolasının yerine ADMIN_PASSWORD değişkeninin yer aldığına dikkat edelim. Admin parolası açıkça ifşa edilmektedir. Bu password bilgisini kullanarak administrator kullanıcısıyla login olabiliriz.
Elde ettiğimiz administrator:8pwbyg2tia0hpierp514 hesap bilgisiyle login olduktan sonra admin paneline erişim sağlayabileceğimizi gözlemleyelim.
Admin panelinde carlos kullanıcısını delete ettikten sonra son laboratuvarı da çözmüş olacağız.
Congratulations, you solved the lab!
NOT: Son laboratuvarın çözümü için linux sistemde git cola aracı kullanılabilir.
