Yetki yükseltme yolları

Klasik sistemlerde yetki yükseltme bir zafiyetten geçer: yamasız bir çekirdek, hatalı bir setuid ikili. Bulutta ise çoğu zaman hiçbir açık yoktur. Politikalar tam da yazıldığı gibi çalışır ve sonuç yine yönetici yetkisidir.

Buluttaki yükseltmeyi öğrenmenin en şaşırtıcı tarafı da budur: aradığın şey bir hata değil, birbirine masum görünen izinlerin birleşimidir. Bu derste yükseltmenin neden politika birleşiminden çıktığını, en bilinen yolları ve bunları denemeden nasıl görüp savunacağını öğreneceksin.

Bulutta yükseltmenin kaynağı bir hata değil, bir birleşimdir. Bazı IAM eylemleri kendi başına zararsız görünür ama yan yana geldiğinde yeni yetki üretir.

Politika yazan kişi eylemlere tek tek bakar ve her birini masum bulur; bir fonksiyon açmak masumdur, bir servise rol atamak masumdur. Saldırgan ise birleşime bakar ve iki masum iznin, çok daha büyük bir üçüncü yetki doğurduğunu görür. Bu yüzden bir politikayı denetlerken tek tek satırlara değil, o satırların birlikte neye yol açtığına bakmak gerekir.

En bilinen örnek iam:PassRole eylemidir. Bir servise rol takabilme yetkisi verir.

Tek başına bir şey yapmaz, çünkü yalnız rol takmak bir iş görmez. Ama fonksiyon açma ya da sanal makine başlatma yetkisiyle birleşince tablo değişir: artık istediğin rolü istediğin servise taktırabilir ve o servisi çalıştırabilirsin. Servis de o rolün yetkileriyle koşar. Yani düşük yetkili bir kimlik, hesaptaki yüksek yetkili bir rolü bir aracıya taktırarak dolaylı yoldan o yetkilere kavuşur.

Zinciri görselleştirmek anlaşılmasını kolaylaştırır. Aşağıdaki şema, dar yetkili bir kimliğin PassRole ile başlayıp yönetici rolüne nasıl ulaştığını adım adım gösterir. Adımlar normal servis çağrılarını kullanır; ancak kayıt altına alınabilir ve alarm üretebilir. Risk, izinlerin birlikte verdiği yetkidedir.

Şemayı okurken sırayı değil, hangi iznin hangi izinle birleştiğini takip et. Zincirin kırılacağı yer, iki izinden birinin kaynak koşuluyla daraltıldığı noktadır. Savunma da zaten tam bu noktayı arar: tek bir koşul, koca zinciri işlemez hale getirir.

Zinciri adım adım görelim. Kimliğin lambda:CreateFunction ve iam:PassRole izinleri var; kaynak alanı yıldızla geniş tutulmuş. Aynı hesaptaki rolün güven politikası da Lambda servisine izin veriyorsa kimlik bu rolü yeni fonksiyona atayabilir. Zincirin tamamlanması için fonksiyonu çalıştırabilmesi de gerekir.

Fonksiyon oluşturma çağrısı CloudTrail kaydında görülebilir. Bir tespit kuralı, beklenmeyen rol atamasını alarm yapabilir. Geniş kaynak izni rol seçimini artırır; güven politikası ve diğer izin sınırları yine geçerlidir.

Fonksiyon çalıştığında yönetici rolünün geçici anahtarlarıyla çalışır. Artık yeni kullanıcı açmak, politika bağlamak ya da veri okumak mümkündür. Hiçbir adımda bir yazılım açığı kullanılmadı; kimlik kendisine verilen izinleri birleştirdi. Sonuç, dar yetkili görünen bir kimliğin hesabın yöneticisine dönüşmesidir.

Buluttaki yükseltmenin özü budur: kod değil, yetki yapılandırması istismar edilir. Savunma da bu yüzden koda değil, izin birleşimine bakar; hangi kimliğin hangi iki izni bir araya getirebildiğini sorar.

Bir ayrıntı tespiti zorlaştırır: iam:PassRole bir arayüz çağrısı değildir, bir izindir. Bu yüzden denetim kaydında kendi başına bir PassRole olayı görünmez ve onu tek başına aramak boş sonuç verir. Rolün hangi servise takıldığını görmek için, o servisi oluşturan çağrının kaydına bakman gerekir.

