Hacklenen Microsoft test hesabının yönetici yetkileri vardı

 (arstechnica.com)
1 puan yazan GN⁺ 2024-01-29 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft ihlali, MFA’sız eski bir test hesabının üst düzey yöneticiler ile güvenlik ve hukuk ekiplerinin e-postalarına erişime yol açması nedeniyle basit bir hesap ele geçirme vakasından daha ciddi
  • Rusya devletiyle bağlantılı Midnight Blizzard grubu, zayıf kimlik bilgilerini password spraying ile kötüye kullanarak “legacy non-production test tenant account” hesabında oturum açtı
  • Saldırganlar, ele geçirilmiş test tenant’ında OAuth uygulama izinlerini kullanarak Office 365 Exchange Online’da full_access_as_app rolünü elde etti
  • full_access_as_app verilmesi için yönetici yetkisi gerektiğinden, test hesabının üretim ortamında aşırı yetkilere sahip olduğu yönünde bir yapılandırma hatası eleştirisi ortaya çıktı
  • En az ayrıcalık ilkesine uymayan test hesabı ve konut tipi proxy tabanlı password spraying, mevcut ihlal göstergesi odaklı tespit yöntemlerini zorlaştırdı

Test hesabından e-posta erişimine

  • Rus devlet destekli hackerlar, password spraying ile zayıf kimlik bilgilerini kötüye kullanarak “legacy non-production test tenant account” hesabında oturum açtı
  • Söz konusu test hesabı çok faktörlü kimlik doğrulama ile korunmuyordu
  • Sonrasında Microsoft’un üst düzey yöneticileri ile güvenlik ve hukuk ekiplerindeki çalışanların e-posta hesaplarına erişim sağlayan yetkiler elde edildi
  • Saldırı grubu Midnight Blizzard, yetkili e-posta hesaplarına kalıcı erişim için OAuth kimlik doğrulama protokolünü kötüye kullandı
    • Ele geçirilmiş test tenant’ında kötü amaçlı bir uygulama oluşturdu
    • Uygulamaya Microsoft Office 365 e-posta hizmetindeki tüm e-posta adreslerine erişim yetkisi verdi
    • Mevcut bir test OAuth uygulamasına Office 365 Exchange Online’un full_access_as_app rolünü atadı

Yönetici yetkilerine sahip legacy test hesabı

  • Microsoft’un güncellemesinde, “legacy test OAuth application”ın Microsoft kurumsal ortamında elevated access sahibi olduğu bilgisi yer aldı
  • Kevin Beaumont’a göre bir OAuth uygulamasına full_access_as_app rolünü verebilmek için hesabın yönetici yetkisine sahip olması gerekiyor
  • Beaumont bu yapılandırmayı “üretimde oldukça büyük bir yapılandırma hatası” olarak değerlendirdi
  • Bu kadar geniş yetkilerin eski bir legacy test hesabına verilmesi ve korunması için makul bir neden hayal etmenin zor olduğu eleştirileri yapıldı
  • Microsoft, test hesabının neden baştan böyle yapılandırıldığını ve legacy hale geldikten sonra neden korunmaya devam ettiğini açıklamayı reddetti

En az ayrıcalık ilkesine aykırı yapılandırma

  • Bu yapılandırma, bir hesabın yalnızca işini yapmak için gerekli en az yetkilere sahip olması gerektiğini söyleyen en az ayrıcalık ilkesini ihlal ediyor
  • Temel sorun, legacy test hesabının neden yönetici yetkilerine ihtiyaç duyduğunu anlamanın zor olması
  • Beaumont bunu, güvenlik, MFA, güvenlik duvarı ve izleme bulunmayan bir test alanında üretim sisteminin Domain Admin kullanıcısını bulundurmaya benzetti
    • Domain Admin kullanıcısı, etki alanı denetleyicileri ve Active Directory dahil olmak üzere ağa bağlı cihazlar üzerinde tam yönetici yetkisine sahiptir
    • Ağdaki en güçlü hesap olduğundan izole edilmesi gerekir ve üretim sistemlerinin parçası olması nadir olmalıdır
    • Güçlü parola ve standart güvenlik önlemleri olmadan böyle bir hesabın ortada bırakılması, zararı büyütür

