Storm-0558’in anahtarı ele geçirmesine ilişkin başlıca teknik inceleme bulguları

 (msrc.microsoft.com)
1 puan yazan GN⁺ 2023-09-07 | 1 yorum | WhatsApp'ta paylaş
  • Çin merkezli tehdit aktörü Storm-0558’in ele geçirdiği MSA tüketici imzalama anahtarı ile token sahteciliği yaparak OWA ve Outlook.com’a eriştiği olaya ilişkin teknik inceleme bulguları
  • Nisan 2021’deki tüketici imzalama sistemi çökmesi sırasında oluşturulan çökme dökümüne, bir yarış koşulu (race condition) nedeniyle anahtar dahil oldu ve sistem bunu tespit edemedi
  • Anahtarı içeren çökme dökümü, izole üretim ağından internet bağlantılı şirket ağındaki hata ayıklama ortamına taşındı; kimlik bilgisi taramasında da tespit edilemedi
  • Tüketici anahtarıyla kurumsal e-postaya erişilebilmesinin nedeni, e-posta sistemi geliştiricilerinin kütüphanenin kapsam doğrulamasını yaptığına dair hatalı varsayımda bulunması ve issuer/scope doğrulaması eklememesiydi
  • Tüm kusurlar giderildi; olay sonrası önlem olarak anahtar kapsamı doğrulama otomasyonu dahil çok katmanlı savunmalar güçlendirildi

Anahtarın ele geçirilme süreci

  • Microsoft; geçmiş kontrolleri, özel hesaplar, güvenli erişim iş istasyonları ve donanım token tabanlı çok faktörlü kimlik doğrulama içeren izole ve kısıtlı bir üretim ortamı işletiyor
    • Bu ortam, e-posta, toplantı, web araştırması gibi iş birliği araçlarının kullanımını engelleyerek zararlı yazılım bulaşması ve phishing gibi hesap ele geçirme yollarını önlüyor
    • Just in Time / Just Enough Access politikalarıyla sistem ve veri erişimi sınırlandırılıyor
  • Şirket ortamı (corporate environment) güvenlik kimlik doğrulaması ve güvenli cihazlar gerektiriyor; ancak e-posta, toplantı ve iş birliği araçlarının kullanımına izin verildiği için hedefli phishing, token çalan zararlı yazılımlar vb. karşısında savunmasız
    • Zero-Trust ve "assume breach" ilkeleri uyarınca anahtar materyali üretim ortamının dışına çıkmamalı
  • Nisan 2021’de tüketici imzalama sistemi çöktü ve bir çökme dökümü (crashed process anlık görüntüsü) oluşturuldu
    • Çökme dökümleri hassas bilgileri maskelediği için imzalama anahtarını içermemeliydi; ancak bir yarış koşulu nedeniyle anahtar dahil oldu (düzeltildi)
    • Sistem, çökme dökümü içinde anahtar bulunduğunu tespit edemedi (düzeltildi)
  • O dönemde anahtar içermediği değerlendirilen çökme dökümü, izole üretim ağından hata ayıklama ortamına taşındı
    • Bu, standart hata ayıklama prosedürlerine uygundu; kimlik bilgisi taraması anahtarın varlığını tespit edemedi (düzeltildi)
  • Anahtar sızıntısının ardından Storm-0558 aktörü bir Microsoft mühendisinin şirket hesabını ele geçirdi
    • Söz konusu hesabın, anahtarı içeren çökme dökümünün bulunduğu hata ayıklama ortamına erişim yetkisi vardı
    • Günlük saklama politikası nedeniyle belirli sızıntı kanıtı günlükleri yok; ancak anahtarın ele geçirilmesi için en olası yol bu

