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)
Hii ni muhtasari wa sehemu za mbinu za kupandisha hadhi za machapisho:
Haki za kujiandikisha zinatolewa kwa watumiaji wenye mamlaka ya chini na CA ya Enterprise.
Idhini ya meneja haitahitajika.
Saini kutoka kwa wafanyakazi walioidhinishwa hazihitajiki.
Maelezo ya usalama kwenye templeti za cheti ni ya kupita kiasi, yanaruhusu watumiaji wenye mamlaka ya chini kupata haki za kujiandikisha.
Templeti za cheti zimewekwa ili kufafanua EKUs zinazosaidia uthibitishaji:
Vitambulisho vya Matumizi ya Funguo vya Kupanua (EKU) kama Uthibitishaji wa Mteja (OID 1.3.6.1.5.5.7.3.2), Uthibitishaji wa Mteja wa PKINIT (1.3.6.1.5.2.3.4), Kuingia kwa Kadi ya Smart (OID 1.3.6.1.4.1.311.20.2.2), Malengo Yoyote (OID 2.5.29.37.0), au hakuna EKU (SubCA) zinajumuishwa.
Uwezo wa waombaji kujumuisha subjectAltName katika Ombi la Kusaini Cheti (CSR) unaruhusiwa na templeti:
Active Directory (AD) inapa kipaumbele subjectAltName (SAN) katika cheti kwa uthibitishaji wa utambulisho ikiwa ipo. Hii inamaanisha kwamba kwa kutaja SAN katika CSR, cheti kinaweza kuombwa kuiga mtumiaji yeyote (mfano, msimamizi wa kikoa). Ikiwa SAN inaweza kutajwa na muombaji inaonyeshwa katika kitu cha AD cha templeti ya cheti kupitia mali ya mspki-certificate-name-flag. Mali hii ni bitmask, na uwepo wa bendera ya CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT inaruhusu kutajwa kwa SAN na muombaji.
Mipangilio iliyoelezewa inaruhusu watumiaji wenye mamlaka ya chini kuomba vyeti vyovyote vya SAN wanavyotaka, na kuwezesha uthibitishaji kama kiongozi yeyote wa kikoa kupitia Kerberos au SChannel.
Kipengele hiki wakati mwingine kinawashwa ili kusaidia uzalishaji wa cheti za HTTPS au mwenyeji kwa bidhaa au huduma za usambazaji, au kutokana na ukosefu wa uelewa.
Imepangwa kwamba kuunda cheti na chaguo hili kunasababisha onyo, ambayo si hali wakati templeti ya cheti iliyopo (kama templeti ya WebServer, ambayo ina CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT iliyoanzishwa) inakopiwa na kisha kubadilishwa ili kujumuisha OID ya uthibitishaji.
Ili kupata templeti za cheti zenye udhaifu unaweza kukimbia:
Ili kutumia udhaifu huu kujifanya kuwa msimamizi mtu anaweza kukimbia:
Kisha unaweza kubadilisha cheti kilichozalishwa kuwa muundo wa .pfx na kukitumia kujiandikisha kwa kutumia Rubeus au certipy tena:
The Windows binaries "Certreq.exe" & "Certutil.exe" zinaweza kutumika kuunda PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Uhesabu wa mifano ya vyeti ndani ya schema ya usanidi wa AD Forest, haswa zile zisizohitaji idhini au saini, zikiwa na Uthibitishaji wa Mteja au Smart Card Logon EKU, na zikiwa na bendera CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT iliyoanzishwa, zinaweza kufanywa kwa kukimbia uchunguzi ufuatao wa LDAP:
Hali ya pili ya unyanyasaji ni toleo la ya kwanza:
Haki za kujiandikisha zinatolewa kwa watumiaji wenye mamlaka ya chini na Enterprise CA.
Hitaji la idhini ya meneja limeondolewa.
Hitaji la saini zilizoidhinishwa limeachwa.
Maelezo ya usalama yaliyo na ruhusa nyingi kwenye kiolezo cha cheti yanatoa haki za kujiandikisha kwa watumiaji wenye mamlaka ya chini.
Kiolezo cha cheti kimewekwa kujumuisha Any Purpose EKU au hakuna EKU.
Any Purpose EKU inaruhusu cheti kupatikana na mshambuliaji kwa kila kusudi, ikiwa ni pamoja na uthibitishaji wa mteja, uthibitishaji wa seva, saini ya msimbo, n.k. Mbinu ile ile iliyotumika kwa ESC3 inaweza kutumika kutekeleza hali hii.
Vyeti vyenye hakuna EKUs, ambavyo vinatumika kama vyeti vya CA vya chini, vinaweza kutumika kwa kila kusudi na vinaweza pia kutumika kusaini vyeti vipya. Hivyo, mshambuliaji anaweza kubainisha EKUs au maeneo yasiyo na mipaka katika vyeti vipya kwa kutumia cheti cha CA cha chini.
Hata hivyo, vyeti vipya vilivyoundwa kwa uthibitishaji wa kikoa havitafanya kazi ikiwa CA ya chini haitakubaliwa na NTAuthCertificates kitu, ambacho ni mipangilio ya default. Hata hivyo, mshambuliaji bado anaweza kuunda vyeti vipya vyenye EKU yoyote na thamani za cheti zisizo na mipaka. Hizi zinaweza kutumika vibaya kwa anuwai ya malengo (mfano, saini ya msimbo, uthibitishaji wa seva, n.k.) na zinaweza kuwa na athari kubwa kwa programu nyingine katika mtandao kama SAML, AD FS, au IPSec.
Ili kuorodhesha mifano inayolingana na hali hii ndani ya mpangilio wa AD Forest, swali lifuatalo la LDAP linaweza kufanywa:
Hali hii ni kama ya kwanza na ya pili lakini inatumia EKU tofauti (Wakala wa Ombi la Cheti) na mifano 2 tofauti (hivyo ina seti 2 za mahitaji),
Wakala wa Ombi la Cheti EKU (OID 1.3.6.1.4.1.311.20.2.1), inayojulikana kama Wakala wa Usajili katika nyaraka za Microsoft, inaruhusu kiongozi kujiandikisha kwa cheti kwa niaba ya mtumiaji mwingine.
“wakala wa usajili” anajiandikisha katika mifano kama hiyo na anatumia cheti kilichosainiwa kwa pamoja kuwasilisha CSR kwa niaba ya mtumiaji mwingine. Kisha anatumia CSR iliyosainiwa kwa pamoja kwa CA, akijiandikisha katika mfano ambao unaruhusu “kujiandikisha kwa niaba ya”, na CA inajibu kwa cheti inayomilikiwa na “mtumiaji mwingine”.
Mahitaji 1:
Haki za usajili zinatolewa kwa watumiaji wenye mamlaka ya chini na CA ya Enterprise.
Mahitaji ya idhini ya meneja yameondolewa.
Hakuna mahitaji ya saini zilizoidhinishwa.
Maelezo ya usalama ya mfano wa cheti ni ya kupitiliza, ikitoa haki za usajili kwa watumiaji wenye mamlaka ya chini.
Mfano wa cheti unajumuisha Wakala wa Ombi la Cheti EKU, ikiruhusu ombi la mifano mingine ya cheti kwa niaba ya viongozi wengine.
Mahitaji 2:
CA ya Enterprise inatoa haki za usajili kwa watumiaji wenye mamlaka ya chini.
Idhini ya meneja inakwepa.
Toleo la muundo wa mfano ni 1 au linazidi 2, na linaelezea Mahitaji ya Sera ya Maombi ambayo yanahitaji Wakala wa Ombi la Cheti EKU.
EKU iliyofafanuliwa katika mfano wa cheti inaruhusu uthibitisho wa kikoa.
Vikwazo kwa wakala wa usajili havitumiki kwenye CA.
Unaweza kutumia Certify au Certipy kutekeleza hali hii:
The watumiaji ambao wanaruhusiwa kupata cheti cha wakala wa kujiandikisha, mifano ambayo wakala wa kujiandikisha wanaruhusiwa kujiandikisha, na akaunti ambazo wakala wa kujiandikisha anaweza kufanya kazi kwa niaba yake zinaweza kudhibitiwa na CAs za biashara. Hii inafikiwa kwa kufungua certsrc.msc snap-in, kubonyeza kulia kwenye CA, kubonyeza Mali, na kisha kuhamia kwenye tab ya “Wakala wa Kujiandikisha”.
Hata hivyo, inabainishwa kwamba mipangilio ya kawaida kwa CAs ni “Usizuilie wakala wa kujiandikisha.” Wakati kizuizi juu ya wakala wa kujiandikisha kinawashwa na wasimamizi, kuweka kwenye “Zuilia wakala wa kujiandikisha,” usanidi wa kawaida unabaki kuwa wa kuruhusu sana. Inaruhusu Kila mtu kupata kujiandikisha katika mifano yote kama mtu yeyote.
Maelezo ya usalama kwenye mifano ya cheti yanaelezea idhini maalum ambazo mashirika ya AD yanaweza kuwa nayo kuhusu mfano huo.
Iwapo mshambuliaji ana idhini zinazohitajika kubadilisha mfano na kuanzisha mabadiliko yoyote yanayoweza kutumika yaliyotajwa katika sehemu za awali, kupandishwa vyeo kunaweza kuwezesha.
Idhini muhimu zinazohusiana na mifano ya cheti ni pamoja na:
Mmiliki: Inatoa udhibiti wa kimya juu ya kitu, ikiruhusu mabadiliko ya sifa zozote.
FullControl: Inaruhusu mamlaka kamili juu ya kitu, ikiwa ni pamoja na uwezo wa kubadilisha sifa zozote.
WriteOwner: Inaruhusu kubadilisha mmiliki wa kitu kuwa shirika chini ya udhibiti wa mshambuliaji.
WriteDacl: Inaruhusu marekebisho ya udhibiti wa upatikanaji, huenda ikampa mshambuliaji FullControl.
WriteProperty: Inaruhusu kuhariri sifa zozote za kitu.
Mfano wa privesc kama wa awali:
ESC4 ni wakati mtumiaji ana haki za kuandika juu ya mfano wa cheti. Hii inaweza kwa mfano kutumika vibaya kubadilisha usanidi wa mfano wa cheti ili kufanya mfano huo uweze kuathiriwa na ESC1.
Kama tunavyoona katika njia hapo juu, ni JOHNPC pekee mwenye haki hizi, lakini mtumiaji wetu JOHN ana kiunganishi kipya cha AddKeyCredentialLink kwa JOHNPC. Kwa kuwa mbinu hii inahusiana na vyeti, nimeanzisha shambulio hili pia, ambalo linajulikana kama Shadow Credentials. Hapa kuna muonekano mdogo wa amri ya shadow auto ya Certipy ili kupata hash ya NT ya mwathirika.
Certipy inaweza kubadilisha usanidi wa kiolezo cha cheti kwa amri moja. Kwa kawaida, Certipy itabadilisha usanidi ili kuufanya kuwa na udhaifu kwa ESC1. Tunaweza pia kubainisha -save-old parameter ili kuhifadhi usanidi wa zamani, ambayo itakuwa muhimu kwa kurejesha usanidi baada ya shambulio letu.
Mtandao mpana wa uhusiano wa ACL, ambao unajumuisha vitu kadhaa zaidi ya templeti za cheti na mamlaka ya cheti, unaweza kuathiri usalama wa mfumo mzima wa AD CS. Vitu hivi, ambavyo vinaweza kuathiri usalama kwa kiasi kikubwa, vinajumuisha:
Kitu cha kompyuta cha AD cha seva ya CA, ambacho kinaweza kuathiriwa kupitia mitambo kama S4U2Self au S4U2Proxy.
Seva ya RPC/DCOM ya seva ya CA.
Kila kitu cha AD au kontena kilichoko ndani ya njia maalum ya kontena CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Njia hii inajumuisha, lakini sio tu, kontena na vitu kama vile kontena za Templeti za Cheti, kontena za Mamlaka ya Uthibitishaji, kitu cha NTAuthCertificates, na Kontena za Huduma za Usajili.
Usalama wa mfumo wa PKI unaweza kuathiriwa ikiwa mshambuliaji mwenye mamlaka ya chini atafanikiwa kupata udhibiti wa yoyote ya vipengele hivi muhimu.
Mada inayozungumziwa katika post ya CQure Academy pia inagusia athari za EDITF_ATTRIBUTESUBJECTALTNAME2 kama ilivyoelezwa na Microsoft. Mipangilio hii, inapowashwa kwenye Mamlaka ya Uthibitishaji (CA), inaruhusu kuingiza maadili yaliyofafanuliwa na mtumiaji katika jina mbadala la somo kwa ombwe lolote, ikiwa ni pamoja na yale yanayojengwa kutoka Active Directory®. Kwa hivyo, kipengele hiki kinawaruhusu wavamizi kujiandikisha kupitia templeti yoyote iliyowekwa kwa ajili ya uthibitishaji wa kikoa—hasa zile zilizo wazi kwa usajili wa mtumiaji asiye na mamlaka, kama vile templeti ya kawaida ya Mtumiaji. Kama matokeo, cheti kinaweza kulindwa, na kumwezesha mhamasishaji kuthibitisha kama msimamizi wa kikoa au kitu kingine chochote kilichopo ndani ya kikoa.
Note: Njia ya kuongezea majina mbadala katika Ombi la Kusaini Cheti (CSR), kupitia hoja -attrib "SAN:" katika certreq.exe (inayojulikana kama “Name Value Pairs”), ina tofauti na mkakati wa unyakuzi wa SANs katika ESC1. Hapa, tofauti iko katika jinsi taarifa za akaunti zinavyofungwa—ndani ya sifa ya cheti, badala ya nyongeza.
Ili kuthibitisha ikiwa mipangilio imewashwa, mashirika yanaweza kutumia amri ifuatayo na certutil.exe:
Hii operesheni kimsingi inatumia ufikiaji wa rejista ya mbali, hivyo, njia mbadala inaweza kuwa:
Tools like Certify and Certipy wana uwezo wa kugundua makosa haya ya usanidi na kuyatumia:
Ili kubadilisha mipangilio hii, ikiwa mtu ana haki za usimamizi wa kikoa au sawa, amri ifuatayo inaweza kutekelezwa kutoka kwa kituo chochote cha kazi:
Ili kuzima usanidi huu katika mazingira yako, bendera inaweza kuondolewa kwa:
Baada ya sasisho za usalama za Mei 2022, vyeti vilivyotolewa hivi karibuni vitakuwa na kiendelezi cha usalama ambacho kinajumuisha sifa ya objectSid ya ombaaji. Kwa ESC1, SID hii inatokana na SAN iliyoainishwa. Hata hivyo, kwa ESC6, SID inakidhi objectSid ya ombaaji, si SAN.
Ili kutumia ESC6, ni muhimu kwa mfumo kuwa na udhaifu kwa ESC10 (Mifumo ya Vyeti Dhaifu), ambayo inapa kipaumbele SAN kuliko kiendelezi kipya cha usalama.
Udhibiti wa upatikanaji wa mamlaka ya cheti unadumishwa kupitia seti ya ruhusa zinazodhibiti vitendo vya CA. Ruhusa hizi zinaweza kuonekana kwa kufikia certsrv.msc, kubonyeza kulia CA, kuchagua mali, na kisha kuhamia kwenye tab ya Usalama. Zaidi ya hayo, ruhusa zinaweza kuorodheshwa kwa kutumia moduli ya PSPKI na amri kama:
Hii inatoa mwanga juu ya haki za msingi, yaani ManageCA na ManageCertificates, zinazohusiana na majukumu ya "meneja wa CA" na "Meneja wa Cheti" mtawalia.
Kuwa na haki za ManageCA kwenye mamlaka ya cheti kunamuwezesha mtumiaji kubadilisha mipangilio kwa mbali kwa kutumia PSPKI. Hii inajumuisha kubadilisha bendera ya EDITF_ATTRIBUTESUBJECTALTNAME2 ili kuruhusu spesifikesheni ya SAN katika kigezo chochote, jambo muhimu katika kupandisha ngazi ya domain.
Rahisishaji wa mchakato huu unaweza kufikiwa kupitia matumizi ya cmdlet ya PSPKI Enable-PolicyModuleFlag, inayoruhusu mabadiliko bila mwingiliano wa moja kwa moja wa GUI.
Kuwa na haki za ManageCertificates kunarahisisha idhini ya maombi yanayosubiri, kwa ufanisi ikiepuka kinga ya "idhini ya meneja wa cheti cha CA".
Mchanganyiko wa moduli za Certify na PSPKI unaweza kutumika kuomba, kuidhinisha, na kupakua cheti:
Katika shambulio la awali Manage CA ruhusa zilitumika kuwezesha bendera ya EDITF_ATTRIBUTESUBJECTALTNAME2 ili kutekeleza ESC6 attack, lakini hii haitakuwa na athari yoyote hadi huduma ya CA (CertSvc) irejelewe. Wakati mtumiaji ana haki ya Manage CA, mtumiaji pia anaruhusiwa kuanzisha huduma tena. Hata hivyo, haitoi maana kwamba mtumiaji anaweza kuanzisha huduma hiyo kwa mbali. Zaidi ya hayo, ESC6 huenda isifanye kazi moja kwa moja katika mazingira mengi yaliyorekebishwa kutokana na masasisho ya usalama ya Mei 2022.
Hivyo, shambulio lingine linawasilishwa hapa.
Mahitaji:
Tu ManageCA ruhusa
Manage Certificates ruhusa (inaweza kutolewa kutoka ManageCA)
Kigezo cha cheti SubCA lazima kiwe kimewezeshwa (inaweza kuwezeshwa kutoka ManageCA)
Teknolojia hii inategemea ukweli kwamba watumiaji wenye haki ya Manage CA na Manage Certificates wanaweza kutoa maombi ya cheti yaliyoshindwa. Kigezo cha cheti SubCA ni dhaifu kwa ESC1, lakini ni wasimamizi pekee wanaoweza kujiandikisha katika kigezo hicho. Hivyo, mtumiaji anaweza kuomba kujiandikisha katika SubCA - ambayo itakataliwa - lakini kisha itatolewa na meneja baadaye.
Unaweza kujiwezesha ruhusa ya Manage Certificates kwa kuongeza mtumiaji wako kama afisa mpya.
The SubCA template inaweza kuiwezesha kwenye CA kwa kutumia parameter ya -enable-template. Kwa kawaida, template ya SubCA imewezesha.
Ikiwa tumekamilisha masharti ya awali kwa shambulio hili, tunaweza kuanza kwa kuomba cheti kulingana na kiolezo cha SubCA.
Omba hii itakataliwa, lakini tutahifadhi funguo binafsi na kuandika chini kitambulisho cha ombi.
Kwa Manage CA na Manage Certificates, tunaweza kisha kutoa ombi la cheti lililoshindwa kwa kutumia amri ya ca na parameter ya -issue-request <request ID>.
Na hatimaye, tunaweza kurejesha cheti kilichotolewa kwa kutumia amri ya req na parameter ya -retrieve <request ID>.
Katika mazingira ambapo AD CS imewekwa, ikiwa kituo cha kujiandikisha mtandaoni kilicho hatarini kinapatikana na angalau kigezo kimoja cha cheti kimechapishwa kinachoruhusu kujiandikisha kwa kompyuta za kikoa na uthibitishaji wa mteja (kama vile kigezo cha Machine cha kawaida), inakuwa inawezekana kwa kompyuta yoyote yenye huduma ya spooler inayofanya kazi kuathiriwa na mshambuliaji!
Mbinu kadhaa za kujiandikisha zinazotumia HTTP zinasaidiwa na AD CS, zinazopatikana kupitia majukumu ya ziada ya seva ambayo wasimamizi wanaweza kuweka. Mifumo hii ya kujiandikisha kwa cheti inayotumia HTTP inakabiliwa na shambulio la NTLM relay. Mshambuliaji, kutoka kwa kompyuta iliyoathiriwa, anaweza kujifanya kuwa akaunti yoyote ya AD inayothibitishwa kupitia NTLM ya ndani. Wakati wa kujifanya kuwa akaunti ya mwathirika, mifumo hii ya mtandao inaweza kufikiwa na mshambuliaji ili kuomba cheti cha uthibitishaji wa mteja kwa kutumia kigezo cha cheti cha User au Machine.
Mifumo ya kujiandikisha mtandaoni (programu ya zamani ya ASP inayopatikana kwenye http://<caserver>/certsrv/), inatumia HTTP pekee, ambayo haina ulinzi dhidi ya shambulio la NTLM relay. Zaidi ya hayo, inaruhusu tu uthibitishaji wa NTLM kupitia kichwa chake cha HTTP cha Uidhinishaji, na kufanya mbinu za uthibitishaji salama zaidi kama Kerberos zisifae.
Huduma ya Kujiandikisha kwa Cheti (CES), Sera ya Kujiandikisha kwa Cheti (CEP) Web Service, na Huduma ya Kujiandikisha kwa Vifaa vya Mtandao (NDES) kwa kawaida zinasaidia uthibitishaji wa negotiate kupitia kichwa chao cha HTTP cha Uidhinishaji. Uthibitishaji wa negotiate unasaidia wote Kerberos na NTLM, ikimruhusu mshambuliaji kushuka hadi NTLM uthibitishaji wakati wa shambulio la relay. Ingawa huduma hizi za mtandao zinawezesha HTTPS kwa kawaida, HTTPS pekee haiwezi kulinda dhidi ya shambulio la NTLM relay. Ulinzi kutoka kwa shambulio la NTLM relay kwa huduma za HTTPS unaweza kupatikana tu wakati HTTPS inachanganywa na uhusiano wa channel binding. Kwa bahati mbaya, AD CS haizindui Ulinzi wa Kupanuliwa kwa Uthibitishaji kwenye IIS, ambayo inahitajika kwa channel binding.
Tatizo la kawaida na shambulio la NTLM relay ni muda mfupi wa vikao vya NTLM na kutoweza kwa mshambuliaji kuingiliana na huduma zinazohitaji saini ya NTLM.
Hata hivyo, kikomo hiki kinashindwa kwa kutumia shambulio la NTLM relay kupata cheti kwa mtumiaji, kwani kipindi cha uhalali wa cheti kinadhibiti muda wa kikao, na cheti kinaweza kutumika na huduma zinazohitaji saini ya NTLM. Kwa maelekezo juu ya kutumia cheti kilichoporwa, rejelea:
AD CS Account PersistenceKikomo kingine cha shambulio la NTLM relay ni kwamba kompyuta inayodhibitiwa na mshambuliaji lazima ithibitishwe na akaunti ya mwathirika. Mshambuliaji anaweza kusubiri au kujaribu kulazimisha uthibitishaji huu:
Force NTLM Privileged AuthenticationCertify’s cas inataja kituo cha HTTP AD CS kilichowezeshwa:
Mali ya msPKI-Enrollment-Servers inatumika na Mamlaka ya Vyeti ya biashara (CAs) kuhifadhi mwisho wa Huduma ya Usajili wa Vyeti (CES). Mwisho hawa wanaweza kuchambuliwa na kuorodheshwa kwa kutumia chombo Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Ombi la cheti linafanywa na Certipy kwa default kulingana na kigezo Machine au User, kinachotambulika kwa kuangalia kama jina la akaunti inayopitishwa linaishia na $. Mwelekeo wa kigezo mbadala unaweza kufikiwa kupitia matumizi ya parameter -template.
Teknolojia kama PetitPotam inaweza kisha kutumika kulazimisha uthibitishaji. Wakati wa kushughulika na wasimamizi wa kikoa, mwelekeo wa -template DomainController unahitajika.
Thamani mpya CT_FLAG_NO_SECURITY_EXTENSION (0x80000) kwa msPKI-Enrollment-Flag, inayoitwa ESC9, inazuia kuingizwa kwa nyongeza ya usalama mpya szOID_NTDS_CA_SECURITY_EXT katika cheti. Bendera hii inakuwa muhimu wakati StrongCertificateBindingEnforcement imewekwa kuwa 1 (mipangilio ya kawaida), ambayo inapingana na mipangilio ya 2. Umuhimu wake unazidi katika hali ambapo ramani dhaifu ya cheti kwa Kerberos au Schannel inaweza kutumika (kama katika ESC10), kwa kuwa ukosefu wa ESC9 haugeuzi mahitaji.
Masharti ambayo mipangilio ya bendera hii inakuwa muhimu ni pamoja na:
StrongCertificateBindingEnforcement haijarekebishwa kuwa 2 (ikiwa mipangilio ya kawaida ni 1), au CertificateMappingMethods inajumuisha bendera ya UPN.
Cheti kimewekwa alama na bendera ya CT_FLAG_NO_SECURITY_EXTENSION ndani ya mipangilio ya msPKI-Enrollment-Flag.
EKU yoyote ya uthibitishaji wa mteja imeainishwa na cheti.
Ruhusa za GenericWrite zinapatikana juu ya akaunti yoyote ili kuathiri nyingine.
Fikiria John@corp.local ana ruhusa za GenericWrite juu ya Jane@corp.local, kwa lengo la kuathiri Administrator@corp.local. Kigezo cha cheti cha ESC9, ambacho Jane@corp.local anaruhusiwa kujiandikisha, kimewekwa na bendera ya CT_FLAG_NO_SECURITY_EXTENSION katika mipangilio yake ya msPKI-Enrollment-Flag.
Kwanza, hash ya Jane inapatikana kwa kutumia Shadow Credentials, shukrani kwa GenericWrite ya John:
Hivyo, Jane's userPrincipalName inabadilishwa kuwa Administrator, ikikusudia kuacha sehemu ya @corp.local ya kikoa:
Hii marekebisho hayakiuka vikwazo, kwa kuwa Administrator@corp.local inabaki kuwa tofauti kama Administrator's userPrincipalName.
Baada ya hii, kiolezo cha cheti ESC9, kilichotajwa kuwa hatarini, kinahitajika kama Jane:
Imepangwa kwamba userPrincipalName wa cheti unarejelea Administrator, bila “object SID” yoyote.
Jane's userPrincipalName inarudishwa kwa yake ya awali, Jane@corp.local:
Kujaribu uthibitisho na cheti kilichotolewa sasa kunatoa NT hash ya Administrator@corp.local. Amri lazima ijumuisha -domain <domain> kutokana na ukosefu wa maelezo ya kikoa katika cheti:
Two registry key values on the domain controller are referred to by ESC10:
The default value for CertificateMappingMethods under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel is 0x18 (0x8 | 0x10), previously set to 0x1F.
The default setting for StrongCertificateBindingEnforcement under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc is 1, previously 0.
Case 1
When StrongCertificateBindingEnforcement is configured as 0.
Case 2
If CertificateMappingMethods includes the UPN bit (0x4).
With StrongCertificateBindingEnforcement configured as 0, an account A with GenericWrite permissions can be exploited to compromise any account B.
For instance, having GenericWrite permissions over Jane@corp.local, an attacker aims to compromise Administrator@corp.local. The procedure mirrors ESC9, allowing any certificate template to be utilized.
Initially, Jane's hash is retrieved using Shadow Credentials, exploiting the GenericWrite.
Hivyo, Jane's userPrincipalName inabadilishwa kuwa Administrator, kwa makusudi ikiacha sehemu ya @corp.local ili kuepuka uvunjaji wa kizuizi.
Kufuata hili, cheti kinachowezesha uthibitishaji wa mteja kinahitajika kama Jane, kwa kutumia kigezo cha User kilichowekwa chaguomsingi.
Jane's userPrincipalName inarudishwa kwa asili yake, Jane@corp.local.
Kuthibitisha na cheti kilichopatikana kutatoa NT hash ya Administrator@corp.local, ikihitaji kuweka jina la eneo katika amri kutokana na ukosefu wa maelezo ya eneo katika cheti.
Ikiwa CertificateMappingMethods ina bendera ya UPN (0x4), akaunti A yenye ruhusa za GenericWrite inaweza kuathiri akaunti yoyote B isiyo na mali ya userPrincipalName, ikiwa ni pamoja na akaunti za mashine na msimamizi wa ndani wa domain Administrator.
Hapa, lengo ni kuathiri DC$@corp.local, kuanzia na kupata hash ya Jane kupitia Shadow Credentials, ikitumia GenericWrite.
Jane's userPrincipalName kisha inawekwa kuwa DC$@corp.local.
A certificate for client authentication is requested as Jane using the default User template.
Jane's userPrincipalName inarudi kwenye asili yake baada ya mchakato huu.
Ili kuthibitisha kupitia Schannel, chaguo la -ldap-shell la Certipy linatumika, likionyesha mafanikio ya uthibitishaji kama u:CORP\DC$.
Kupitia shell ya LDAP, amri kama set_rbcd zinawezesha mashambulizi ya Resource-Based Constrained Delegation (RBCD), ambayo yanaweza kuhatarisha udhibiti wa kikoa.
Hii udhaifu pia inahusisha akaunti yoyote ya mtumiaji isiyo na userPrincipalName au ambapo haifanani na sAMAccountName, huku Administrator@corp.local ikiwa lengo kuu kutokana na haki zake za juu za LDAP na ukosefu wa userPrincipalName kwa kawaida.
Ikiwa CA Server haijasanidiwa na IF_ENFORCEENCRYPTICERTREQUEST, inaweza kufanya mashambulizi ya NTLM relay bila kusaini kupitia huduma ya RPC. Reference in here.
Unaweza kutumia certipy kuorodhesha ikiwa Enforce Encryption for Requests imezimwa na certipy itaonyesha udhaifu wa ESC11.
Inahitajika kuweka seva ya relay:
Note: Kwa wasimamizi wa eneo, lazima tuweke -template katika DomainController.
Au kutumia sploutchy's fork of impacket :
Wasimamizi wanaweza kuanzisha Mamlaka ya Cheti ili kuihifadhi kwenye kifaa cha nje kama "Yubico YubiHSM2".
Ikiwa kifaa cha USB kimeunganishwa na seva ya CA kupitia bandari ya USB, au seva ya kifaa cha USB katika kesi ambapo seva ya CA ni mashine ya virtual, funguo ya uthibitishaji (wakati mwingine inaitwa "nenosiri") inahitajika kwa Mtoa Huduma wa Hifadhi ya Funguo ili kuunda na kutumia funguo katika YubiHSM.
Funguo/hifadhi hii inahifadhiwa katika rejista chini ya HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword kwa maandiko wazi.
Reference in here.
Ikiwa funguo ya faragha ya CA imehifadhiwa kwenye kifaa cha USB cha kimwili wakati umepata ufikiaji wa shell, inawezekana kurejesha funguo hiyo.
Kwanza, unahitaji kupata cheti cha CA (hii ni ya umma) na kisha:
Finally, tumia amri ya certutil -sign kuunda cheti kipya cha kiholela kwa kutumia cheti cha CA na funguo zake za faragha.
Sifa ya msPKI-Certificate-Policy inaruhusu sera ya utoaji kuongezwa kwenye kiolezo cha cheti. Vitu vya msPKI-Enterprise-Oid vinavyohusika na utoaji wa sera vinaweza kupatikana katika Muktadha wa Ujumbe wa Mipangilio (CN=OID,CN=Public Key Services,CN=Services) wa kontena la PKI OID. Sera inaweza kuunganishwa na kundi la AD kwa kutumia sifa ya msDS-OIDToGroupLink ya kitu hiki, ikiruhusu mfumo kumthibitisha mtumiaji anayeleta cheti kana kwamba yeye ni mwanachama wa kundi hilo. Reference in here.
Kwa maneno mengine, wakati mtumiaji ana ruhusa ya kujiandikisha kwa cheti na cheti kimeunganishwa na kundi la OID, mtumiaji anaweza kurithi haki za kundi hili.
Tumia Check-ADCSESC13.ps1 kupata OIDToGroupLink:
Pata ruhusa ya mtumiaji ambayo inaweza kutumia certipy find au Certify.exe find /showAllPermissions.
Ikiwa John ana ruhusa ya kujiandikisha VulnerableTemplate, mtumiaji anaweza kurithi haki za kundi la VulnerableGroup.
Yote yanahitaji kufanya ni kubaini kiolezo, itapata cheti chenye haki za OIDToGroupLink.
Mipangilio ya kujiandikisha kwa msitu wa kuvuka imefanywa kuwa rahisi. Cheti cha CA cha mzizi kutoka kwa msitu wa rasilimali kinachapishwa kwa misitu ya akaunti na wasimamizi, na vyeti vya CA ya biashara kutoka kwa msitu wa rasilimali vinongezwa kwenye NTAuthCertificates na AIA containers katika kila msitu wa akaunti. Ili kufafanua, mpangilio huu unampa CA katika msitu wa rasilimali udhibiti kamili juu ya misitu mingine yote ambayo inasimamia PKI. Ikiwa CA hii itashindwa na washambuliaji, vyeti vya watumiaji wote katika misitu ya rasilimali na akaunti vinaweza kuundwa na wao, hivyo kuvunja mpaka wa usalama wa msitu.
Katika mazingira ya misitu mingi, tahadhari inahitajika kuhusu CAs za Biashara ambazo zinachapisha mifano ya vyeti ambayo inaruhusu Watumiaji Waliothibitishwa au wakuu wa kigeni (watumiaji/vikundi vya nje ya msitu ambao CA ya Biashara inamiliki) haki za kujiandikisha na kuhariri. Baada ya uthibitisho kupitia imani, SID ya Watumiaji Waliothibitishwa inaongezwa kwenye token ya mtumiaji na AD. Hivyo, ikiwa kikoa kina CA ya Biashara yenye mfano ambao unaruhusu haki za kujiandikisha kwa Watumiaji Waliothibitishwa, mfano unaweza kujiandikisha na mtumiaji kutoka msitu tofauti. Vivyo hivyo, ikiwa haki za kujiandikisha zinatolewa wazi kwa mkuu wa kigeni na mfano, uhusiano wa udhibiti wa ufikiaji wa msitu wa kuvuka unaundwa, ukimwezesha mkuu kutoka msitu mmoja kujiandikisha katika mfano kutoka msitu mwingine.
Mifano yote inasababisha kuongezeka kwa uso wa shambulio kutoka msitu mmoja hadi mwingine. Mipangilio ya mfano wa cheti inaweza kutumika na mshambuliaji kupata haki za ziada katika kikoa cha kigeni.
