GTFOBins

• Unix ikili dosyalarının listesi işlevlerine göre düzenlenmiş ve her ikili için mümkün olan eylemler ayrıntı sayfalarına ve anchor bağlantılarına doğrudan bağlanmış
• Tekrarlayan sınıflandırmalar Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load, Privilege escalation olup bazı maddelerde bunlara Bind shell de ekleniyor
• File read ve Shell çok geniş bir alana yayılıyor; dd, sed ve sqlite3 gibi araçlar okuma ve yazmayı birlikte sunduğu için yalnızca görüntüleme odaklı araçlarla aralarındaki sınır bulanıklaşıyor
• apt, git, journalctl, systemctl gibi araçlar sık sık Command ve Inherit içeriyor; bee, pipx, sqlmap ve vim ailesi gibi ağ aktarımı ve kabuk davranışını birlikte taşıyan çok işlevli ikililer de tekrar tekrar öne çıkıyor
• Privilege escalation yalnızca ayrı bağlantı verilen bazı ikililerde görülüyor; 7z'den zypper'a uzanan geniş liste, genel araçların davranış kombinasyonlarındaki farkları tek bakışta gösteriyor

---

Temel işlev dağılımı

• Yalnızca dosya okuma yapan ya da ağırlıklı olarak okuma odaklı maddeler çok geniş bir alana yayılıyor
  • 7z, cat, grep, jq, od, tail, wc, zcat gibi araçlar File read ekseninde bağlanıyor
• Kabuk çalıştırma yapabilen maddeler de oldukça fazla
  • bash, awk, find, less, python, ruby, tar, vi, zsh gibi araçlarda Shell bulunuyor
• Dosya yazma ile okumayı birlikte sunan çok sayıda madde var; bu da yalnızca görüntüleme odaklı araçlarla aradaki sınırı bulanıklaştırıyor
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd bu gruba giriyor
• Komut çalıştırma ya da yetki devralma paket yöneticilerinde, sistem araçlarında ve etkileşimli programlarda sık görülüyor
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless bunun öne çıkan örnekleri

Çok işlevli ikililer

• Birden fazla eylemi aynı anda barındıran çok işlevli ikililer tekrar tekrar karşımıza çıkıyor

• Inherit tabanlı çok işlevli maddeler

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve için Inherit ile birlikte Shell, Command, File read ve File write bir arada sunuluyor

• Ağı ve dosya aktarımını da kapsayan maddeler

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility Reverse shell, Upload, Download ve Library load özelliklerini de birlikte taşıyor

• Editör ve hata ayıklayıcı ailesi

  • gdb, nvim, rvim, view, vim, vimdiff için Inherit ile birlikte Shell, Reverse shell, Bind shell ya da File read/write, Upload, Download, Library load bir araya getirilmiş

• Paket yöneticisi ve runtime ailesi

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum için kabuk, dosya erişimi ve ağ davranışları sık sık birlikte görülüyor

Ağ, kabuk ve kütüphane yükleme

• Upload/Download işlevleri yalnızca ağ araçlarında değil, kabuklarda ve dil runtime'larında da birlikte bulunuyor

• Aktarım odaklı araçlar

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois Upload ya da Download yeteneklerine sahip

• Reverse shell ve Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh bu gruba dahil

• Library load etiketli maddeler

  • bash, byebug, curl, ffmpeg, gdb, gem, gimp, irb, knife, ldconfig, mysql, nginx, nvim, openssl, pip, python, rake, ruby, ssh-keygen, tclsh, vim, volatility, wish, yum buna dahil

Yetki yükseltme maddeleri

• Privilege escalation yalnızca ayrı bir madde olarak işaretlenen ikililerde görülüyor

• Yetki yükseltme bağlantı listesi

  • chattr
  • chmod
  • chown
  • cp
  • getent
  • install
  • ln
  • mount
  • mv
  • passwd
  • setcap
  • setfacl
  • unsquashfs
  • unzip

[GN⁺]

Hacker News yorumları

