Hack The Box – Keeper Write-Up | KeePass Memory Dump ile Root Erişimi

Bugün Hack The Box platformunda çözdüğüm Keeper makinesinden bahsetmek istiyorum. Keeper, Linux tabanlı ve Easy seviyesinde bir makine. Ancak çözüm sırasında karşılaştığım bazı detaylar, özellikle Linux privilege escalation konusunda bana farklı bir bakış açısı kazandırdı.

Genelde Linux makinelerinde root yetkisine yükselmek için ilk baktığım şeyler sudo izinleri, SUID dosyaları, cron görevleri ve yanlış yapılandırılmış servisler oluyor. Keeper'da da aynı şekilde başladım fakat çözüm tahmin ettiğimden biraz farklı ilerledi.

Bu makinede özellikle CVE-2023-32784 (KeePass Master Password Recovery) zafiyetini, bellek dökümlerinden parola kurtarmayı ve PuTTY SSH anahtarlarıyla root erişimini ele alacağım.

Öncelikle htb üzerinden verilen ip adresine rustscan ve nmap ile port taraması yaptım ve 22 ve 80 portlarının açık olduğunu gördüm .

80 üzerinde bulunan web sayfasında ulaştığımda başka bi adrese yönlendirdi

Bu adrese ulaşabilmek için nano /etc/hosts dosyasına vhost adresini eklememiz gerekiyor

bu şekilde web adresine ulaşabiliriz.

Keeper makinesinde web üzerinden erişilebilen bir Request Tracker (RT) uygulaması bulunuyor.

Uygulamaya şu adres üzerinden ulaştım:

http://tickets.keeper.htb/rt

Request Tracker, destek taleplerinin ve iş kayıtlarının yönetilmesi için kullanılan bir sistem.

Küçük bir google araması ile bu 4.4.4+dfsg-2ubuntu1 versiyon üzerinde default bir user password açık bırakılmış

İlk olarak varsayılan giriş bilgilerini denedim.

Username: root
Password: password

Giriş başarılı oldu.

Buradaki root hesabı, Linux sisteminin root kullanıcısı değil. Request Tracker uygulamasının yönetici hesabı. İkisi arasındaki farkı bilmek önemli.

Yönetim panelinde kullanıcı bilgilerini incelerken lnorgaard hesabına ulaştım.

Kullanıcının açıklama alanındaki bilgiler sayesinde SSH bağlantısında kullanılabilecek kimlik bilgilerini elde ettim.

Kali Linux terminalinden bağlantı kurdum:

ssh lnorgaard@keeper.htb

Parolayı girdikten sonra sisteme erişim sağladım.

Welcome to Ubuntu 22.04.3 LTS
GNU/Linux 5.15.0-78-generic x86_64

İlk olarak bulunduğum dizini ve içerideki dosyaları kontrol ettim.

whoami
pwd
ls -la

Ev dizininde iki dosya dikkatimi çekti:

RT30000.zip
user.txt

user.txt dosyasını okuyarak user flag'i aldım.

cat user.txt

Böylece makinenin ilk aşaması tamamlandı.

Ancak asıl mesele bundan sonra başlıyordu. Çünkü artık normal kullanıcıdan root kullanıcısına geçmem gerekiyordu.

Sisteme girdikten sonra hemen exploit çalıştırmak yerine öncelikle mevcut yetkilerimi incelemek istedim.

İlk denediğim komut:

sudo -l

Yani mevcut kullanıcının sudo üzerinden çalıştırabileceği herhangi bir komut yoktu.

Ardından SUID dosyalarını kontrol ettim.

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

Çıktıda passwd, mount, su, sudo gibi standart Linux dosyaları bulunuyordu.

Bunların SUID yetkisine sahip olması tek başına bir güvenlik açığı olduğu anlamına gelmiyor.

SGID dosyalarını da kontrol ettim.

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

Burada da doğrudan kullanabileceğim bir ipucu bulamadım.

Bir sonraki adımda sistemdeki capabilities izinlerini araştırdım.

getcap -r / 2>/dev/null

Sadece ping komutunun cap_net_raw yetkisine sahip olduğunu gördüm.

Root tarafından düzenli olarak çalıştırılan bir script olup olmadığını görmek için:

cat /etc/crontab
ls -lah /etc/cron*
systemctl list-timers --all

komutlarını kullandım.

