Linux: SUID ve sudo kuralları

Laboratuvar makinesine düşük yetkili bir kullanıcıyla girdin. Okuyabildiğin dosyalar sınırlı, servisleri yönetemezsin. İlk erişim neredeyse her zaman böyle dar gelir. Asıl iş, bu sınırı aşan bir yanlış yapılandırma bulup yetkini yükseltmektir.

Yükseltme tek bir sihirli komut değildir. Sistemi sabırla tanıman, sonra birbirinden habersiz iki küçük ayrıntının birleştiği yeri görmen gerekir. Bu derste o birleşmelerin Linux'taki en sık biçimlerini tek tek çözeceksin.

Bu aşama bir sızma testinin gerçek değerini belirler. Bir web uygulaması üzerinden alınan düşük yetkili kabuk tek başına çoğu zaman değersizdir. Değer, o kabuktan sistemin tamamını yöneten yetkiye geçebildiğinde ortaya çıkar. Bir lojistik firmasının sunucusunda sınırlı bir servis hesabı düşün.

Tek başına yalnız birkaç günlük dosyası okur. Ama yanlış yazılmış bir sudo kuralıyla birleşince bütün makinenin kapısını açar. Yükseltme, işte bu birleşmeyi görmektir. Bu dersin konusu da Linux'ta bu birleşmenin en sık çıktığı yerlerdir.

Yükseltme aramak bir kesişim bulmaktır. Bir yanda sistemin root yetkisiyle çalıştırdığı şeyler durur: SUID dosyaları, zamanlanmış görevler, servisler. Öte yanda senin dokunabildiğin şeyler durur: yazabildiğin dizinler, düzenleyebildiğin dosyalar, çağırabildiğin komutlar. Bu iki kümenin kesiştiği her nokta bir yükseltme adayıdır.

Acele etmemek en iyi taktiktir. İlk on dakikayı sistemi tanımaya ayırırsan sonraki denemelerin hedefli olur. Rastgele sömürü denemek hem gürültü üretir hem makineyi bozar. Tek tek bakınca sıradan görünen iki ayrıntı, sabırla birleştirilince root'a giden yolu açar.

İlk bakılan yer SUID bitidir. Bu bit açık bir dosya, çalıştıran kim olursa olsun sahibinin yetkisiyle koşar. Bazı dosyalarda bu normaldir. passwd komutu parolanı değiştirirken korumalı parola dosyasına yazmak zorundadır, bu yüzden root sahipli ve SUID çalışır.

Sorun, kabuk çağırabilen bir ikilide bu bit açıksa doğar. find, vim ya da nmap kendi içinden komut çalıştırabilir. SUID ile birleşince o komut root olarak koşar ve sınırlı kullanıcıyı root'a taşır.

İzin bitleri normalde üç hanede yazılır. Özel bitler için başa dördüncü bir hane eklenir. 4000 değeri SUID bitini, 2000 değeri SGID bitini, 1000 değeri yapışkan biti gösterir.

Bir dosyanın yetki satırında sahip bölümünde x yerine s harfini görürsen, o dosyada SUID açıktır. Avı buradan başlatırsın. Önce makinedeki bütün SUID dosyalarını listeler, sonra bu listeyi beklenen ve beklenmeyen diye ikiye ayırırsın.

$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/mount
/usr/bin/find        <-- ilgi çekici

Komutu parça parça oku. -perm -4000 ifadesi yalnız SUID biti açık dosyaları seçer. Baştaki eksi işareti bu bitin açık olmasını şart koşar ve öbür bitlere karışmaz. -type f seçeneği sonucu sıradan dosyalarla sınırlar, dizinleri eler.

Sondaki 2>/dev/null, okuma iznin olmayan dizinlerden gelen hata satırlarını atar ve listeyi okunur tutar. Çıktıdaki passwd, sudo ve mount beklenen satırlardır. find satırı ise kendi içinden komut çağırabildiği için ilgi çeker ve ilk denenecek adaydır.

