Microsoft iç uygulamalara erişim için Entra OAuth'un kötüye kullanımı

• Araştırmacılar, Entra OAuth'ta onay ve yetki devri sürecini kötüye kullanarak Microsoft iç uygulamalarına erişim mümkün olabileceğini doğruladı
• Bu zafiyet, kurum içi sistem koruması için yeni bir tehdit olup dış kullanıcıların iç servislere erişim kanalı edinebileceğini göstermektedir
• Temel onay mekanizması ve yetersiz izin ayarları, sorunun ana nedeni olarak öne çıkıyor
• Çalışma bulguları, mevcut güvenlik kontrollerinin yalnızca OAuth onay isteği ve erişim kontrolüne karşı yeterli olmadığını ortaya koyuyor
• Şirketler ve kuruluşlar, OAuth onay ve izin yönetimini güçlendirmenin önemini teyit ediyor

---

Araştırma Özeti ve Arka Plan

• Microsoft Entra OAuth, kullanıcının onayıyla farklı uygulamaların farklı hizmetlere erişim yetkisi kazandığı bir kimlik doğrulama/ yetkilendirme çerçevesidir
• Araştırmacılar, hedef ortamda normalde yalnızca dahili olarak erişilebilen Microsoft uygulamalarının, belirli bir onay ve yetki devri senaryosu kötüye kullanıldığında dışarıdan da erişilebildiğini tespit etti

Kök Neden Analizi

• Zafiyet, OAuth onay isteği sürecinin kötüye kullanılmasından kaynaklanıyor
• Uygulama doğru şekilde sınırlandırılmadığında, saldırgan kullanıcı onayını tetikleyerek iç kaynak token'ını elde edebiliyor
• Varsayılan sunulan onay ve yetkilendirme mekanizması yeterince ayrıntılı olmadığından, bazı dahili servisler dışa açılma riski taşıyor

Etki ve Riskler

• Kötü niyetli bir kullanıcı bu zafiyetten yararlanarak Microsoft iç sistemlerine ve uygulamalara erişebilir
• Erişim sağlandığında duyarlı veri sızıntısı veya iç işlevlerin kötüye kullanılma riski oluşur

Yanıt ve Öneriler

• Kuruluşlar OAuth yönetim çerçevesini yeniden değerlendirmeli ve tüm onay ve yetki atama akışlarını sıkı bir şekilde kontrol altına almalıdır
• En az ayrıcalık ilkesi temel alınarak, onaylanan kaynaklar ve izin kapsamları net biçimde sınırlandırılmalıdır
• Düzenli olarak OAuth uygulama denetimi ve onay yönetimi süreçlerini kurarak yönetimi güçlendirmek gereklidir

[GN⁺]

Hacker News Yorumu

• Microsoft belgeleri gerçekten bir kabus; bir güvenlik açığı olmasının hiç şaşırtıcı olmaması normal
  Yakın zamanda Entra ID ile SSO oturum açma kurdum; (en azından tek kiracı olduğu için iyi oldu) erişim belirtecinin doğru kapsamını ve ek alanların geri dönmesini ayarlayana kadar neredeyse rastgele denemeler yapmak zorunda kaldım
  Başlangıç kılavuzu ararken sayısız alt sayfaya gidiyor, içinde Microsoft’a özgü anlaşılması zor terimler ve işe yaramayan doküman linkleriyle karşılaşıyorsunuz

• Bu durumun şaşırtıcı olmaması normal
  Entra'nın OAuth2 ayarları ve dökümanları tamamen dağınık
  O kadar karmaşık ki Microsoft'un kendisinin bile düzgün çalıştıramayacağı açık
  Bu soruna verdikleri çözüm “daha fazla doküman” eklemek; fakat halihazırdaki spagetti gibi dokümanlar bile okumaya zor

  • Bunu birkaç hafta önce yaşadım
    Resmi dokümantasyonda, birden fazla kaynak sunucuyu hedef alan kapsamlarla authorization code flow çalıştırılamayacağı yazıyor
    Ama openid $clientid/.default istediğinizde çalışıyor
    Akışın sonunda ID token ve access token alıyorsunuz; ID token OIDC kapsamının uygulandığını gösteriyor
    Fakat access token'da scope'ta openid eksik
    Bu yüzden Microsoft Graph'ı (UserInfo endpoint rolü) çağırmak gerçekten mümkün olmuyor
    Neden böyle davrandıklarına dair doğru bir açıklama bulamadım

