Yetki Yükseltme (Privilege Escalation) — Gerçek Dünyadan Teknik Bir İnceleme

Yetki yükseltme, bir saldırganın normal bir kullanıcı (veya kısıtlı yetkili süreç) seviyesinden daha yüksek izinlere (örn. root/Administrator) ulaşmasıdır. Bu yazıda gerçek bir zafiyet senaryosunu laboratuvarda yeniden üretecek şekilde ele alacağım: Linux tarafında setuid / yanlış kullanım ve Windows tarafında unquoted service path / servis izinleri örnekleriyle hem “nasıl çalıştığı” hem “neden tehlikeli olduğu” hem de “nasıl düzeltilir” adımlarını göreceksiniz.
Neden Önemli?

Yetki yükseltme, saldırı zincirinin kritik halkasıdır: bir zafiyet ile sisteme sızan saldırgan, yükseltme ile kalıcılık, veri sızdırma veya ağda hareketlilik (lateral movement) elde eder. Bu, bir güvenlik açığının yalnızca başlangıç aşamasında olduğunun kanıtıdır.
1) Linux: Yanlış Yazılmış setuid Programı (Pratik Senaryo)
Senaryo (özet)

Basit bir yönetim aracı vuln_updater root olarak çalışan ve dışarıdan gelen dosya isimlerini system() ile çalıştıran setuid programı olsun. Girdi doğrulaması yok; dolayısıyla saldırgan yerel dosya/çevresel değişkenler üzerinden kod çalıştırabilir.
Zafiyetin kökü

system() çağrılarında kullanıcı kontrollü argümanların doğrudan kullanılması.
Setuid binary’lerin çevresel değişkenleri yeterince sabitlememesi (PATH, LD_PRELOAD, IFS vb.).
Dosya izinlerinin kötü yapılandırılması.

Laboratuvar Hazırlığı (güvenli ortamda)

İzole bir VM oluştur (ör. Ubuntu VM).

Aşağıdaki gibi bilinçli olarak güvensiz bir program derle (sadece lab için):

// vuln_updater.c - LAB ONLY
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
if (argc != 2) {
printf("Usage: %s <script>\n", argv[0]);
return 1;
}
// Tehlikeli: doğrudan formatlanmış shell çağrısı
char cmd[512];
snprintf(cmd, sizeof(cmd), "/bin/sh -c '%s'", argv[1]);
system(cmd);
return 0;
}

Derle:

gcc -o vuln_updater vuln_updater.c
sudo chown root:root vuln_updater
sudo chmod 4755 vuln_updater # setuid bit

NOT: Bu program bilerek zayıf yazıldı. Canlı sistemlerde böyle bir program bulunuyorsa acilen kaldırın.
Exploit mantığı (konsept — adımlar)

Saldırgan normal kullanıcıyla vuln_updater çalıştırır ve shell komutu gönderir. Eğer program setuid ise ve system() root bağlamında çalışıyorsa saldırgan root seviyesinde kod çalıştırabilir.
Modern distro’larda setuid + system kombinasyonu bazen sınırlı olsa da çevresel değişkenleri kullanarak veya /tmp üzerinden kötü amaçlı dosyalar yerleştirerek kodu root altında çalıştırmak mümkündür.
Örnek (lab): ./vuln_updater "cp /bin/sh /tmp/rootsh; chmod +s /tmp/rootsh" — eğer root yetkisiyle çalışıyorsa /tmp/rootsh SUID shell olur ve kullanıcı bunu çalıştırınca root elde eder.

Güvenlik (düzeltme) önerileri

Asla setuid programlarda system() veya benzeri shell-eğilimli çağrılar kullanma. execve() ile sabitlenmiş argümanlar kullan.
Çevresel değişkenleri (PATH, LD_* vb.) sıfırla ve güvenli yol kullan.
Setuid ihtiyacını yeniden değerlendir: mümkünse capability’ler veya sudoers ile sınırlı komutlar kullan.
Kod inceleme ve SAST ile setuid binary’leri tarayın.

2) Windows: Unquoted Service Path ve Servis İzinleri (Örnek)
Senaryo (özet)

Bir Windows servisi C:\Program Files\MyApp\bin\my service.exe şeklinde kurulmuş ancak servis yolu quotes ile korunmamış (yol boşluk içeriyor). Windows servis yükleme davranışı nedeniyle, belirli durumlarda ilk eşleşen .exe çalıştırılabilir — bu da DLL hijack veya executable hijack’e yol açabilir.
Zafiyetin kökü

Servis dosya yolu tırnaklanmadan ayarlanmışsa, Windows boşluklara göre ilk uygun executable’ı çalıştırabilir.
Servis dosyalarının ve klasör izinlerinin zayıf olması, düşük ayrıcalıklı bir kullanıcının kendi DLL/EXE’sini yerleştirerek yükselmesine neden olabilir.

Tespit (araçlar / komutlar)

PowerShell ile servisleri listele ve PathName alanlarını kontrol et:

Get-WmiObject Win32_Service | select Name, StartName, PathName

PathName içinde boşluk var mı ve tırnaklama yok mu kontrol et.
Exploit mantığı (konsept — adımlar)

Servis C:\Program Files\Bad App\bin\daemon.exe şeklinde ve tırnaksız kaydedilmiş olsun.
Sistem servisi başlatılırken Windows C:\Program.exe, C:\Program Files\Bad.exe, C:\Program Files\Bad App\bin\daemon.exe sırasıyla arayabilir — eğer saldırgan C:\Program.exe koyabiliyorsa o çalışır.
Genelde üretim sistemlerde bu tür eksiklikler nadiren doğrudan exploit edilebilir çünkü yazma izinleri kısıtlıdır; ancak paketleme/yanlış izin durumlarında saldırgan bir yol oluşturabilir.

Düzeltilmesi

Servis ImagePath değerlerini mutlaka tırnak içine alınmış şekilde yazın: "C:\Program Files\Bad App\bin\daemon.exe".
Servis dosyası ve üst dizinler için NTFS izinlerini sıkılaştırın (Yalnızca admin/root yazma yetkisi).
UAC/Service Hardening ve least privilege prensibini kullanın.

Tespit & Keşif (Detection) — Hem Linux Hem Windows İçin

Linux: find / -perm -4000 -type f 2>/dev/null ile SUID dosyalarını listele. İncele ve beklenmeyen setuid dosyalarını kaldır.
Windows: Get-WmiObject Win32_Service ile servis yollarını kontrol et. Zayıf izinli servis exe/dizinleri için ACL denetimi yap.
IDS/EDR kurallarıyla anormal işlem zincirlerini ve beklenmeyen cp/chmod aktivitelerini yakalayın.
CI/CD ve paketlemede otomatik güvenlik taramaları (SCA/SAST) entegre edin.

Özet — Kısa İyi Uygulamalar Listesi

Setuid / servis gibi yüksek-izin gerektiren bileşenlerin kodunu minimal, güvenli ve audit edilebilir tut.
system() ve shell interpolasyonlarından kaçının; sabit execve() veya API’ler kullanın.
Dosya/klasör izinlerini sıkılaştırın, geliştirici/deployment sürecinde yanlış izin verilmesini engelleyin.
Servis path’lerini tırnakla ve servis hesaplarını least-privilege ile yapılandır.
Otomatik taramalar + el ile kritik inceleme (code review) kombinasyonu uygulayın.