Kaçış ve kalıcılık

Bir konteynerin içinde root olmak, ana makinede root olmak değildir. Bu ayrım bu dersin kalbidir.

Konteyner bir güvenlik duvarı değil, bir yalıtım katmanıdır ve yanlış yapılandırılınca delinir. Kalıcılık ise ayrı bir konudur: testin ertesi gün de sürebilmesi için kurulan, denetimli ve kayıtlı bir erişim. İki konu da aynı disiplini ister: önce ortamı doğru oku, sonra bulduğun yetkiyi ait olduğu katmanla sınırlı tut.

Konteyner yalıtımı iki mekanizmayla kurulur. Ad alanları süreçleri, ağı ve dosya sistemini ayırır; konteyner yalnız kendi parçasını görür. Yetenek listesi ise konteyner içindeki root'un yapabileceklerini kısar. Sanal makineden farkı buradadır.

Sanal makinede ayrı bir çekirdek çalışır ve kaçış çok zordur. Konteynerde çekirdek ana makineyle ortaktır. Yalıtım yapılandırmaya bağlıdır, dolayısıyla hata payı daha yüksektir. Çekirdekteki bir hata da her iki tarafı birden etkiler, çünkü ikisi aynı çekirdeği paylaşır.

Kaçış, bu mekanizmalardaki bir gevşeklikten doğar. Ayrıcalıklı modda çalışan bir konteyner, neredeyse tam çekirdek yetkisi alır. Yetenek kısıtı kalkar, ana makine aygıtları görünür hale gelir. Bu mod genelde donanıma erişmesi gereken tek bir servis için açılır.

Sorun, kopyalanan şablonlarda bu satırın sessizce başka servislere de taşınmasıdır. docker-compose dosyasındaki tek bir satır, kurulan bütün yalıtımı baştan kaldırır. O tek satır, konteyneri ana makineyle neredeyse eşit yetkiye taşır.

Bağlanmış birimler ikinci büyük gevşekliktir. Ana makinenin kök dizini ya da konteyner yönetim soketi konteynere bağlanmışsa, yalıtım zaten yoktur. Yönetim soketine erişen bir konteyner, ana makinede yeni ve ayrıcalıklı bir konteyner başlatıp bütün dosya sistemini okuyabilir. Bu yapılandırmalar kolaylık için kurulur, bir hata ayıklama turundan kalır ve üretimde unutulur.

Yapılandırma dosyasını okumak bu satırları ilk bakışta gösterir. Bu yüzden denetim, bir kaçış denemesinden önce her zaman yapılandırma dosyasını okur.

Ayrıcalıklı modun neden bu kadar tehlikeli olduğunu anlamak önemlidir. Normal bir konteynerde yetenek listesi kısadır ve ana makinenin aygıtları görünmez. Ayrıcalıklı mod açıldığında bu iki koruma birden kalkar.

Konteyner artık ana makinenin disklerini görür, çekirdek modülü yükleyebilir ve dosya sistemini bağlayabilir. Bu da ana makinenin kök diskini konteyner içinden bağlayıp okumaya ya da yazmaya kadar gider. Yani ayrıcalıklı bir konteynerde root olmak, çoğu durumda ana makinede root olmaya giden kısa bir adımdır. Bu yüzden bu mod bir aday değil, doğrudan yüksek önemli bir bulgudur.

Gerçek hayatta bu yapılandırmalar çoğu zaman geliştirme kolaylığından sızar. Bir ekip bir aracı hızlı çalıştırmak için ayrıcalıklı modu açar ve sonra kapatmayı unutur. Bir başka ekip hata ayıklamak için yönetim soketini konteynere bağlar ve o satır üretim şablonuna taşınır.

Bir bulut platformunda bu tür tek bir yanlış yapılandırma, bütün düğümdeki konteynerleri birbirine açabilir. Denetimde bu satırları aramak, uzun bir kaçış denemesinden çok daha hızlı ve kesin sonuç verir.

Kalıcılık konusuna gelelim. Yetkili bir testte kalıcılık, erişimi gizlice korumak için değil, çok günlük bir senaryoyu sürdürmek için kurulur. Müşteri bunu kapsamda onaylar ve yöntem yazılı olarak bildirilir.