Numaralandırmayı disiplinle yaparsın. Önce hızlı ve güvenli kontroller gelir: SUID listesi, sudo kuralları, dosya yetenekleri ve yazılabilir dizinler. Bunların hepsi dakikalar sürer ve makineyi riske atmaz.

Topladığın her ayrıntıyı bir yere not alırsın; kullanıcıları, grup üyeliklerini, çalışan servisleri, zamanlanmış görevleri ve ağdaki açık portları. Bu notlar sonradan kesişimi görmeni kolaylaştırır. Yükseltme çoğu zaman tek bir satırda değil, iki ayrı notun yan yana gelmesinde saklıdır. Acele eden analist bu kesişimi kaçırır ve rastgele sömürü denemeye başlar.

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

İkinci bakılan yer sudo kurallarıdır. sudo -l komutu, geçerli kullanıcının hangi komutu hangi yetkiyle çalıştırabileceğini listeler. Kurallar çoğu zaman tek bir bakım ihtiyacı için yazılır, sonra unutulur.

Bir yönetici, servis yeniden başlatmayı kolaylaştırmak ister ve geniş bir kural bırakır. Aradan aylar geçer, kural durur ve saldırgana kapı olur. Önce bu listeyi okur, sonra listedeki her ikilinin kabuk çağırıp çağıramadığını sorarsın.

$ sudo -l
User ogrenci may run the following commands:
    (root) NOPASSWD: /usr/bin/find

Çıktı iki şey söyler. Parantez içindeki root, komutun hangi kullanıcı olarak koşacağını belirtir. NOPASSWD etiketi ise parola sorulmayacağını gösterir. Burada find ikilisi root olarak ve parolasız açılmış.

find bir dosya ararken kendi içinden komut çalıştırabildiği için bu kural tek bir araçla sınırlı kalmaz. Doğrudan bir root kabuğuna açılır. Aynı mantık tar, awk ve git gibi kabuk çağırabilen her araç için geçerlidir.

sudo kurallarında daha ince tuzaklar da vardır. Bir kural komutun sonuna yıldız koyduysa, dilediğin argümanı ekleyebilirsin. Bir başka hata, bazı ortam değişkenlerini koruyan bir yapılandırmadır; bu durumda kendi hazırladığın paylaşımlı kütüphaneyi yükletebilirsin.

sudo sürümünün kendisi de önemlidir, çünkü eski sürümlerde bilinen açıklar bulunur. Kuralı okurken yalnız komutun adına değil, argümanlara, korunan değişkenlere ve sürüme de bakarsın. Her ayrıntı ayrı bir kapı olabilir.

Kural yazarken sık yapılan hata, tek bir görev için tam yetkili bir araç vermektir. Bir metin düzenleyici root olarak açıldığında, düzenleyicinin içinden kabuk çağrılır.

Kural bir dosyayı hedeflese bile sonuç sınırsız erişimdir. Kuralın hedefi dar görünür, ama aracın yeteneği geniştir. Bu yüzden bir sudo kuralını okurken komutun adına değil, o komutun neler yapabildiğine bakarsın. Bir aracın adı masum görünse bile, yeteneği tehlikeli olabilir.

Bir ikilinin yükseltmeye dönüp dönmediğini ezbere bilmen gerekmez. GTFOBins, Unix ikililerinin bilinen kaçış yollarını derleyen ortak bir başvuru listesidir. Bir aracı sudo, SUID ya da yetenek bağlamında arar, karşılığında o aracın hangi komutla kabuk açtığını okursun.

Bulguyu raporlarken bu kaynağa atıf vermek, düzeltmeyi yapan ekibin işini hızlandırır. find ikilisi SUID ise liste sana doğrudan çalışan tek satırlık bir kaçış verir.

$ ls -l /usr/bin/find
-rwsr-xr-x 1 root root 224848 Mar  4  2026 /usr/bin/find
$ /usr/bin/find . -exec /bin/sh -p \; -quit
# id
uid=1001(ogrenci) gid=1001(ogrenci) euid=0(root) groups=1001(ogrenci)