Ancak bu kontrollerde de doğrudan yararlanabileceğim bir yanlış yapılandırma tespit edemedim.

Burada biraz yön değiştirmem gerektiğini fark ettim. Çünkü makine bana zaten ilginç bir dosya bırakmıştı: RT30000.zip.

Ev dizinindeki ZIP dosyasını daha detaylı incelemeye karar verdim.

Öncelikle Kali Linux'a aktardım:

scp lnorgaard@keeper.htb:/home/lnorgaard/RT30000.zip .

scp ile keeper makinesine bağlanıp zip dosyasını kendi kali makinemde çıkardım

unzip RT30000.zip

İçerisinden iki dosya çıktı:

passcodes.kdbx
KeePassDumpFull.dmp

İlk dosya oldukça küçüktü. İkinci dosya ise yaklaşık 242 MiB boyutundaydı.

Dosyaların uzantılarını araştırdığımda bunların KeePass ile ilişkili olduğunu gördüm.

passcodes.kdbx: KeePass tarafından kullanılan şifrelenmiş parola veritabanı.

KeePassDumpFull.dmp: KeePass uygulamasının bellek dökümü.

KeePass, parolaları şifreli bir veritabanında saklayan parola yöneticisi.

Normal şartlarda .kdbx dosyasını açabilmek için ana parolayı bilmek gerekiyor.

Fakat elimizde bir de uygulamanın bellek dökümü vardı.

Bu noktada araştırmam beni CVE-2023-32784 zafiyetine götürdü.

CVE-2023-32784, KeePass'in bazı eski sürümlerinde bulunan bir parola kurtarma zafiyeti.

Normalde bir parola yöneticisinin ana parolasının uygulama belleğinde kolayca elde edilememesi gerekir.

Ancak KeePass'in etkilenen sürümlerinde, parola giriş işlemi sırasında oluşan bazı bellek kalıntıları kullanılarak ana parolanın büyük bir bölümü kurtarılabiliyor.

Bu zafiyetin ilginç tarafı, her zaman parolanın tamamının doğrudan elde edilememesi.

Özellikle ilk karakter veya bazı özel karakterler eksik kalabiliyor.

Yine de yeterli karakter elde edildiğinde parolayı tahmin etmek mümkün olabiliyor.

Bu zafiyet için CVE-2023-32784 numarasını araştırabilirsiniz.

Bellek dökümünü analiz etmek için keepass_dump aracını kullandım.

Öncelikle GitHub üzerinden aracı indirdim.

git clone https://github.com/z-jxy/keepass_dump.git

Daha sonra şu komutu çalıştırdım:

python3 keepass_dump/keepass_dump.py \
  -f KeePassDumpFull.dmp

Bu komutta:

• python3 Python ile yazılmış aracı çalıştırıyor.

• keepass_dump/keepass_dump.py çalıştırdığım Python dosyası.

• -f analiz edilecek bellek dökümünü belirtmek için kullanılıyor.

• KeePassDumpFull.dmp ise incelemek istediğim bellek dosyası.

Yani araca aslında şunu söylüyoruz: Bu bellek dökümünü incele ve içerisinde KeePass ana parolasına ait kalıntılar olup olmadığını araştır.

Araç ilk olarak şu uyarıyı verdi:

[*] Searching for masterkey characters
[-] Couldn't find jump points in file.
Scanning with slower method.

İlk satırda araç, ana parolaya ait karakterleri aramaya başladığını belirtiyor.

İkinci satırdaki uyarı ise ilk bakışta bir hata gibi görünebilir. Ancak burada tarama tamamen başarısız olmuyor.

Araç normalde bellek dökümü içerisinde belirli işaretleri kullanarak ilgili alanlara daha hızlı ulaşmaya çalışıyor. Bu işaretleri bulamayınca dosyayı daha kapsamlı ve yavaş bir yöntemle taramaya devam ediyor.

Yani bu mesajı gördüğümüzde işlemin durduğunu düşünmemize gerek yok.

Tarama devam ettiğinde aşağıdaki sonuçları aldım:

En sonunda:

[*] Extracted: {UNKNOWN}dgrd med flde

sonucunu aldım.

İlk baktığımda çok anlamlı gelmedi. Bazı karakterler eksikti ve elde ettiğim ifade doğrudan kullanılabilecek bir parola gibi görünmüyordu.

Fakat karakterlerin konumlarını ve boşlukları inceleyince bunun bir kelime veya cümle olabileceğini düşündüm.

