Microsoft Önerileri Kötüleşiyor


Bu yılın sonlarında Salı Yaması’nın 20. yıl dönümü yaklaşırken, birçok kişi Microsoft güvenlik yama döngülerine öngörülebilirlik getiren programın önemi üzerine kafa yoruyor. Salı Yaması şüphesiz müşterilerin güvenliğini artırdı ve programın başarısı Adobe, Siemens, Schneider Electric ve daha fazlası dahil olmak üzere kendi Yama Salılarını kuran kuruluşların sayısına yansıdı.

Ancak Microsoft tarafından Salı Yamasında yayınlanan güvenlik açığı ayrıntılarının kalitesi gözle görülür şekilde düştü. Güvenlik açığı açıklamaları eskiden yararlıydı. Şimdi neredeyse anlamsız olmaya indirgendiler. Örneğin, CVE-2017-0290 ve CVE-2023-21554 (aka QueueJumper) için Ulusal Güvenlik Açığı Veritabanındaki (NVD) CVE açıklamalarını karşılaştırın:

CVE-2017-0290 NVD Güvenlik Açığı Açıklaması

Microsoft Windows Server 2008 SP2 ve R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold ve R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607 ve 1703 üzerinde Microsoft Forefront ve Microsoft Defender üzerinde çalışan Microsoft Zararlı Yazılımlara Karşı Koruma Altyapısı ve Windows Server 2016, “Microsoft Kötü Amaçlı Yazılımdan Koruma Altyapısı Uzaktan Kod Yürütme Güvenlik Açığı” olarak da bilinen bellek bozulmasına yol açan özel hazırlanmış bir dosyayı düzgün şekilde taramaz.

CVE-2023-21554 Güvenlik Açığı Açıklaması

Microsoft Message Queuing Uzaktan Kod Yürütme Güvenlik Açığı

İlk açıklama, etkilenen bileşenleri (Forefront ve Defender), etkilenen sürümleri (çeşitli Windows işletim sistemleri), saldırı vektörünü (hazırlanmış dosya) ve bir hata sınıfını (bellek bozulması) detaylandırır. İkinci açıklama, bu ayrıntıların neredeyse tamamından yoksundur.

Bu, ayrı bir durum değildir. Aslında, Microsoft’un CVE açıklamaları birkaç yıldır düşüşte. Aşağıdaki grafik, son 20 yılda Microsoft tarafından oluşturulan CVE açıklamalarının medyan uzunluğunu eşler:

Microsoft CVE açıklamasının medyan uzunluğunu gösteren grafik
Kaynak: Jacob Baines

Savunmacılar Üzerindeki Etki

Zayıf betimlemeler uygulayıcılar üzerinde ciddi bir etkiye sahiptir. Sorunların ne olduğu net olmadığında güvenlik açıklarına öncelik vermek zordur. Microsoft Message Queuing Uzaktan Kod Yürütme Güvenlik Açığı’nın önemli olup olmadığını kimse nasıl bilebilir? Microsoft Message Queuing’in ne olduğunu veya hangi büyük yazılım parçalarının onu kullandığını kaç uygulayıcı biliyor? Varsayılan olarak etkin mi? Bir ağ bağlantı noktasını dinliyor mu? Uygulayıcı, tüm bu bilgileri kendisi aramaya gitmek zorunda kalır.

Bu tür şeylerden kaçınmak için MITRE, bir CVE açıklamasında neyin gerekli olduğuna dair iyi tanımlanmış kurallar oluşturdu. Bunlar minimum gereksinimlerdir:

8.2.1 Bir okuyucunun hangi ürünlerin etkilendiğine dair makul bir anlayışa sahip olması için yeterli bilgi SAĞLAMALIDIR.

8.2.3 Aşağıdakilerden birini İÇERMEK ZORUNLUDUR:

1. Güvenlik Açığı Türü

2. Temel Neden

3. Etki

Microsoft Message Queuing Uzaktan Kod Yürütme Güvenlik Açığı Bu Gereksinimleri Karşılıyor mu?

Belki 8.2.3’ün çok gevşek bir yorumu, Kod Yürütme Güvenlik Açığı ile tatmin olabilir. Ancak “Microsoft Message Queuing”in etkilenen ürünleri açıkladığını makul bir şekilde söyleyen var mı?

En azından Microsoft, CVE-2023-21554 (Message Queuing) için belirli bir hizmet dahil etti. Bunu CVE-2023-23415 için bile yapmadı. Bu açıklama herhangi bir yazılımı listelemez ve bunun yerine etkilenen bir protokolü listelemeyi tercih eder:

CVE-2023-23415 Güvenlik Açığı Açıklaması

İnternet Denetim İletisi Protokolü (ICMP) Uzaktan Kod Yürütme Güvenlik Açığı

CWE, Microsoft CVE’ye Atandı

MITRE’nin Microsoft’un CVE açıklama kurallarını görmezden gelmesine (veya cömertçe kenardan atlamasına) neden izin verdiği açık değil. Açık olan şu ki, bu yüzden herkes daha kötü durumda. Aşırı yüklenen uygulamacıya hitap etmek yeterli değilse, Microsoft’un kötü CVE açıklamalarının NIST’in CVE ortak zayıflık sıralaması (CWE) kimliği ataması başına etkisini gerçekten ölçebiliriz.

