Azure Entra ID oturum açma günlüklerini atlatan güvenlik açığının üçüncü ve dördüncü örnekleri açıklandı

 (trustedsec.com)
1 puan yazan GN⁺ 2026-03-22 | 1 yorum | WhatsApp'ta paylaş
  • 2023’ten bu yana toplam 4 adet Azure Entra ID oturum açma günlüğü atlatma açığı bulundu ve son iki tanesinin geçerli token üretilebilen kritik sorunlar olduğu doğrulandı
  • GraphGoblin, OAuth2 ROPC akışında scope parametresini tekrar tekrar girerek günlük oluşturulmasını atlatıyor; Graph**** ise 50 bin karakteri aşan bir User-Agent dizesiyle günlüklerin tamamen düşmesini engelliyor
  • Her iki açığın da nedeni olarak SQL sütun uzunluğunun aşılması nedeniyle loglamanın başarısız olması gösterildi; Microsoft, bildirimden sonra düzeltmeyi tamamladı
  • Microsoft bu sorunu “Orta (Medium)” seviyede sınıflandırdı ve ödül ya da resmî takdir olmadan sessizce düzeltti; CVSS’ye göre ise High (7.5~8.7 puan) seviyesinde değerlendiriliyor
  • Tekrarlanan girdi doğrulama hatalarından kaynaklanan kusurlar sürmeye devam ettiğinden, logların çapraz doğrulanması ve KQL tabanlı tespit kurallarının güçlendirilmesi güvenlik ekipleri için zorunlu bir görev olarak gösteriliyor

Azure Entra ID oturum açma günlüğü atlatma açıkları açıklandı

  • 2023’ten bu yana toplam 4 adet Azure Entra ID oturum açma günlüğü atlatma açığı bulundu
    • İlk iki örnekte yalnızca parolanın geçerliliği doğrulanabiliyordu, ancak son iki örnek geçerli token üretimine kadar gidebilen daha ciddi sorunlar
    • Tüm açıklar şu anda Microsoft tarafından düzeltilmiş durumda

  • GraphNinja ve GraphGhost özeti

    • GraphNinja: Başka bir tenant’ın endpoint’i belirtilerek oturum açma denendiğinde, parolanın doğru olup olmadığı anlaşılabiliyor ancak log oluşmuyor
      • Saldırgan, kimlik doğrulama isteğini harici bir tenant’a gönderip yanıta bakarak parolanın doğru olup olmadığını anlayabiliyor
      • Microsoft daha sonra bu sorunu gidermek için ek loglama ekledi
    • GraphGhost: Hatalı bir Client ID kullanıldığında kimlik doğrulama akışı parola doğrulamasından sonra başarısız oluyor ve loglarda yalnızca başarısızlık görünüyor
      • Parolanın doğru olduğu bilgisi yönetici loglarına düşmüyor
      • Microsoft, oturum açma loglarına parola doğrulaması bilgisini ekleyerek sorunu düzeltti

  • GraphGoblin açığı

    • GraphGoblin, OAuth2 ROPC akışında scope parametresini tekrarlayarak log oluşturulmasını atlatıyor
      • "openid openid openid ..." biçiminde binlerce kez tekrarlandığında geçerli bir token üretiliyor ancak Entra ID oturum açma loglarında hiçbir kayıt bırakılmıyor
    • Neden olarak SQL sütun uzunluğu aşımı nedeniyle INSERT işleminin başarısız olması gösteriliyor
      • Tekrarlanan scope dizesinin veritabanı alanı uzunluğunu aşması nedeniyle log kaydının başarısız olduğu tahmin ediliyor
    • Microsoft sorunu yeniden üretmekte zorlandı ancak video kanıtı sağlandıktan sonra düzeltmeyi tamamladı

  • Graph****** (User-Agent tabanlı atlatma)

    • User-Agent alanına 50.000 karakterden uzun bir dize girildiğinde log oluşturulmuyor
      • Kimlik doğrulama isteği normal şekilde işleniyor ve token üretiliyor, ancak loglar tamamen eksik kalıyor
      • SQL sütun uzunluğu aşımı nedeniyle loglamanın başarısız olduğu tahmin ediliyor
    • 28 Eylül 2025’te bulundu ve 8 Ekim’de Microsoft bunu rapor gelmeden önce zaten düzeltmişti

  • Zaman çizelgesi özeti

    • 2025-09-20: GraphGoblin ilk kez bulundu
    • 2025-09-26: GraphGoblin Microsoft’a raporlandı
    • 2025-09-28: Graph****** bulundu
    • 2025-10-08: Graph****** düzeltmesi tamamlandı
    • 2025-11-21: Microsoft GraphGoblin’i yeniden üretmeyi başardı ve düzeltmeye başladı

