| Link | Difficulty | Creator |
|---|---|---|
| Backdoor | Easy | hkabubaker17 |
Scan / Enumeration
Makinedeki açık portları tespit edebilmek için bütün portları tarayan bir nmap taraması ile keşif aşamasına başlıyorum. Komuttaki -T4 parametresi, varsayılan olarak -T3 olan nmap’in tarama hızını biraz daha arttırmamızı sağlıyor. Tarama bitmeden bulduğu port numaralarını ekrana basması ve taramanın ne kadar daha süreceği hakkında düzenli olarak bilgi vermesi için -vv-p- parametresiyle nmap’in 1. porttan 65535. porta kadar tarama yapmasını sağlıyorum. Eğer 0. portu da taramak istersem -p0-65535 parametresini kullanabilirim fakat şu an bunu gerekli görmüyorum.
nmap -T4 -vv -p- $IPTarama sonucunda 3 adet açık port ve 33 adet filtered port ile karşılaşıyorum.
Sadece açık olarak bulduğum portlar üzerinde taramaya devam ediyorum. Bu portları daha ayrıntılı inceleyebilmek için bir nmap taraması daha gerçekleştiriyorum. Komutta belirtmiş olduğum -sVC parametresi, versiyon tespit etme işlevini gören -sV ve script tarama işlevini gören -sC parametrelerinin birleşimiş olarak ifade edilmesidir. Daha önceki taramada bulduğum portları -p parametresiyle belirterek taramanın sadece bu portlar özelinde gerçekleştirilmesini sağlıyorum. Taramanın sonucunda verdiği çıktıyı normal bir metin çıktısı olarak kaydetmek için -oN parametresini kullanıyorum.
nmap -sVC -p22,80,1337 $IP -oN backdoor.nmap
Makinede, 22 portunda SSH – Secure Shell – servisi, 80 portunda Apache web server ve 1337 portunda nmap’ın ne olduğunu tespit edemediği bir servis çalışmakta. 22 portunda bulunan OpenSSH 8.2p1 versiyonunu yakın bir zamanda HackTheBox’ın Secret makinesiyle uğraşırken incelemiş ve herhangi bir zafiyet ile karşılaşmamıştım. Bu yüzden şu an için 22 portu es geçerek 80 portundan zafiyet aramasına başlıyorum.
İlk iş olarak bir tarayıcı aracılığıyla makinenin IP adresini kullanarak web sitesine erişiyorum ve keşfetmeye başlıyorum. Sitenin WordPress ile yapıldığını ve web sitesinin navbar’ında bulunan Home elementinin backdoor.htb domain’ine yönlendirme yaptığını görüyorum. Kendi hosts dosyama backdoor.htb’ı ekliyorum.
Tarayıcı üzerinden backdoor.htb adresi ile makineye ait siteye ulaşabiliyorum. Site üzerinde gezinerek zafiyet içerebilecek noktaları aramaya devam etmeden önce gobuster aracını kullanarak bir dizin ve dosya taraması yapmaya, bu sırada da apache server’ın makinede kullanılan versiyonu herhangi bir zafiyet içeriyor mu kontrolünü yapmaya karar veriyorum.
Gobuster aracına dir parametresini vererek dizin taraması yapacağımı belirtiyorum. -u parametresi ile üzerinde tarama yapılacak olan sitenin adresini, -w parametresi ile de tarama yaparken kullanılacak olan wordlist’i veriyorum. İşime yarayabilecek bilgiler içeren dosyaları da keşfedebilmek için -x parametresini kullanarak, verdiğim wordlistteki kelimelerin sonlarına verdiğim uzantıları ekleyerek tarama yapmasını sağlıyorum. Varsayılan olarak 10 olan tarama hızını -t parametresine 30 değerini vererek yükseltiyorum. Tarama sonucundaki çıktının bir dosyaya kaydedilmesi için -o parametresini kullanıyorum.
gobuster dir -u http://backdoor.htb -w common.txt -x php,txt,db,bak -t 30 -o backdoor.busterTarama devam ederken nmap yardımıyla ulaşmış olduğumuz, ‘Apache httpd 2.4.41’ versiyonu için zafiyet ve zafiyete ait exploit taraması yapıyorum. Searchsploit ve arama motorları aracılığıyla aramalar gerçekleştiriyorum fakat herhangi bir exploit ile karşılaşmıyorum. Bu sırada gobuster taraması sonuçlanıyor ve olağan WordPress dosyaları dışında dikkate değer bir dosya ile karşılaşmıyorum.
Sitede kullanılan WordPress‘in versiyonunun 5.8.1 olduğunu görüyorum ve bu versiyon için bilinen herhangi bir exploit var mı araştırması yapıyorum fakat herhangi bir exploit bulamıyorum. CMS‘ler üzerinde zafiyet taraması için kullanılan nuclei aracını kullanarak site üzerinde bir zafiyet taraması yapmaya karar veriyorum. Araca, -u parametresi ile hedef siteyi ve -o parametresi ile çıktıyı kaydedeceği dosya adını veriyorum.
Araç, site üzerinde CVE-2017-5487 ve CVE-2016-10924 zafiyetlerini buluyor.
CVE-2017-5487 zafiyetinin saldırganların site üzerindeki hassas bilgileri wp-json/wp/v2/users dizinine request atarak ele geçirebilecekleri bir zafiyet olduğunu öğreniyorum. Nuclei’nin de rest_route=/wp/v2/users ile ulaşabileceği bilgilere ulaşmaya çalışıp bize kullanıcı adının admin olduğuna dair bilgiyi getirdiğini görüyorum.
CVE-2016-10924 zafiyetinin ise WordPress’e yüklenmiş olan ebook-download eklentisinin sömürülmesiyle ortaya çıkan bir LFI -Local File Inclusion- ya da Path Traversal zafiyeti olduğunu görüyorum.
Bu zafiyeti kullanarak hedef makinedeki /etc/passwd dosyasına erişip hangi kullanıcıların olduğuna dair bilgi alıp kullanıcıların id_rsa dosyalarını ele geçirerek ssh bağlantısı elde etmeyi hedefliyorum.
curl http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../../../../etc/passwd
Makinede bulunan user kullanıcısının id_rsa dosyasına ulaşmaya çalışıyorum fakat böyle bir dosya olmadığından ya da bu dosyaya erişme yetkim olmadığından başaramıyorum.
curl http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../../../../home/user/.ssh/id_rsaDaha fazla bilgiye ulaşmak için wp-config.php dosyasını okuyorum. Buradan database kullanıcısının adına ve şifresine ulaşabiliyorum. Bu şifreyi user kullanıcısı için ssh şifresi olarak deniyorum fakat erişemiyorum.
curl http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php
Bu zafiyeti kullanarak nasıl shell alabileceğimi düşünürken zafiyetin aynı zamanda RFI -Remote File Inclusion- içerdiğini de keşfediyorum.
Bir süre uğraştıktan sonra zafiyetin eriştiğimiz dosyayı tarayıcı üzerinden görüntülememize izin vermeden direkt olarak indirmemizi sağlamasından mütevellit RFI to RCE gibi yöntemlerle shell alma çabalarımın boşuna olduğunu anlıyorum.
Gain Shell
Üzerinde hala ne çalıştığını bilmediğim port olan 1337 portunun ne olduğunu araştırmaya karar veriyorum. Arama motorları aracılığıyla 1337 portunda çalışabilecek servislere göz gezdiriyorum fakat tutarlı bir sonuç elde edemiyorum. Port üzerinde ne çalıştığını anlayabilmek için bulmuş olduğum LFI zafiyetini nasıl kullanabileceğime dair araştırma yapmaya başlıyorum. Uzun süren bir araştırma ve blog okuma sürecinin ardından LFI üzerine hazırlanmış bir blogda işime yarayabilecek bir şeyler buluyorum.
Burada makinede hangi process’lerin çalıştığını bulabileceğimiz /proc/sched_debug dosyasını öğreniyorum. Ayrıca her process’in başlatıldığı komutu kendi içerisinde, /proc/PID/cmdline dosyasında sakladığını öğreniyorum. sched_debug dosyası üzerinden ilginç process’lerin PID değerlerini bularak LFI zafiyetini kullanıp bunların ne olduğunu ve hangisinin 1337 portu üzerinde çalışıyor olabileceğini bulmayı deniyorum.
curl http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../../../../proc/sched_debug -o sched_debug
Bir kaç farklı servisi denedikten sonra aradığım servisin gdbserver olduğunu anlıyorum.
GdbServer için exploit araması yaptığımda 9.2 versiyonu için exploit olduğunu görüyorum. Fakat GdbServer’ın versiyonunu bilmediğimden önce keşfetmeye çalışyorum. GdbServer‘a nasıl bağlanacağımı araştırıyorum ve gdb ile bağlanabileceğimi öğreniyorum.
Bağlantıdan sonra bir süre GdbServer’ın versiyon bilgisine nasıl ulaşabileceğimi öğrenmeye çalışıyorum fakat bulamıyorum. HackTricks‘den bulduğum yöntem ile shell almayı denemeye karar veriyorum.
Shell’i daha stabil bir hale getirebilmek için kullanıcının dizininde .ssh dizinini yaratıp kendi oluşturuğum id_rsa dosyasına ait public key’i, kullanıcının authorized_keys dosyasına yazarak ssh ile erişim sağlıyorum.
Privilege Escalation
Yetki yükseltebilmek için öncelikle user kullanıcısının sudo yetkisini sudo -l komutuyla kontrol etmeyi deniyorum fakat şifreyi bilmediğim için sudo yetkisini göremiyorum. Kullanabileceğim bir SUID dosyası var mı kontrolünü yapıyorum. find komutuna ilk değer olarak / işaretini vererek aramayı kök dizinden itibaren yapmasını sağlıyorum. Yalnızca SUID dosyaları bulması için-perm parametresi ile -4000 değerini veriyorum. Komutun çalışması sırasında herhangi bir hata ile karşılaşırsa bu hatayı ekranana basmaması /dev/null dizinine yani hiçliğe göndermesi için 2>/dev/null değerini veriyorum.
find / -perm -4000 2>/dev/nullSUID dosyalarında da işime yarayacak herhangi bir dosya ile karşılaşamıyorum. Sistemde kullanabileceğim herhangi bir cron job olabilmesi ihtimaline karşı /etc/crontab dosyasını kontrol ediyorum fakat buradan da bir sonuç alamıyorum. Son olarak getcap -r 2>/dev/null komutu ile yetki yükseltmek için kullanabileceğim herhangi bir capability olup olmadığını kontrol ediyorum ve herhangi bir capability göremiyorum. /opt dizini gibi içerisinde kullanabileceğim scriptler olacabileceğini düşündüğüm bir kaç dizini daha kontrol ettikten ve bu dizinlerden de sonuç alamadıktan sonra, olası yetki yükseltme yollarını bulmaya çalışan ve bulgularını ekrana basan linPEAS scriptini kullanma kararı alıyorum. linPEAS‘in çıktısını incelerken process’ler içerisinde root kullanıcısı tarafından çalıştırılmış minik bir bash scripti dikkatimi çekiyor.
/bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root ;; done
Kod, durdurmaya zorlanana kadar her saniye /var/run/screen/S-root/ dizini içerisindeki her boş dosya ve boş dosya içeren dizinler için screen -dmS root komutunu çalıştırıyor. screen komutuna -dmS parametresini vererek root adındaki screen oturumunu daemon olarak detached modda başlatıyor. Açılmış olan bir screen oturumuna nasıl bağlanacağıma dair araştırma yapıyorum ve bir blog yazısında screen -x userName/sessionName komutuyla bağlanabileceğimi görüyorum ve denediğimde başarıya ulaşıyorum.
screen -x root/root