Linux Sistemde Privilege Escalation Tespiti ve Önlenmesi

Bir gece yarısı alarm aldığınızı düşünün: production sunucunuzda garip bir süreç çalışıyor, root yetkisiyle. Log’lara bakıyorsunuz ama neyin ne zaman olduğunu tam olarak çıkaramıyorsunuz. İşte bu an, privilege escalation tespitinin ne kadar kritik olduğunu bizzat hissediyorsunuz. Bu yazıda hem savunma hem de saldırı perspektifinden konuya bakacağız; saldırganların ne yaptığını anlarsak, onları tespit etmek de çok daha kolay olacak.

Privilege Escalation Nedir ve Neden Bu Kadar Önemli?

Privilege escalation, bir kullanıcının sisteme sahip olduğu yetkinin ötesine geçmeye çalışması anlamına geliyor. İki temel türü var:

• Yatay (Horizontal) Escalation: Aynı yetki seviyesindeki başka bir kullanıcının hesabına geçiş
• Dikey (Vertical) Escalation: Daha yüksek yetkiye sahip bir hesaba, genellikle root’a yükselme

Saldırganlar bir sisteme ilk erişimi genellikle düşük yetkili bir hesapla sağlarlar. Web uygulamasındaki bir açık, misconfigure edilmiş bir servis, ya da sosyal mühendislik… Asıl hedef ise çoğu zaman root ya da sudo yetkisi. Bu yüzden privilege escalation, bir saldırının en kritik adımlarından birini oluşturuyor.

Sistemde Neye Bakmalıyız?

Tespit işine girişmeden önce saldırganların hangi teknikleri kullandığını bilmek gerekiyor. Çünkü tespit, saldırı tekniğinin izini sürmek demek.

SUID/SGID Bitleri

Saldırganların en çok yararlandığı alanlardan biri SUID bitli dosyalar. SUID biti ayarlı bir dosya, dosyanın sahibinin yetkileriyle çalışır. Eğer dosyanın sahibi root ise ve bu dosya kötüye kullanılabiliyorsa, oyun bitti demektir.

Sistemdeki tüm SUID dosyalarını bulmak için:

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

Bu komutların çıktısını bir baseline ile karşılaştırın. Eğer /tmp/backdoor veya /home/kullanici/.local/bin/somefile gibi alışılmadık yerlerde SUID dosya görüyorsanız, bu ciddi bir uyarı işaretidir. Meşru SUID dosyaları genellikle /usr/bin, /usr/sbin, /bin gibi sistem dizinlerinde bulunur.

Sudo Yapılandırmasındaki Zafiyetler

Sudo konfigürasyonundaki hatalar, privilege escalation’ın en yaygın kaynaklarından biri. /etc/sudoers dosyası ve /etc/sudoers.d/ dizini altındaki dosyalar incelenmelidir.

cat /etc/sudoers
ls -la /etc/sudoers.d/
sudo -l

sudo -l çıktısında dikkat etmeniz gereken bazı tehlikeli durumlar:

• NOPASSWD ile birlikte şüpheli komutlar
• (ALL:ALL) ALL gibi aşırı geniş yetkiler
• vim, less, more, nano gibi editörlere sudo yetkisi (GTFOBins üzerinden exploit edilebilir)
• find, awk, perl, python gibi araçlara verilen sudo yetkileri

Cron Job’lar ve Zamanlı Görevler

Saldırganların sevdiği bir diğer alan: cron job’lar. Özellikle root yetkisiyle çalışan ve yazılabilir script’lere işaret eden cron job’lar tehlikeli.

crontab -l
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.weekly/
cat /var/spool/cron/crontabs/root

Burada şunu arıyoruz: root yetkisiyle çalışan bir cron job, eğer çalıştırdığı script dosyası başka kullanıcılar tarafından yazılabilirse, o script’i manipüle ederek komutlarımızı root olarak çalıştırabiliriz. Tespit açısından bakınca, aniden değişen script dosyaları veya beklenmedik cron job eklemeleri izlenmelidir.