Tüketici anahtarıyla kurumsal e-postaya erişilebilmesinin nedeni

  • Hem tüketici hem de kurumsal uygulamaları destekleme yönündeki müşteri talebine yanıt olarak Eylül 2018’de ortak anahtar meta verisi yayımlama uç noktası kullanıma alındı
    • Birleşik sunumun parçası olarak, kurumsal ve tüketici hesaplarına göre anahtar kapsamı doğrulama gereksinimlerini netleştirmek için dokümantasyon güncellendi
  • İmzayı kriptografik olarak doğrulayan bir API sağlandı; ancak kütüphane kapsam doğrulamasını otomatik yapacak şekilde güncellenmedi (düzeltildi)
  • E-posta sistemi 2022’de ortak meta veri uç noktasını kullanacak şekilde güncellendi
    • E-posta sistemi geliştiricileri, kütüphanenin tam doğrulama yaptığını yanlış varsaydı ve gerekli issuer/scope doğrulamasını eklemedi
    • Bunun sonucunda e-posta sistemi, tüketici anahtarıyla imzalanmış güvenlik token’larıyla yapılan kurumsal e-posta isteklerini kabul etti (güncellenmiş kütüphaneyle düzeltildi)

Olay sonrası inceleme ve iyileştirme önlemleri

  • İmzalama anahtarının çökme dökümüne dahil olmasına yol açan yarış koşulu tespit edilip giderildi
  • Anahtar materyalinin çökme dökümlerine yanlışlıkla dahil olduğu durumlara yönelik önleme, tespit ve müdahale güçlendirildi
  • Hata ayıklama ortamında imzalama anahtarının varlığını daha iyi tespit etmek için kimlik bilgisi taraması güçlendirildi
  • Kimlik doğrulama kütüphanesinde anahtar kapsamı doğrulamasını otomatikleştiren geliştirilmiş kütüphane dağıtıldı ve ilgili dokümantasyon netleştirildi