• Çok kiracılı uygulama yetkilendirmesi beklenmedik sorunlar üretmeye devam ediyor
  Ben Microsoft'ta Wiz araştırma sonuçlarına göre uygulanmış bir yama üzerinde çalışan (işten ayrılmış) bir PM'im
  Bir düzeltme önerisinde, çok kiracılı uygulama yetkilendirmesinde “iss” veya “tid” claim'lerini kontrol edin denmiş
  Gerçek öneri bundan biraz daha karmaşık
  Yalnızca kiracı doğrulanırsa, herhangi bir service principal'e yetkili erişim kazandırılabilir
  Token için kiracıya ek olarak her zaman subject de doğrulanmalı
  Örneğin tid+oid kombinasyonu ile token doğrulaması yapmak veya yetkilendirme öncesi hem kiracı hem subject için koşulları kontrol etmek lazım
  Detaylar claims validation resmi belgesinde bulunuyor

  • Tüm token'ların sahte olduğu varsayımıyla yaklaşımı vurguluyorum
    Varsayılan olarak daima güvenli şekilde tasarlanmalı
    CPU harcansa da her alan tamamen doğrulanmalı
    İmza, doğrulama yapılmadıkça anlam ifade etmez
    Mümkünse kimlik veritabanıyla da karşılaştırmalı doğrulama önerilir
    Kiracı, kullanıcı, grup, kaynak gibi her şeyin onaydan önce dikkatlice doğrulanması gerektiğini geliştiricilere öğrettik

  • Kesinlikle doğru
    Aslında mühendislerin resmi kılavuzu mutlaka okuması gerekiyor
    İlgili kılavuz buradan bakılabilir

  • “Kontrol edilmesi gereken şeyler için açık bir kılavuz”un net olup olmadığını da merak ediyorum
    Eskiden bunun Yes/No diye basitleştirilmesi gerektiğini düşünürdüm
    Bir sistemde “Bu gruptaki kullanıcılar herkesin kişisel notlarını okuyabilsin mi?” gibi bir onay kutusu varlığını hiç duymadım

• Entra'nın karmaşıklığını bir kenara bırakırsak da, özellikle Microsoft içinde desteklenmesi gereken çok sayıda kiracıyla 3P müşteri kiracılarının karışık şekilde bir arada olması hataları fark etmeyi zorlaştırıyor
  Ondan da daha kötü olan, güvenliğin tek bir “kimlik doğrulama token'ı”yla çözülebileceğine inanılması
  Böyle bir site en baştan internete açılmamalıydı (şimdi kamusal olarak erişilebilir değil)
  Ağ güvenliği gerçekten geri plana atılsa da en etkili savunma aracıdır

  • Ağ güvenliği de sadece savunmanın bir katmanı
    Asıl mesele savunmayı katmanlı kurmaktır (defense-in-depth yaklaşımı)

• Bize bulutun daha güvenli olduğu, şirket içinde çalıştırılan her şeyin daha tehlikesiz olduğu ve kendi operasyon ekibi tutma yükünün yalnızca aptallara ait olduğu söylenmişti
  O kadar eskiyim ki, iç Microsoft için uygulama dışarıdan erişilebilir olmasını hala anlamıyorum

  • Son 10 yıldır Google'da “Zero Trust” dediğimiz şeyin başlangıcından bu yana VPN'ler tamamen bırakılma eğiliminde
    Artık sadece VPN'e girebilen herkesin kritik veriye erişmesini engellemek çok zor
    Bu yüzden bugün “iç” servisler bile dışarıya açılıyor; her seviyede permission yönetimi şart
    Bu, bir saldırganın birden çok hizmete aynı seferde sızmasını çok daha zorlaştırıyor
    Zero Trust kavramına giriş

  • Bence asıl sorun, uygulamanın ortak ağa açık olması (yani intranet olmaması) değil
    Asıl sorun, bu tür bir uygulamanın (Entra ID) çok kiracılı olması
    Kritik kimlik bilgileri birçok kiracıyla (kötü niyetli saldırganlar da dahil) aynı veritabanında tutulup paylaşılıyor
    Bu yüzden çok kiracılık ihlalleri sıkça görülüyor
    Entra ID'nin tenant kontrolü ne kadar güçlü olursa olsun zafiyetler kalır
    Örneğin blogdaki gibi iki ve üzeri kiracıya yayılan istekler (çok kiracılı istekler) zaten yetkilendirmeyi çok zorlaştırıyor, küçük bir hata tüm riski tetikleyebilir
    Tek kiracılı uygulamalarla karşılaştırınca, saldırganın mutlak surette o kiracının kullanıcısı olması gerektiği için önceden yetki ele geçirme saldırısı çok daha zorlaşır

  • “Buluta geçin, daha güvenli, kendi operasyon ekibinizi tutmanıza gerek yok” söylemi çok yaygın olsa da
    asıl mesele, blogdaki örnekte de görüldüğü gibi, kaynak sunucu yetkilendirmesiyle uğraşan geliştiricilerin token içindeki issuer, audience, subject gibi temel claim'leri bile kontrol etmemesi
    Bu hata intranette dahi tekrarlanırsa hiçbir fark yaratmaz
    Sonuçta mesele bulut mu, kendi sunucu mu değil; güvenlik doğası gereği zor ve gerçek olaylar yaşanmadan iyileştirme döngüsü düzgün çalışmıyor
    İnternet değil de intranet veya VPN'e taşımakla bu güvenlik eksiklikleri kaybolmuyor

  • “Defence in depth” (çok katmanlı savunma) artık modası geçti mi?

  • Çoğu şirket için kendi sunucularını işletmek hâlâ iyi bir öneri
    Üç eyalette en iyi çatı kaplama firması olsanız bile web sitenizi, e-postanızı ve rezervasyon sisteminizi tamamen onlara bırakmak istemezsiniz
    Bu forumdaki biri sunucu kurup yönetebilir ama bu “ortalama kullanıcı” için değil

