exec() Olmadan RCE: File Write Primitive’leri Zor Yoldan Sömürmek

exec() Olmadan RCE: File Write Primitive’leri Zor Yoldan Sömürmek​

Herkese Merhabalar. Bu yazımda "exec() Olmadan RCE: File Write Primitive’leri Zor Yoldan Sömürmek" konusunu ele alacağız. Keyifli okumalar..

Genişletmek için tıkla ...

Uzaktan Kod Yürütme (RCE), modern web uygulamalarında en çok yanlış anlaşılan zafiyet sınıflarından biridir. Birçok ekip için bu tanım hala bir kontrol listesine indirgenmiş durumdadır:

• exec() veya system() erişilebilir durumda mı?
• shell_exec() devre dışı mı?
• Tehlikeli PHP fonksiyonları kara listeye alındı mı?

Eğer cevap "evet, devre dışı bırakıldılar" ise, genellikle şu sonuca varılır:

"RCE riski yoktur."

Bu varsayım temelden hatalıdır. RCE, bir fonksiyonla tanımlanmaz.RCE, etki (impact) ile tanımlanır. Eğer bir saldırgan, çalışma zamanının (runtime) hangi kodu yürüteceğini etkileyebiliyorsa — komut yürütme fonksiyonlarının (primitives) mevcut olup olmadığına bakılmaksızın — RCE mevcuttur. Bu makale; komut yürütme (command execution) gerektirmeyen, ancak dosya yazma yetkilerinin yürütme noktalarıyla (execution sinks) zincirlenmesi yoluyla tam sunucu taraflı kod yürütmenin sağlandığı, daha az bilinen fakat yüksek etkili bir RCE sınıfını analiz etmektedir.

Tehdit Modellemesi: Gerçek Saldırı Yüzeyini Tanımlamak​

İncelenen uygulama, ilk bakışta masum görünen bir özellik sunar:

• Kullanıcı bir template adı girer
• Kullanıcı template içeriği girer
• Uygulama bu template’in önizlemesini gösterir

Fonksiyonel açıdan sorun yok gibi görünür.
Ancak güvenlik perspektifinden bakıldığında, iki kritik saldırgan kontrollü veri hemen göze çarpar:

1. Sunucu tarafı bir kaynağın tanımlayıcısı
2. Bu kaynağa yazılan içerik

Buradaki esas soru şudur:

Bu kullanıcı girdisi, hangi güven sınırlarını (trust boundary) aşıyor?

Genişletmek için tıkla ...

Primitive #1: Kalıcı File Write​

Uygulama, kullanıcıdan gelen içeriği bir cache mekanizması gerekçesiyle disk üzerinde saklar.
Bu davranışın kritik özellikleri:

• Dosya .php uzantısıyla yazılır
• İçerik data olarak değil, kod olarak ele alınır
• Dosya kalıcıdır ve sonraki request’lerde tekrar kullanılır

Bu noktada oluşan şey şudur:

File Write Primitive

Genişletmek için tıkla ...

Henüz RCE yoktur.
Henüz kod çalışmamıştır.
Ancak en tehlikeli ön koşul artık mevcuttur:

Saldırgan kontrollü, kalıcı ve executable bir artefact disk üzerinde vardır.

Genişletmek için tıkla ...

Birçok rapor bu noktada durur ve bunu “arbitrary file write” olarak kapatır.
Bu, ciddi bir analiz hatasıdır.

Primitive #2: Execution Sink –​

Zincirin tamamlandığı yer, template’in render edildiği noktadır:

Bu satır sıklıkla yanlış yorumlanır.

Bash:

include $templateFile;

Genişletmek için tıkla ...

PHP’de include:

• Dosyayı parse eder
• Opcode’lara çevirir
• Mevcut runtime context’inde çalıştırır

Yani attacker-controlled bir dosyanın include edilmesi, doğrudan kod çalıştırılması demektir. Bu noktada zafiyet, dosya sistemi seviyesinden çıkar ve:

Arbitrary PHP Code Execution seviyesine ulaşır.

Genişletmek için tıkla ...

Bu yüzden bu sınıf, Indirect RCE olarak adlandırılır.

Neden Bu RCE Sınıfı Gözden Kaçar?​

Bu tür zafiyetler çoğu zaman:

• Code review’lardan geçer
• SAST araçları tarafından kaçırılır
• WAF’lara takılmaz

Sebebi şudur:

• Belirgin bir payload yoktur
• “Tehlikeli fonksiyon” çağrısı yoktur
• İş mantığı meşru görünür
• Zafiyet tek bir noktada değil, zincirde gizlidir

Otomatik araçlar tekil sink arar.Bu zafiyet ise primitive’lerin etkileşiminde ortaya çıkar.

Kanıt (PoC): Sorumlu ve Teknik Doğrulama​

Sorumlu bir PoC’nin amacı zarar vermek değil, etkiyi ispatlamaktır.
Bu doğrulama şunları göstermelidir:

• Kodun server-side çalıştığını
• Disk üzerinde kalıcı değişiklik oluştuğunu
• Execution flow’un saldırgan tarafından kontrol edildiğini

Linux sistemlerde bu genelde /etc/passwd ile yapılır. Windows (XAMPP) ortamlarında ise hosts dosyası eşdeğer bir kanıttır. İşletim sistemi değil, execution context önemlidir.

Exploit Edilebilirlik ve Şiddet Değerlendirmesi​

Bu zafiyet sınıfı genellikle High – Critical olarak değerlendirilir çünkü:

• Çoğu senaryoda authentication gerekmez
• Race condition yoktur
• Exploit deterministiktir
• Etki tam uygulama kompromisidir

Bu bir edge-case değildir. Bu, tasarım hatasının doğal sonucudur.

Mitigasyon: Taktik Değil, Mimari​

Bu zafiyetler:

• Regex ile
• Blacklist ile
• Fonksiyon kapatarak

çözülemez.
Doğru savunma prensipleri şunlardır:

• Kullanıcı girdisi asla executable dosyaya dönüşmemeli
• Template’ler allowlist üzerinden seçilmeli
• Cache dosyaları data formatında tutulmalı
• Execution sink’ler kullanıcı kontrollü path’leri tüketmemeli

Altın kural nettir:

User input → executable file hattı kesinlikle olmamalıdır.

Genişletmek için tıkla ...

Sonuç​

Indirect RCE’ler sessizdir.Gösterişli değildir.Ama hayatta kalır.Gerçek güvenlik araştırması, tek bir bug bulmak değil; primitive’lerin nasıl zincirlendiğini anlamaktır. Bu zafiyet sınıfı nadir değildir.
Sadece yeterince ciddiye alınmamaktadır.

Bu konu hakkında anlatacaklarım bu kadar. Aşağıda bu konuyu anlattığım youtube videosunu ekliyorum. Herkese İyi Forumlar.