NIST’in NVD’sindeki her CVE için bir CWE atamaya çalışır. Güvenlik açığı, belirli bir CWE’yi atamak için yeterli bilgi içermediğinde NIST, NVD-CWE-noinfo’yu atar. Temel olarak, “bu CVE, zayıflığın ne olduğunu bilmemiz için yetersiz ayrıntılara sahip.”

2015’te NIST, NVD-CWE-noinfo’yu yalnızca birkaç Microsoft CVE’ye atadı. 2022’de Microsoft CVE’lerin çoğu NVD-CWE-noinfo atamasını aldı.

Microsoft CVE'ye atanan CWE'yi gösteren grafik
Kaynak: Jacob Baines

NIST’in her bir CVE’ye CWE atama çabası, güvenlik açığı önceliklendirmesine yardımcı olur ve güvenlik açıklarını CAPEC ve/veya MITRE ATT&CK ile eşlemeyi kolaylaştırır. NVD CWE, MITRE’nin kendi CWE İlk 25’i de dahil olmak üzere bir dizi aşağı akış projesi tarafından kullanılır. Microsoft, güvenlik açıklarına bir CWE atamak için bile yetersiz bilgi sağlamayı seçtiğinden, son Microsoft güvenlik açıkları büyük ölçüde bu etkinliklerden hariç tutulur.

Ne yazık ki, bilgiler Microsoft danışma belgesinde de bulunabilecek gibi değil. Aslında uygulayıcıların dış kaynaklara başvurması gerekir çünkü Microsoft tavsiyelerini güncel tutmaz. Örneğin, 2023’te hem CVE-2022-41080 hem de CVE-2019-1388, Siber Güvenlik ve Altyapı Güvenliği Ajansı Bilinen Yararlanılan Güvenlik Açıkları Kataloğuna eklenmiştir. Microsoft’un NVD girişleri bunu doğru bir şekilde yansıtmaktadır. Ancak her iki Microsoft danışma belgesi de güvenlik açıklarının “istismar edilmediğini” belirtir. Bunun nedeni, tavsiyelerinin yalnızca yayınlandığı tarihteki istismarı yansıtmasıdır.

CVE-2019-1388 için Microsoft Danışmanlık Yararlanma Tablosu

Sonuç olarak, Microsoft’un danışma belgesi hem güncelliğini yitirmiş hem de bilgiden yoksundur. NVD girişi güncel, ancak bilgi de eksik. Neyse ki, bilgi açığını kapatmaya çalışan bir dizi üçüncü taraf var. Örneğin, Zero Day Initiative Salı günü her Yama’nın özetini yayınlar. Bu, CVE-2023-21554’ün (aka QueueJumper) açıklamasıdır:

Bu bir CVSS 9.8 hatasıdır ve Microsoft’un en yüksek istismar derecesini alır. Uzak, kimliği doğrulanmamış bir saldırganın, Message Queuing hizmeti etkinken etkilenen sunucularda kodunu yükseltilmiş ayrıcalıklarla çalıştırmasına olanak tanır. Bu hizmet varsayılan olarak devre dışıdır, ancak birçok iletişim merkezi uygulaması tarafından yaygın olarak kullanılır. Varsayılan olarak 1801 numaralı TCP bağlantı noktasını dinler, bu nedenle çevrede bunu engellemek dış saldırıları önleyecektir. Ancak bunun operasyonlar üzerinde ne gibi bir etkisinin olabileceği net değil. En iyi seçeneğiniz, güncellemeyi test etmek ve dağıtmaktır.

Bu açıklama, aşağıdakiler gibi CVE girişinin içermediği önemli bilgileri içerir:

1. Message Queuing bir hizmettir.

2. Message Queuing varsayılan olarak devre dışıdır.

3. Message Queuing, 1801 numaralı TCP bağlantı noktasını dinler.

4. İstismar, yükseltilmiş ayrıcalıklarla sonuçlanabilir.

Tüm bunlar, savunucular için inanılmaz derecede faydalıdır – CVE sözlüğünde ve NVD girişinde yer alması gereken, ancak görünmeyen bilgiler. Bu, bağlam, güvenlik açığı önceliklendirme ve geçmiş koruma açısından CVE kataloğuna ait olan bilgilerdir. Bunun yerine, zaten zamanı kısıtlı olan savunucular, her Microsoft güvenlik açığının üçüncü taraf açıklamalarını aramaya zorlandıkları için dezavantajlı duruma düşerler.

Çözüm

Microsoft’un Salı Yaması neredeyse içilecek kadar eski, ancak bu programın olgunluğunu yansıtmıyor. Öngörülebilir bir yama temposu güzeldir, ancak Microsoft tarafından üretilen ilgili bilgiler kötüdür ve yıllardır bu yönde eğilim göstermektedir. Microsoft çok daha fazlasını yapabilir ve topluluğa da borçludur. Sekiz kelimelik güvenlik açığı açıklamaları norm olmamalı ve olamaz.



Source link