Amaç, mavi takımın tepkisini ölçmek ve gerçek bir saldırganın kalıcılığını taklit etmektir; ortamda sahipsiz bir arka kapı bırakmak değil. Kalıcılık kurmadan önce bu iki koşulun sağlandığından emin olursun. Onaysız bir kalıcılık, testi bir saldırıdan ayıran çizgiyi siler.

Yöntem seçerken gürültü düzeyini düşün. Yeni bir yerel yönetici hesabı açmak izleme panelinde hemen görünür. Güvenlik duvarını kapatmak da aynı ölçüde dikkat çeker.

Var olan bir servisin komutunu değiştirmek ya da bir anahtar dosyasına satır eklemek daha sessizdir, çünkü meşru yapıya yaslanır. Kırmızı takım tatbikatında bu fark, mavi takımın ne kadar hızlı yakaladığını ölçen asıl sınavdır. Sessiz yöntem, savunmanın körlüğünü ortaya çıkarır.

Kalıcılık yöntemleri ortama göre değişir. Linux'ta authorized_keys dosyasına bir anahtar eklemek, bir cron görevine satır koymak ya da bir servis birimini değiştirmek yaygın yollardır.

Windows'ta zamanlanmış görev, çalıştırma kaydı ya da bir servis aynı işi görür. Konteynerde ise imajın kendisine ya da başlangıç betiğine dokunmak gerekir, çünkü konteyner yeniden oluşturulunca dosya sistemi sıfırlanır ve diske yazdığın her şey silinir. Hangi yöntemi seçersen seç, onu kayıt altına alır ve test sonunda geri alırsın.

Gürültü düzeyini seçmek tek başına yetmez; seçimini belgelersin. Hangi yöntemi, hangi makinede ve hangi saatte kullandığını yazarsın. Bu kayıt hem mavi takımın tespitini doğrular hem test sonunda temizliği kolaylaştırır.

Sessiz bir yöntem seçtiysen bile bir iz bırakırsın; fark yalnız o izin ne kadar göze battığındadır. Kırmızı takımın değeri, gürültüsüz kalmakta değil, bıraktığı her izi hesaba katıp kayda geçirebilmekte durur. İzi olmayan bir kalıcılık, test sonunda temizlenemeyen bir risk demektir.

Yanlış yerde saldırı denemesi hem zaman kaybettirir hem gereksiz gürültü üretir. Bu yüzden ilk iş, bulunduğun yerin bir konteyner olup olmadığını anlamaktır. Birkaç satırlık komut bunu dakikada söyler.

Ortamı tanımadan atılan her adım raporu da yanıltır. Konteyner ile ana makineyi karıştırmak, bu dersteki en pahalı hatadır. Birkaç satırlık tanı komutu, bu hatayı daha ilk dakikada önler ve sonraki adımları doğru atmanı kolaylaştırır.

# Konteyner icinde miyim?
$ ls -la /.dockerenv
$ grep -E 'docker|containerd' /proc/1/cgroup

# Riskli yapilandirma gostergeleri
$ capsh --print | grep sys_admin
$ ls -l /var/run/docker.sock

Dört satır dört ayrı soruyu yanıtlar. /.dockerenv dosyasının varlığı, çalıştığın yerin bir Docker konteyneri olduğuna işaret eder.

İkinci komut ilk sürecin cgroup kaydında docker ya da containerd izini arar; bu iz ortamı doğrular. capsh çıktısındaki sys_admin satırı, geniş sistem yönetimi yeteneğinin açık kaldığını gösterir ve kaçış olasılığını doğrudan artırır. Son komut, yönetim soketinin konteynerden erişilebilir olup olmadığını söyler. Gerçek bir denetimde bu dört satır ilk dakikada çalışır ve haritanın iskeletini kurar.

Bir ayrıntıya dikkat et. uname komutu konteynerde de ana makinenin çekirdeğini gösterir, çünkü çekirdek ortaktır. Yani farklı bir çekirdek sürümü beklersen yanılırsın. Buna karşılık kısa ve onaltılık bir makine adı, çoğu konteynerin tipik izidir.