Çıktıyı oku. İlk satırdaki rws, dosyada SUID bitinin açık olduğunu gösterir. find bir dosya ararken -exec ile her eşleşmede bir komut koşturur; burada o komut /bin/sh kabuğudur. Sondaki -p bayrağı önemlidir.

bash ve dash, etkin kullanıcı kimliği gerçek kimlikten farklıysa ayrıcalığı kendiliğinden düşürür. -p bu düşmeyi engeller ve kabuk root olarak açık kalır. id çıktısındaki euid=0 tek kanıttır. Etkin kullanıcı kimliğin sıfır, yani root olmuştur.

Gerçek hayatta bu doğrulama adımı raporun kalitesini belirler. Bir kurumun denetiminde find ikilisinde SUID bulduğunu yazmak tek başına yeterli değildir. Bulgunun yanına hangi komutun root kabuğu açtığını, kanıt olarak euid=0 çıktısını ve kaynak olarak GTFOBins girişini koyarsın. Böylece düzeltmeyi yapan ekip tartışmaya girmeden sorunu kabul eder ve kapatır.

İyi bir bulgu, yalnız okuyanı ikna eden değil, aynı adımlarla tekrar üretilebilen bulgudur. Rapor okuyan bir yöneticinin elinde kesin bir kanıt ve net bir düzeltme adımı olur.

SUID ikili bir güçtür: ya hep ya hiç. Dosya yetenekleri bunun ince kardeşidir. Yetenekler, root yetkisini küçük parçalara böler ve bir ikiliye yalnız gereken parçayı verir. getcap -r / 2>/dev/null komutu, yetenek atanmış dosyaları tarar.

ping gibi dosyalarda ağ yetkisi beklenir ve zararsızdır. Ama yanlış bir ikilide duran cap_setuid=ep ya da cap_dac_override=ep gibi bir hak, SUID kadar tehlikeli bir yükseltme yolu açar. Listeyi SUID avıyla aynı özenle okursun.

$ getcap -r / 2>/dev/null
/usr/bin/ping = cap_net_raw+ep
/usr/local/bin/arac = cap_setuid+ep        <-- ilgi çekici

Ağ dosya paylaşımları sessiz bir yol açar. Sunucu bir dizini, kök yetkisini kısmadan paylaşıyorsa risk doğar. /etc/exports dosyasındaki no_root_squash seçeneği, istemcideki root'un sunucuda da root sayılması demektir. Bu seçenek açıkken istemci tarafında SUID bir dosya oluşturur, paylaşıma koyarsın; sunucu onu kendi root'uyla çalıştırır.

Paylaşım seçeneklerini okumak bu durumu ilk bakışta gösterir. Gerçek hayatta eski bir yedek sunucusunda bu seçeneğin unutulmuş olması sık rastlanan bir bulgudur.

En sık hata, SUID biti açık her dosyayı yükseltme sanmaktır. passwd, ping ve mount zaten SUID çalışır ve güvenlidir. Bir bulgu, dosyanın kabuk çağırabilmesi, yazılabilir olması ya da bilinen bir kaçış yolu taşımasıyla doğar.

Otomatik bir aracın işaretlediği satırı elle doğrulamadan rapora yazmak da aynı hatanın başka yüzüdür. Araç bir satırı kırmızıya boyar; o satır bir olasılıktır, kanıt değildir. O satırı elle denemeden rapora geçirmek, bütün bulgularına gölge düşürür.

Savunma iki cümleye sığar. Gereksiz SUID bitlerini kaldır ve kalan listeyi düzenli denetle. sudo kuralını tam yol, tam argüman ve dar kapsamla yaz; kabuk çağırabilen araçlara NOPASSWD verme. Yetenekleri yalnız gereken ikiliye, yalnız gereken parçayla ata.

Ağ paylaşımlarında kök yetkisini kıs. Bu alışkanlıklar, bu dersteki yolların neredeyse hepsini kapatır ve denetim turunu kısaltır. Bir kurumda bu kuralları yazılı bir politikaya bağlamak, aynı hataların tekrar doğmasını engeller.