• Windows build sunucusunda RCE zafiyeti bulunup da ödülün 0$ olması saçma
  Gerçek bir zero-day değil de sadece yapılandırma sorunuysa bile, arka kapı bir DLL ile build ortamı kirletilebiliyorsa tüm dünyada büyük bir felaket olabilir

  • Ben Microsoft'un Windows build mühendisiydim
    Bu build aracı yönetim arayüzüne aşina değilim (işten ayrıldıktan sonra eklenmiş olabilir), gerçek bir uzak kod çalıştırma (RCE) için tasarlanmış bir UI olduğunu düşünmüyorum
    Her zaman NuGet'ten paket alınır; görünen o ki her paketi ve kaynağı seçebilirsiniz ama gerçekte dahili Microsoft NuGet feed ile sınırlandıran bir allowlist vardı
    NuGet paket kontrolü Windows mühendislik ekibinde bizim için çok kritik bir konuydu
    Dışarıdaki açık NuGet paketleri tamamen yasaktı; gerektiğinde yeniden paketleyip iç kaynaktan yayınlananları kullanmaya zorlanıyorduk

• Microsoft çok iyi insan barındırsa da, son dönemde master key sızıntısı, mühendislerin PR'de GPT'den kod istemesi ve CEO'nun backend mühendisin kalmayacağını söylemesi düşünüldüğünde
  bu şirkete güvenmem
  Elbette çoğu kişinin başka seçeneği yok
  Yine de orada kalmak biraz sorumsuzluk olur

  • “Mühendislerin PR'de GPT'den feature request istemesi” nedir tam olarak
    Acaba dotnet/runtime mi

• Düşüncem çok basit
  Entra*(Azure AD gibi isim değişse de fark etmez) AuthZ (yetkilendirme) için kullanılmamalı
  AuthN (kimlik doğrulama) için uygundur ama yetkilendirme doğrudan uygulanmalı
  Yetkilendirmeyi sadece siz uyguladığınızda bu tür sorunları kolayca atlarsınız
  *- İsimlerin neden değiştiğini bilmiyorum. Sanki Microsoft yönetiminde “İsmi değiştirirsem var olurum” tarzında bir mottosu olan biri varmış gibi

  • “Azure AD” adı, yalnızca Azure'da AD barındırıldığını düşündürüyor
    Oysa artık bunun çok ötesi var

  • Entra ile AuthZ uygulaması aslında mümkün
    “Bu uygulamaya kullanıcıları zorunlu olarak atayın” kutusunu işaretleyip doğrudan atama yapılır [1]
    Ama bu Entra'nın sunduğu tek AuthZ özelliğidir
    AuthZ'i etkinleştirmezseniz, Entra'nın yetkilendirme yönetimini otomatik yapacağını varsaymak yanlış
    Basit “izin ver/engelle” modeli yalnızca tüm kullanıcıların aynı yetkiye sahip olduğu çok basit uygulamalarda anlamlı
    Genelde karmaşık uygulamalarda kullanıcılar farklı erişim seviyelerine sahip olur, bu yüzden gerçek yetkilendirme uygulama içinde yapılmalıdır
    [1] Yönetim portalında kullanıcı/grup erişimi atama

• Bu durumdaki asıl problem, Entra ID çok kiracılı uygulamalarda belirli kiracıları blacklist/whitelist edememek
  Üstelik MSAL, tarayıcı uzantıları gibi yapılarda çalışmadığı için kullanıcılar Entra ID ile konuşurken ek güvenlik önlemlerini kendileri kodlamak zorunda kalıyor
  Bu yüzden bu tür sorunların gelmesi doğal

  • Entra ID'de çok kiracılı uygulamalarda belirli kiracıları allow/deny edememek gerçekten can sıkıcı
    “Bu uygulama yalnızca şunlar kadar kiracıya açık olsun” seçeneği olsa iyi olurdu ama şuan sadece “benim kiracım” veya “Azure'daki tüm kiracılar” seçeneği var
    Benim workaround'ım, uygulamayı “tek kiracıya özel” kurup diğer kiracı kullanıcılarını kiracıma davet etmek
    Yoksa “tüm kiracıları açık” bırakıp gerçek kullanıcıları gruplar üzerinden yönetmek
    Bu kısıtın teknik bir gereklilikten mi, yoksa önemli bir müşterinin bunu istemediği için mi olduğundan bilmiyorum

• Azure gerçekten bir kaos
  Okta'nın da sorunları var ama, belgeleri çok daha iyi; pahalı olmasına rağmen güvenliği Azure servisleriyle karıştırmadan tamamen ayrı yönetebiliyorsunuz
  Buna değdiğini düşünüyorum