Yetenek listesi de kaçış olasılığını belirler: geniş sistem yönetimi yeteneği açıksa dosya sistemi bağlama ve aygıt erişimi mümkün olur. Yalnız gerekli yetenekleri bırakmak, ayrıcalıklı moddan kaçınmanın karşılığıdır.

cgroup kaydı tek başına da güçlü bir göstergedir. İlk sürecin, yani PID 1'in cgroup dosyasını okumak çoğu zaman yeter. Ana makinede bu satır kök cgroup yolunu gösterir; konteynerde ise yol içinde docker ya da containerd geçer.

Tek bir komutla ortamın hangi katman olduğunu doğrularsın. Bu komut, ortam hakkındaki ilk kesin yanıtı verir ve sonraki kararları yönlendirir. Doğru okunan bir ortam, boşa harcanacak onlarca denemeyi baştan eler.

Bulut ortamında kaçışın karşılığı çoğu zaman kimlik yükseltmesidir. Konteynere bağlı bir servis kimliği geniş yetkiye sahipse, çekirdek düzeyinde kaçmaya gerek kalmaz. Konteyner, bulut sağlayıcının üstveri adresinden geçici kimlik bilgisi çeker. Bu kimlik aşırı geniş bir politikaya bağlıysa, saldırgan onu kullanarak depolama kovalarını okur ya da yeni kaynaklar açar.

Yetki politikalarını okumak, çekirdek açığı aramaktan çok daha kısa bir yoldur. Bir bulut denetiminde çoğu yükseltme, çekirdekte değil, aşırı geniş bir izin politikasında saklıdır.

Bulut üstveri adresi bu yolun kalbindedir. Konteynerin içinden erişilebilen bu adres, düğüme ya da iş yüküne bağlı geçici kimlik bilgilerini döndürür. Saldırgan, bu kimliğin hangi izinlere sahip olduğunu birkaç sorguyla ortaya çıkarır.

İzinler dar yazılmışsa yol kapanır; geniş yazılmışsa saldırgan bulut hesabının büyük bölümünü dolaşır. Modern platformlar bu adrese erişimi kısıtlayan bir koruma sunar, ama bu koruma çoğu zaman kapalı bırakılır. Denetimde önce bu korumanın açık olup olmadığını kontrol edersin.

En sık hata, konteynerde bulunan yetkiyi ana makineyi ele geçirmiş gibi raporlamaktır. Bir konteynerde root olan kişi, kolayca ana makineyi de aldığını sanır. Doğru terminoloji, bulunan yetkiyi ait olduğu katmanla sınırlı tutar.

Konteyner içinde elde edilen yetki ayrı bulgudur, ana makinede elde edilen yetki ayrı. İkisini aynı cümlede yazmak etkiyi yanlış gösterir ve okuyucuyu yanıltır. Raporun değeri de bu ayrımı doğru koymaktan gelir.

Savunma listesi nettir. Ayrıcalıklı mod yerine yalnız gereken dar yetenek seti verilir. Yönetim soketi konteynere asla bağlanmaz. authorized_keys dosyaları ve servis birim dosyaları bütünlük açısından izlenir.

Yeni hesap oluşturma olayı uyarı üretir. Bulut tarafında konteyner kimliklerine en az yetki ilkesi uygulanır. Kalıcılık yalnız kapsamda yazılıysa kurulur ve her iz kaydedilip test sonunda temizlenir. Mavi taraf için bu liste doğrudan bir izleme kuralı setine döner.

Bu modülün sonunda elinde iki liste olur. Birincisi elde ettiğin erişimler, ikincisi bıraktığın izler. Birinci liste raporun bulgu bölümünü, ikinci liste temizlik bölümünü besler.

İkinci listeyi eksiksiz tutmak, testin en çok unutulan sorumluluğudur. Tespit tarafını da rapora eklersin: kullandığın yöntem hangi kayıt satırını üretti? Bunu yazarsan mavi takım aynı davranışı yakalayan kuralı hemen çıkarır. Kırmızı takımın asıl ürünü, açılan kapı değil, o kapıyı bir daha kapatan kuraldır.