Yetki Verme Tehditleri: Microsoft'ta CVE-2020-17049 KCD Güvenlik Açığı Yamasını Derinlemesine İnceleme

*****Dor Segal tarafından, Güvenlik Araştırmacısı Silverfort*****

11 Kasım 2020'de Microsoft, yeni bir CVE-2020-17049'u açıkladı. Kerberos Güvenlik Özelliğini Atlama güvenlik açığı. Güvenlik açığının kendisi 8 Şubat 2021'den önce düzeltilmeyecek olsa da Microsoft, bu arada istismarı azaltmak için 8 Kasım ve 8 Aralık'ta yamalar yayınladı. Ne kamuya açık bir POC ne de teknik bir analiz ile güvenlik açığının dahili işleyişi hakkında çok az şey ifşa edildi.
Bu gönderi, genel olarak Kerberos Delegasyonuna ışık tutarak ve Microsoft'un CVE-2020-17049 KCD güvenlik açığı için yayınladığı yamaya derinlemesine girerek bu boşluğun bir kısmını doldurmaya çalışıyor.

Kerberos Delegasyonu 101

Kerberos Delegasyonu, Kerberos'un en karmaşık kavramlarından biridir kimlik doğrulama işlem. Standart protokol üzerindeki bu uzantı, başlangıçta hizmet sağlamak için oluşturuldu ve hizmet hesapları aslında herhangi bir izin vermeden kaynaklara erişim kullanırlar.

Delegasyon, ilk kullanıma sunulduğundan bu yana, bugün kullandığımız Kaynağa Dayalı Kısıtlı Delegasyon (KCD olarak da bilinir) haline gelene kadar birkaç önemli değişiklikten geçti. Bu nedenle, güvenlik açığının kendisine yaklaşmadan önce, farklı yetkilendirme türlerini ve bunların artılarını ve eksilerini gözden geçirelim.

1. Aşama: Kısıtlanmamış delegasyon

Kısıtlanmamış yetkilendirme, Windows Server 2000'de tanıtıldı ve hizmetlerin erişim izinlerine sahip bir kullanıcının kimliğine bürünmesine izin veren ilk kişi oldu. Adından da anlaşılacağı gibi, bu tür bir yetkilendirme, bir hizmete herhangi bir zamanda herhangi bir kaynağa erişmek için kullanıcının kimlik bilgilerini kullanma gücü verir.

İşlem, kullanıcının iletilebilir bir TGT talep etmesini ve bunu hizmet biletine eklemesini gerektirir. Ardından, hizmet TGT'yi alır ve daha sonra kullanmak üzere lsass.exe yerel önbelleğine enjekte eder.

Bugünlerde bu yöntemin oldukça riskli olduğunu biliyoruz çünkü devredilen hizmetlere sınırsız erişim sağlıyor, bu da ödün verilmesi durumunda saldırganın önbelleğe alınmış tüm biletleri toplamasına ve tüm ayrıcalıklarına tam erişim elde etmesine olanak tanıyor.

Bu tür bir yetkilendirme, çoğunlukla geriye dönük uyumluluğu desteklemek için bugün hala mevcuttur ve userAccountControl özniteliğinde ADS_UF_TRUSTED_FOR_DELEGATION bayrağı sorgulanarak tespit edilebilir. Bu bayrak ayrıca izlenir Silverfort, kısıtlamasız yetki kullanan hizmetler hakkında rapor verir.

2. Aşama: Kısıtlı delegasyon

Yeni nesil yetkilendirme daha sınırlıdır ve hizmetin, yalnızca "Hesap hassastır ve temsilci atanamaz" bayrağıyla tanımlanmış kaynaklara erişimi taklit etmesine izin verir. Active Directory belirli kullanıcıları kimliğe bürünmekten sınırlamak için.
Bu tür yetkilendirme, hizmetin kimlik doğrulamasını S4U2Self ve S4U2Proxy uzantılarını (MS-SFU) kullanarak gerçekleştirdiği yerdir.

Peki nasıl çalışır?

Hizmet hesabımızda TRUSTED_TO_AUTH_FOR_DELEGATION bayrağı ve kaynağın SPN'sini içeren ms-AllowedToDelegateTo özelliği açık olmalıdır.

Bir kullanıcı, kerberos anlaşmasını (TGT ve TGS) kullanarak hizmette her zamanki gibi kimlik doğrulaması yapar.

Şimdi bu karmaşıklaşmaya başlar: yetki verilmiş bir hizmet hesabı kendisine iletilebilir bir TGT ister. Bu bileti, cname PA-DATA alanımız için kimliğe bürünmüş kullanıcı adını kullanarak S4U2SELF kullanarak bir hizmet bileti talep etmek için kullandık.

Hizmet bu bileti alır, kısıtlanmış temsilci bayrağıyla kaynak hizmet biletine (S4U2Proxy) ekler.

Alınan bilet, mevcut kullanıcının hizmetimiz tarafından taklit edilmesidir.

3. Aşama: Kaynağa Dayalı Kısıtlı Yetkilendirme

Bu delegasyondaki en büyük fark çoğunlukla idaridir.

