Dün Microsoft’un “hata ödül” programını, 3.partileri de içine alacak şekilde genişlettiğini yazmıştık. Bugün Microsoft’un bugüne kadarki başlıca yazılım tedarik zinciri güvenlik açıkları ve sistemik zayıflıklarına bakalım dedik. Bu, doğrudan ihlalleri, üçüncü taraf güvenlik açıklarını, tasarım kusurlarını, kimlik katmanı sorunlarını ve hükümet incelemeleri tarafından belirlenen kültürel ve organizasyonel sorunları içeren bir liste olacak. Çünkü Windows kötü amaçlı yazılımlar için bir mıknatıs görevi görüyor.
I. Başlıca Microsoft Tedarik Zinciri Sorunları (Kronolojik)
1) SolarWinds Tedarik Zinciri İhlali (2020) – dönüm noktası olayı
2020 yılında Rus SVR (APT29), SolarWinds’in yazılım geliştirme hattını ele geçirdiği, Sunburst arka kapısını yerleştirdiği ve yaklaşık 18.000 müşteriye kötü amaçlı yazılım dağıttığı ortaya çıktı. Microsoft, önemli hedeflerden biriydi. SolarWinds, Microsoft bulut kimlik altyapısının üçüncü taraf bileşenlerle derinlemesine iç içe olduğunu ve tedarik zincirindeki bir ihlalin Microsoft’un kendi sistemlerine kadar uzanabileceğini kanıtladı.
Saldırganlar, Microsoft kaynak kod depolarına erişti. Kimlik doğrulama bileşenleri için dahili kaynak kodunu çaldılar. Azure AD zayıflıklarından yararlanarak “Golden SAML” ve token sahteciliği saldırıları başlattılar.
2) Kaseya VSA Tedarik Zinciri Saldırısı (2021)
Doğrudan bir Microsoft saldırısı değil, ancak binlerce Windows sistemi etkilendi. Saldırganlar Kaseya’nın kod imzalama hattını kullandı ve güvenilir kanallar kullanarak fidye yazılımı dağıttı. PowerShell otomasyonunu kullandı ve Windows’a güveni zayıflattı.
Bu saldırı, Windows güven modellerinin ve kurumsal güncelleme kanallarının tedarik zinciri ihlallerini artırabileceğini gösterdi.
3) Log4j / Log4Shell (2021–2022) – küresel açık kaynak tedarik riski
Log4j, Minecraft sunucuları (Microsoft’a ait), Azure hizmetleri, M365 bileşenleri, Kurumsal Windows tabanlı iş yükleri dahil her yerdeydi. Microsoft’un acil olarak büyük çaplı yama yapması gerekiyordu.
Microsoft asıl kodu yazmamış olsa bile, bulut hizmetleri savunmasız üçüncü taraf bileşenlere bağımlıydı. Google’ın kendi araştırması, Microsoft’un katıldığı ekosistemlerde Log4j’nin erişim alanının büyüklüğünü gösterdi (Maven Central’da 17.000’den fazla etkilenen paket).
4) OpenSSL ve diğer OSS güvenlik açıkları (devam eden)
Microsoft, OpenSSL, zlib, cURL, Python, Go, Java kütüphaneleri ve Azure altyapısı içindeki Linux bileşenlerine güveniyor ama birkaç tedarik zinciri olayı, bağımlılık takibi, SBOM olgunluğu ve yukarı akış denetimindeki boşlukları ortaya çıkardı.
5) XZ Utils Arka Kapı Girişimi (2024) – kıl payı atlatıldı
Devletle uyumlu bir aktör, Linux’un XZ Utils’ine (SSH’de kullanılan) arka kapı yerleştirmeye çalıştı. Microsoft bulut altyapısı, konteynerler, sanal makineler ve hizmetler için Linux imajlarına dayanmaktadır. Arka kapı daha önce başarılı olsaydı, Azure, GitHub, Defender bulut aracıları ve M365 arka uç Linux bileşenleri tehlikeye girebilirdi.
Microsoft’un Linux tabanlı bağımlılıkları tedarik zincirinin bir parçası. Ancak tarihsel olarak Windows kodu kadar izlemiyor.
6) Storm-0558 / Çin APT Token Sahteciliği Olayı (2023)
Storm-0558 imzalama anahtarı sızıntısı – Çinli bir grup, güvenli bir ortamdan çıkarılmış bir çökme dökümünden bir tüketici imzalama anahtarını çaldı; bu anahtar daha sonra belirteçler oluşturmak ve Exchange Online ve Azure AD posta kutularına erişmek için kullanıldı. Dolayısıyla, ABD hükümeti e-posta hesaplarına (Ticaret Bakanlığı, Dışişleri Bakanlığı) eriştiler. Temel neden, Microsoft’un dahili tedarik zincirindeki hataydı. Hassas imzalama anahtarı yanlış şekilde saklanmıştı. Günlük kaydı (LOG) yetersizdi. Microsoft, aylarca bu ihlali tespit edemedi. Bu olay, ABD Kongresi’nin eleştirisine ve 2024 CISA uyarısına yol açtı.
7) Midnight Blizzard (APT29) Kaynak Kod Hırsızlığı (2023–2024)
Rus APT29, Microsoft’un kurumsal e-posta sistemlerini hackledi ve İç e-postaları, kaynak kodları, kimlik mimarisi belgeleri, bulut altyapısı tasarım detaylarını çaldı. Devlet destekli olarak tanımlanan saldırgan, Microsoft bulut iç bileşenlerine erişti ve bu da tedarik zinciri ve kimlik zafiyetlerinin daha sonra istismar edilme riskini artırdı.
II. ABD Hükümeti İncelemeleri Tarafından Belirlenen Sistemik Tedarik Zinciri Zafiyetleri
Hükümet organları (CISA, NSA, Siber Güvenlik İnceleme Kurulu) tekrarlayan Microsoft zafiyetlerini belirledi:
- Güvenlik ortamlarının yetersiz ayrılması : Kritik kriptografik anahtarlar, kod imzalama anahtarları ve hata ayıklama ortamları, karma güven ortamlarında saklandı veya işlendi. Kazara sızıntılara yol açtı (örneğin, Storm-0558 imzalama anahtarı).
- Zayıf iç kayıt ve telemetri : Birden fazla ABD kurumu, Microsoft’un ayrıntılı telemetri eksikliği, kritik kimlik olaylarını kaydetmemesi, müşterilerden güvenlik kayıtları için ekstra ücret alması (kör noktalar oluşturması) ve dolayısıyla saldırganların Microsoft ortamlarında tespit edilmeden faaliyet göstermesine olanak sağlaması konularında sorunlu olduğunu raporladı.
- Aşırı merkezileştirilmiş kimlik sistemleri (Azure AD) :Azure AD, Office 365, Azure, GitHub, Microsoft Defender, Devlet bulut kiracıları için merkezi kimlik sistemi yürütüyor. Yani saldırganlar OAuth belirteci sahteciliği, SAML yanlış yapılandırmaları, yanlış verilmiş sertifikalar gibi konularda başarılı olurlarsa, Microsoft bulutunda erişim elde ederler. SolarWinds ve Storm-0558 bunu gösterdi.
- Bağımlılık Körlüğü (Tedarik Zinciri Gözlemlenebilirlik Açığı) :2024’ten önce Microsoft, Azure mikro hizmetleri, Microsoft 365 iş yükleri, Windows kurumsal bileşenleri ve GitHub arka uç sistemleri için eksiksiz SBOM’lar veya bağımlılık haritaları tutmuyordu. Bu nedenle, Microsoft genellikle savunmasız açık kaynak bağımlılıklarının nerede gömülü olduğunu bilmiyordu.
- Dahili kod imzalama süreçlerine aşırı güven :SolarWinds, Microsoft ekosistemini yeniden incelemeye zorladı. İmzalama anahtarlarının nasıl saklandığı, derlemelerin nasıl doğrulandığı, yazılım kökeninin nasıl doğrulandığı konuları yeniden incelendi. Microsoft’un in-toto, Sigstore / Fulcio ve enel olarak SLSA Seviye 3+ konularında yavaş kaldığı ve bunun, devam eden bir zayıflık alanı olmaya devam ettiği raporlanıyor.
III. Microsoft Tedarik Zincirinde Buluta Özgü Zayıf Noktalar
1) Çoklu Kiracılık Riskleri : Azure’un çoklu kiracı mimarisi, küçük hataları büyük etkilere dönüştürür. Herhangi bir zayıf üçüncü taraf kütüphanesi (YAML ayrıştırıcı, JSON doğrulayıcı, konteyner çalışma zamanı) yatay bir tırmanma vektörü haline gelebilir.
2) Linux Tabanlı Altyapıya Bağımlılık :Azure’un arka ucu Linux’u yoğun olarak kullanıyor. Kubernetes, konteyner çalışma zamanları, orkestrasyon sistemleri, uç hizmetler bunlar arasında. Ancak Microsoft’un tarihsel güvenlik kültürü Windows merkezliydi. Bu da Linux tabanlı tedarik zincirinin yakın zamana kadar yeterince denetlenmemesine yol açtı.
3) GitHub Türetilmiş Araçların Hızlı Entegrasyonu : GitHub’ın tedarik zinciri (Actions, npm, PyPI entegrasyonları) artık Microsoft bulut hizmetleriyle iç içe geçmiş durumda. Açık kaynak kayıt defterlerindeki olaylar Azure ekosistemlerini doğrudan etkileyebilir.
IV. Stratejik Desen
Daha geniş bir perspektiften bakıldığında, Microsoft’un tedarik zinciri sorunları dört ana temayı paylaşıyor:
- Kimlik, en zayıf nokta : Her büyük güvenlik açığı, token sistemlerini, anahtar yönetimini veya kimlik altyapısını istismar etti.
- Açık kaynak bağımlılıkları yaygın ve gevşek bir şekilde yönetiliyor : Microsoft yüzlerce açık kaynak projesine güveniyor, ancak geçmişte tam bir görünürlüğe sahip değildi.
- İç güvenlik disiplini dengesiz : Özellikle, kod imzalama anahtarları, hata ayıklama dökümleri, günlük (LOG) kaydı,kimlik bilgisi hijyeni konularında sorun yaşanıyor.
- Bulut tek kültürlülüğü her zayıflığı artırıyor : Azure veya M365 zayıfladığında, tüm küresel ekosistem yani hükümetler, Fortune 500 şirketleri, altyapı operatörleri etkileniyor.
V. Microsoft’un bu sorunları çözmek için ne yapıyor?
(ABD hükümetinin baskısı ve kendi 2023-2024 başarısızlıkları nedeniyle.)
1) Hizmetler genelinde zorunlu SBOM oluşturma
2) SLSA uyumlu derleme işlem hatları (Seviye 3 hedefi)
3) Geliştirilmiş gizlilik hijyeni ve anahtar kasası
4) Devlet ve kurumsal müşteriler için varsayılan günlük kaydı
5) Tedarik zinciri bileşenlerinin dahili kırmızı ekip çalışması
6) Üçüncü taraf bileşen güvenlik açıklarını içerecek şekilde yeni hata ödül programının genişletilmesi
Kaynak : 