Zaman zaman sızma testlerinde 0-day açıkları ile karşılaşıyorum. Çoğu zaman böyle bir aksiyona girmek gereksiz olsa da, güvenlik yamaları tam olan, sıkı ağlarda Nessus gibi zafiyet tarama araçlarının doğal olarak atlayacağı basit 0-gün açıkları, iplik söküğünün başlangıcı olabiliyor. Ele geçirilen bir sunucu üzerinden gelecek olan bir domain parola hash'i domain controller'a giden yolun başlangıcı olabilir.
Binary dosyalarını fuzzlamak genellikle zaman kaybı olsa da, karşılaştığım IP kamera, IP telefon ve Parmak izi okuyucusu [bunun hikayesi çok güzel :) ] gibi cihazların web uygulamalarını fuzzlamak pek eğlenceli olabiliyor.
Not: Burada dikkat edilmesi gereken önemli bir unsur var. Bu tür cihazları kolay bir şekilde hizmet dışı bırakabilirsiniz. Körü körüne değil, cihazlara arkada ne olup ne bittiğini anlayarak yaklaşmak elzem.
Bu sefer bir Network Management System yazılımı ile karşılaştım.
Bilgi Toplama
Bir NMS ürününden beklediğimiz birkaç şey var:- Ağdaki cihazların tespiti
- Ağdaki cihazların izlenmesi
- Ağ performansının analizi
- Ağdaki cihazların yönetimi
- Özelleştirilebilir uyarı ve alarmlar
Küçük bir Google araması, yazılımın ne yaptığına dair bir bilgi verdi. Ürünün kendi sayfasını ziyaret ettiğimizde ürüne ait bir datasheet olduğunu görüyoruz. Bütün bunlar ürünün nasıl çalıştığını anlamamıza yardımcı olması için.
Ürünü exploit-db.com, securityfocus.com, cvedetails.com ve birkaç forumda arattığımda, herhangi bir istismar kodu veya CVE ID bulamadım. Büyük ihtimalle, daha önce birilerinin istismar etmediği bir uygulama.
Yazılımın web arayüzünü tarayıcı ile ziyaret edecek olursak. (Yazılımın güncel versiyonununun bu olduğu sonradan ortaya çıktı) aşağıdaki gibi bir ekranla karşılaşıyoruz.
Daha şimdiden iki problemimiz var gibi gözüküyor.
- 1) CAPTCHA veya benzeri bir doğrulama yok gibi (acaba bir lockout mekanizması var mı?)
- 2) Sayfa herhangi bir şifreleme kullanmıyor
Buraya yapılacak basit bir MiTM saldırısı kullanıcı giriş bilgilerini cleartext olarak saldırgana ifşa edecektir. Üstelik uygulama bruteforce parola tahmin saldırılarına izin verecekmiş gibi gözüküyor. (Sadece daha bilmiyoruz)
Adet yerini bulsun diye yanlış kullanıcı adı ve parola ile giriş denemesi gerçekleştiriyorum:
Dönen cevaba bakacak olursak:
Bruteforce gerçekleştirmek için kolaylıkla hydra veya benzeri bir araca failure string olarak "Wrong User Id or Password" tanımlayabiliriz. Ama (hiç sanmasam da) bu bir lockout durumu gerçekleştirebileceği için bu safhada böyle bir şey girişmiyorum. Hem, gerek de yok. Bu en son çare.
Bir kullanıcı giriş panelinin arkada bir veri tabanı kullanması çok muhtemel. Dahası, arka tarafta bir veri tabanı kullanmayan bir NMS yazılımı ender rastlanan bir şey olurdu. Akla ilk gelen şey olası bir SQL injection açığı.
Id ve Password kutucuklarına rastgele girdiler girdikten sonra gönderdiğim POST isteğini burp'de yakalıyorum ve aşağıdaki gibi değiştiriyorum:
Bu bana giriş yetkisi verdiğine göre,
- 3) bir SQL injection açığı ile karşı karşıyayız. (CVE-2018-9245)
Normalde işimiz daha kolay olurdu, fakat SQLi üzerinden authentication bypass gerçekleştirdiğimizde yukarıdaki hata mesajını alıyoruz ve uygulama bizi tekrar giriş sayfasına yönlendiriyor.
Eminim bunun üstesinden gelmek için bir sürü başka yol düşünülebilir. Ben uygulamanın hatalı yapılandırılmasından kaynaklanan bir hassas bilgi ifşasını kullandım.
Tekrar Burp-Suite ile araya girdiğimizde, giriş yaptıktan sonra gönderdiğimiz ikinci POST isteğine bakıyoruz.
İlk isteğimize bir session id çerezi dönmesini beklerdik. Bunun yerine aşağıdaki çerez ile karşılaşıyoruz:
mainTab_selectedChild=sysinfotab
Burada başka bir açıktan söz edebiliriz,
- 4) Hatalı Doğrulama Mekanizması (CVE-2018-10285)
Uygulama doğrulama sonrası tarayıcıya bir oturum çerezi atamadığından buradan oturum kontrollerinin yapılmadığı ya da eksik yapıldığı çıkarımına varabiliriz. Bunu test etmek için, yukarıdaki isteği kaydedelim ve kullanıcı girişi yapmadan karşıya gönderiyorum.
Dönen cevaba bakacak olursak,
bunun işe yaramadığını göreceğiz. Uygulama oturum çerezleri kullanmasa da, bu sayfanın ziyaret edilmesi için son birkaç dakika içinde (kaynak kodu incelemek lazım) geçerli bir kullanıcı girişi yapılmış olması gerekiyor. Bu noktada SQL injection komutumuzu gönderdikten hemen sonra 2. POST isteğimizi gönderdiğimiz takdirde, az önce olduğu gibi giriş yapıyoruz, fakat uygulamadan hemen geri atılıyoruz.
işte işler burada ilginçleşiyor...
İkinci POST isteğimize dönen HTTP cevabına bakacak olursak,
Yeni bir bulgu ile karşılaşıyoruz
- 5) Hassas Bilgi İfşası (CVE-2018-10286)
Veri tabanı yönetici kullanıcısının ve parolasının cleartext olarak ifşa edildiğini görüyoruz. MiTM saldırısı gerçekleştiren bir saldırgan, bütün bu bilgileri cleartext olarak görebilirdi, ancak bu durumda, böyle bir şey yapmaya ihtiyacı yok.
Not: Veri tabanı parolasını cleartext elde etmiş olmamız güzel haber. Bunu tek başına SQL injection açığından yararlanarak yapamazdık. Ancak parolanın şifrelenmiş halini görüntüleyebilirdik. Eğer parola uzun ve karmaşık bir parola ise, şifreyi kırma şansımız oldukça düşük olurdu.
Uygulama otomatik olarak 2. POST isteğimize cevap dönen veri tabanı kullanıcı ve parola bilgilerini 3. POST requestimizin içinde gönderiyor.
Buradaki "Adam zaten kendi kullanıcı parolası ile giriş yapmış, kendi bilgilerini görüntülese ne çıkar?" mantığı, görüdüğümüz üzere son derece tehlikeli ve güvensiz bir yaklaşım.
Şimdi bu 3. POST isteğine dönen cevaba bakalım,
Artık NMS web arayüzünün admin kullanıcı adı ve parolasını öğrendiğimize göre, bu kullanıcı adı ve parolayı kullanarak arayüze bağlanabiliriz.
İsteğin devamını görüntüleyecek olursak, başka bilgilerin de ifşa olduğunu görebiliriz.
Bunların dışında,
/nms/js/module/define.js
/nms/index.html
gibi dizinleri kullanıcı girişi yapmadan ziyaret ederek kaynak kod içerisinden başka hassas bilgilere ulaşabiliyoruz.
Bütün bunlar çok güzel ama biraz zaman alıyor. Bu işlemlerin hepsini basit bir script ile otomatik bir şekilde gerçekleştirebiliriz.
birşeyler.py
Öncelikle yapmamız gereken şeyleri bir sıralayalım.1) SQLi üzerinden giriş gerçekleştirmek (Hatırlarsak, yakın zamanda giriş yapmadıysak bir sonraki istekler kabul edilmiyordu.)
2) Karşıya nms_start komutunu barındıran bir POST isteği göndermek
3) İsteğe gelen cevap içinden veri tabanı kullanıcı ve parolasını elde etmek
4) Veri tabanı kullanıcı adı ve parolasını 3. bir POST isteği içinde karşıya göndermek
5) Son gönderdiğimiz isteğe gelen cevap içinden NMS arayüzünün yönetici kullanıcı adı ve parolasını öğrenmek
Yeni bir dosya oluşturup karşıya SQL injection komutumuzu gönderelim.
Şimdi nms_start komutunu barındıran POST isteğini gönderelim ve dönen cevabı db_cred_dump değişkenine atayalım.
POST isteğine dönen cevaptan kullanıcı adı ve parolayı ayrıştıralım. Bunu yapmak için basit bir regex kullanabiliriz. Veri tabanı kullanıcı adı ve parolasını sırasıyla postgre_db_user ve postgre_db_pwd değişkenlerine değer olarak atayalım.
Elde ettiğimiz veri tabanı kullanıcı adı ve parolasını son bir POST isteği içinde karşıya gönderelim. Dönen cevabı ise user_dump değişkenine değer olarak atayalım.
user_dump içerisinden, listedeki ilk kullanıcının kullanıcı adı ve parolasını çekelim. İlk oluşturulan kullanıcı her zaman yönetici kullanıcı olacağından, bu işimizi görecektir. Bunun için de basit bir regex yazabiliriz.
Bir şeyler yanlış gider de, elde ettiğimiz dump içinden NMS yönetici kullanıcı adı ve parolasını alamaz isek manuel olarak dump'ı okuyabilmemiz için her şeyi bir dosyaya yazalım.
İşte bu kadar.
Scriptin tamamını exploit-db üzerinden görüntüleyebilirsiniz.
https://www.exploit-db.com/exploits/44515/
Sonuç
Düzenli olarak ağınızda Nessus, OpenVAS gibi zafiyet tarama araçları çalıştırabilir, bütün yamaları eksiksiz bir şekilde geçebilirsiniz. Kendi geliştirdiğiniz uygulamalarınız düzenli olarak sızma testlerinden geçiyor olabilir. Bütün bu çabalar, işlerinizi kolaylaştırması için satın aldığınız test edilmemiş bir ürünün karşısında boşa gidebilir. Daha önce üzerinde hiçbir açık tespit edilmemiş olan ürünlere ekstra dikkat etmekte var.
