PwnLab: init | VulnHub Makina Çözümü

Öncelikle siz de şimdi çözeceğimiz makinaya erişmek istiyorsanız https://www.vulnhub.com/entry/pwnlab-init,158/ adresinden makinaya ulaşabilirsiniz : 

pwnlab_init.ova dosyasını indirip sanal makinamıza kurduğumuza göre artık çözüm aşamasına geçebiliriz.Hem hedef  makinamızın hem de kali linux sistemimizin açık olduğundan emin olun.

Her şey hazır olduğuna göre hedef makinamıza sızmamız için öncelikle hedefimizin ip adresini öğrenmeliyiz. Bunun öncesinde hem kali hem de hedef makinamızın aynı ağda olduğundan emin olmalıyız.Ben iki makinamın da networkünü NAT Network yaptım ki size de bunu tavsiye ederim.

Şimdi geldik hedefimizin ip adresini öğrenmeye.

Bu aşamada "netdiscover" adlı aracı kullanacağız.Terminalimizde aşağıda göstermiş olduğum şekilde komudumuzu yazalım:

Bu tarama sonucunda hedef sistemin ip adresinin "192.168.11.134" olduğunu tespit ettik. Şimdi hedef sistemi keşfetmek için nmap taraması atacağız.Aşağıdaki çıktıda gördüğünüz gibi nmap taramamı atıyorum ve çıkan sonuçları inceliyoruz:

80 Http,111 Rpcbind ve 3306 portunda da mysql servisinin çalıştığını görüyoruz. Öncelikle sistemde çalışan web servisini yakından incelemek için 80 portuna gidiyorum, bizi aşağıdaki gibi bir sayfa karşılıyor:

Sitede bulunan upload kısmına geldiğimde login olma uyarısı veriyor ama hala elimizde login olmak için herhangi bir giriş bilgisi yok. Daha da detay elde etmek için siteye "dirsearch" ile dizin taraması atıyorum.
(dirsearch -u http://192.168.11.134):

Aldığımız çıktıda "login.php", "config.php" ve "upload.php" dikkat çekiyor. Tarayıcımda bu dosyaları kontrol etmek istiyorum, önce config.php dizinine gidiyorum:

Gördüğünüz gibi bizi boş ve içeriği gözükmeyen bir sayfa karşılıyor. Bu noktada detaylı düşündüğümüz ve kurcaladığımız zaman içeriğini görmek istediğimiz dizinin .php uzantılı bir dosya olduğunu da göz önüne aldığımız zaman aklımıza "Local file inclusion" zafiyeti geliyor. PHP kapsamında local file inclusion zafiyetlerini kurcaladığımız zaman "php base64 encode filter" zafiyetinin olduğunu tespit ediyoruz. "/?page=php://filter/convert.base64-encode/resource=config.php" payloadını deniyorum, başta olmuyor fakat config.php deki .php uzantısını çıkarıp sadece config ile denediğimde başarılı sonuca ulaşıyorum ve evet artık config.php dosyasının içeriğine sahibiz:

Buradaki base64 ile şifrelenmiş metni decode ediyorum ve root kullanıcısının mysql database giriş bilgilerine ulaşıyorum:

Şimdi terminalimin başına dönüyorum ve hedef sistemdeki mysql servisine az önce elde ettiğimiz bilgilerle giriş yapıyorum:

Yukarıda da gördüğünüz gibi "show databases;" komuduyla var olan veritabanlarını görüntüledim, şimdi ise "use Users" komuduyla Users veritabanını seçiyorum. Daha sonra "show tables;" diyerek users adında bir tablo görüyorum, bu tablonun içeriğini de görmek için "select * from users;" komudunu kullanıyorum ve kullanıcıların isimlerini ve base 64 ile şifrelenmiş şifrelerini ele geçiriyorum:

Base64 ile şifrelenmiş şifreleri kırıyorum ve sitede login olabileceğim şifreleri elde etmiş oluyorum, bu şifreleri yine base64decode.org sitesinde kırdım ve kırılmış şifreleri kullanıcı adlarıyla birlikte users adlı bir dosyaya kaydettim:

Şimdi siteye kent kullanıcısı olarak giriş yapıyorum ve upload kısmına geliyorum, burada bir php reverse shell dosyası oluşturup yüklemek istiyorum fakat yükleyemediğimi görüyorum. Hangi çeşit dosyaların yüklenebildiğini görmemiz lazım. Bunun için aklıma hemen başta yaptığımız local file inclusion açığı geliyor. Bu sefer config.php dosyasının değil de upload.php dosyasının kaynak kodlarını incelememiz lazım,bunun için tekrardan aynı payloadın sonuna upload dosyasını getirerek kaynak kodları ele geçiriyorum:

"/?page=php://filter/convert.base64-encode/resource=upload"

Yine base64 ile şifrelenmiş kodu decode ediyorum ve kaynak kodunu inceliyorum, fotoğrafta daha rahat gözükmesi için kaynak kodunu not defterine kopyalıyorum:

Kaynak kodundan da görüldüğü gibi bir $whitelist tanımlanmış ve ".jpg,.jpeg,.gif ve .png" uzantılı dosyaların yüklenebileceğini belirtmiş, bende bu sebepten ötürü php reverse shell dosyamın başına GIF98 headeri ekliyorum ve dosyanın ismini "shell.php.gif" yapıyorum ki reverse shell dosyam bir gif dosyası olarak algılansın ve sorunsuzca yüklenebilsin (NOT: Kullanmış olduğum reverse shell dosyasını internetten "pentestmonkey php reverse shell" yazarak bulabilirsiniz ve shellin içindeki ip bölümüne kendi hostunuzu yazarak konfigre edebilirsiniz.):

Evet artık login olma ve dosya formatı şartlarını sağladık ve dosyamızı yükledik:

Dosyamızı başarıyla yükledik, dosyamızı kontrol etmek için /upload dizinine gidiyoruz ve en başta gözüken dosyamızı buluyoruz, bir yandan da terminalimizde "rlwrap nc -nvlp 4444" komuduyla dinleyicimizi başlatıyoruz ve upload bölümündeki dosyamıza tıklayarak shell gelmesini bekliyoruz:

Ve evet bir hatayla karşılaştık, dosyamız bir hata sebebiyle açılamıyor. Öncelikle hatanın kaynağına inmemiz lazım. Yükleme ile ilgili şartlar sağlandı ve başarıyla yüklendi fakat şimdi de sorun dosyanın açılamamasında. Tekrardan Local file inclusion açığına başvuracağız çünkü bu sefer de web servisinin "index.php" kaynak kodlarını incelemek istiyoruz."/?page=php://filter/convert.base64-encode/resource=index" komuduyla şifrelenmiş kaynak kodunu buluyorum, tekrardan base64 decode işlemini gerçekleştiriyorum ve index.php sayfasının da kaynak kodlarına ulaşmış oluyorum:

Görüldüğü gibi kaynak kodlarının başında yorum satırına çevrilmiş kod bloğu görülüyor,setcookie parametresi belirtilmiş ve lang teriminden bahsedilmiş. İnternette yaptığımız araştırmalar sonucu cookie ve lang ilişkisini öğreniyoruz ve bununla ilgili bir zafiyet olduğunu tespit ediyoruz, detaylı araştırma için (https://stackoverflow.com/questions/44745295/setting-a-php-cookie-value-to-be-intentionally-vulnerable) kaynağını inceleyebilirsiniz.

Peki bu zafiyeti nasıl sömüreceğiz? Araştırmalarımız sonucunda sayfaya gönderdiğimiz istekteki cookie bölümünü lang parametresiyle yeniden kendimize göre düzenlersek revers shell dosyamızın çalışmasını sağlayabiliriz. Şimdi ne demek istediğimi daha detaylı açıklayabilmem için burp suite kullanacağım.

Burp suite ile web sitesinin upload bölümünde gönderdiğimiz isteği intercept aracılığıyla yakalıyorum, bu isteği repeater bölümüne yollayarak analiz ediyorum :

İşte burada işaretlemiş olduğum Cookie kısmını silip lang parametresiyle yüklediğimiz shell dosyasının konumunu başına "../" getirerek cookie ifadesini tekrardan set etmiş oluyoruz : 

İsteği Send ile gönderdik ve evet artık başarılı bir şekilde hedef sistemden shell alabildik:

"whoami" yazarak "www-data" kullanıcısı olduğumu görüyorum, belki en başta bulduğumuz web kullanıcılarından biri bilinçsizlik yapıp sistemdeki şifrelerini de sitedeki şifreleriyle aynı yapmıştır umuduyla " su kane" yazıyorum ve kane kullancısını test ediyorum:

Evet gerçekten kane kullanıcısı web site şifresiyle local sistemdeki şifresini aynı yapmış, artık kane kullanıcısına sahibiz. /home dizini altındaki kane'in klasörünü inceliyorum: 

kane klasörünün altında mike tarafından suid biti verilmiş "msgmike" adında bir dosya bulunuyor. Suid bitinin ne olduğu hakkında kısaca bahsedersem suid biti verilmiş bir dosyayı çalıştırdığınız zaman o dosyanın sahibinin haklarıyla çalıştırmış olursunuz. Detaylı bilgi için linux dosya izinleri konusuna göz atabilirsiniz.

Şimdi test amaçlı "msgmike" dosyasını çalıştırıyorum ama "/home/mike/msg.txt" adlı bir dosyanın bulunamadığı hatasını alıyorum:

Bu aşamada "strings" komuduyla msgmike dosyasının içeriğine bakıyorum  ve cat ile /home/mike/msg.txt adlı bir dosyayı okumaya yönelik bir kod bloğunun çalıştırıldığını görüyorum:

Burada dikkat etmemiz gereken şey cat komudu path belirtilmeden çalıştırılmış, yani cat adında zararlı bir dosya oluşturup bunu yetki yükseltmek için kullanabiliriz. Öncesinde echo $PATH komuduyla var olan path ortamını görüntülüyoruz:

Mevcut $PATH ortamı /user/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games olarak ayarlanmış.Yapacağımız şey, tmp dizininde kötü niyetli bir cat dosyası oluşturmak ve onu çalıştırılabilir hale getirmek. Daha sonra Path ortamını /tmp dizinini kötü amaçlı dosyamıza işaret edecek şekilde değiştireceğiz:

Evet cat dosyasının içine /bin/bash kodumuzu yazdık ve path ortamını /tmp dizinine göre ayarladık. Bu sayede msgmike adlı dosyayı çalıştırdığımız zaman bu dosya mike yetkileriyle çalıştırılacağı için(bknz:suid yetkisi) ve bash kabuğumuz mike tarafından çalıştırılmış olacağı için artık mike kullanıcısı olmuş olacağız:

Evet gördüğünüz üzere mike kullanıcısı olduk, şimdi mike klasörüne gidelim ve root yetkisine ulaşmak için keşfimize devam edelim.mike klasörünü görüntülediğimiz zaman root tarafından suid biti verilmiş "msg2root" adlı bir dosyayla karşılaşıyoruz. Bunu çalıştırdığımız zaman ise bizden bir input istiyor. Herhangi bir şey girdiğimizde  yazdığımız mesajı tekrardan yazarak program kendini sonlandırıyor: 

Bu sefer yine strings ile dosyanın içeriğini gözlemlemek istiyorum:

Buradan anlıyoruz ki bizden aldığı inputu "/bin/echo" kullanarak root dizini altındaki messages.txt adındaki bir dosyaya yazıyor. İşte zafiyette kendini burada belli ediyor. Çünkü eğer biz "hello;/bin/sh" yazarsak arka planda kod şu şekilde çalışacak: "/bin/echo hello;/bin/sh >> /root/messages.txt"

Bu sayede ise aslında "/bin/sh" komudunu çalıştırmış olacağız ve en önemlisi bu işlem root yetkileriyle gerçekleşeceği için root kullanıcısı olmuş olacağız:

Evet gördüğünüz gibi başarılı bir şekilde root haklarına sahip olduk ve makinamızı başarılı bir şekilde tamamladık.

Okuduğunuz için teşekkürler. Daha fazla teknik ve makina çözümleri için takipte kalın. Sonraki yazılarımda görüşmek dileğiyle.