Bir fonksiyon oluşturulduğunda kayıt CreateFunction20150331 adıyla düşer ve requestParameters alanında hangi rolün geçtiğini yazar; makine başlatmada aynı iz RunInstances kaydında durur. Aşağıda bu kaydın sadeleştirilmiş bir örneği var.

{
  "eventName": "CreateFunction20150331",
  "userIdentity": { "arn": "arn:aws:iam::111122223333:user/laborant" },
  "requestParameters": {
    "functionName": "rapor-isleyici",
    "role": "arn:aws:iam::111122223333:role/yonetici-rol"
  }
}

Kaydı oku. eventName alanı CreateFunction20150331 biçimindedir; sondaki tarih sürüm bilgisidir ama yine de sıradan fonksiyon oluşturma çağrısını gösterir. userIdentity çağrıyı yapan dar yetkili kimliktir.

Asıl ipucu requestParameters içindeki role alanıdır: dar bir kimlik, adı yonetici-rol olan çok yetkili bir rolü bir fonksiyona takmış. Bir tespit kuralı tam bu eşleşmeyi arar: düşük yetkili bir kimliğin, kendi yetkisinin çok üstünde bir rolü bir servise taktığı an. PassRole'u tek başına aramak boş sonuç verir; CreateFunction ve RunInstances gibi kaynak oluşturan çağrıların taşıdığı rolü izlersin.

İkinci grup, IAM'in kendi yazma eylemleridir. Bunlar bir servise dokunmadan doğrudan yetki değiştirir. CreatePolicyVersion yeni bir sürüm üretip varsayılan yapar, böylece o politikaya bağlı herkesin yetkisi anında değişir.

AttachUserPolicy hazır bir yönetici politikasını doğrudan bağlar. UpdateAssumeRolePolicy bir rolün güven kapısını kendine açar ve o rolü üstlenebilir hale gelir. CreateAccessKey ve CreateLoginProfile ise başka bir kimliğe yeni bir giriş yolu ekler; anahtar ya da parola sende olduğundan o kimliğe bürünürsün.

IAM yazma eylemi              Kavramsal etki
CreatePolicyVersion           yeni surum varsayilan olur, bagli herkes degisir
SetDefaultPolicyVersion       var olan bir surumu varsayilan yapar
AttachUserPolicy              hazir yonetici politikasini dogrudan baglar
UpdateAssumeRolePolicy        rolun guven kapisini cagirana acar
CreateAccessKey               baska kimlige programatik anahtar ekler
CreateLoginProfile            baska kimlige konsol parolasi ekler

Üçüncü grup daha dolaylıdır. Bir sanal makine başlatma yetkisi, o makineye rol takma yetkisiyle birleşirse aynı sonuca çıkar.

Makineye bağlanmak bile gerekmez; kullanıcı verisi alanına yazılan bir betik açılışta çalışır ve makinenin rolüyle iş görür. Aynı kalıp farklı servislerde tekrar eder: rolü taşıyan yeni bir kaynak oluştur, sonra o kaynağı çalıştır. Konteyner görevleri, veri hattı işleri ve otomasyon şablonları da bu kalıbın birer örneğidir; hepsinde ortak nokta bir kaynağa rol atayıp o kaynağı çalıştırmaktır.

Bu iki grubu ayırt etmek denetimde hız kazandırır. Okuma eylemleri, örneğin bir kullanıcıyı ya da rolleri listelemek, yalnız keşif verir ve tek başına hiçbir yetki eklemez. Yazan, bağlayan ve rol taktıran eylemler ise yetki yapısını değiştirir.

Bir politikaya baktığında ilk ayıracağın şey budur: bu eylem bir şey öğrenir mi, yoksa bir şey değiştirir mi? Öğrenen eylemler tek başına tehlikesizdir ama bir yükseltme zincirinin keşif adımını besler; değiştiren eylemler ise zincirin asıl kırılma noktasıdır.

Yetkili bir testte bu yolları denemeden görmek mümkündür. Politika simülatörü, bir kimliğin belirli bir eylemi yapıp yapamayacağını gerçek çağrı atmadan söyler. Böylece hem gürültü çıkmaz hem de üretim ortamında bir değişiklik olmaz. Karar örtük ret çıkarsa o kapı kapalıdır; izin çıkarsa incelemen gereken bir yol vardır.

