NFS Misconfiguration ve SUID Injection ile Privilege Escalation
Ömer Faruk SEVİM · @n0sfy
1. Giriş
Network File System (NFS), ağ üzerindeki sistemler arasında dosya paylaşımını sağlayan, Unix/Linux dünyasında onlarca yıldır kullanılan bir protokoldür. Kurumsal ortamlarda dosya sunucularının merkezi bir noktadan paylaşılması için sıkça tercih edilir. Ancak doğru yapılandırılmadığında, NFS bir saldırgana düşük yetkili bir kullanıcıdan root yetkisine geçiş imkânı sunabilecek kritik bir zafiyet yüzeyi haline gelebilir.
Bu yazıda öncelikle NFS'in çalışma mantığını, ardından yaygın misconfiguration senaryolarını ve bu yanlış yapılandırmaların SUID injection tekniğiyle nasıl istismar edilerek privilege escalation sağlandığını teorik olarak ele alacağız.
2. NFS (Network File System) Nedir?
NFS, Sun Microsystems tarafından 1984 yılında geliştirilen, bir dizin veya dosya sistemini ağ üzerinden uzak istemcilere "mount" edilebilir hale getiren dağıtık bir dosya sistemi protokolüdür. Temel amacı, fiziksel olarak farklı makinelerde bulunan dosyaları, sanki yerel diskteymiş gibi erişilebilir kılmaktır.
2.1. Temel Bileşenler
- NFS Server: Paylaşıma açılacak dizinleri (export) tanımlayan ve istemci bağlantılarını kabul eden taraf.
- NFS Client: Sunucu tarafından paylaşılan dizini kendi dosya sistemine mount eden taraf.
/etc/exports: Sunucu üzerinde hangi dizinlerin, hangi istemcilere, hangi izinlerle paylaşılacağını tanımlayan yapılandırma dosyası.rpcbind/portmapper: NFS'in çalışması için gerekli olan RPC (Remote Procedure Call) servislerinin port eşlemesini yöneten servis.mountd,nfsd: Mount isteklerini ve dosya sistemi operasyonlarını işleyen daemon'lar.
2.2. NFS Sürümleri
- NFSv2 / NFSv3: Stateless yapıdadır, kimlik doğrulama büyük ölçüde istemci tarafından gönderilen UID/GID bilgisine dayanır. Bu durum, güvenlik açısından en kritik noktadır.
- NFSv4: Stateful yapıya geçmiştir, Kerberos entegrasyonu ile güçlü kimlik doğrulama desteği sunar, tek portta (2049) çalışır ve ACL desteği getirmiştir.
NFSv3 ve öncesinde kimlik doğrulama mekanizmasının zayıflığı, bu yazının konusu olan istismar tekniğinin temelini oluşturur.
3. NFS'te Kimlik Doğrulama Mantığı ve Zayıf Nokta
NFSv3, kullanıcı kimlik doğrulamasını gerçek bir kimlik doğrulama olarak değil, istemci tarafından gönderilen UID (User ID) ve GID (Group ID) değerlerine güvenerek yapar. Yani:
- İstemci, "Ben UID 1000 kullanıcısıyım" der.
- Sunucu bu bilgiye güvenir ve buna göre dosya erişim izni verir.
- Sunucu, istemcinin gerçekten o kullanıcı olup olmadığını doğrulayacak bir parola veya token mekanizması çalıştırmaz.
Bu durum tek başına bir zafiyet değildir; çünkü normalde root kullanıcısı (UID 0) özel olarak ele alınır. Burada devreye root squashing kavramı girer.
3.1. Root Squashing Nedir?
Root squashing, bir istemciden gelen root (UID 0) isteklerinin sunucu tarafında yetkisiz bir kullanıcıya (genellikle nobody, UID 65534) eşlenmesi mekanizmasıdır. Bu sayede bir istemci makinenin root kullanıcısı, NFS paylaşımı üzerinde otomatik olarak root yetkisi kazanamaz.
/etc/exports dosyasında bu davranış şu şekilde kontrol edilir:
/paylasilan/dizin istemci_ip(rw,sync,root_squash)root_squash(varsayılan davranış): İstemciden gelen root isteklerininobodykullanıcısına indirger. Güvenli yapılandırma budur.no_root_squash: İstemciden gelen root isteklerini olduğu gibi kabul eder. Yani istemci tarafında root olan biri, NFS paylaşımı üzerinde de root olarak işlem yapabilir.
İşte asıl misconfiguration tam olarak burada ortaya çıkar.
4. Yaygın NFS Misconfiguration Senaryoları
4.1. no_root_squash Kullanımı
Sistem yöneticileri genellikle uygulama uyumluluğu, yedekleme script'leri veya "kolaylık olsun" mantığıyla no_root_squash seçeneğini aktif hale getirir. Bu, en kritik ve en sık karşılaşılan misconfiguration türüdür. Bir saldırgan kontrolündeki herhangi bir Linux makinesinden bu paylaşıma root olarak mount işlemi yapılabildiğinde, oluşturulan her dosya hedef sistemde de root sahipliğiyle oluşur.
4.2. Aşırı Geniş veya Hatalı IP/Subnet Tanımı
/export *(rw,no_root_squash)* ile tüm istemcilere izin verilmesi veya geniş subnet'lerin (10.0.0.0/8 gibi) gereğinden fazla yetkiyle tanımlanması, ağdaki herhangi bir makinenin paylaşıma erişebilmesine yol açar.
4.3. insecure Seçeneği
NFS normalde istemciden gelen isteklerin 1024'ün altındaki (privileged) portlardan gelmesini zorunlu kılar (secure varsayılandır). insecure seçeneği bu kontrolü kaldırır, root olmayan bir kullanıcının da yüksek portlardan sahte istekler göndererek sunucuyu kandırmasına imkân tanır.
4.4. rw (read-write) Yetkisinin Gereksiz Yere Verilmesi
Salt okunur olması gereken paylaşımların rw ile açılması, saldırganın paylaşıma dosya yazabilmesine — dolayısıyla istismar zincirinin ilk adımını atabilmesine — zemin hazırlar.
4.5. Zayıf Dosya/Dizin İzinleri
Paylaşılan dizinin kendisinin dünya tarafından yazılabilir (777) olması, kimlik doğrulama zafiyetiyle birleştiğinde etkiyi katlar.
5. SUID Nedir ve Neden Önemlidir?
SUID (Set User ID), Linux/Unix dosya izin sisteminde bir çalıştırılabilir dosyaya atanabilen özel bir bittir. Normal şartlarda bir program çalıştırıldığında, o program çalıştıran kullanıcının yetkileriyle işlem yapar. SUID biti set edilmiş bir binary ise, kim çalıştırırsa çalıştırsın, dosya sahibinin yetkileriyle çalışır.
Örnek:
-rwsr-xr-x 1 root root 44784 /usr/bin/passwdBuradaki s harfi SUID bitinin aktif olduğunu gösterir. passwd komutunun SUID root olarak işaretlenmesinin sebebi, normal bir kullanıcının kendi parolasını değiştirirken /etc/shadow dosyasına erişebilmesi gerekliliğidir — bu da ancak root yetkisiyle mümkündür.
5.1. SUID'in Saldırı Yüzeyi Olarak Değeri
Eğer bir saldırgan, root sahipliğinde ve SUID biti set edilmiş, kendi kontrolündeki bir binary'yi hedef sistemde çalıştırabilirse, bu binary çalıştığı anda root yetkisiyle işlem yapar. Normalde bir saldırganın kendi oluşturduğu dosyayı root sahipliğinde işaretlemesi (chown root:root + chmod +s) mümkün değildir çünkü bu işlemler root yetkisi gerektirir.
İşte burada NFS'teki no_root_squash zafiyeti devreye girer: saldırgan, NFS paylaşımına kendi makinesinde root olarak bağlanıp dosya oluşturduğunda, sunucu bu isteği gerçek root isteği olarak kabul eder ve dosyanın sahipliğini root:root olarak atar. Böylece saldırgan, kendi kontrolündeki istemci üzerinde root yetkisiyle, hedef sunucuda geçerli olacak bir SUID binary üretebilir.
6. İstismar Zincirinin Teorik Akışı (SUID Injection)
Saldırının mantıksal akışı şu adımlardan oluşur:
- Keşif:
showmount -e <hedef_ip>gibi komutlarla hedef sunucudaki NFS export'ları listelenir. - Yapılandırma Analizi: İlgili export'un
no_root_squashverwseçenekleriyle paylaşıldığı tespit edilir. - Mount: Saldırgan kendi kontrolündeki (genellikle root yetkisine sahip olunan) bir Linux makinesinden bu paylaşım yerel bir dizine mount edilir.
- Binary Hazırlığı: Root yetkisiyle çalıştığında bir kabuk (shell) verecek bir dosya hazırlanır. Bu,
setuid(0); setgid(0); system("/bin/bash")mantığında yazılmış özel bir C programının derlenmesiyle yapılabileceği gibi, pratikte çok daha sık kullanılan bir yöntemle, sistemde zaten var olan/bin/bashkabuğunun doğrudan paylaşım dizinine kopyalanmasıyla da yapılabilir; her iki durumda da amaç, SUID biti atandığında root yetkisiyle çalışacak bir çalıştırılabilir dosya elde etmektir. - Sahiplik ve Bit Ataması: Hazırlanan dosya, mount edilen dizin içinde saldırganın kendi root yetkisiyle
root:rootsahipliğine ve SUID bitine sahip olacak şekilde işaretlenir. Bu işlem saldırganın kendi makinesinde root olarak yapıldığı için mümkündür; sunucu bu değişikliği "gerçek root'tan geldi" varsayarak kabul eder. - Tetikleme: Hedef sunucu üzerinde, paylaşımın mount edildiği karşılık gelen dizine düşük yetkili bir kullanıcı olarak erişilip binary çalıştırılır.
- Yetki Yükseltme: Binary, SUID biti sayesinde dosya sahibinin (root) yetkisiyle çalışır ve saldırgana root shell'i teslim eder.
Bu zincirin kritik noktası, sahiplik ve izin bilgisinin istemci tarafından belirlenip sunucu tarafından sorgusuzca kabul edilmesidir. no_root_squash olmasaydı, 6. adımdaki SUID biti devreye girmezdi çünkü dosyanın sahibi root değil nobody olurdu ve SUID bitinin bir anlamı kalmazdı.
7. Neden Bu Zincir Bu Kadar Etkili?
- Kimlik doğrulama eksikliği: NFSv3, kriptografik bir doğrulama yapmaz; istemcinin beyanına güvenir.
- İstemcideki root yetkisi, normalde sunucudaki root yetkisi anlamına gelmemelidir; ancak misconfiguration bu ayrımı tamamen ortadan kaldırır.
- SUID mekanizması tasarım gereği güçlüdür: Dosya sahibinin yetkisini kalıcı olarak taşır, bu da onu hem meşru sistem ihtiyaçları hem de istismar senaryoları için değerli kılar.
- Tespiti genellikle zordur: Loglama ve monitoring olmayan ortamlarda, bu işlem dışarıdan bakıldığında sıradan bir dosya yazma operasyonundan farksız görünür.
8. Önleme ve Sertleştirme (Hardening) Önerileri
/etc/exportsdosyasında her zamanroot_squashkullanılmalı (varsayılan davranış korunmalı),no_root_squashyalnızca kesinlikle gerekli ve izole edilmiş senaryolarda, ek kontrollerle kullanılmalı.- Export edilen dizinlere erişim, mümkün olan en dar IP/subnet tanımıyla sınırlandırılmalı;
*gibi genel tanımlardan kaçınılmalı. - Gereksiz yere
rwverilmemeli, mümkün olduğuncaro(read-only) tercih edilmeli. insecureseçeneğinden kaçınılmalı,secure(varsayılan) korunmalı.- Mümkünse NFSv4 + Kerberos (
sec=krb5p) gibi güçlü kimlik doğrulama mekanizmaları tercih edilmeli. - Dosya sistemleri
nosuidmount seçeneğiyle mount edilerek, NFS üzerinden gelen SUID bitlerinin işletim sistemi tarafından yok sayılması sağlanmalı. Bu, tek başına en etkili savunma katmanlarından biridir. - Düzenli olarak sistem genelinde beklenmedik SUID binary taraması yapılmalı (
find / -perm -4000gibi).
9. Pratik Uygulama
9.1. Senaryo
Bu demo ortamında aynı yerel ağ üzerinde iki makine bulunmaktadır:
- Server (Hedef): 172.21.27.84 — üzerinde NFS servisi çalışan ve
/srv/nfs/sharedizininino_root_squashveinsecureyapılandırmasıyla paylaşıma açmış bir Ubuntu sunucu. Bu sunucuda, hiçbir özel yetkisi olmayanlowprivadlı düşük yetkili bir kullanıcı da bulunmaktadır. - Attacker (Saldırgan): Aynı ağ üzerinde bulunan ve hedefin NFS paylaşımına erişebilen, saldırganın kendi kontrolünde olan ve üzerinde root yetkisine sahip olunan bir Ubuntu makinesi.
Senaryoda amaç, saldırgan bakış açısıyla önce hedef üzerindeki NFS servisini keşfetmek, ardından yanlış yapılandırılmış (no_root_squash ve insecure) paylaşımı tespit edip bunu istismar ederek, sunucu üzerindeki düşük yetkili bir kullanıcı konumundan root yetkisine yükselmektir.
9.2. Keşif
Öncelikle saldırgan gözüyle bir keşif yapalım.
Aynı ağda bulunduğumuz hedef cihazın dışarıya açtığı bir NFS paylaşımı olup olmadığını kontrol etmek için showmount -e 172.21.27.84 komutunu çalıştırıyoruz. Çıktıda /srv/nfs/share dizininin herkese açık (*) şekilde paylaşıldığını tespit ediyoruz.
Bu paylaşıma erişmek amacıyla kendi cihazımızda /mnt/kurban_share adında bir dizin oluşturup hedef paylaşımı buraya mount ediyoruz. Dizin içeriğini kontrol ettiğimizde boş olduğunu görüyoruz. Ardından hedef sistemin root yetkilerimizi nasıl ele alacağını test etmek üzere touch test komutuyla ilk dosyamızı atıyoruz.
9.3. Zafiyetin Doğrulanması
Hedef sunucudaki /etc/exports konfigürasyon dosyasını doğrudan okuma yetkimiz olmadığı için zafiyeti davranışsal olarak analiz ediyoruz. Kendi sistemimizde root yetkisiyle touch test komutunu çalıştırdıktan sonra ls -la ile dizin içeriğini kontrol ediyoruz. Oluşturduğumuz dosyanın sahipliğinin kısıtlanmayarak root:root olarak kaldığını gördüğümüzde, paylaşımda no_root_squash zafiyetinin aktif olduğunu kesinleştiriyoruz.
Zafiyeti doğruladıktan sonra yetki yükseltme aşamasına geçiyoruz. İlk olarak test amacıyla oluşturduğumuz test dosyasını siliyoruz. Ardından kendi makinemizdeki /bin/bash kabuğunu paylaşımlı dizine rootbash adıyla kopyalıyoruz.
Dosya sahibini root:root olarak ayarlayıp chmod 4755 komutuyla dosyaya SUID (Set User ID) bitini tanımlıyoruz. ls -la çıktısında dosya yetkilerinin -rwsr-xr-x şeklinde değiştiğini ve SUID bitinin aktifleştiğini doğruluyoruz. Bu sayede hedef sunucudaki her kullanıcı bu dosyayı root yetkisiyle çalıştırabilecektir.
Hedef sunucuya düşük yetkili lowpriv kullanıcısı ile erişim sağladıktan sonra paylaşımlı dizine (/srv/nfs/share) geçiyoruz. ls -la komutuyla dizini incelediğimizde, saldırgan makineden yüklenen ve SUID biti atanmış olan rootbash dosyasının burada yer aldığını görüyoruz.
Root shell'i tetiklemek için ./rootbash -p komutunu çalıştırıyoruz; -p (privileged) parametresi burada kritik bir rol oynar, çünkü bash SUID ile çalıştırıldığında bu parametre verilmezse euid'ini gerçek gid'ine eşitleyerek SUID bitini kendiliğinden devre dışı bırakır. Ardından whoami ve id komutlarıyla yetkilerimizi kontrol ettiğimizde, euid=0(root) yetkisine eriştiğimizi ve hedef sunucuda root kullanıcısına başarıyla yükseldiğimizi doğruluyoruz.
9.4. Kök Neden Analizi
İstismarın ardından hedef sunucuda /etc/exports dosyası incelendiğinde kök neden netleşmektedir. Yapılandırmada hem no_root_squash hem de insecure parametresi birlikte tanımlanmıştır: no_root_squash istemcinin root yetkilerini kısıtlamadığı için dışarıdan SUID biti atanmış zararlı binary yüklenmesine imkân sağlamış, insecure ise bu isteklerin privileged port zorunluluğu olmadan kabul edilmesine izin vererek saldırı yüzeyini daha da genişletmiştir. İki yanlış yapılandırmanın bir araya gelmesi, sunucuda root yetkisi elde edilmesini mümkün kılmıştır. Bu senaryoda saldırgan zaten kendi makinesinde root olduğundan, istekler doğal olarak privileged porttan (1024 altı) gönderilir ve insecure olmasa da saldırı mümkündür; insecure burada saldırı yüzeyini, root olmayan istemcilerin de yüksek porttan sahte istek göndererek bu zafiyeti istismar edebilmesini sağlayacak şekilde genişletir.
9.5. Sıkılaştırma (Hardening)
Zafiyetli yapılandırmayı düzeltmek ve sistemi güvenli hale getirmek için /etc/exports dosyasındaki ayarı şu şekilde güncelliyoruz:
/srv/nfs/share 172.21.27.0/24(rw,root_squash,secure,sync,no_subtree_check)root_squash: İstemcideki root isteklerini sunucuda yetkisiz nobody kullanıcısına düşürür. SUID injection ile yetki yükseltmeyi tamamen engeller.
172.21.27.0/24: Wildcard (*) kaldırılmıştır; paylaşım sadece belirtilen IP bloğuna sınırlandırılır.
secure: Bağlantıların yalnızca güvenli (1024 altı) portlardan gelmesini zorunlu kılar, sahte istekleri önler.
Sunucu tarafındaki bu düzeltme tek başına yeterlidir, ancak derinlemesine savunma (defense in depth) açısından istemci tarafında da bir katman eklenmelidir: paylaşımın istemcide mount -o nosuid seçeneğiyle mount edilmesi, root_squash herhangi bir nedenle atlatılsa veya yanlışlıkla devre dışı bırakılsa bile, paylaşım üzerinden gelen SUID/SGID bitlerinin işletim sistemi tarafından yok sayılmasını sağlar. İki katmanın (sunucuda root_squash, istemcide nosuid) birlikte uygulanması, tek bir yapılandırma hatasının tüm zinciri tekrar açık hale getirmesini engeller.
10. Özet
Bu çalışmada, NFSv3 protokolündeki no_root_squash ve wildcard (*) kaynaklı yanlış yapılandırmaların doğurduğu güvenlik riskleri ele alınmıştır. Saldırganın istemci tarafındaki root yetkisini paylaşımlı dizine SUID biti verilmiş bir kabuk (rootbash) enjekte etmek için kullanabileceği ve hedef sunucudaki düşük yetkili bir kullanıcı üzerinden tam root yetkisine yükselebileceği (Privilege Escalation) uygulamalı olarak gösterilmiştir. Zafiyeti engellemek için NFS paylaşımlarında varsayılan olarak root_squash kullanılmalı ve erişimler sadece yetkili IP bloklarıyla kısıtlanmalıdır.