• Yorumlarda biraz kafa karışıklığı var gibi, bunun güvenlik/CTF bağlamında ne zaman kullanıldığına örnek vermek gerekirse şöyle
  Kısıtlı shell’lerde ya da yalnızca bazı komutların/binary’lerin çalıştırılabildiği ortamlarda, argümanlar genelde oldukça serbest verilebiliyor
  O noktada GTFOBins kullanarak dosya okuma/yazmadan komut çalıştırmaya kadar ilerleyip kısıtlı bağlamdan çıkıp bir shell elde etmek mümkün olabiliyor
  Birisi sudo erişimi bırakmışsa ya da bir GTFOBin’e SUID bit vermişse, bunu ayarlayan kişinin hiç düşünmediği yollarla hassas dosyaları okuyup yazmak ve yetkili komutlar çalıştırmak da mümkün olabilir

  • Bu durum claude-code gibi araçlar için de oldukça geçerli
    Yetki işleme mantığı block-list ve allow-list merkezli olduğu için epey ilkel kalıyor
    Bir oturumda yanlışlıkla Claude’a powershell izni vermiştim; sonrasında git gibi araçlar engellendiğinde, aynı işi yapan powershell script’leri yazıp çalıştırarak engellenen izinleri baypas ettiğini gördüm
    Düzgün kurulmuş bir sistemde powershell’i genel allow-list’e koymazsınız tabii, ama araç bazlı izin seviyeleri arasında boşluklar varsa bu sayfadaki tekniklerle rahatça dolaşılabilecek gibi görünüyor
  • Yetki yükseltme aracılığı yaptığını söyleyen bazı kurumsal güvenlik yazılımları da benzer şekilde riskli olabilir
    Bir şirkette gördüğüm dağıtım modelinde, yöneticinin allowlist’e eklediği programlar parola olmadan sudo ile çalıştırılabiliyordu ve en baştan vim, bash gibi genel amaçlı araçlar da listede vardı
    Evden çalışan biri olarak bunu aslında biraz iyi bir şey gibi görmüştüm; çünkü bilgisayarımı "koruduğunu" söyleyen bu yazılım, ben kısa süreliğine kalkıp ekranı kilitlemeyi unuttuğumda, birinin gelip bir şeyler çalıştırmasını çok daha kolay hale getiriyordu
  • Bu sonuçta restricted shell’in pratikte ne kadar kolay aşılabildiğini gösteren epey kapsamlı bir rehber gibi duruyor
  • Somut bir örnek de var
    Birkaç yıl önce destek ekibinin tcpdump ile ağ yakalaması alması gerekiyordu; işi hızlandırmak için argümanları bir ölçüde açık bırakan bir sudo kuralı eklenmişti
    Port ya da NIC değişebilir diye o an mantıklı görünmüştü, ama aslında tcpdump içindeki -z seçeneğiyle sıkıştırma komutu belirtilebildiği için, oraya "özel" bir komut koyarsanız sunucuyu tamamen ele geçirebiliyordunuz
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    Küçük bir ayrıntı gibi görünse de bunları gözden kaçırmak gerçekten çok kolay
    Bugünlerde apparmor gibi katmanlar bu riski azaltabiliyor, ama bununla birlikte başka dertler de getiriyor ve hâlâ yanlış yapılandırılması çok kolay
  • Buna bakınca, sanki yapay zekanın sandbox kaçış yöntemlerini öğrenmesi için düzenlenmiş bir liste gibi geliyor

• Buna benzer bir şeyi en son 1995 civarında, Windows 3.11 yüklü bir ortaokul bilgisayarında kullanmıştım
  Sadece onaylı birkaç uygulamanın çalışmasına izin verecek şekilde kilitlemişlerdi ve onlardan biri Word’dü
  Word içinde makro kullanıp shell üzerinden başka uygulamalar çalıştırabiliyordunuz
  Böylece yalnızca birkaç uygulamanın göründüğü kilitli bilgisayar, fiilen her şeyi çalıştırabilir hale gelmişti
  O zamanlar oldukça heyecan vericiydi; sonrasında buna benzer şeyleri pek görmedim
  Ara sıra mağaza ya da AVM’lerdeki dokunmatik bilgi ekranlarında kiosk mode’dan çıkılabildiğine dair şeyler görüyorum; o da aynı türden sanırım

• restic - Shell, Command, Upload kısmını görünce, yedekleri root olarak çalıştırmamak için yaptığım değişiklik biraz daha haklı geldi
  Onun yerine normal kullanıcı olarak çalıştırıyorum ama sadece read-all-files capability verip giriş shell’ini kaldırdım
  Elbette masaüstü sistemlerde bu fazla kaçabilir; ayrıca o noktaya kadar sızmış bir saldırgan zaten neredeyse tüm dosyaları okuyabilir ve yedeklere arka kapı da ekleyebilir
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • Kısıtlamaları görünce, "o zaman baypas için yardımcı bir araç kullanıp dolaşırım" diye düşünen LLM eğilimi, eski dünyanın varsayımlarını epey sarsıyor gibi geliyor
    Uzak insan saldırganlara, uzak bot saldırganlara ve bir ölçüde yerel insan saldırganlara karşı önlemlerimiz vardı; ama yerelde kendi kodunu yazabilen bot saldırgan, artık eskisinden çok daha fazla hesaba katılması gereken bir tehdit haline geldi
    Bu, kötü amaçlı yazılımla da tamamen aynı kategori değil
    Ben de kapsayıcıyı ilgili güvenlik sınırı olarak görüp iç süreçleri tamamen root olarak çalıştırdığım oldu; ama LLM işin içine girince OS düzeyi güvenliğin bir anda daha mı önemli hale geldiği, yoksa tam tersine daha mı anlamsızlaştığı konusunda emin olamıyorum