Simülatör kararı politikaları okuyarak verir ama canlı ortamın birebir kopyası değildir. SCP'leri hesaba katar, RCP'leri katmaz. VPC uç nokta politikası ve rol zinciri gibi durumlarda sonucu canlı ortamdan ayrılabilir.

Kendi laboratuvar hesabında ise zinciri uçtan uca kurmak öğreticidir. Dar bir kullanıcı açarsın, ona PassRole verirsin ve yükseltmenin kaç komutla olduğunu kendin görürsün. Aynı zinciri sonra bir koşul ekleyerek kırarsın.

Kırılan zincir, doğru düzeltmenin ne olduğunu somut biçimde gösterir; artık aynı komut çalışmaz ve neden çalışmadığını da bilirsin. Bu tatbikat, bir bulguyu yalnız okumaktan çok daha kalıcı bir anlayış bırakır.

Hesabın tamamındaki yolları görmek için haritalama araçları vardır. get-account-authorization-details komutu bütün kimlikleri ve politikaları tek komutla döker. PMapper bu veriden bir yetki grafiği çıkarır ve yönetici yetkisine giden yolları listeler.

Güvenli tatbikat için CloudGoat ya da Stratus Red Team gibi araçlar, kendi lab hesabında bilerek açık senaryolar kurup güvenle denemene yarar. Böylece gerçek bir sisteme dokunmadan, kontrollü bir ortamda hem zinciri kurar hem de kapatmayı öğrenirsin.

Savunma tarafında iki araç işe yarar. Birincisi yetki sınırıdır (permissions boundary): kimliğin ulaşabileceği en geniş yetkiyi tavandan kısar, kendi başına izin vermez. Bir geliştiriciye kullanıcı açma yetkisi verirken, açtığı kullanıcının yönetici olamamasını bu tavan güvenceye alır.

İkincisi organizasyon servis kontrol politikasıdır ve tüm hesabın üstünde durur. PassRole özelinde ise doğru düzeltme kaynağı daraltmaktır: rolü asla yıldızlı kaynakla verme, yalnız o servisin takabileceği rolleri yaz ve iam:PassedToService koşuluyla hangi servise takılabileceğini sınırla.

Bir de tespit tarafı var. Politika oluşturma, politika sürümü değiştirme, güven politikası güncelleme ve yeni kullanıcıya yönetici bağlama olayları uyarı üretmelidir. CreatePolicyVersion özellikle dikkat ister: yeni sürüm varsayılan yapıldığı anda o politikaya bağlı herkesin yetkisi değişir. Bu çağrılar meşru işlerde de olur, ama seyrek ve öngörülebilir zamanlarda; gündüz, bilinen bir kişinin elinden, bir değişiklik talebiyle birlikte.

Gece yarısı gelen bir UpdateAssumeRolePolicy ya da art arda gelen AttachUserPolicy çağrıları ise bakılması gereken izlerdir. İyi bir tespit kuralı, olağan dışı zamanı ve kaynağı yakalar.

Bulgu yazarken etkiyi net anlatmak da gerekir. Geniş politika başlığı kimseyi harekete geçirmez ve rapor bir kenarda bekler. Bu kimlik üç komutla hesabın yöneticisi olur cümlesi ise düzeltmeyi aynı hafta getirir.

Yetkili bir testte zinciri laboratuvar kopyasında kurup kanıt eklersin: hangi komutların çalıştığını ve sonuçta hangi yetkiye ulaşıldığını gösterirsin. Etki cümlesi bir yönetici için sayfalarca politika dökümünden daha ikna edicidir, çünkü riski iş diline çevirir.

Yükseltme yollarını kapatmak tek seferlik bir iş değildir. Yeni servisler yeni eylemler getirir ve bazıları rol takma ile çalıştırma kalıbını aynen tekrarlar. Bu yüzden politika kütüphanesi düzenli gözden geçirilir ve riskli eylem listesi güncellenir.

Ayrıca yeni bir servis hesaba girdiğinde, yetkisi dar bir şablondan başlar ve ihtiyaç kanıtlandıkça genişler. Böylece her yeni servis, en geniş değil en dar hâliyle hesaba girer ve yükseltme kapıları daha açılmadan kapanır.