Diğer kuruluş ihlalleri ve gizli password spraying

  • Microsoft, Midnight Blizzard’ın başka kuruluşları da ek olarak ihlal ettiğini tespit etti ve etkilenen kuruluşları bilgilendirdi
  • Hewlett-Packard Enterprises da kendi ağının Midnight Blizzard tarafından hacklendiğini açıkladı
    • Söz konusu ihlal mayıs ayında gerçekleşti
    • Tespit edilmesi ve engellenmesi ise aralık ayına kadar olmadı
  • Test hesabına erişimde kullanılan password spraying, sınırlı sayıdaki hesap üzerinde hesap başına az sayıda denemeyle gerçekleştirildi
  • Saldırganlar, dağıtık konut tipi proxy altyapısı kullanarak kötü amaçlı faaliyetlerini daha az görünür hale getirdi
    • İyi itibara sahip IP adreslerinden bağlandılar
    • Beklenen coğrafi bölgelerde bulunan IP adreslerini kullandılar
    • Meşru kullanıcı trafiğine karışıyormuş gibi göründüler

Mevcut ihlal göstergesi tespitinin sınırları

  • Konut tipi proxy kullanımına dayalı bu yöntem yeni değil; 2020’deki SolarWinds tedarik zinciri saldırısında da kullanılmıştı
  • SolarWinds saldırısının da Midnight Blizzard tarafından gerçekleştirildiği değerlendiriliyor
  • Konut tipi proxy’ler trafiği çok sayıda meşru kullanıcı IP’si üzerinden yönlendirdiği için geleneksel ihlal göstergesi tabanlı tespit pratikte oldukça zorlaşıyor
  • Midnight Blizzard, ABD ve Birleşik Krallık hükümetlerinin açıklamasına göre Rusya Dış İstihbarat Servisi SVR adına faaliyet gösteren bir grup
  • Aynı grubu izlemek için kullanılan diğer adlar arasında APT29, the Dukes, Cloaked Ursa, UNC2452 ve Dark Halo bulunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-29
