AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bu, gönderilerin yükseltme teknikleri bölümlerinin bir özetidir:
Kayıt hakları, Kurumsal CA tarafından düşük ayrıcalıklı kullanıcılara verilmektedir.
Yönetici onayı gerekmemektedir.
Yetkili personelden imza gerekmemektedir.
Sertifika şablonlarındaki güvenlik tanımlayıcıları aşırı izinlidir, bu da düşük ayrıcalıklı kullanıcıların kayıt hakları elde etmesine olanak tanır.
Sertifika şablonları, kimlik doğrulamayı kolaylaştıran EKU'ları tanımlamak için yapılandırılmıştır:
Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) veya no EKU (SubCA) gibi Genişletilmiş Anahtar Kullanımı (EKU) tanımlayıcıları dahildir.
Sertifika İmzalama Talebi (CSR) içinde subjectAltName ekleme yeteneği şablon tarafından izin verilmektedir:
Active Directory (AD), bir sertifikada kimlik doğrulama için subjectAltName (SAN) varsa öncelik verir. Bu, CSR'de SAN belirterek, herhangi bir kullanıcıyı (örneğin, bir alan yöneticisi) taklit etmek için bir sertifika talep edilebileceği anlamına gelir. Talep edenin SAN belirleyip belirleyemeyeceği, sertifika şablonunun AD nesnesinde mspki-certificate-name-flag özelliği aracılığıyla gösterilmektedir. Bu özellik bir bitmask'tır ve CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağının varlığı, talep edenin SAN'ı belirtmesine izin verir.
Belirtilen yapılandırma, düşük ayrıcalıklı kullanıcıların istedikleri herhangi bir SAN ile sertifika talep etmelerine izin vererek, Kerberos veya SChannel aracılığıyla herhangi bir alan ilkesinin kimliğini doğrulamalarını sağlar.
Bu özellik, bazen ürünler veya dağıtım hizmetleri tarafından HTTPS veya ana bilgisayar sertifikalarının anında oluşturulmasını desteklemek için etkinleştirilir veya bir anlayış eksikliğinden dolayı etkinleştirilir.
Bu seçeneği kullanarak bir sertifika oluşturmanın bir uyarı tetiklediği, ancak mevcut bir sertifika şablonunun (örneğin, WebServer şablonu, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT etkin) kopyalanıp ardından bir kimlik doğrulama OID'si eklemek için değiştirilmesi durumunda böyle bir durumun söz konusu olmadığı belirtilmiştir.
Zayıf sertifika şablonlarını bulmak için şunu çalıştırabilirsiniz:
Bu açığı kötüye kullanarak bir yöneticiyi taklit etmek için şunu çalıştırabilirsiniz:
Sonra oluşturulan sertifikayı .pfx formatına dönüştürebilir ve bunu Rubeus veya certipy kullanarak tekrar kimlik doğrulamak için kullanabilirsiniz:
Windows ikili dosyaları "Certreq.exe" ve "Certutil.exe", PFX oluşturmak için kullanılabilir: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
AD Ormanı'nın yapılandırma şemasındaki sertifika şablonlarının, özellikle onay veya imza gerektirmeyen, Client Authentication veya Smart Card Logon EKU'suna sahip olan ve CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağı etkin olanların sayımı, aşağıdaki LDAP sorgusunu çalıştırarak gerçekleştirilebilir:
İkinci kötüye kullanım senaryosu, birincisinin bir varyasyonudur:
Kayıt hakları, Kurumsal CA tarafından düşük ayrıcalıklı kullanıcılara verilir.
Yönetici onayı gereksinimi devre dışı bırakılmıştır.
Yetkili imzaların gerekliliği atlanmıştır.
Sertifika şablonundaki aşırı izinli bir güvenlik tanımlayıcısı, düşük ayrıcalıklı kullanıcılara sertifika kayıt hakları verir.
Sertifika şablonu, Any Purpose EKU'yu veya hiç EKU'yu içerecek şekilde tanımlanmıştır.
Any Purpose EKU, bir saldırganın herhangi bir amaçla, istemci kimlik doğrulaması, sunucu kimlik doğrulaması, kod imzalama vb. dahil olmak üzere bir sertifika almasına izin verir. Bu senaryoyu istismar etmek için ESC3 için kullanılan aynı teknik uygulanabilir.
Hiç EKU'su olmayan sertifikalar, alt CA sertifikaları olarak hareket eder ve herhangi bir amaçla istismar edilebilir ve yeni sertifikaları imzalamak için de kullanılabilir. Bu nedenle, bir saldırgan, bir alt CA sertifikası kullanarak yeni sertifikalarda keyfi EKU'lar veya alanlar belirleyebilir.
Ancak, alan kimlik doğrulaması için oluşturulan yeni sertifikalar, alt CA NTAuthCertificates nesnesi tarafından güvenilir değilse çalışmayacaktır; bu, varsayılan ayardır. Yine de, bir saldırgan hala herhangi bir EKU ile yeni sertifikalar ve keyfi sertifika değerleri oluşturabilir. Bunlar, potansiyel olarak geniş bir yelpazede amaçlar için kötüye kullanılabilir (örneğin, kod imzalama, sunucu kimlik doğrulaması vb.) ve SAML, AD FS veya IPSec gibi ağdaki diğer uygulamalar için önemli sonuçlar doğurabilir.
AD Ormanı'nın yapılandırma şemasında bu senaryoya uyan şablonları listelemek için aşağıdaki LDAP sorgusu çalıştırılabilir:
Bu senaryo, birincisi ve ikincisi gibi ancak farklı bir EKU (Sertifika Talep Ajanı) ve 2 farklı şablon istismar ederek (bu nedenle 2 set gereksinimi vardır),
Sertifika Talep Ajanı EKU (OID 1.3.6.1.4.1.311.20.2.1), Microsoft belgelerinde Kayıt Ajanı olarak bilinir, bir yetkilinin başka bir kullanıcı adına bir sertifika için kayıt olmasına izin verir.
“kayıt ajanı”, böyle bir şablona kayıt olur ve elde edilen sertifikayı diğer kullanıcı adına bir CSR'yi eş imzalamak için kullanır. Daha sonra eş imzalı CSR'yi CA'ya gönderir, “adına kayıt olma” izni veren bir şablona kayıt olur ve CA, “diğer” kullanıcıya ait bir sertifika ile yanıt verir.
Gereksinimler 1:
Kayıt hakları, Enterprise CA tarafından düşük ayrıcalıklı kullanıcılara verilir.
Yönetici onayı gereksinimi atlanır.
Yetkili imzalar için bir gereksinim yoktur.
Sertifika şablonunun güvenlik tanımlayıcısı aşırı derecede izin vericidir, düşük ayrıcalıklı kullanıcılara kayıt hakları verir.
Sertifika şablonu, diğer yetkililer adına diğer sertifika şablonlarının talep edilmesini sağlayan Sertifika Talep Ajanı EKU'sunu içerir.
Gereksinimler 2:
Enterprise CA, düşük ayrıcalıklı kullanıcılara kayıt hakları verir.
Yönetici onayı atlanır.
Şablonun şema versiyonu ya 1'dir ya da 2'yi aşar ve Sertifika Talep Ajanı EKU'sunu gerektiren bir Uygulama Politikası Yayınlama Gereksinimi belirtir.
Sertifika şablonunda tanımlanan bir EKU, alan kimlik doğrulamasına izin verir.
Kayıt ajanları için kısıtlamalar CA üzerinde uygulanmaz.
Bu senaryoyu istismar etmek için Certify veya Certipy kullanabilirsiniz:
Kullanıcılar, kayıt ajanı sertifikası edinme iznine sahip olanlar, kayıt ajanlarının kayıt olmasına izin verilen şablonlar ve kayıt ajanının hareket edebileceği hesaplar, kurumsal CA'lar tarafından kısıtlanabilir. Bu, certsrc.msc snap-in'ini açarak, CA'ya sağ tıklayarak, Özellikler'i tıklayarak ve ardından “Kayıt Ajanları” sekmesine geçerek gerçekleştirilir.
Ancak, CA'lar için varsayılan ayarın “Kayıt ajanlarını kısıtlamayın” olduğu belirtilmektedir. Kayıt ajanları üzerindeki kısıtlama, yöneticiler tarafından etkinleştirildiğinde, “Kayıt ajanlarını kısıtla” olarak ayarlandığında, varsayılan yapılandırma son derece izin verici kalır. Herkes'in herhangi biri olarak tüm şablonlara kayıt olmasına izin verir.
Sertifika şablonları üzerindeki güvenlik tanımlayıcı, şablonla ilgili olarak belirli AD ilkeleri tarafından sahip olunan izinleri tanımlar.
Bir saldırgan, bir şablonu değiştirmek ve önceki bölümlerde belirtilen herhangi bir istismar edilebilir yanlış yapılandırmayı kurmak için gerekli izinlere sahip olursa, ayrıcalık yükseltmesi sağlanabilir.
Sertifika şablonlarına uygulanabilir önemli izinler şunlardır:
Sahip: Nesne üzerinde örtük kontrol sağlar, herhangi bir niteliği değiştirme yetkisi verir.
TamKontrol: Nesne üzerinde tam yetki sağlar, herhangi bir niteliği değiştirme yeteneği dahil.
YazSahibi: Nesnenin sahibini saldırganın kontrolündeki bir ilkeye değiştirme izni verir.
YazDacl: Erişim kontrollerinin ayarlanmasına izin verir, potansiyel olarak bir saldırgana TamKontrol verebilir.
YazNitelik: Herhangi bir nesne niteliğinin düzenlenmesine yetki verir.
Önceki gibi bir ayrıcalık yükseltme örneği:
ESC4, bir kullanıcının bir sertifika şablonu üzerinde yazma ayrıcalıklarına sahip olduğu durumdur. Bu, örneğin, sertifika şablonunun yapılandırmasını değiştirmek için istismar edilebilir ve şablonu ESC1'e karşı savunmasız hale getirebilir.
Yukarıdaki yolda görüldüğü gibi, yalnızca JOHNPC bu ayrıcalıklara sahiptir, ancak kullanıcı JOHN'ın JOHNPC'ye yeni AddKeyCredentialLink bağlantısı vardır. Bu teknik sertifikalarla ilgili olduğundan, bu saldırıyı da uyguladım; bu saldırı Gölge Kimlik Bilgileri olarak bilinir. İşte kurbanın NT hash'ini almak için Certipy'nin shadow auto komutunun küçük bir önizlemesi.
Certipy, bir sertifika şablonunun yapılandırmasını tek bir komutla geçersiz kılabilir. Varsayılan olarak, Certipy yapılandırmayı ESC1'e karşı savunmasız hale getirmek için geçersiz kılar. Ayrıca, saldırımızdan sonra yapılandırmayı geri yüklemek için eski yapılandırmayı kaydetmek üzere -save-old parametresini belirtebiliriz.
Sertifika şablonları ve sertifika otoritesinin ötesinde birkaç nesneyi içeren, ACL tabanlı ilişkilerin geniş ağı, tüm AD CS sisteminin güvenliğini etkileyebilir. Güvenliği önemli ölçüde etkileyebilecek bu nesneler şunları içerir:
CA sunucusunun AD bilgisayar nesnesi, S4U2Self veya S4U2Proxy gibi mekanizmalar aracılığıyla tehlikeye girebilir.
CA sunucusunun RPC/DCOM sunucusu.
Belirli bir konteyner yolundaki herhangi bir alt AD nesnesi veya konteyner CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Bu yol, Sertifika Şablonları konteyneri, Sertifikasyon Otoriteleri konteyneri, NTAuthCertificates nesnesi ve Kayıt Hizmetleri Konteyneri gibi konteynerler ve nesnelerle sınırlı olmamakla birlikte, bunları içerir.
PKI sisteminin güvenliği, düşük ayrıcalıklı bir saldırgan bu kritik bileşenlerden herhangi birine kontrol sağlamayı başarırsa tehlikeye girebilir.
CQure Academy gönderisinde tartışılan konu, Microsoft tarafından belirtilen EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağının etkilerini de kapsamaktadır. Bu yapılandırma, bir Sertifikasyon Otoritesi (CA) üzerinde etkinleştirildiğinde, herhangi bir istekte kullanıcı tanımlı değerlerin konu alternatif adı olarak dahil edilmesine izin verir; bu, Active Directory®'den oluşturulanları da içerir. Sonuç olarak, bu düzenleme, bir saldırganın herhangi bir şablon aracılığıyla kayıt olmasına olanak tanır—özellikle ayrıcalıksız kullanıcı kaydına açık olanlar, standart Kullanıcı şablonu gibi. Sonuç olarak, bir sertifika güvence altına alınabilir ve saldırganın bir alan yöneticisi veya alan içindeki herhangi bir başka aktif varlık olarak kimlik doğrulaması yapmasına olanak tanır.
Not: Sertifika İmzalama Talebi (CSR) içine alternatif adların eklenmesi için certreq.exe içindeki -attrib "SAN:" argümanı aracılığıyla kullanılan yaklaşım, ESC1'deki SAN'ların istismar stratejisinden bir fark sunar. Burada, fark, hesap bilgilerinin nasıl kapsüllendiği ile ilgilidir—bir sertifika niteliği içinde, bir uzantı yerine.
Ayarın etkin olup olmadığını doğrulamak için, kuruluşlar certutil.exe ile aşağıdaki komutu kullanabilir:
Bu işlem esasen uzaktan kayıt defteri erişimi kullanır, bu nedenle alternatif bir yaklaşım şu olabilir:
Certify ve Certipy gibi araçlar, bu yanlış yapılandırmayı tespit etme ve bunu istismar etme yeteneğine sahiptir:
Bu ayarları değiştirmek için, domain yönetici haklarına veya eşdeğerine sahip olunduğu varsayılarak, aşağıdaki komut herhangi bir iş istasyonundan çalıştırılabilir:
Bu yapılandırmayı ortamınızda devre dışı bırakmak için, bayrak şu komutla kaldırılabilir:
Mayıs 2022 güvenlik güncellemelerinden sonra, yeni verilen sertifikalar, istek sahibinin objectSid özelliğini içeren bir güvenlik uzantısı içerecektir. ESC1 için, bu SID belirtilen SAN'dan türetilir. Ancak, ESC6 için, SID istek sahibinin objectSid ile aynıdır, SAN ile değil.
ESC6'yi istismar etmek için, sistemin ESC10'a (Zayıf Sertifika Eşleştirmeleri) karşı hassas olması gerekmektedir; bu, yeni güvenlik uzantısından ziyade SAN'ı önceliklendirir.
Bir sertifika otoritesinin erişim kontrolü, CA eylemlerini yöneten bir dizi izin aracılığıyla sürdürülmektedir. Bu izinler, certsrv.msc'ye erişerek, bir CA'ya sağ tıklayarak, özellikleri seçerek ve ardından Güvenlik sekmesine giderek görüntülenebilir. Ayrıca, izinler PSPKI modülü kullanılarak şu komutlarla sıralanabilir:
Bu, "CA yöneticisi" ve "Sertifika Yöneticisi" rollerine karşılık gelen ManageCA ve ManageCertificates gibi temel haklar hakkında bilgiler sunar.
Bir sertifika otoritesinde ManageCA haklarına sahip olmak, yetkilinin ayarları uzaktan PSPKI kullanarak manipüle etmesine olanak tanır. Bu, herhangi bir şablonda SAN belirtimine izin vermek için EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını değiştirmeyi içerir; bu, alan yükseltmesinin kritik bir yönüdür.
Bu sürecin basitleştirilmesi, doğrudan GUI etkileşimi olmadan değişikliklere izin veren PSPKI’nin Enable-PolicyModuleFlag cmdlet'inin kullanımıyla mümkündür.
ManageCertificates haklarına sahip olmak, bekleyen taleplerin onaylanmasını kolaylaştırır ve "CA sertifika yöneticisi onayı" korumasını etkili bir şekilde aşar.
Bir Certify ve PSPKI modülleri kombinasyonu, bir sertifika talep etmek, onaylamak ve indirmek için kullanılabilir:
Önceki saldırıda Manage CA izinleri ESC6 saldırısını gerçekleştirmek için EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını etkinleştirmek için kullanıldı, ancak bu, CA hizmeti (CertSvc) yeniden başlatılmadıkça herhangi bir etki yaratmayacaktır. Bir kullanıcının Manage CA erişim hakkı olduğunda, kullanıcı aynı zamanda hizmeti yeniden başlatma iznine de sahiptir. Ancak, bu kullanıcının hizmeti uzaktan yeniden başlatabileceği anlamına gelmez. Ayrıca, ESC6 çoğu yamanmış ortamda kutudan çıktığı gibi çalışmayabilir çünkü Mayıs 2022 güvenlik güncellemeleri nedeniyle.
Bu nedenle, burada başka bir saldırı sunulmaktadır.
Gereksinimler:
Sadece ManageCA izni
Manage Certificates izni (bu ManageCA üzerinden verilebilir)
Sertifika şablonu SubCA etkinleştirilmiş olmalıdır (bu ManageCA üzerinden etkinleştirilebilir)
Teknik, Manage CA ve Manage Certificates erişim hakkına sahip kullanıcıların başarısız sertifika talepleri yayınlayabilmesi gerçeğine dayanmaktadır. SubCA sertifika şablonu ESC1'e duyarlıdır, ancak sadece yöneticiler şablona kaydolabilir. Böylece, bir kullanıcı SubCA'ya kaydolmak için talep edebilir - bu reddedilecektir - ancak sonrasında yönetici tarafından verilecektir.
Kendinize Manage Certificates erişim hakkını, kullanıcıyı yeni bir yetkili olarak ekleyerek verebilirsiniz.
SubCA şablonu, -enable-template parametresi ile CA üzerinde etkinleştirilebilir. Varsayılan olarak, SubCA şablonu etkindir.
Eğer bu saldırı için ön koşulları yerine getirmişsek, SubCA şablonuna dayalı bir sertifika talep etmeye başlayabiliriz.
Bu talep reddedilecektir, ancak özel anahtarı kaydedeceğiz ve talep kimliğini not alacağız.
Manage CA ve Manage Certificates ile ardından başarısız sertifika talebini ca komutu ve -issue-request <request ID> parametresi ile verebiliriz.
Ve nihayet, req komutunu ve -retrieve <request ID> parametresini kullanarak verilen sertifikayı alabiliriz.
AD CS yüklü olan ortamlarda, eğer web kayıt noktası zayıf ise ve en az bir sertifika şablonu yayınlanmışsa ve alan bilgisayarı kaydı ve istemci kimlik doğrulaması iznine sahipse (varsayılan Machine şablonu gibi), spooler servisi aktif olan herhangi bir bilgisayarın bir saldırgan tarafından tehlikeye atılması mümkün hale gelir!
AD CS, yöneticilerin yükleyebileceği ek sunucu rolleri aracılığıyla sunulan birkaç HTTP tabanlı kayıt yöntemi desteklemektedir. HTTP tabanlı sertifika kaydı için bu arayüzler NTLM relay saldırılarına karşı hassastır. Bir saldırgan, tehlikeye atılmış bir makineden, gelen NTLM aracılığıyla kimlik doğrulayan herhangi bir AD hesabını taklit edebilir. Kurban hesabını taklit ederken, bu web arayüzleri bir saldırgan tarafından User veya Machine sertifika şablonlarını kullanarak bir istemci kimlik doğrulama sertifikası talep etmek için erişilebilir.
Web kayıt arayüzü ( http://<caserver>/certsrv/ adresinde bulunan eski bir ASP uygulaması), varsayılan olarak yalnızca HTTP'ye ayarlanmıştır ve NTLM relay saldırılarına karşı koruma sağlamaz. Ayrıca, yalnızca NTLM kimlik doğrulamasına izin vererek, Kerberos gibi daha güvenli kimlik doğrulama yöntemlerinin uygulanamaz hale gelmesine neden olur.
Sertifika Kayıt Servisi (CES), Sertifika Kayıt Politikası (CEP) Web Servisi ve Ağ Cihazı Kayıt Servisi (NDES) varsayılan olarak, yetkilendirme HTTP başlıkları aracılığıyla müzakere kimlik doğrulamasını destekler. Müzakere kimlik doğrulaması hem Kerberos'u hem de NTLM'yi destekleyerek, bir saldırganın NTLM kimlik doğrulamasına geçiş yapmasına olanak tanır. Bu web hizmetleri varsayılan olarak HTTPS'yi etkinleştirse de, HTTPS tek başına NTLM relay saldırılarına karşı koruma sağlamaz. HTTPS hizmetleri için NTLM relay saldırılarına karşı koruma, HTTPS'nin kanal bağlama ile birleştirilmesiyle mümkündür. Ne yazık ki, AD CS, kanal bağlama için gerekli olan IIS'de Genişletilmiş Kimlik Doğrulama Korumasını etkinleştirmemektedir.
NTLM relay saldırılarındaki yaygın bir sorun, NTLM oturumlarının kısa süresi ve saldırganın NTLM imzalamayı gerektiren hizmetlerle etkileşimde bulunamamasıdır.
Yine de, bu sınırlama, bir kullanıcı için bir sertifika edinmek amacıyla bir NTLM relay saldırısını kullanarak aşılmaktadır, çünkü sertifikanın geçerlilik süresi oturumun süresini belirler ve sertifika, NTLM imzalamayı zorunlu kılan hizmetlerle kullanılabilir. Çalınan bir sertifikanın nasıl kullanılacağına dair talimatlar için bakınız:
NTLM relay saldırılarının bir diğer sınırlaması, bir saldırgan kontrolündeki makinenin bir kurban hesabı tarafından kimlik doğrulanması gerektiğidir. Saldırgan ya bekleyebilir ya da bu kimlik doğrulamayı zorlamaya çalışabilir:
Certify’nin cas etkin HTTP AD CS uç noktalarını listeler:
msPKI-Enrollment-Servers özelliği, kurumsal Sertifika Otoriteleri (CA'lar) tarafından Sertifika Kaydı Servisi (CES) uç noktalarını depolamak için kullanılır. Bu uç noktalar, Certutil.exe aracını kullanarak ayrıştırılabilir ve listelenebilir:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Certipy, varsayılan olarak, Machine veya User şablonuna dayalı olarak bir sertifika talep eder; bu, iletilen hesap adının $ ile bitip bitmediğine bağlıdır. Alternatif bir şablonun belirtilmesi, -template parametresinin kullanılmasıyla sağlanabilir.
Kimlik doğrulamasını zorlamak için PetitPotam gibi bir teknik kullanılabilir. Alan denetleyicileri ile çalışırken, -template DomainController belirtilmesi gereklidir.
Yeni değer CT_FLAG_NO_SECURITY_EXTENSION (0x80000) için msPKI-Enrollment-Flag, ESC9 olarak adlandırılır, bir sertifikada yeni szOID_NTDS_CA_SECURITY_EXT güvenlik uzantısının gömülmesini engeller. Bu bayrak, StrongCertificateBindingEnforcement 1 (varsayılan ayar) olarak ayarlandığında önem kazanır; bu, 2 ayarıyla çelişir. Daha zayıf bir sertifika eşlemesi için Kerberos veya Schannel'in istismar edilebileceği senaryolarda (ESC10'da olduğu gibi) önemi artar, çünkü ESC9'un yokluğu gereksinimleri değiştirmez.
Bu bayrağın ayarının önemli hale geldiği koşullar şunlardır:
StrongCertificateBindingEnforcement 2 olarak ayarlanmamışsa (varsayılan 1), veya CertificateMappingMethods UPN bayrağını içeriyorsa.
Sertifika, msPKI-Enrollment-Flag ayarındaki CT_FLAG_NO_SECURITY_EXTENSION bayrağı ile işaretlenmişse.
Sertifika tarafından herhangi bir istemci kimlik doğrulama EKU'su belirtilmişse.
Başka bir hesabı tehlikeye atmak için herhangi bir hesap üzerinde GenericWrite izinleri mevcutsa.
Diyelim ki John@corp.local, Jane@corp.local üzerinde GenericWrite izinlerine sahip ve amacı Administrator@corp.local'ı tehlikeye atmaktır. Jane@corp.local'ın kaydolmasına izin verilen ESC9 sertifika şablonu, msPKI-Enrollment-Flag ayarında CT_FLAG_NO_SECURITY_EXTENSION bayrağı ile yapılandırılmıştır.
Başlangıçta, Jane'in hash'i, John'un GenericWrite'ı sayesinde Shadow Credentials kullanılarak elde edilir:
Sonrasında, Jane'in userPrincipalName değeri Administrator olarak değiştirilir, @corp.local alan kısmı kasıtlı olarak atlanır:
Bu değişiklik, Administrator@corp.local'ın Administrator'ın userPrincipalName'i olarak farklı kalması koşuluyla kısıtlamaları ihlal etmez.
Bunun ardından, savunmasız olarak işaretlenen ESC9 sertifika şablonu, Jane olarak talep edilir:
Belirtilmiştir ki, sertifikanın userPrincipalName değeri Administrator olarak yansımaktadır, herhangi bir “object SID” içermemektedir.
Jane'in userPrincipalName değeri daha sonra orijinaline, Jane@corp.local olarak geri döndürülmektedir:
Şimdi verilen sertifika ile kimlik doğrulama denemesi, Administrator@corp.local NT hash'ini veriyor. Sertifikanın alan belirtimi eksik olduğundan, komut -domain <domain> içermelidir:
ESC10 tarafından belirtilen iki kayıt defteri anahtar değeri alan denetleyicisinde bulunmaktadır:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel altındaki CertificateMappingMethods için varsayılan değer 0x18 (0x8 | 0x10), daha önce 0x1F olarak ayarlanmıştı.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc altındaki StrongCertificateBindingEnforcement için varsayılan ayar 1, daha önce 0 idi.
Durum 1
StrongCertificateBindingEnforcement 0 olarak yapılandırıldığında.
Durum 2
Eğer CertificateMappingMethods UPN bitini (0x4) içeriyorsa.
StrongCertificateBindingEnforcement 0 olarak yapılandırıldığında, GenericWrite izinlerine sahip bir A hesabı, herhangi bir B hesabını tehlikeye atmak için kullanılabilir.
Örneğin, Jane@corp.local üzerinde GenericWrite izinlerine sahip bir saldırgan, Administrator@corp.local hesabını tehlikeye atmayı hedefler. Prosedür ESC9'u yansıtır ve herhangi bir sertifika şablonunun kullanılmasına izin verir.
İlk olarak, Jane'in hash'i Shadow Credentials kullanılarak elde edilir, GenericWrite'ı suistimal ederek.
Sonrasında, Jane'in userPrincipalName'i Administrator olarak değiştirilir, kısıtlama ihlalini önlemek için @corp.local kısmı kasıtlı olarak atlanır.
Bunun ardından, varsayılan User şablonunu kullanarak Jane olarak istemci kimlik doğrulamasını sağlayan bir sertifika talep edilir.
Jane'in userPrincipalName'i daha sonra orijinaline, Jane@corp.local olarak geri döndürülür.
Elde edilen sertifika ile kimlik doğrulama, Administrator@corp.local'ın NT hash'ini verecektir; bu, sertifikada alan bilgileri bulunmadığı için komutta alanın belirtilmesini gerektirir.
CertificateMappingMethods içinde UPN bit bayrağı (0x4) bulunan bir A hesabı, userPrincipalName özelliğinden yoksun olan herhangi bir B hesabını, makine hesapları ve yerleşik alan yöneticisi Administrator dahil olmak üzere, tehlikeye atabilir.
Burada amaç, Jane'in hash'ini Shadow Credentials aracılığıyla elde ederek DC$@corp.local'ı tehlikeye atmaktır ve GenericWrite'ı kullanmaktır.
Jane'in userPrincipalName değeri DC$@corp.local olarak ayarlanır.
Jane olarak varsayılan User şablonunu kullanarak bir istemci kimlik doğrulama sertifikası talep edilir.
Jane'in userPrincipalName'i bu işlemden sonra orijinal haline geri döner.
Schannel üzerinden kimlik doğrulamak için, Certipy'nin -ldap-shell seçeneği kullanılır ve kimlik doğrulama başarısı u:CORP\DC$ olarak belirtilir.
LDAP shell üzerinden, set_rbcd gibi komutlar, Kaynak Tabanlı Kısıtlı Delegasyon (RBCD) saldırılarını etkinleştirir ve bu da etki alanı denetleyicisini tehlikeye atabilir.
Bu zafiyet, userPrincipalName'ı olmayan veya sAMAccountName ile eşleşmeyen herhangi bir kullanıcı hesabını da kapsamaktadır; varsayılan Administrator@corp.local, yükseltilmiş LDAP ayrıcalıkları ve varsayılan olarak userPrincipalName'ın olmaması nedeniyle önemli bir hedef olmaktadır.
Eğer CA Sunucusu IF_ENFORCEENCRYPTICERTREQUEST ile yapılandırılmamışsa, RPC hizmeti aracılığıyla imzalamadan NTLM iletme saldırıları gerçekleştirilebilir. Burada referans bulunmaktadır.
Enforce Encryption for Requests devre dışıysa, certipy kullanarak durumu belirleyebilirsiniz ve certipy ESC11 Zafiyetlerini gösterecektir.
Bir relay sunucusu kurmak gerekiyor:
Not: Alan denetleyicileri için, DomainController'da -template belirtmemiz gerekir.
Veya sploutchy'nin impacket çatallamasını kullanarak:
Yönetici, Sertifika Otoritesini "Yubico YubiHSM2" gibi harici bir cihazda depolamak için ayarlayabilir.
USB cihazı CA sunucusuna bir USB portu aracılığıyla bağlıysa veya CA sunucusu sanal bir makineyse bir USB cihaz sunucusu varsa, YubiHSM'de anahtarları oluşturmak ve kullanmak için Anahtar Depolama Sağlayıcısı tarafından bir kimlik doğrulama anahtarı (bazen "şifre" olarak adlandırılır) gereklidir.
Bu anahtar/şifre, HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword altında açık metin olarak kayıt defterinde saklanır.
Burada referans.
Eğer CA'nın özel anahtarı fiziksel bir USB cihazında saklanıyorsa ve shell erişimi elde ettiyseniz, anahtarı geri almak mümkündür.
Öncelikle, CA sertifikasını (bu kamuya açıktır) elde etmeniz ve ardından:
Son olarak, CA sertifikası ve özel anahtarını kullanarak yeni bir keyfi sertifika oluşturmak için certutil -sign komutunu kullanın.
msPKI-Certificate-Policy niteliği, sertifika şablonuna ihraç politikasının eklenmesine olanak tanır. İhraç politikalarından sorumlu msPKI-Enterprise-Oid nesneleri, PKI OID konteynerinin Yapılandırma İsimlendirme Bağlamı'nda (CN=OID,CN=Public Key Services,CN=Services) keşfedilebilir. Bir politika, bu nesnenin msDS-OIDToGroupLink niteliği kullanılarak bir AD grubuna bağlanabilir ve bu, bir sistemin sertifikayı sunan bir kullanıcıyı grubun üyesiymiş gibi yetkilendirmesine olanak tanır. Burada referans.
Diğer bir deyişle, bir kullanıcının bir sertifika almak için izni olduğunda ve sertifika bir OID grubuna bağlandığında, kullanıcı bu grubun ayrıcalıklarını miras alabilir.
OIDToGroupLink bulmak için Check-ADCSESC13.ps1 kullanın:
Bir kullanıcı izni bulun, certipy find veya Certify.exe find /showAllPermissions kullanabilir.
Eğer John, VulnerableTemplate'e kaydolma iznine sahipse, kullanıcı VulnerableGroup grubunun ayrıcalıklarını miras alabilir.
Tek yapması gereken şablonu belirtmek, OIDToGroupLink haklarına sahip bir sertifika alacaktır.
Çapraz orman kaydı için yapılandırma oldukça basittir. Kaynak ormandan gelen kök CA sertifikası, yöneticiler tarafından hesap ormanlarına yayımlanır ve kaynak ormandan gelen kurumsal CA sertifikaları, her hesap ormanındaki NTAuthCertificates ve AIA konteynerlerine eklenir. Bu düzenleme, kaynak ormandaki CA'nın PKI'yi yönettiği diğer tüm ormanlar üzerinde tam kontrol sağlamaktadır. Eğer bu CA saldırganlar tarafından ele geçirilirse, hem kaynak hem de hesap ormanlarındaki tüm kullanıcılar için sertifikalar onlar tarafından sahte olarak düzenlenebilir, böylece ormanın güvenlik sınırı ihlal edilmiş olur.
Çoklu orman ortamlarında, sertifika şablonları yayımlayan Kurumsal CA'lar konusunda dikkatli olunmalıdır; bu şablonlar Kimlik Doğrulanmış Kullanıcılar veya yabancı prensipler (Kurumsal CA'nın ait olduğu ormanın dışındaki kullanıcılar/gruplar) için kayıt ve düzenleme hakları sağlar. Bir güven ilişkisi üzerinden kimlik doğrulama yapıldığında, Kimlik Doğrulanmış Kullanıcı SID'si, AD tarafından kullanıcının token'ına eklenir. Dolayısıyla, bir alan, Kimlik Doğrulanmış Kullanıcıların kayıt haklarına izin veren bir Kurumsal CA'ya sahipse, bir farklı ormandan gelen bir kullanıcı tarafından bir şablon kaydedilebilir. Benzer şekilde, eğer bir şablon tarafından bir yabancı prensipe açıkça kayıt hakları verilirse, çapraz orman erişim kontrol ilişkisi oluşturulur, bu da bir ormandan bir prensibin başka bir ormandan bir şablona kaydolmasına olanak tanır.
Her iki senaryo da bir ormandan diğerine saldırı yüzeyinin artmasına yol açar. Sertifika şablonunun ayarları, bir saldırgan tarafından yabancı bir alanda ek ayrıcalıklar elde etmek için istismar edilebilir.