Dünya Tarafından Yazılabilir Dosyalar ve Dizinler

find / -writable -type f 2>/dev/null | grep -v proc
find / -writable -type d 2>/dev/null | grep -v proc

/etc/passwd veya /etc/shadow gibi kritik dosyaların yazılabilir olması, ya da PATH içindeki dizinlerin başkaları tarafından yazılabilir olması büyük sorun.

Gerçek Dünya Senaryosu: Log İncelemesi ile Tespit

Geçmişte karşılaştığım bir vakayı paylaşayım. Bir e-ticaret firmasının sunucusunda anormal aktivite vardı. Kullanıcılardan biri olan webuser hesabı normalde sadece web uygulamasının çalışması için kullanılıyordu. Ama auth.log’da ilginç şeyler görmeye başladık.

grep -i "sudo|su|root" /var/log/auth.log | tail -100
grep "COMMAND" /var/log/auth.log
journalctl -u sudo --since "2024-01-01" --until "2024-01-02"

Bu komutların çıktısında şunu gördük: webuser hesabı sudo python3 -c "import os; os.system('/bin/bash')" komutunu çalıştırmaya çalışmıştı. Sudoers’a bakınca, eski bir geliştirici bu hesaba python3 için NOPASSWD yetkisi vermişti ve bunu unutmuşlardı. GTFOBins’deki klasik bir teknikti.

Kernel Exploit Tespiti

Saldırganlar bazen kernel zafiyetlerini kullanır. Dirty COW (CVE-2016-5195), OverlayFS zafiyetleri bunların en bilinenleri. Kernel exploit kullanımının izleri farklı yerlerde görünür.

Önce sistemin kernel versiyonuna bakın:

uname -r
uname -a
cat /proc/version

Sonra bu versiyona karşı bilinen CVE’leri kontrol edin. Ama asıl önemli olan, runtime tespiti. Kernel exploit’ler genellikle belirli sistem çağrılarını tetikler. auditd kurulu bir sistemde bunları yakalayabilirsiniz.

auditctl -a always,exit -F arch=b64 -S ptrace -k privilege_escalation
auditctl -a always,exit -F arch=b64 -S personality -k privilege_escalation
ausearch -k privilege_escalation

Auditd ile Kapsamlı İzleme

auditd, Linux’un yerleşik denetim sistemi ve privilege escalation tespitinde en güçlü araçlardan biri. Doğru yapılandırılmış bir auditd, saldırının her adımını kaydedebilir.

Temel bir audit kuralı seti:

# /etc/audit/rules.d/privilege_escalation.rules

# Yetki değişikliklerini izle
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_changes
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_changes

# Sudo kullanımını izle
-w /usr/bin/sudo -p x -k sudo_usage
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d -p wa -k sudoers_changes

# SUID/SGID bit değişikliklerini izle
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -k chmod_operations

# Kritik dosya değişikliklerini izle
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes

auditctl -R /etc/audit/rules.d/privilege_escalation.rules

Kuralları yükledikten sonra log’ları analiz etmek için:

ausearch -k privilege_changes --start today
ausearch -k sudo_usage --start yesterday --end today
aureport --auth --failed
aureport --sudo

/proc Dosya Sistemi ile Anlık Analiz

/proc dosya sistemi, çalışan süreçler hakkında muazzam bilgi sunar. Bir süreç aniden root yetkisi kazandıysa veya capabilities değiştiyse, bunu /proc üzerinden tespit edebilirsiniz.

# Tüm süreçlerin effective UID'lerine bak
for pid in /proc/[0-9]*/status; do
    grep -E "^(Name|Pid|Uid|Gid|CapEff):" "$pid" 2>/dev/null
done | paste - - - - - | awk '$10 != $8 {print}'

