TryHackMe Madness Write Up

Bu rapor, TryHackMe içerisinde bulunan Madness için hazırlanmış bir write-up’tır.

author image

Written by

Furkan İbiş

Published on

Sep 7

https://furkanibis.dev
TryHackMe Madness Write Up

Madness

Esenlikler, bugünkü yazımda sizlere TryHackMe üzerinde bulunan Madness makinesinin çözümüyle alakalı raporumu sunacağım. Şimdiden keyifli okumalar dilerim.

Information Gathering

Hedef sistem ile alakalı TryHackMe tarafından bize ilk olarak hedef sistemin IP adresi veriliyor ve aynı ağda olduğumuz belirtiliyor.

Service Enumeration

Service Enumeration, hedef sistem üzerinde çalışan servisleri tespit etme ve bu servisler hakkında ayrıntılı bilgi edinme aşamasıdır. Bu aşamada temel amaç:

  • Hangi servislerin aktif olduğunu,
  • Bu servislerin hangi portlarda çalıştığını,
  • Kullanılan yazılım ve sürüm bilgilerini,
  • Varsayılan veya yanlış yapılandırılmış ayarların var olup olmadığını öğrenmektir.

Bu bilgiler, daha sonraki aşamalarda hangi zafiyetlerin kullanılabileceğini anlamak için kritik önem taşır. Örneğin, güncel olmayan bir FTP servisi veya hatalı yapılandırılmış bir web sunucusu, saldırgan için potansiyel bir giriş noktası olabilir.

Bu noktada hedef sistem üzerinde service enumeration aşamasına başlıyorum. Bunun için Nmap aracını kullanacağım. Kısaca, bir SYN taraması gerçekleştirerek hedef sistemdeki açık portları ve bu portlarda çalışan servislerin versiyon bilgilerini elde etmeyi amaçlıyorum.

nmap 10.10.1.120 -sS -sV -p 1-1000

Hedef sistemin versiyon bilgileri incelendiğinde, 22 numaralı portta OpenSSH 7.2p2, 80 numaralı portta ise Apache 2.4.18 servislerinin çalıştığı tespit ettik.

Hedef sistemin 80 numaralı portta sunduğu web sitesine baktığımda dikkatimi çeken şey bir adet resim oldu. Resim bozuk göründüğü için görüntülenemiyordu. Kaynak kodlarına baktığımda ise aşağıdaki bilgiyi gördüm:

Apache servisinin etkilendiği zafiyetleri internette arattığımda, doğrudan Apache’nin CVE-2019-10082.

Daha ayrıntılı bir araştırma yaptığımda ise yalnızca bu CVE’nin değil, çok daha fazla zafiyetin bulunduğu Apache HTTP Server Security Vulnerabilities.

Bu zafiyetlere tek tek bakarken hedef sistem ile alakalı çeşitli taramalar yapmaya devam edeceğim. Bu noktada, subpage taraması için bize dirb aracı yardımcı olacak. Bir yandan bu işlem devam ederken, bir yandan da internetteki zafiyetleri incelemeyi sürdüreceğim.

dirb http://10.10.1.120

Resmin İncelenmesi

Ancak dirb taramasından herhangi bir sonuç elde edemedim. Bu sebeple, bir yandan hedef sistemin Apache versiyonunu incelerken bir yandan da bulduğum bu resmi kendi sistemime indirip incelemeye karar verdim.

Şimdi sorun şu: Dosya kısaca .jpg formatında görünüyor, ancak aslında .png formatında. Burada doğrudan aklıma dosyanın içinde bir şeylerin gizlendiği geliyor. Bu sebeple dosyayı düzeltmek istiyorum. Bunun için internette “PNG image did not start with IHDR” araması yapıyorum.

Ayrıca, resmi düzeltmeden önce içerisinde gizlenmiş bir şey olup olmadığını kontrol ettiğimde doğrudan dikkatimi çeken bir şey olmadı.

binwalk thm.jpg

Ya da

strings thm.jpg

Steghide ile deneme yapmaya çalışsak bile elimizde bir passphrase olmadığı için o işlemi şimdilik geçiyorum.

İnternetten resmi nasıl düzeltebileceğimi araştırırken şu bilgiye ulaştım: https://edu.anarcho-copy.org/other/Regex/hex_file_and_regex_cheat_sheet.pdf

Burada gördüğümüz bilgilere göre resim başlığını düzenlediğimde, aşağıda görebildiğin resim ortaya çıkıyor.

Burada hidden directory'i görebiliyoruz.

Hidden Directory

Hedef path’e gittiğimde aşağıdaki gibi bir sistem beni karşıladı. Burada aslında minik bir oyun vardı.

Bizden kısaca doğru secret element’i bulmamız isteniyor. Bunu manuel olarak da yapabilirim, ancak manuel işlem yapmak yerine bir kod aracılığıyla bu işlemleri hızlıca gerçekleştirmek istiyorum.

import request
from tqdm import tqdm

URL = f"http://10.10.1.120/{secret_path}?secret="
for secret in tqdm(range(1,101), desc="DENEM [*]"):
	response = request.get(f"{URL}{SECRET}")
	if "That is wrong!" in response.text:
		pass
	else:
		print(response.text)