Microsoft’un yanıtı ve değerlendirme

  • Microsoft bu açığı “Orta (Medium)” seviyede sınıflandırdı ve ödül ya da kamuya açık takdir vermedi
    • Önceki iki örnekte (2023~2024) ödül ve takdir vardı
    • Bu kez geçerli token üretilebilen ciddi bir sorun olmasına rağmen önemli görülmedi
  • CVSS v3.1’e göre 7.5 puan (High), v4.0’a göre 8.7 puan (High) olarak değerlendiriliyor
    • Integrity (bütünlük) etkisi nedeniyle yüksek puan çıkıyor
    • Log eksikliği, güvenlik bileşeninin doğrudan zarar görmesi olarak kabul ediliyor
  • Microsoft, sorunu yeniden ürettikten sonra 2 hafta içinde düzeltmeyi tamamladı
    • Geçmişte GraphNinja düzeltmesi 7 ay, GraphGhost ise 5 ay sürmüştü

Log atlatmayı tespit etme yöntemi

  • KQL sorgusu ile Graph Activity logları ve Sign-In loglarındaki Session ID veya UniqueTokenIdentifier karşılaştırılabiliyor
    • Graph Activity’de bulunup Sign-In loglarında olmayan oturumlar, atlatılmış girişler olarak değerlendirilebilir
    • Ancak Graph Activity loglarını toplamak için E5 lisansı gerekiyor
  • Örnek KQL sorgusu: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Gerekirse SessionId temelinde de karşılaştırma yapılabilir
    • Tespit sonuçlarına göre Azure Log Search Alert Rule yapılandırılabilir

Dört oturum açma logu atlatma yönteminin özeti

Bulunma zamanı Yöntem Token üretimi Microsoft tarafından kabul
2023-08 / 2024-05 Harici tenant ID belirtilerek parola doğrulama logunun oluşmaması X X
2024-12 / 2025-04 Hatalı Client ID ile kimlik doğrulama hatasına yol açma X X
2025-09-20 Scope tekrarlarıyla SQL sütun taşması O X
2025-09-28 Uzun User-Agent dizesiyle SQL sütun taşması O N/A

Microsoft’un güvenlik sürecine yönelik eleştiriler

  • Entra ID oturum açma loglama işlevinde birçok parametrede kusur bulundu

    • tenant ID, client ID, scope, user-agent gibi temel alanlarda tekrarlayan açıklar ortaya çıktı
    • Sorun, karmaşık bir saldırı değil basit bir girdi doğrulama hatasından kaynaklanıyor
    • Microsoft’un güvenlik incelemesi ve kalite kontrol eksikliği eleştiriliyor
    • Yıllar boyunca aynı alanda benzer kusurlar tekrarlandı
    • Yapay zeka ile kod üretimi kullanılıp kullanılmadığı ya da kod yönetim sürecinde eksiklik olup olmadığı soruları gündeme geliyor

  • Açıklık ve şeffaflık eksikliği

    • Dört örneğin hiçbirine CVE verilmedi ve resmî duyuru yapılmadı
    • Microsoft, CNA olarak kendi açıklarının açıklanıp açıklanmayacağına tek taraflı karar veriyor