Hacker News yorumları

  • Eskiden duyduğum eski bir Roblox hack’i aklıma geldi. Kullanıcı kaydına açık, üretimde olmayan bir staging sitesi vardı ve üzerinde “buradaki hiçbir şey kalıcı değildir” yazan bir banner bulunuyordu.
    Üretim ortamına yeni bir yönetici hesabı eklenmişti; biri staging sitesinde aynı kullanıcı adıyla kayıt olup o çerezleri ve token’ı kullanarak üretim hesabını ele geçirebilmiş ve siteyi ihlal edebilmişti.
    Kullanıcı adı ya da kullanıcı ID’si temelinde kriptografik token üretirken üretim/staging için farklı gizli değerler kullanılmıyorsa veya staging sitesi dış servislerle iletişim kurarken üretim yetkilendirmesiyle karışıyorsa, bu tür sorunların çok da nadir olacağını sanmıyorum.

    • Eskiden e-ticaret için bir kargo API’si uygulamıştım; DHL gibi yerlerle entegreydi. Üretim sunucusuna geçmeyi unutup aylarca test API’sinin bastığı etiketlerle gönderim yaptık; ürünler teslim edildi ama faturalandırılmadı.
      Fark eder etmez durumu dürüstçe bildirdim.
    • Token’larda audience alanının olmasının nedeni de bu.

  • Büyük şirketlerde geliştirme/üretim sınırı, insanların düşünmek istediğinden çok daha delik deşiktir.
    Tipik bir günü düşünün: PC’ye giriş yaparsınız, e-postanızı kontrol edersiniz, sonra aynı kimlik bilgileriyle Azure portalına girersiniz. Sonuçta hepsi aynı tenant’a bağlıdır; hesap GitHub ve bulut hesaplarına da bağlanmıştır.
    Groups ve Teams her yerde oluşturulur; Teams ya da OneDrive kullanmak için ortaya çıkmış, şüpheli yetkiler taşıyan şeyler şirket dizini içinde güvenlik gruplarından neredeyse ayırt edilemeden kalır.
    Ara sıra “buna hâlâ ihtiyacınız var mı?” diyen otomatik e-postalar gelir ama mesajlar anlaşılmazdır; çok büyük bir şirkette soracak doğru kişiyi bulmak da kolay değildir. Helpdesk ancak iki gün sonra yanıt verir, Twitter’da John Savill’e de soramayacağınıza göre onaylayıp geçersiniz.
    Sonunda kurumun dokusu yırtılmaya başlar; saldırgan zayıf bir noktadan şans eseri içeri girer, tenant içinde yatay hareket eder ve istediğini alır.
    Akıllı bir CISO’nun dediği gibi, hacker’lar zorla içeri girmez; giriş yaparlar.

    • Buradaki “tipik” varsayımın epey cesur olması ilginç.
      Elbette herkesin Microsoft bulutu, Skype, Twitter, OneDrive gibi şeyleri kullandığı varsayılıyor; hatta kulağa makul gelsin diye bir kişi adı bile serpiştirilmiş.

  • Kevin Beaumont’un “Yalnızca yönetici yetkisine sahip hesaplar bir OAuth uygulamasına neredeyse tam yetkili full_access_as_app rolünü verebilir. Birileri üretim ortamında oldukça büyük bir yapılandırma hatası yapmış” sözlerine, sistemin ayrıntılarını bilmeden bakınca, asıl sorun buymuş gibi görünmüyor.
    Böyle bir hatayı yapmanın yolu hiç olmamalıydı. Tasarlayanlar ve işletenler bunu imkânsız kılmalıydı; sorumluluk da orada.
    İçerideki herkesi elektrik çarpmasına uğratacak bir düğmesi olan bir fabrika kurup işletirseniz ve biri yanlışlıkla o düğmeye basarsa, sorunun nerede olduğu açıktır.

    • Bunun teknik bir sorun olmama ihtimali yüksek. Teknik olarak engellemek için muhtemelen 20 kadar en iyi uygulama ve emniyet önlemi vardır; ama bu tür guardrail’ler ancak kurum, liderlik ve bürokrasi önem verdiğinde anlam taşır.
      Yıllar boyunca politikaları, prosedürleri, düzenlemeleri ve yasaları tamamen görmezden gelip, böyle yetkilere hiç ihtiyacı olmayan VIP’lere süper yönetici/root yetkisi vermem yönünde defalarca talep aldım.
      Günümüzde her şey çapraz görev, yarı zamanlı görev, çift rol, üçlü rol gibi hâle geldiği için bu daha da kötüleşiyor.
      Verilebilecek gerçek yetkilerden daha fazla rol bulunan rol tabanlı erişim denetimi de gördüm. Bu durumda RBAC’in amacı kendi kendini boşa çıkarıyor. Yetkileri tek tek vermek daha hızlıydı, ama raporda rol görünmüyor diye buna izin verilmiyordu.
      Bunlar teknik ekipten değil, kötü liderlikten kaynaklanır.
      Bir zamanlar şirket içi ERP’nin RBAC yetki sistemi için bu sorunu hafifleten bir eklenti tasarlamıştım. “Yetki istisnası” diye bir tür ekledik; rolünün dışında yetkiye ihtiyaç duyan kişiler bu yolla atanıyor, böylece iş rolünün dışındaki işleri yapabilen kişilerin listesi raporlanabiliyordu.
      Sonuçta yetkiye tek bir bayrak eklemekten ibaretti ama iyi çalıştı. İK her çeyrek yetki istisnalarını kontrol edip kaldırılmaları gerekip gerekmediğini inceliyordu; yarı zamanlı helpdesk’in deneme yanılmayla yetkileri dağıtması yerine, gerçekten bilen yetkili kişiler kontrolü elinde tutabiliyordu.
    • Yapılandırma hatasını nasıl imkânsız hâle getirmeyi önerdiklerini merak ediyorum.

  • Şirketleri ve sektörleri ölçülebilir risklere karşı koruduğunu iddia eden gösterişli güvenlik sertifikaları bolca var; ama Amazon’da 36 dolarlık bir kitapta yazan akılcı ve düşünülmüş en iyi uygulamaların tamamen yok sayılması komik.
    Güvenlik sanki kurdele kampanyası gibi görünüyor.

    • Güvenlik bir süreçtir, ürün değil.
      Güvenliği ürün gibi satan kişi dolandırıyordur.
    • Benim güvenlik sertifikam olsa bile diğer 1.000 çalışanın olmayabilir.
      Sıradan çalışanlar güvenliğin kendisiyle pek ilgilenmez; sadece işlerini yaparlar.
      O kadar çok sunucu, uygulama ve ayar var ki, güvenlik bilinci olan çalışanlar tek başına hepsini incelemeye yetmez.
      Yeterince uzun bakarsanız, herhangi bir şirkette bir gün açık olmaması gereken bir şey açık kalır. Hacker gruplarının yaptığı iş de sürekli boşluk aramaktır.
      Şirketler çalışırken yeni sunucular ve yeni ayarlar oluşturmaya devam etmek zorunda olduğundan, bu bir kez ayarlayıp biten bir mesele değildir.
    • Hangi kitap olduğunu merak ediyorum.

  • Yeni bir işe başladığımda birinin “böylesi daha kolay” diyerek bana bir sürü yetki vermesinden gerçekten nefret ediyorum. Bunu yapmamalılar.
    Bu yalnızca şirketi ihlale açık bırakmakla kalmıyor, bana istemediğim bir sorumluluk da yüklüyor. Yanlışlıkla önemli bir şeyi bozabilirim; bir şey hack’lendiğinde de o yetkilere sahip olduğum için insanlar benden şüphelenebilir.

    • Çalışan başına birden çok servisteki hesap ve yetkilerin tamamını yönetmek zorunda kalmanın yükünü düşününce, bu akış doğal bir evrim gibi de hissedilebiliyor.
      Aslında servis düzeyinde Windows XP güvenlik açılır pencereleri benzeri bir şey yaşıyoruz. Bir işin her adımında başka bir şeye kimlik doğrulamanız isteniyor; uygun yetkilere sahip doğru kimlik bilgilerini almak günler sürebiliyor.
      Destek ekibinin pes edip yeni başlayanlara hesapları ve yetkileri topluca vermesini insani açıdan anlayabiliyorum.

  • Bu yazıda eksik kalan nokta şu: üretim dışı bir hesap üretim etki alanı yöneticisi yetkilerine sahipse, yazarlar “üretim”i nasıl tanımlıyor?

    • Bence kilit nokta bu. Yazı ve alıntılar bunu “hata” diye adlandırıyor ama Microsoft kadar büyük ve karmaşık bir organizasyonda yanlış yetki atamalarının kaçınılmaz olduğunu düşünüyorum.
      Bu yüzden “220 bin kişilik bir şirkette bir noktada biri hata yaptı” açısına odaklanmak pek faydalı değil.
      Ancak çoğu şirkette üretim sistemleri ile test sistemleri arasında genellikle sağlam ve kalın bir çizgi vardır. Bir test hesabına üretim erişimi verilmesi fiilen imkânsız olmalı; dolayısıyla bunun nasıl gerçekleştiği soruşturmanın odağı olmalı.

  • Daha kötü durumlar da gördüm. Bir hukuk bürosunda çalışmıştım; yöneticilere ve ortaklara her şeye yönetici erişimi veriliyordu.
    Parola sıfırlama sonrası varsayılan parola “passme” idi; gerekçe de asıl parolanın çok uzun olup hatırlanmasının zor olmasıydı. Sunucuya giriş yaptıktan sonra parolayı değiştirmeleri gerekiyordu.
    Bir hacker onların birkaç hesabını ele geçirip orayı burayı kurcaladı ve veri çaldı. Bazı test hesaplarında da yönetici yetkileri vardı.
    Artık orada çalışmadığım için mutluyum. Ben programcı analisttim ve Visual BASIC 6.0’ı çalıştırabilmek için yalnızca kendi PC’mde yönetici yetkim vardı.

  • Bu örüntü Microsoft ekosistemi genelinde istisnadan çok kurala yakın; ama Microsoft’un kendisinin bunu yapmış olması özellikle yüz kızartıcı.
    Microsoft güvenlik ekibi, bu tür büyük olayları önlemeye yönelik araçlara ve en iyi uygulama dokümantasyonuna ciddi emek harcadı.

    • İlk test hesabının nasıl ele geçirildiğini merak ediyorum. Muhtemelen çok faktörlü kimlik doğrulama yoktu ve OAuth ROPC akışı üzerinden parola püskürtmeden sonra yanal hareket yapılmış olabilir.
      M365’te çok faktörlü kimlik doğrulamayı zorunlu kılma oldukça kötü. Para ödemeniz gereken bir yapı.
    • Bu tür şeyler her yerde oluyor. Birlikte çalıştığım birçok kişinin test yöntemi neredeyse her zaman azami yetki vermek şeklindeydi. Bilmiyorum, sanki saçma sapan, rastgele hata ayıklama gibi.
      Daha büyük sorun, insanların unutması. Yönetici yetkili beş test hesabı oluşturuluyor ve şirket genelinde kullanıcı yetkisi denetimini biri yapana kadar ortaya çıkmıyor.

  • Eskiden çalıştığım şirket, üretim sunucularının ve veritabanlarının tüm parolalarını kod deposundaki bir metin dosyasına koymuştu. Sebebi de baş mimarın parolaları hatırlamak istememesiydi.
    CTO’ya bunun ne kadar aptalca olduğunu söylediğimde “çalışanlarımıza güveniyoruz” ve “güvenlik denetiminden geçtik” yanıtlarını aldım.
    Hâlâ yüzüme avuç içiyle vurmanın etkisi geçmedi.

    • Ben de veritabanı parolalarından nefret ediyorum. Çok hızlı kırılıyorlar.
      Güvenlik özelliği değil, sadece can sıkıcı bir unsur. “c00lz500” gibi parolalar kullanmıyorum; onun yerine boş dize gibi şeyler kullanıyorum.
      Bunun yerine güvenlik duvarı ve iç ağ kullanıyorum.