12 Mart 2024 ek güncellemesi

  • Operasyonel bir hata nedeniyle anahtar materyalinin güvenlik token’ı imzalama ortamının dışına çıktığı ve ele geçirilmiş bir mühendis hesabı üzerinden hata ayıklama ortamında erişildiği yönündeki temel hipotez korunuyor; müşteri/Microsoft etkisi veya aktör faaliyetinde değişiklik yok
  • 2021 çökme dökümünün aktör erişimine neden olabileceği belirtilmişti; ancak etkilenen anahtar materyalini içeren bir çökme dökümü bulunamadı
  • Bahsedilen yarış koşulu, anahtarın çökme dökümünde bulunup bulunmamasını değil, çökme dökümünün güvenli imzalama ortamından dışarı çıkarılıp çıkarılamamasını etkiledi
  • Çökme dökümünün dışarı çıkarılmasının standart hata ayıklama prosedürlerine uygun olduğu ifadesi, geçmişte bunun yasaklanmadığı anlamına geliyordu; Microsoft’un mevcut standart hata ayıklama prosedürleri, bu tür materyallerin üretim ortamından dışarı çıkarılmasını yasaklıyor
  • Devam eden incelemede kimlik bilgisi tarama teknolojisinin sınırlamaları ortaya çıktı; tespit edildikçe giderilecek

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-07
Hacker News yorumları

  • Burada eksik bir halka var gibi görünüyor: bir eşzamanlılık hatası ya da bellek güvenliği hatası yüzünden özel anahtarın tesadüfen hata ayıklama çıktısına girmesi kolayca anlaşılabilir; ama saldırganın çökme gerçekleştiğini, çökme dökümünün yapısını biliyor olması ve Microsoft’un iç ağında bekliyor olması gerekmiyor muydu?
    İhlal varsayımıyla savunma iyi bir ağ güvenliği stratejisidir, ama gerçekten ihlal edildiği varsayımını öylece kabul etmemek gerekir

    • Çin tarafında bir gelişmiş kalıcı tehdit (APT) saldırganı olsaydım ve çalışan kimlik bilgileriyle Microsoft’un iç ağına sızsaydım, ilk iş olarak çökme günlüklerinin saklandığı yeri bulup debug sembolleriyle birlikte sessizce dışarı alırdım
      Bu tür veriler çoğu zaman gerçek değerine kıyasla yeterince güvenli saklanmaz. FAANG’de çalışınca gördüm ki finans ya da kurumsal regülasyon deneyimi olmayan yeni çalışanların neredeyse tamamı çökme verilerini bug tracker’a eklemenin sorun olmadığını düşünüyor. Bu yüzden çökme dökümleri gibi şeylerin, insanların etrafından dolaşmak istemeyeceği kadar kullanımı kolay kasalara konması için alışkanlığı değiştirmek gerekiyor
      Ele geçirilmiş bir mühendis hesabı varsa, en azından bug tracker erişimi vardır; muhtemelen binary’nin debug sembollerini de elde edebilir ya da oluşturabilir diye varsaymak gerekir. Geriye kalan tek şey, bir mühendisin dikkatsizce çökme dökümünü bug eki olarak yüklemesini bekleyip, biri fark edip silmeden önce onu almak
    • Yazıya göre çalışan hesabının ele geçirilmesi, çökme dökümü iç ağa taşındıktan sonra gerçekleşmiş. Microsoft sızıntı kanıtı olmadığını söylüyor, ama hesap ihlaline dair bir miktar kanıt olduğu anlaşılıyor
      Ayrıca Microsoft’un kimlik bilgisi tarama aracının anahtarı bulamadığı ve bu sorunun düzeltildiği söyleniyor; demek ki anahtar taramayla tespit edilebilir bir formdaymış gibi görünüyor
      Genel tablo şu gibi: bir mühendis anahtarı içeren dökümü kendi hesabına taşıyıp bir süre bıraktı; sonra saldırgan hesabı ele geçirip kullanılabilir tüm dosyaları aldı ve Microsoft’unkinden daha iyi araçlarla anahtarı tararken büyük ikramiyeyi vurdu
    • Alıntılanan içeriğe göre, 2021 Nisan’ından sonra anahtar bir çökme dökümüyle kurumsal ortama sızdıktan sonra Storm-0558 bir Microsoft mühendisinin kurumsal hesabını ele geçirmiş ve bu hesap, anahtarın yanlışlıkla dahil edildiği çökme dökümünün bulunduğu hata ayıklama ortamına erişebiliyormuş
      Yani saldırgan zaten ağın içindeydi ve tespit edilmeden yaptığı tarama sırasında dökümü tesadüfen buldu ya da en başından bu belirli hesabı hedefledi demek
    • Cold boot saldırıları döneminden beri bellek dökümlerinde kriptografik materyal arayan standart araçlar olduğunu biliyorum. Saldırganın da bu bakış açısıyla çökme dökümlerini fırsatçı şekilde araması hayal edilebilir
      Yine de saldırgan açısından olay zinciri fazla şanslı biçimde üst üste gelmiş gibi hissettiriyor
    • Bir sisteme sızmışken dosya sisteminde sshd.core görürsen, elbette almaz mısın?

  • Küçük sorunların belirli bir sırayla art arda gelip sonunda felaket düzeyinde başarısızlığa yol açmasını ele alan sistem mühendisliği dersleri var. Bu olay o felaket başarısızlık denebilir
    Önce bir yarış koşulu olmalı ve bu yarış koşulu beklenmedik bir sonuca yol açmalı. Kod test edilmiş ve sık kullanılmışsa, daha bu noktada gerçekleşme olasılığı muhtemelen %10’un altındadır. Sonra bir mühendisin özellikle bu çökme dökümüne ihtiyaç olduğuna karar vermesi, kimlik bilgisi tarama yazılımının bu belirli kimlik bilgisini bulamaması, bir hesabın ele geçirilerek ağ erişimi kazanılması, o kullanıcının ilgili döküme erişebilmesi ve hacker’ın bunu bulup alması gerekir
    Buna rağmen anahtar eskiydi ve yalnızca tüketici e-posta hesaplarına erişimde kullanılabildiği için güvenli olması gerekirdi; ama eski anahtarları kabul eden bir bug ve şirket e-posta hesaplarına yönelik token’larda bu imza anahtarını reddetmeyen bir bug daha vardı
    İyi bir sistem mühendisliği dersi. Ne kadar uğraşırsanız uğraşın, sonunda küçük şeyler yeterince birikirse büyük bir kaza olur; bu yüzden patlasa bile patlama yarıçapı sınırlı kalacak şekilde tasarlamak gerekir

    • Güvenlikte bu tür zincirlerin rastgele bir süreç gibi gelmediğini, aktif olarak hedeflendiğini ve istismar edildiğini hesaba katmak gerekir. Saldırgan rastgele yazı tura atan biri değildir; kendi lehine sık sık tura gelen paraları atabilir
      Olay sonrası analizler, şanssız olayların rastgele çakışması gibi sunulur. Saldırgan tesadüfen Microsoft’u hedeflemiş, tesadüfen yarış koşulu varmış, tesadüfen çökme olmuş, tesadüfen bir yerde çökme dökümü bulmuş gibi görünür
      Ama ilk yarış koşulu bug’ının bile kasıtlı olarak yerleştirilmiş olabileceğini düşünmek gerekir. Çökme kasıtlı olarak tetiklenmiş olabilir, saldırgan dökümün belirli bir konumda oluşmasını beklemiş olabilir ve içeriden bir ortak da olmuş olabilir
    • Microsoft’un sistem mühendisliği yaptığını ve ürünleri test ettiğini varsayıyor gibisiniz; oysa gerçeklik bundan epey uzak görünüyor
      Microsoft ekosistemi, mahalledeki çocukların kendi evlerinden getirdikleri parçaları kabaca birleştirerek yaptığı Lego arabaya benziyor
    • Yarış koşulu, aptalca bir bug yazıldığında yönetime açıklamak için herkesin kullandığı gerekçedir. “Maskeleyici asenkron olduğu için, maskeleyici ayarlanmadan önce yazıcı dökümü yazmaya başladı” demek kulağa düpedüz saçma bir uygulama gibi geliyor
      Yarış koşulu denince insanlar “gerçekleşme olasılığı %10’un altında” der, ama gerçekte her büyük çökmede gerçekleşiyor ve sadece çökme sık olmuyor olabilir
      Diske yazmadan önce neden maskelemediklerini ancak Tanrı bilir
    • Böyle bilinmeyen bilinmez felaket başarısızlıklar hep vardı ve gelecekte de olmaya devam edecek. Bu yüzden dayanıklılık gerekiyor; belki de daha az merkeziyetçi bir bakış açısı gerekiyor
      Batı iş dünyasının yarısından fazlasının Outlook.com’a bağımlı olduğu yapı çok yanlış bir duruma yakın; ama mevcut finansal teşvikler dayanıklılığı ya da Outlook.com gibi aşırı merkezi varlıkları parçalamayı desteklemediğinden, böyle şeyler ileride de yaşanmaya devam edecek gibi görünüyor
    • Okurken “gerçekten çok fazla iğne deliğinden geçmiş” diye düşündüm. Voyager’ın Grand Tour yerçekimi yardımı yörüngesinin yanlışlıkla gerçekleşmiş hali gibi

  • Açıkça açıklanmayan noktalar var: 11 Temmuz 2023’te tespit edildiyse ve Nisan 2021’de gerçekleştiğinden şüpheleniliyorsa, bu saldırganın bu kimlik bilgisini 2 yıldan uzun süre elinde tuttuğu ve tespitten kamuya açıklamaya kadar 2 ay geçtiği anlamına geliyor.
    Kaç sahte token olduğu ve ne kadar erişim sağlandığı da eksik. Açıklanmadıysa insan kötü yönde varsayım yapıyor.
    Tespitten sonra düzeltmenin ne zaman uygulandığına dair bir takvim de yok; sadece “bu sorun düzeltildi” deniyor. Umarım hızlıca düzeltmişlerdir.
    Doğrudan 4 sorunu düzeltmişler ama açıkça sistemik bir sorun var gibi görünüyor; buna karşı ne yapacakları da görünmüyor.

  • Böyle bir ihlal, Microsoft’un iç altyapısına dair çok derin bir anlayış gerektirir. Bunun bir hacker ekibinin organize çalışması olduğunu varsaymak daha güvenli.
    Ucuz yapılabilecek bir iş değil ama getirisi muazzam. Aşırı merkezileşme, hacker’ların çabalarını az sayıdaki yüksek değerli hedefe yoğunlaştırmasına yol açıyor. Çünkü başarılı olurlarsa elde edecekleri şey çok büyük.
    Google, Microsoft, Amazon gibi yerlerin iç altyapısını halihazırda derinlemesine inceleyen ve analiz eden devlet destekli hacker ekipleri olduğundan neredeyse eminim. Bu ihlal, onların bunu zaten ne kadar iyi anladığını gösteriyor.
    Daha geniş güvenlik sınırı içinde merkeziyetsizleşmenin zamanı geldiğini düşünüyorum.

    • Bir kuruluş yeterince büyükse, içeride bir devlet aktörünün çalıştığını varsaymak gerekir. Ne yazık ki herkes her an ihlal edilebildiği için bu varsayımdan kaçınmak zor.

  • Temkinli ifadeleri bir kenara bırakırsak, biri üretim ortamından bir minidump’ı geliştirme iş istasyonuna indirmiş; bu da muhtemelen ilgili geliştiricinin şirket içi OneDrive’ında bir yerlerde beklerken hesabı ele geçirilmiş. Birisi dump’ı alıp anahtarı bulmuş ve büyük vurgunu yapmış gibi.

    • Bu saldırının gerçekten bu kadar başarılı olmasında belirleyici olan şey, Microsoft geliştiricilerinin kendi kütüphaneleri ve altyapıları üzerinde güvenli kimlik doğrulama denetimi uygulayamamış olmasıydı.
    • Ayrıca anahtarı gizleyemeyen bir silme/maskeleme sistemi ve o anahtarı bulamayan bir tespit sistemi vardı. Ardından anahtar, tamamen farklı erişim düzeyine sahip bambaşka bir sistemde kullanıldığı halde çalıştı.
      “Birkaç belirsiz bug’ın sofistike biçimde istismar edilmesi” ifadesi biraz yanlış görünüyor. Daha çok, güvenlik sistemlerinin hiçbirinin işini yapmadığı bir hatalar zinciri trajikomedisi gibi görünüyor.

  • Neden HSM kullanmadıklarını bilmiyorum. Böyle donanımların temel amacı anahtar materyalinin dışarı sızmasını önlemek değil mi?

    • Bu şirketler [1] “saniyede 20.000’den fazla işlemi işleyebilen dünyanın en hızlı ödeme HSM’i” olduğunu iddia ediyor. Microsoft hesap kimlik doğrulama token’ı imzalamanın tepe yükü muhtemelen bundan çok daha yüksektir.
      [1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
    • Açıklanış biçimine bakınca, elde ettikleri çökme günlüğünün HSM’den geldiğini sanmıştım.

  • Bu, anahtarın kurtarılamaz bir donanımda saklanmadığı; yüksek yetkili bir ortamda çalışan, sıradan derlenmiş kod olan normal bir sunucu süreci tarafından erişilebilir olduğu anlamına geliyor.
    Bu anahtara erişebilen sistemin genel operasyon ortamından ayrı bir ortamda olduğuna dair bir ifade de yok. Dolayısıyla herhangi bir operasyon makinesinin anahtara erişebildiği ve o ortama erişimi olan herkesin potansiyel olarak anahtar materyalini dışarı sızdırabileceği varsayılabilir.

  • https://learn.microsoft.com/en-us/azure/active-directory/dev... adresindeki doğrulama bölümüne bakınca, bir şeyi kaçırmıyorsam, yayımlayanın tarihini veya iptal edilip edilmediğini kontrol etmenin önemi hâlâ eksik gibi görünüyor.
    Sözde kodda da yok; yani Microsoft’un bir kez bile yayımladığı herhangi bir anahtara güvenen başka uygulamalar olma ihtimali yüksek. Önbellek temizleme gibi istisnalar hariç, durum bu demek.

    • Asıl en çok endişe veren nokta tam da bu. Microsoft geliştiricileri, kendi kütüphaneleri ve altyapıları üzerinde güvenli kimlik doğrulama denetimi uygulayamamış.
      Microsoft bile kendi amiral gemisi ürünü Outlook’ta kendi kimlik platformunu doğru kullanamıyorsa, başkalarının ne şansı var diye düşünüyor insan.
    • Esas sorun bu. Herkes çökme dump’ı ve sızıntıdan bahsediyor ama asıl mesele, Microsoft’un anahtarın geçerliliğini de doğrulamamış, anahtarın kullanım bağlamını da doğrulamamış olması. Sızan anahtar zaten geçersizdi ve bu anahtar yönetici token’ı üretmek için izin verilen bir anahtar da değildi.
      Sadece Microsoft CA tarafından imzalanıp imzalanmadığını kontrol etmişler. Bu, kod incelemesinde inanılması güç derecede bariz görünen bir sorun.

  • Gerçekten büyük darbe almalarının nedenlerinden biri, anahtarı rotate etmemiş olmaları gibi görünüyor. Anahtarın olmaması gereken yere taşındığı an ile fiilen çalındığı an arasında epey zaman geçmiş gibi.
    Anahtarı sık sık rotate etmiş olsalardı, o anahtarla token sahteciliği yapmak imkânsız olurdu.

  • Bu tür yazılar çıktığında her seferinde hissediyorum: Sırf saldırı fiziksel değil de dijital diye devlet düzeyindeki saldırılara karşı koyma işini özel şirketlere bırakan yapı gerçekten tuhaf görünüyor.
    Çin savaş uçakları Pasifik üzerindeki bir FedEx uçağını düşürseydi, bu ABD egemenliğine saldırı sayılır ve hükümet uygun şekilde karşılık verirdi. FedEx’in kendi nakliye uçaklarını korumak için bizzat savaş uçağı filoları bulundurması da beklenmezdi. Kimse “uçaksavar savunmasını düzgün yapmayan FedEx’in suçu” demezdi.
    Ama dijital alana girince, Microsoft’un Çin ve Rusya’ya karşı kendini kendi başına savunması gerektiğini kabul eden bir hava oluşuyor.

    • Bir grup Çinli, ABD’deki bir bankayı, örneğin Federal Reserve’i soyup büyük finansal zarara yol açsa ama can kaybı olmasa, tepki benzer olurdu. Gerçek Çin hükümetiyle bağlantıdan şüphelenilse ama kesin kanıtlamak zor olsa bu daha da böyle olurdu.
      Hükümetler yabancı ajanları epey düzenli şekilde yakalıyor, ama bu tür tutuklamalar topyekûn savaşa dönüşmüyor.
    • FedEx uçağı örneğinden farklı olarak, bu olayda altyapı saldırıya uğramadı ya da yok edilmedi; can kaybı da olmadı. Yalnızca ABD hükümet yetkililerinin e-postaları okundu.
      İkincisi, ABD de bu tür şeyleri sürekli yapıyor, müttefiklerine karşı da yapıyor; bu yüzden daha sert önlemleri meşrulaştırmak zor.
    • Dijital alan, fiziksel alana kıyasla doğası gereği daha düşük risk seviyesine sahip ve savunması daha zor. Siber saldırılara fiziksel saldırılar gibi karşılık verilmemesi iyi bir şey. Öyle olsaydı, 10 yıldan da önce nükleer savaşa kadar tırmanmış olurdu.
      Siber saldırıların kapsamı ve hacmi çok büyük, ancak anladığım kadarıyla ABD de buna karşılık gelecek ölçekte çok sayıda dış saldırı gerçekleştiriyor.
    • Bir devletin yolcu uçağı düşürdüğü veya gemiye el koyduğu hâlde bunun savaş eylemi olarak ele alınmadığı birden fazla örnek var.
    • ABD’den Asya’ya giden ve içinde bir ABD Temsilciler Meclisi üyesi bulunan bir sivil uçak düşürüldü, ama gerçekte 3. Dünya Savaşı çıkmadı: https://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007