Burada yanıtı zaten doğrudan görebiliyoruz. Bulduğumuz secret ile siteye deneme yaptığımızda (zaten Python kodunun verdiği sonucu görmüştük ama maksat şov), hedef sistem bize şu şekilde yanıt veriyor:

“Urgh, you got it right! But I won’t tell you who I am! bir key”

Burada bir şifre verdi ama sırf resmin üstüne çizgi çekmemek için bu şekilde yazdım. Resimde de öğeyi denetle üzerinden şifreyi değiştirdim. :)

Exploit

Şimdi elimizde bir resim ve bir şifre var. Ne olabileceğini düşünmeden, yukarıda steghide ile passphrase’ini bilmediğim için es geçtiğim aşamaya geri dönüyorum.

Username’i aldık, ancak parola için ne yapacağız? Burada dürüst olmak gerekirse TryHackMe üzerindeki en saçma işlemle karşı karşıya kaldım. Uzunca süre ne yapabileceğime baktım ama bir sonuç bulamayınca write-up’ları kontrol ettim. O noktada, room içerisinde gösterilen görselde şifrenin steghide ile saklandığını gördüm.

Resmi indirip açmaya çalıştığımızda ise, parolasız bir şekilde bize password.txt dosyasını veriyor, neyse ki.

SSH ile oturum açmaya çalıştığımda yine başarılı olamadım. Sebebini düşündüğümde ise kullanıcı adının hashlenmiş olduğunu fark ettim. Bu tarz durumlarda her zaman yaptığım gibi şifreyi alıp doğrudan Google’da arattığımda, ROT-13 ile şifrelendiğini gördüm.

Doğrudan internetten decode edebiliyoruz. Bu sayede gerçek kullanıcı adına ulaşıyor ve hedefe bir SSH oturumu açabiliyoruz.

Bu sayede ilk görevimiz olan user.txt dosyasını görüntüleyebiliyoruz.

Privilege Escalation

Bir kullanıcı ile oturum açtığımda kısaca şu işlemleri yaparım:

  1. Kullanıcının sudo ile çalıştırabileceği komutları kontrol etmek.
  2. Sistemde kayıtlı olan kullanıcıları kontrol etmek.
  3. Home dizininde bulunan dosyaları incelemek.
  4. SSH bilgilerini kontrol etmek.
  5. Crontab bilgilerini kontrol etmek.
  6. SUID bit set edilmiş dosyaları kontrol etmek.

Maalesef kullanıcı, sudo yetkisiyle herhangi bir işlem yapamıyor.

Sistemde joker kullanıcısı haricinde başka bir kullanıcı bulunmuyor.

Joker kullanıcısının home dizininde yine bir şeylere rastlamıyorum. Ne .bashrc ne de .bash_history dosyalarında, ayrıca SSH ile ilgili işime yarayabilecek dosyalarda da kayda değer bir şey çıkmıyor.

Ayrıca crontab’dan da bir şey çıkmıyor.

Ancak son aşamada SUID için aşağıdaki komutu girdiğimde verilen çıktıları araştırırken bir şeyler dikkatimi çekiyor

find / -perm -4000 -type f 2>/dev/null

Burada her şeye teker teker bakıyorum, ancak screen programı haricinde şu durumlar normal:

  • /usr/bin/passwd, /usr/bin/chsh, /usr/bin/sudo, /bin/su: Linux’ta şifre değişimi ve kullanıcı işlemleri için kullanım amaçlı, bu nedenle normal.

  • /bin/ping, /bin/mount, /bin/umount, /bin/fusermount: Ağ ve disk işlemleri için SUID bit verilmiş.

  • /usr/lib/openssh/ssh-keysign, /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Sistem yardımcı uygulamaları.

Ancak screen-4.5.0 ile ilgili yaptığım kısa bir Google araması sonucu bazı önemli bir şeylere rastladım.

Neden Önemli?

GNU Screen 4.5.0, CVE-2017-5618 ile yerel privilege escalation’a izin veren bir zafiyet içeriyor. Bu zafiyete göre, program log dosyası oluştururken uygun izin kontrolü yapmıyor; eğer log dosyası mevcut değilse root imkânlarına sahip şekilde dosyayı yaratabiliyor. (CVE Details, NVD)

Bu açık, ld.so.preload dosyasına rastgele kütüphane tanımlarının eklenmesine ve böylece root ayrıcalıklarıyla kod çalıştırılmasına yol açabiliyor. (Medium, Exploit Database)

GTFOBins veritabanında da belirtildiği gibi, screen komutu doğrudan bir shell açmak veya log dosyası oluşturmak için kullanılabiliyor. (gtfobins.github.io)

Root Olmak

scp ile hedef sisteme https://github.com/YasserREED/screen-v4.5.0-priv-escalate adresindeki full-exploit.sh'ı gönderip hedef sistemde çalıştığımda root oturumu elde edebiliyorum. Tabii önemli olan bu screen neden privilege escalation yiyor bilmek gerekiyor

Teşekkürler

Buraya kadar okuduysanız gerçekten teşekkür ederim. Bir sonraki yazımda görüşmek üzere, kendinize iyi bakın. Esenlikler!