Scan / Enumeration
Makinede hangi portların erişilebilir olduğunu anlamak için bütün portları kontrol eden bir nmap taraması çalıştırıyorum.
nmap -T4 -vv -p- <IP>Buradan açık olarak gördüğüm portları daha ayrıntılı tarayarak hangi servislerin çalıştığını öğrenmeye çalışıyorum.
nmap -A -p <PORTS> -oN academy.nmap <IP>
Cihazda: 22 portunda SSH – Secure Shell –, 80 portunda HTTP, 33060 portunda ise mysqlx servisi çalışıyor. Web servisini incelemeye başlıyorum ve /etc/hosts dosyasına “academy.htb” domain’ini ekliyorum. Bir login sayfası ve bir register sayfası olduğunu, ayrıca register sayfasının kaynak kodunda bulunan <input type="hidden" value="0" name="roleid" /> satırını fark ediyorum. Alınan input’un adının roleid olmasından farklı rolleri temsil edebileceğini ve muhtemelen 0’ın normal kullanıcı 1’in ise admin olduğunu düşünüyorum. Kayıt olurken gönderdiğim request’i BurpSuite aracılığıyla yakalayıp inceliyorum ve “roleid” isimli bir parametreyi 0 değeriyle yolladığımızı görüp bunun değerini 1 olarak değiştiriyorum.
Kayıt olma işlemi gerçekleştikten sonra beni login.php sayfasına yönlendiriyor fakat burada roleid değerini 1 göndererek kayıt olduğum kullanıcı ile 0 göndererek kayıt olduğum kullanıcının aynı yere, egre55 hesabına geldiğini fark ediyorum. Admin kullanıcısı için farklı bir giriş paneli olacağını düşünerek admin.php sayfasına request atıyorum ve burada da bir login page olduğunu görüyorum. Admin yetkisiyle kayıt olduğum kullanıcıyla giriş yaptığımda Academy Launch Planner isimli bir sayfa ile karşılaşıyorum.
Buradan dev-staging-01.academy.htb isimli bir subdomain olduğunu öğreniyorum ve bunu da /etc/hosts dosyasına ekliyorum. Öncelikle bir mysql kullancı adı ve şifresi gözüme çarpıyor bunları denemek için mysql ile 33060 portuna bağlanmayı deniyorum fakat ERROR: mesajıyla karşılaşıyorum. Bunun üzerine mysqlx’i biraz araştırıp bağlanmak için mysqsl-shell gerektiğini öğreniyorum. Mysql-shell’i kullanarak bulduğum bilgiler ile bağlanmayı deniyorum fakat yine başaramıyorum.
Bunun üzerine daha fazla gitmek istemiyorum ve bulduğum subdomain’e gobuster taraması yapıyorum. İlginç olabilecek cgi-bin ve web.config dosyalarını buluyorum. APP_NAME olarak Laravel’i görebiliyorum fakat herhangi bir versiyon bilgisi bulamıyorum. Bulabileceğim bir exploit ile laravel’den içeriye girebileceğimi düşünerek exploit aramaya başlıyorum. Sonunda Laravel RCE için bir exploit bulabiliyorum.
Gain Shell
Bulduğum zafiyeti sömürebilmek için gerekli olan phpgcc‘yi de indirdekten sonra netcat reverse shell için payload oluşturup base64 ile şifreliyorum.
Bulduğum PoC’deki php dosyasını kullanarak, önceden eriştiğim subdomain’de yer alan APP_KEY ile oluşturduğum payload’ı birleştiriyorum.
Oluşturduğum payload’ı curl aracılığıyla subdomain’e POST request olarak, X-XSRF-TOKEN header’ı olarak gönderdiğimde makineden reverse shell alabiliyorum.
Privilege Escalation
Daha stabil bir shell ile bağlanabilmek için /home dizini altındaki kullanıcıların .ssh dizinlerini, id_rsa dosyası bulmak amacıyla kontrol ediyorum fakat bulamıyorum. Makinede çok fazla kullanıcı olması nedeniyle yatay yetki yükseltme işlemi gerçekleştireceğimizi düşünüyorum ve işimi kolaylaştırmak için makineye LinPeas‘i çekip tarama başlatıyorum.
Tarama sonucunda, okunabilir dosyalar içerisinde bulunan olası şifreler arasında bir kaç tanesi gözüme çarpıyor.
Bulduğum şifreleri bütün kullanıcılar için sırasıyla deniyorum ve cry0l1t3 kullanıcısına başarıyla giriş yapabiliyorum.
Daha kullanışlı bir shell’e sahip olmak için cry0l1t3 kullanıcısına ssh ile bağlanıyorum ve bash’e geçiyorum. Kullanıcının sudo ile çalıştırabileceği herhangi bir dosya bulunmamakta. Yine linpeas çalıştırıp output’unu inceliyorum fakat dikkate değer pek bir şey bulamıyorum. id komutunun çıktısında kullanıcının adm grubunda olduğunu görmüştük bu grubun ne olduğu hakkında biraz araştırma yaptıktan sonra /var/log dizininin altındaki logları okuyabilen bir grup olduğunu öğreniyorum.
Burada uzun bir süre logların çoğuna göz gezdirmeye çalışıyorum fakat kayda değer bir şey dikkatimi çekmiyor. Muhtemelen loglarda diğer 5 kullanıcıdan birine ait şifre olması gerektiğini düşünerek grep -hr <kullanıcıadı> 2>>/dev/null şeklinde bütün kullanıcıların isimlerini kontrol ediyorum. Yalnızca egre55 ve mrb3n kullanıcı adlarını
içeren dosyalar olduğunu görüyorum.
grep komutuyla okuma iznim olan dosyalardan hangilerinin mbr3n içerdiğini bulmaya çalışıyorum. audit dizininin içindeki audit.log.3 dosyasında, mbr3n ve /usr/bin/su birlikte geçtiği için burada işime yarayacak bir şeyler olabileceğini düşünüyorum. Uzun uzun dosyayı okuyorum ve sonunda dosyada data=xxxxxxxxxxxxx şeklinde xxxxx kısmı hex kodu olarak terminale girilen komutların bulunduğunu fark ediyorum. Birkaçına baktıntan sonra su komutunun karşısında hex halinde mrb3n kullanıcısına ait şifreyi buluyorum.
sudo -l komutuyla kullanıcının sudo yetkilerini kontrol ediyorum ve composer binary’sini sudo yetkisi ile çalıştırabileceğimizi görüyorum. GTFOBins‘in yardımıyla kullanıcıya verilmiş olan sudo yetkisini istismar ediyorum ve root kullanıcısına erişiyorum.