Sonuç

  • Azure Entra ID’nin oturum açma logları, dünya genelindeki kuruluşların saldırı tespitinde kullandığı temel veriler arasında yer alıyor
    • Log eksikliği durumunda tüm saldırı tespit mekanizması etkisiz kalabilir
  • Bulunan dört açığın tamamı, basit girdi fuzzing’i ile tespit edilebilecek seviyedeydi
  • Microsoft’un bu tekrarlayan kusurlar için kamuya açık açıklama yapması ve şeffaf güvenlik inceleme süreçlerini güçlendirmesi gerekiyor
  • Yöneticiler ve güvenlik ekipleri, logların çapraz doğrulanması ve KQL tabanlı tespit kuralları ile savunma yapısını güçlendirmeli

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-22
Hacker News yorumları

  • CISA'nın yayımladığı Microsoft ihlal olayı raporunu hatırlatıyor
    Devlet destekli bir hacker grubu Microsoft'u aşarak ABD Dışişleri Bakanlığı dahil çeşitli kurumlara sızmıştı
    Şaşırtıcı olan, ihlalin Microsoft tarafından değil, Dışişleri'ndeki bir sistem yöneticisi tarafından e-posta loglarındaki anormallik fark edilerek ortaya çıkarılmasıydı
    CISA rapor bağlantısı

  • ProPublica ve ArsTechnica'nın Azure'u doğrudan eleştiren haberinde, federal siber güvenlik uzmanlarının Microsoft bulutunu “berbat” diye nitelendirdiği söyleniyor
    yazı bağlantısı

    • Aslında bir uzman bunu dokümantasyon kalitesi için söylemişti; ProPublica bunu sanki Azure'un geneline söylenmiş gibi genişletmiş olabilir
    • Ars bunu sadece lisanslı yeniden yayın olarak yayımlamış
    • Tanıdığım Azure güvenlik mühendisleri neredeyse tamamen mental çöküş halinde. Yaklaşık 12 kişiden yarısı tükenmiş durumda, geri kalanın da yetkinliği çok düşük
    • Bloomberg ya da CNBC bu olayı işlemedi. Keşke biri bunu medya bağlantıları üzerinden duyursa

  • Bugünkü siber güvenlik durumu, medeniyetin bütünüyle bağımlı olduğu sistemler için fazlasıyla zayıf
    Delik bir tekneyi koli bandıyla kapatıp okyanusa açılmaya benziyor

    • Daha da kötüsü, sektörün bu delikleri kapatmak yerine çözüm diye daha fazla makineli tüfek kulesi dikmeyi önermesi

  • SQL loglarıyla ilgili tartışmada, saldırganın aşırı uzun girdi gönderip kolon uzunluğu aşımı yüzünden INSERT'in başarısız olmasına yol açtığı anlaşılıyor
    Sonuç olarak giriş denemesi kayda geçmemiş

    • İki servis ayrı çalışıyormuş. Doğrulama servisi hatayı algılayıp log servisine kayıt isteği göndermiş ama log servisi başarısız olsa bile doğrulama servisi yanıt vermeye devam etmiş
      Kimlik doğrulama akışı çok karmaşık tasarlanmış yapısal bir sorun gibi görünüyor

  • Azure'un denetim loglarının gerçek davranıştan farklı kayıt tuttuğunu bizzat yaşadım
    Bir client secret'ı sildim; UI B'yi sildiğini gösterirken API fiilen yalnızca A'yı bırakacak şekilde çalışıyordu
    Sonunda loglarda bunu ben yapmışım gibi görünüyordu ama aslında sebep sistem hatasıydı
    Bu deneyimden sonra yalnızca Azure loglarına değil, denetim loglarına genel olarak duyduğum güven de sarsıldı
    Mahkemede delil olarak kullanmak için riskli olduğunu düşünüyorum

    • Bu yüzden değişiklikten önce onay adımı zorunlu olan UI'ları tercih ediyorum. “Video oyunu tarzı” otomatik kaydetme arayüzleri fazla tehlikeli
    • Azure portalı (yeni sürüm ve eski sürüm dahil) hata dolu, o yüzden şaşırtıcı değil. Tek bir yanlış tıklamayla başka bir nesnenin değiştiği durumlar bile olabiliyor
    • Bu örnek, eşzamanlı düzenleme ortamlarında set işlemi ile delete işlemi arasındaki riskleri anlatmak için iyi bir eğitim vakası. Log doğruydu ama sorun UI tasarımındaydı
    • Sonuçta kullanıcı yalnızca niyetini ifade ediyor, asıl neyin uygulanacağını frontend belirliyor; bu da ürkütücü

  • Son dönemdeki EntraID açıklarıyla kıyaslanınca log atlatma daha az önemli görünüyor

    • Ama kritik kimlik doğrulama logları yalnızca 'best-effort' mantığıyla çalışıyorsa, bu güvenlik denetimi için temel oluşturma açısından ciddi bir sorun
    • Sonuçta başarılı ve gizli saldırılar çoğu zaman birden fazla zafiyetin birlikte çalışmasıyla mümkün olur

  • Microsoft daha önce Notepad'e bile kritik bir açık sokmuştu; bu yüzden buna şaşırmıyorum

  • Eskiden Azure VPN'i değerlendirirken, bağlantı başarısı/başarısızlığına dair hiç log tutulmadığını görmüştüm
    Bunu gündeme getirdiğimde Microsoft “onu yeni özellik talebi olarak kaydet” demişti
    O anda Azure'a dair güvenimi tamamen kaybettim. Zaman geçtikçe düzelmek yerine daha da kötüleşiyor gibi geliyor

  • BT yöneticilerinin Microsoft kullanmaya devam etmesinin nedeni başka seçenek olmaması

    • Benimki gibi .NET tabanlı LOB uygulamalarını ve çeşitli SaaS'leri yönetmek zorunda olan ortamlarda en gerçekçi tercih Microsoft çözümleri oluyor
      Bütçe düşük, insan kaynağı yetersiz; bu yüzden sistem sadece maaşını alıp mesai sonunda çıkabilecek kadar işler halde tutuluyor
    • Genç yöneticiler Microsoft'tan hoşlanmama eğiliminde. Belki de kuşak farkıdır
    • “Kimse X satın aldığı için kovulmadı” sözündeki gibi, Microsoft seçmek kariyer açısından daha az risk taşıyor

  • Microsoft, Azure açığının yeniden üretilemediğini söyleyip video kanıtı istediğinde, bunun tek satırlık bir curl komutuyla gösterilmiş olması etkileyiciydi
    Gerçekten çok tatmin edici bir andı