Araştırınca ifadenin Danimarkacada kullanılan bir tatlı adı olduğunu öğrendim.

Eksik karakterleri tamamladığımda parola şu hale geldi:

rødgrød med fløde

Burada dikkat edilmesi gereken nokta ø karakteri. Normal o harfiyle aynı değil.

Böylece KeePass veritabanının ana parolasını elde etmiş oldum.

Bu aşama benim için makinenin en ilginç kısmıydı. Çünkü bir parola kırma saldırısı yapmak yerine, uygulamanın belleğinde kalan verilerden yararlanmış olduk.

Ana parolayı bulduktan sonra sıra passcodes.kdbx dosyasını açmaya geldi.

Bunun için KeePassXC kullandım.

keepassxc passcodes.kdbx

Açılan ekrana bulduğum ana parolayı girdim.

Veritabanı başarılı şekilde açıldı.

Sol tarafta şu klasörler bulunuyordu:

Başlangıçta farklı kayıtları inceledim. Hatta Recycle Bin içerisinde bulunan örnek kayıtlardan birini de açtım.

Ancak aradığım şey sunucu erişim bilgileri olduğu için Network klasörüne yöneldim.

Burada:

keeper.htb (Ticketing Server)

isimli kaydı buldum.

Kaydın Notes bölümünde bir SSH private key bulunuyordu.

Anahtarın ilk satırı:

PuTTY-User-Key-File-3: ssh-rsa

Bu satırdan anahtarın PuTTY formatında olduğunu anlayabiliyoruz.

KeePass içerisindeki Notes alanında bulunan private key'i kopyaladım.

Kali Linux üzerinde bir dosya oluşturdum:

nano putty.ppk

Anahtarın tamamını dosyaya kaydettim.

Burada .ppk uzantısı önemli. Çünkü elimizdeki anahtar PuTTY formatında.

Linux üzerinde OpenSSH istemcisiyle kullanmak için anahtarı dönüştürmemiz gerekiyor.

Bunun için puttygen aracını kullanabiliriz ben bu şekilde indirmeyi tercih ediyorum 🤣

Ardından:

puttygen putty.ppk -O private-openssh -o root_key

Bu komut PuTTY formatındaki özel anahtarı OpenSSH formatına dönüştürüyor.

Daha sonra dosya izinlerini düzenliyoruz.

chmod 600 root_key

SSH özel anahtarlarının erişim izinlerinin kısıtlı olması gerekiyor. Aksi halde SSH istemcisi anahtarın kullanılmasını reddedebiliyor.

Son olarak root kullanıcısına bağlanmak için:

ssh -i root_key root@keeper.htb

komutunu kullanıyoruz.

Bağlantı başarılı olduğunda:

whoami
id

ile root yetkisini doğrulayabiliriz.

Ardından root flag'i okumak için:

cat /root/root.txt

komutunu kullanabiliriz.

Keeper'da beni en çok düşündüren şey, başlangıçta klasik privilege escalation yöntemlerine odaklanmam oldu.

Sudo izinlerini kontrol ettim, SUID ve SGID dosyalarını araştırdım, capabilities kontrolü yaptım, cron görevlerini inceledim.

Ancak hiçbirinde doğrudan bir sonuç alamadım.

Sonrasında kullanıcının ev dizininde bulunan ZIP dosyasına yönelince makinenin asıl çözüm yolunu keşfettim.

Keeper sayesinde özellikle şu konuları tekrar etmiş oldum:

• Linux sistemlerinde temel enumeration işlemleri

• Sudo, SUID, SGID ve Linux capabilities kontrolleri

• KeePass veritabanlarının çalışma mantığı

• CVE-2023-32784 ve bellek üzerinden parola kurtarma

• PuTTY ve OpenSSH private key formatları

• SSH anahtarlarıyla kimlik doğrulama

Bence bu makineden çıkarılabilecek en önemli ders, yetki yükseltmenin her zaman doğrudan bir exploit çalıştırmak anlamına gelmediği.

Bazen bir yapılandırma dosyası, unutulmuş bir yedek veya bellek dökümü bizi root erişimine götürebilecek en önemli ipucu olabiliyor.

Bir de şu var: Enumeration yaparken sadece araçların bulduğu sonuçlara odaklanmamak gerekiyor. Sistemde karşımıza çıkan dosyaların neden orada olduğunu da sorgulamalıyız.