Bu betik, gerçek UID’si ile efektif UID’si farklı olan süreçleri listeliyor; yani potansiyel SUID exploit kullanan süreçleri.

Capabilities de kritik bir alan. Linux capabilities, root yetkisini küçük parçalara böler. Bir sürecin olmaması gereken capabilities’i varsa bu şüpheli:

# Tüm süreçlerin capabilities'ini göster
cat /proc/*/status | grep -A 5 "^Name:" | grep -E "Name:|CapEff:" | paste - - | awk '$4 != "0000000000000000" {print}'

# Belirli bir process için
cat /proc/1234/status | grep Cap
capsh --decode=0000003fffffffff

LinPEAS ve Manuel Kontrollerin Birlikte Kullanımı

Bir pentest yapıyorsanız ya da sistemin güvenliğini değerlendiriyorsanız, LinPEAS gibi otomatik araçlar zaman kazandırır. Ama bu araçların çıktısını körü körüne kabul etmemek gerekir.

LinPEAS’ı güvenli şekilde kullanmak:

# Doğrudan çalıştırmak yerine, önce indirip incelemek daha sağlıklı
curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh -o linpeas.sh
less linpeas.sh  # İçeriği mutlaka inceleyin
chmod +x linpeas.sh
./linpeas.sh -a 2>&1 | tee linpeas_output.txt

Ama LinPEAS’ın göremeyeceği şeyler var. Mesela özel yapılandırılmış bir uygulama, in-memory exploit, ya da sadece o ortama özgü bir misconfiguration. Bu yüzden manuel kontroller vazgeçilmez.

Manuel olarak mutlaka bakılması gereken yerler:

• Ortam değişkenleri: env ve printenv çıktıları, PATH manipulation için
• Yazılabilir PATH dizinleri: Özellikle /tmp ve kullanıcı dizinleri PATH’de mi?
• NFS mount’ları: no_root_squash ayarı varsa root yetkisi devralınabilir
• Docker socket erişimi: /var/run/docker.sock dosyasına erişim varsa oyun bitti
• Servis hesapları: www-data, postgres gibi hesapların gereksiz yere sahip olduğu yetkiler

Fail2Ban ve IDS ile Proaktif Tespit

Pasif log analizi yerine aktif tespit için Fail2Ban’ı privilege escalation denemeleri için de yapılandırabilirsiniz.

# /etc/fail2ban/filter.d/sudo-abuse.conf
[Definition]
failregex = sudo:.*FAILED su for .* by .*
            sudo:.*authentication failure.*
            sudo:.*command not allowed.*

# /etc/fail2ban/jail.d/sudo-abuse.conf
[sudo-abuse]
enabled = true
port = ssh
filter = sudo-abuse
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

AIDE (Advanced Intrusion Detection Environment) ile dosya bütünlüğü izlemesi de kritik:

# AIDE kurulumu ve başlangıç baseline'ı
apt-get install aide
aide --init
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Sonraki kontroller için
aide --check

# Cron ile otomatik kontrol
echo "0 2 * * * root /usr/bin/aide --check | mail -s 'AIDE Report' [email protected]" >> /etc/cron.d/aide-check

Systemd Journal ile Merkezi Log Analizi

Modern Linux sistemlerde journalctl oldukça güçlü bir analiz aracı. Privilege escalation’ı tespit etmek için:

# Son 24 saatteki tüm yetki değişikliklerini göster
journalctl --since "24 hours ago" | grep -E "sudo|su|SUID|privilege|root"

# Belirli kullanıcının tüm aktivitelerini izle
journalctl _UID=1001 --since "2024-01-01"

# Başarısız sudo denemelerini say ve sırala
journalctl -u sudo | grep "authentication failure" | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# Gece yarısı aktiviteleri (09:00-17:00 dışı)
journalctl --since "2024-01-01" --until "2024-01-02" | awk -F: '$2 < 9 || $2 > 17 {print}'

Anlık Savunma: Bir Saldırı Tespit Ettiğinizde Ne Yapmalısınız?

Gerçek bir vakada soğukkanlı olmak çok önemli. Panik yapıp sistemi kapatmak yerine önce delilleri koruyun.

# Anlık sistem durumunu kaydet
ps auxf > /secure-location/ps_$(date +%Y%m%d_%H%M%S).txt
netstat -tlnp > /secure-location/netstat_$(date +%Y%m%d_%H%M%S).txt
ss -tlnp >> /secure-location/netstat_$(date +%Y%m%d_%H%M%S).txt
w > /secure-location/who_$(date +%Y%m%d_%H%M%S).txt
last > /secure-location/last_$(date +%Y%m%d_%H%M%S).txt
find / -mtime -1 -type f 2>/dev/null > /secure-location/recently_modified.txt

# Şüpheli süreçleri inzele, hemen öldürme
ls -la /proc/ŞÜPHELI_PID/exe
cat /proc/ŞÜPHELI_PID/cmdline | tr '' ' '
cat /proc/ŞÜPHELI_PID/environ | tr '' 'n'

# Memory dump (eğer volatility kullanacaksanız)
dd if=/dev/mem of=/secure-location/memory.dump bs=1M

Sonrasında kullanıcıyı sistemden atmak için:

# Oturumu zorla kapat
pkill -KILL -u şüpheli_kullanici
usermod -L şüpheli_kullanici
passwd -l şüpheli_kullanici

Önleyici Tedbirler

Tespit kadar önemli olan, bu açıkların oluşmamasını sağlamak. Birkaç temel önlem:

• Kernel’i güncel tut: unattended-upgrades veya dnf-automatic ile otomatik güvenlik güncellemelerini aktif et
• SUID dosyaları minimize et: Gereksiz SUID bitleri kaldır, chmod u-s /path/to/file
• AppArmor veya SELinux kullan: MAC (Mandatory Access Control) katmanı, exploit başarılı olsa bile hasarı sınırlar
• Sudo’yu dikkatli yapılandır: NOPASSWD direktifinden kaçın, sadece gerçekten ihtiyaç duyulan komutlara izin ver
• Capability’leri kısıtla: setcap ile gereksiz capability’leri kaldır
• Docker socket’ini koru: /var/run/docker.sock erişimini gerçekten ihtiyacı olan servislerle sınırla

# Gereksiz SUID bitlerini kaldırmak için örnek
chmod u-s /usr/bin/at
chmod u-s /usr/bin/newgrp

# Mevcut SUID dosyaları listele ve değişimi izle
find / -perm -4000 -type f 2>/dev/null | sort > /etc/security/suid_baseline.txt
# Düzenli olarak karşılaştır
find / -perm -4000 -type f 2>/dev/null | sort | diff /etc/security/suid_baseline.txt -

Sonuç

Privilege escalation tespiti, tek bir araç veya tek bir log dosyasına bakmakla olmuyor. Katmanlı bir yaklaşım şart: auditd ile sistem çağrılarını izlemek, AIDE ile dosya bütünlüğünü korumak, log’ları düzenli analiz etmek ve en önemlisi, sistemin “normal” halini bilmek.

En sık gördüğüm hata şu: sysadmin’ler sistemi kuruyor, güvenliği bir kez düşünüyor ve sonra bir daha bakmıyor. Oysa güvenlik bir durum değil, sürekli devam eden bir süreç. Baseline oluşturun, değişiklikleri izleyin, log’larınızı okuyun.

Bir de şunu eklemeliyim: Bu teknikleri kendi sistemlerinizde öğrenmek için kullanın. Pentest yapmak istiyorsanız TryHackMe veya HackTheBox gibi platformlarda yasal ortamlarda pratik yapın. Başkasının sisteminde izinsiz bu teknikleri denemek sadece etik değil, aynı zamanda yasal bir sorun.

Sistemleriniz güvende kalsın.