• Kafam karıştı; bu, cat yoksa cat /path/to/input-file yerine base64 /path/to/input-file | base64 --decode kullanın mı demek
  Yoksa base64 /path/to/input-file | base64 --decode ifadesi, dosya okuma izninin kendisini mi baypas ediyor

  • İlki doğru
    Çağrılan süreç, genelde onu başlatan kullanıcının izinlerini aynen devralır; sadece setuid bit varsa istisna oluşur
    Mesele, standart Unix araçlarını kapatarak saldırganın lateral movement yapmasını engellemeye çalışan ortamlarda, aynı işi başka araçlarla da yapabilmesidir
  • Yani kara liste tabanlı komut kısıtlamalarıyla yetki engelleme yaklaşımı baştan beri pek işe yaramıyordu, hâlâ da yaramıyor
  • İkincisi değil, birincisi
    Yetkilerin kendisini aşmak değil; yalnızca birkaç komuta izin verilen kısıtlı shell içinde, aynı sonucu başka bir binary ile üretmekten bahsediliyor
    Bu tarz şeyler CTF’lerde gerçekten çok yaygın
  • Ama okunamayan bir dosya varsa ve buna karşılık root olarak base64 çalıştırmak mümkünse durum değişir
    base64’ü root yetkisiyle çalıştırıp dosya içeriğini base64’e kodlarsınız, sonra o çıktıyı başka bir base64 süreciyle çözüp sonuçta dosya içeriğini görürsünüz
    Sonuçta bu, sadece birkaç adım eklenmiş bir cat olur
  • O durumda tar pipe daha hafif olmaz mı diye de düşünülebilir

• Zamanında bu araçlardan birinin bakımını yapıyordum; biri onunla shell elde edince oldukça komiğime gitmişti
  Yaratıcı ve eğlenceli, ayrıca kaynak olarak da çok iyi

• hackthebox.eu oynarken bunu çok fazla kullandım

• GTFOBins epey eski; yapay zekadan önce de faydalı bir kaynaktı

  • Zaten bu yüzden gelecek daha da kaygı verici
    Yapay zekayı faydalı kılan şeyin kendisi, sonuçta zaten var olan bu tür kaynakları önümüze getirebilmesi

• base64’ün listede olmasını tam anlayamıyorum
  Bana göre o, ancak kullanıcının zaten erişebildiği dosyaları okuyabilir; yanlış mı düşünüyorum
  Yoksa yanlış yapılandırılmış bir sistemde yerel güvenlik kısıtlarını aşma ifadesi, benim anladığımdan farklı bir şey mi demek

  • Esas nokta, yanlış yapılandırılmış kısıtlı shell’ler ya da yalnızca belirli komut erişimi verilen durumlarda, o listedeki araçlarla kullanıcının normalde kısıtsız ortamda sahip olduğu erişimin bir kısmını geri kazanabilmesidir
    En basit örnekle, varsayılan shell’i rbash yapmış olsanız bile kullanıcı yalnızca bash çalıştırıp normal shell’e geçebiliyorsa bunun anlamı kalmaz
  • Örneğin sudoers, base64’ün root olarak çalıştırılmasına izin veriyor olabilir
    Neden böyle bir şey yapılır bilmiyorum, ama böyle bir durumda amaçlanan yetki sınırlarını aşıp sistemdeki herhangi bir dosyayı okumak mümkün hale gelir
    Ya da Claude Code içinde base64 çalıştırmaya inceleme olmadan izin verirseniz, .env gibi gizli dosyaların okunmasına da kapı açmış olabilirsiniz
  • Yaygın senaryo, bazı araçların root yetkisiyle çalıştırılabiliyor olmasıdır
    Bu bazen sudo -l içinde açıkça izinli olur, bazen de başka bir şey o aracı root olarak çağırır

• Bu tür baypaslar için hafifletme yöntemlerinin de gösterilmesi iyi olurdu
  Mesela more ile shell elde etme durumunda
  more çalıştırılmadan önce SHELL değişkenini /bin/false yapmak
  secure mode ile less kullanmak
  sudo ile more çalıştırılıyorsa NOEXEC flag kullanmak gibi

  • En iyi hafifletme, kullanıcıların okuyup yazmaması gereken dosyalar için gerçek dosya izinlerini düzgün ayarlamaktır
    Bunun dışındaki yöntemlerin hepsi bir ölçüde şansa kalıyor

• Oldukça havalı ve beklenmedik derecede yaratıcı yöntemler var
  Mesela yt-dlp hiç aklıma gelmezdi
  Onu yüklü tutmayı tekrar düşünmem gerekecek