Hizmetin bir kaynağa erişim yetkisi verilmesine izin vermek yerine, kaynak sahibine hangi hizmetin yetkilendirme yapmasına izin verildiğini tanımlama yetkisi veririz.

Bu, kullanılarak PowerShell tarafından yapılandırılabilir. MüdürlerAllowedToDelegateToAccount parametresi veya sadece niteliği düzenleyerek msDS-Diğer Kimlik Adına Harekete Geçmesine İzin Verildi

CVE-2020-17049 için Microsoft Güvenlik Yaması – Teknik Analiz

Gerekli geriye dönük uyumluluk desteği nedeniyle protokol güvenlik açıklarını azaltmak her zaman daha zordur.

Resmi internet sitesinde yayınlanan bilgileri okuyarak Microsoft'un yamasını incelemeye başladık.

Güvenlik açığının “biletleri kurcalamakla” ilgili olduğunu ve Kerberos Kısıtlı Delegasyonu sürecinde bir yerde olduğunu anladık.

Güvenlik açığı bulunan bir Etki Alanı Denetleyicisinde yetkilendirmeyi simüle etmeyi ve farkı kontrol etmek için yamalı bir denetleyicide yeniden oluşturmayı seçtik:

İlk göze çarpan değişiklik her paketin uzunluğunda yer alıyor, kendinden imzalı bilet (S4U2Self) isteğinin aynı olduğunu ancak yanıtının 40 bayt daha uzun olduğunu görebiliyoruz.

Bu, bir sonraki S4U2Proxy isteği ve yanıtı için de geçerlidir, peki ne değişti?

Değiştirilen metin biletin içinde şifrelendiğinden, metin karşılaştırması yardımcı olmadı.

Hizmetin keytab'ını kullanarak şifrenin şifresini çözdükten sonra, metin okunabilir ancak yine de anlaşılması gerekir.

AuthorizationData alanına baktığımızda, 840 boyutunda ofset 20'ta başlayan yeni bir Bilinmeyen alan görebiliriz.

Bu yeni alan nereden geliyor? KDC bununla nasıl başa çıkıyor?

Protokollerle ilgili en çok sevdiğim şey, çoğunun RFC'leri düzenli olarak sürdürmesi ve güncellemesidir - ve Kerberos da bir istisna değildir.

Ziyaret MS-SFU 11 tarihinde güncellendiğini fark ettim. açtığımızda Farklı belge biletin bütünlüğünü doğrulamak için kullanılan yeni bir imza olduğunu 3.2.5.2.2 bölümünde öğrendik. Ek olarak, Microsoft'un yaması, ilk değiştirilen biletin S4U2Self olduğunu ima ediyor.
Bilet İmzası referansına bakarak RFC'den daha fazla bilgi çıkardık – MS-PAC 2.8.3:
"KDC, KDC (krbtgt) anahtarını [RFC4120] kullanacak, böylece diğer KDC'ler bir PAC alırken bu imzayı doğrulayabilir."
Bilet imzası, biletlerin KDC dışındaki taraflarca kurcalandığını tespit etmek için kullanılır. Bilet imzası, krbtgt hesabına (şifre değiştirme hizmeti dahil) veya bir güven hesabına şifrelenmemiş biletlere dahil EDİLMELİDİR.”
"bilet imzasına karşılık gelen 0x00000010 değerini içerecektir"
MS-PAC RFC, bütünlüğünü doğrulamak için krbtgt anahtarı kullanılarak şifrelenmiş yeni bir bilet imzası olan ofset 840'taki bilinmeyen alanın ardındaki gizemi ortaya çıkardı.

Kerberos Bronz Bit

8 Aralık'ta bir uygulama CVE-2020-17049 Kerberos'ta KCD güvenlik açığı bronz bit saldırısı daha ayrıntılı olarak yayınlandı ve S4U2Self biletinin manipülasyonu hakkında biraz daha ışık tuttu.

İstismar, biletin encRepPart'ı içindeki iletilebilir alanın bitinin şifresini çözme ve düzenleme ile ilgilidir.

Delegasyon yeteneğine sahip bir hizmet, şu adrese S4U2Self biletleri üretebilir: tüm kullanıcılar 'Hesap hassas ve yetki verilemez' bayrağı açık olanlar bile.
Bu bayrak, iletilebilir bayrağı Yanlış olarak ayarlar, ancak değişiklik durumunda bilet KDC tarafından asla doğrulanmaz.

Final Kelimeler

Yeni güvenlik açığının ifşa edilmesi, güvenlik araştırmacıları arasında her zaman ilgi uyandırır. Tipik olarak, bu tür açıklama, gerekli bitlerin ve baytların ayrıntılı açıklamasını içermez. Bu, operasyonel açıdan anlamlı görünse de, yazılım uygulamasına - bu durumda Kerberos yetkilendirme mekanizmasına - ilişkin daha iyi içgörüler elde etmek için bu tür ifşaatlardan yararlanmak da aynı derecede önemlidir. Bilgi Güçse, umarım bu analiz bizi biraz daha güçlendirmiştir.