AD CS Domain Escalation
Hii ni muhtasari wa sehemu za mbinu za kupanda kwa machapisho:
Templeti za Cheti Zilizopangwa Visivyo Sawa - ESC1
Maelezo
Templeti za Cheti Zilizopangwa Visivyo Sawa - ESC1 Zilizoelezwa
Haki za kujiandikisha zinatolewa kwa watumiaji wenye mamlaka ndogo na Enterprise CA.
Idhini ya Meneja haihitajiki.
Hakuna saini kutoka kwa wafanyikazi walioruhusiwa inahitajika.
Maelezo ya usalama kwenye templeti za cheti ni ya kutoa ruhusa sana, ikiruhusu watumiaji wenye mamlaka ndogo kupata haki za kujiandikisha.
Templeti za cheti zimepangwa kufafanua EKUs ambazo hufanikisha uwakilishi:
Vitambulisho vya Matumizi ya Msingi ya Kigeni (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), Ingia kwa Kadi ya Smart (OID 1.3.6.1.4.1.311.20.2.2), Kusudi Lolote (OID 2.5.29.37.0), au hakuna EKU (SubCA) zimejumuishwa.
Uwezo wa wanaomba kujumuisha jina la Alt ya Mada katika Ombi la Kusaini Cheti (CSR) unaruhusiwa na templeti:
Active Directory (AD) inapendelea jina la Alt ya Mada (SAN) kwenye cheti kwa uthibitisho wa kitambulisho ikiwa ipo. Hii inamaanisha kwamba kwa kufafanua SAN katika CSR, cheti linaweza kuombwa kuiga mtumiaji yeyote (k.m., msimamizi wa kikoa). Ikiwa SAN inaweza kufafanuliwa na mwombaji inaonyeshwa kwenye mali ya AD ya templeti ya cheti kupitia mali ya
mspki-certificate-name-flag
. Mali hii ni bitmask, na uwepo wa bendera yaCT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
inaruhusu ufafanuzi wa SAN na mwombaji.
Usanidi ulioelezwa unaruhusu watumiaji wenye mamlaka ndogo kuomba vyeti na SAN yoyote wanayotaka, ikiruhusu uthibitisho kama mwakilishi yeyote wa kikoa kupitia Kerberos au SChannel.
Kipengele hiki mara nyingine kimeamilishwa kusaidia uzalishaji wa haraka wa vyeti vya HTTPS au mwenyeji na bidhaa au huduma za kupeleka, au kutokana na ukosefu wa uelewa.
Inabainishwa kwamba kuunda cheti na chaguo hili kunasababisha onyo, jambo ambalo si hivyo wakati templeti ya cheti iliyopo (kama templeti ya WebServer
, ambayo ina CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
imeamilishwa) inapodhaniwa kisha kuhaririwa kujumuisha OID ya uthibitishaji.
Mabaya
Kutafuta templeti za cheti zilizodhaifu unaweza kukimbia:
Kwa kutumia udhaifu huu kujifanya kuwa msimamizi, mtu anaweza kukimbia:
Kisha unaweza kubadilisha cheti kilichozalishwa kuwa muundo wa .pfx
na kutumia kwa uthibitishaji kwa kutumia Rubeus au certipy tena:
Windows binaries "Certreq.exe" & "Certutil.exe" zinaweza kutumika kuzalisha PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Uchambuzi wa templeti za vyeti ndani ya schema ya usanidi wa AD Forest, hasa zile ambazo hazihitaji idhini au saini, zenye Kibali cha Mteja cha uthibitishaji au Kadi ya Akili ya kuingia, na na bendera ya CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
kuwezeshwa, unaweza kufanywa kwa kukimbia swali la LDAP lifuatalo:
Templeti za Cheti Zilizowekwa Visivyo Sawa - ESC2
Maelezo
Skenario la unyanyasaji la pili ni tofauti na la kwanza:
Haki za usajili zinatolewa kwa watumiaji wenye mamlaka ndogo na Enterprise CA.
Mahitaji ya idhini ya meneja yamelemazwa.
Hitaji la saini zilizoidhinishwa limeachwa.
Msimamizi wa usalama ulio na ruhusa kubwa kwenye templeti ya cheti unatoa haki za usajili wa cheti kwa watumiaji wenye mamlaka ndogo.
Templeti ya cheti imefafanuliwa kujumuisha EKU ya Kusudi Lolote au hakuna EKU.
EKU ya Kusudi Lolote inaruhusu cheti kupatikana na mshambuliaji kwa madhumuni yoyote, ikiwa ni pamoja na uthibitishaji wa mteja, uthibitishaji wa seva, sahihi ya nambari, n.k. Mbinu ile ile iliyotumika kwa ESC3 inaweza kutumika kudukua hali hii.
Cheti zenye hakuna EKUs, ambazo hufanya kama vyeti vya CA vya msaidizi, zinaweza kutumiwa kwa madhumuni yoyote na zinaweza pia kutumika kusaini vyeti vipya. Hivyo, mshambuliaji anaweza kubainisha EKUs au sehemu za vyeti vipya kwa kutumia cheti cha CA msaidizi.
Hata hivyo, vyeti vipya vilivyoundwa kwa uthibitishaji wa kikoa havitafanya kazi ikiwa CA msaidizi haitegemewi na kipengele cha NTAuthCertificates
, ambacho ni mipangilio ya msingi. Hata hivyo, mshambuliaji bado anaweza kuunda vyeti vipya vyenye EKU yoyote na thamani za cheti za kupindukia. Hivi vinaweza kunyanyaswa kwa madhumuni mbalimbali (k.m., sahihi ya nambari, uthibitishaji wa seva, n.k.) na inaweza kuwa na athari kubwa kwa programu nyingine kwenye mtandao kama vile SAML, AD FS, au IPSec.
Kutambua templeti zinazolingana na hali hii ndani ya mpangilio wa msitu wa AD, uchunguzi wa LDAP ufuatao unaweza kutekelezwa:
Templeti za Mawakala wa Usajili Zilizopangwa Visivyo - ESC3
Maelezo
Hali hii ni kama ya kwanza na ya pili lakini ikichukua faida ya EKU tofauti (Mwombaji wa Cheti la Mawakala) na mabano 2 tofauti (hivyo ina mahitaji 2 ya seti),
EKU ya Mwombaji wa Cheti (OID 1.3.6.1.4.1.311.20.2.1), inayojulikana kama Mawakala wa Usajili katika nyaraka za Microsoft, inaruhusu mwakilishi kujisajili kwa cheti kwa niaba ya mtumiaji mwingine.
"mawakala wa usajili" wanajisajili kwenye template kama hiyo na kutumia cheti kilichopatikana kusaini pamoja na CSR kwa niaba ya mtumiaji mwingine. Kisha wanatuma CSR iliyosainiwa pamoja kwa CA, wakijiandikisha kwenye template inayoruhusu "kujisajili kwa niaba ya", na CA inajibu na cheti linamilikiwa na mtumiaji "mwingine".
Mahitaji 1:
Haki za usajili zinatolewa kwa watumiaji wenye mamlaka ya chini na Enterprise CA.
Mahitaji ya idhini ya meneja hayazingatiwi.
Hakuna mahitaji ya saini zilizoidhinishwa.
Msimbo wa usalama wa templeti ya cheti ni wa kupitisha sana, ukitoa haki za usajili kwa watumiaji wenye mamlaka ya chini.
Templeti ya cheti inajumuisha EKU ya Mwombaji wa Cheti, ikiruhusu ombi la templeti zingine za cheti kwa niaba ya wakala wengine.
Mahitaji 2:
Enterprise CA inatoa haki za usajili kwa watumiaji wenye mamlaka ya chini.
Idhini ya meneja inapuuzwa.
Toleo la mpango wa templeti ni 1 au linazidi 2, na linabainisha Mahitaji ya Kutolewa kwa Sera ya Maombi inayohitaji EKU ya Mwombaji wa Cheti.
EKU iliyoelezwa katika templeti ya cheti inaruhusu uwakilishi wa uwanja.
Vizuizi kwa mawakala wa usajili havijatekelezwa kwenye CA.
Mabaya
Unaweza kutumia Certify au Certipy kuchukua faida ya hali hii:
Watumiaji ambao wanaruhusiwa kupata cheti cha wakala wa usajili, templeti ambazo mawakala wa usajili wanaruhusiwa kusajili, na akaunti kwa niaba ya ambayo wakala wa usajili anaweza kutenda zinaweza kuzuiwa na CAs za kampuni. Hii inafikiwa kwa kufungua certsrc.msc
snap-in, bonyeza kulia kwenye CA, bonyeza Mipangilio, na kisha navigating kwenye kichupo cha "Mawakala wa Usajili".
Walakini, inasisitizwa kuwa mipangilio ya msingi kwa CAs ni "Usizuie mawakala wa usajili." Wakati kizuizi kwenye mawakala wa usajili kinaamilishwa na waendeshaji, kukiweka kuwa "Zuia mawakala wa usajili," usanidi wa msingi unabaki kuwa wa kipekee sana. Inaruhusu Kila mtu kupata usajili katika templeti zote kama yeyote.
Udhibiti wa Upatikanaji wa Templeti ya Cheti Inayoweza Kudhurika - ESC4
Maelezo
Maelezo ya usalama kwenye templeti za cheti inaamua idhini maalum ambazo mabwana wa AD wanamiliki kuhusu templeti.
Ikiwa mshambuliaji ana idhini inayohitajika ya kubadilisha templeti na kuweka mikokoteni inayoweza kudhurika iliyoelezwa katika sehemu zilizotangulia, upandishaji wa hadhi unaweza kurahisishwa.
Idhini muhimu zinazoweza kutumika kwa templeti za cheti ni pamoja na:
Mmiliki: Hutoa udhibiti wa moja kwa moja juu ya kitu, kuruhusu kubadilisha sifa yoyote.
KudhibitiKamili: Inawezesha mamlaka kamili juu ya kitu, ikiwa ni pamoja na uwezo wa kubadilisha sifa yoyote.
AndikaMmiliki: Inaruhusu kubadilisha mmiliki wa kitu kuwa mkuu chini ya udhibiti wa mshambuliaji.
AndikaDacl: Inaruhusu marekebisho ya udhibiti wa upatikanaji, ikiruhusu mshambuliaji KudhibitiKamili.
AndikaMali: Inaidhinisha kuhariri mali yoyote ya kitu.
Mabaya
Mfano wa privesc kama ule uliopita:
ESC4 ni wakati mtumiaji ana ruhusa za andika juu ya templeti ya cheti. Hii inaweza kwa mfano kutumika kubadilisha usanidi wa templeti ya cheti ili kufanya templeti iweze kudhurika kwa ESC1.
Kama tunavyoona kwenye njia hapo juu, tu JOHNPC
ana ruhusa hizi, lakini mtumiaji wetu JOHN
ana pembe mpya ya AddKeyCredentialLink
kwa JOHNPC
. Kwa kuwa mbinu hii inahusiana na vyeti, nimeitekeleza shambulio hili pia, ambalo linajulikana kama Shadow Credentials. Hapa kuna kidokezo kidogo cha amri ya shadow auto
ya Certipy kupata NT hash ya muathiriwa.
Certipy inaweza kubadilisha usanidi wa kiolezo cha cheti kwa amri moja. Kwa chaguo-msingi, Certipy itabadilisha usanidi ili kuifanya iwe inayoweza kushambuliwa na ESC1. Tunaweza pia kutaja parameter ya -save-old
ili kuokoa usanidi wa zamani, ambao utakuwa na manufaa kwa kurejesha usanidi baada ya shambulio letu.
Kudhibiti Upatikanaji wa Vitu Hatarishi vya PKI - ESC5
Maelezo
Mtandao mpana wa mahusiano uliounganishwa na udhibiti wa upatikanaji wa ACL, ambao unajumuisha vitu kadhaa zaidi ya templeti za vyeti na mamlaka ya vyeti, unaweza kuathiri usalama wa mfumo mzima wa AD CS. Vitu hivi, ambavyo vinaweza kuathiri usalama kwa kiasi kikubwa, ni pamoja na:
Kipengee cha kompyuta cha AD cha seva ya CA, ambacho kinaweza kudukuliwa kupitia mbinu kama S4U2Self au S4U2Proxy.
Seva ya RPC/DCOM ya seva ya CA.
Kipengee chochote cha AD kilichoshuka au chombo ndani ya njia maalum ya chombo
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>
. Njia hii inajumuisha, lakini sio tu, vyombo na vitu kama chombo cha Templeti za Vyeti, chombo cha Mamlaka ya Uthibitishaji, kipengee cha NTAuthCertificates, na chombo cha Huduma za Usajili.
Usalama wa mfumo wa PKI unaweza kudukuliwa ikiwa mshambuliaji mwenye mamlaka ya chini anafanikiwa kupata udhibiti juu ya mojawapo ya vipengee muhimu hivi.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Maelezo
Mada iliyozungumziwa katika chapisho la CQure Academy pia inagusa EDITF_ATTRIBUTESUBJECTALTNAME2
na matokeo yake, kama ilivyoelezwa na Microsoft. Mpangilio huu, unapowashwa kwenye Mamlaka ya Uthibitishaji (CA), inaruhusu ujumuishaji wa thamani zilizoundwa na mtumiaji katika jina mbadala la mada kwa ombi lolote, ikiwa ni pamoja na lile lililoundwa kutoka kwa Active Directory®. Kwa hivyo, utoaji huu unaruhusu muingiliaji kujiandikisha kupitia templeti yoyote iliyowekwa kwa ajili ya uthibitishaji wa uwanjani—hasa zile zinazowezesha ujiandikishaji wa mtumiaji asiye na mamlaka, kama vile templeti ya Mtumiaji ya kawaida. Kama matokeo, cheti linaweza kusimbwa, kuruhusu muingiliaji kujithibitisha kama msimamizi wa uwanja au kiumbe mwingine mwenye shughuli ndani ya uwanja.
Maelezo: Mbinu ya kuongeza majina mbadala katika Ombi la Kusaini Cheti (CSR), kupitia hoja ya -attrib "SAN:"
katika certreq.exe
(inayoitwa "Jozi za Jina Thamani"), inaleta tofauti kutoka kwa mkakati wa kutumia SANs katika ESC1. Hapa, tofauti iko katika jinsi habari ya akaunti inavyofungwa—ndani ya sifa ya cheti, badala ya kipanuzi.
Mabaya
Ili kuthibitisha ikiwa mpangilio umewashwa, mashirika yanaweza kutumia amri ifuatayo na certutil.exe
:
Operesheni hii kimsingi inatumia upatikanaji wa usajili wa mbali, hivyo, njia mbadala inaweza kuwa:
Vyombo kama Certify na Certipy wanaweza kugundua hii hitilafu ya usanidi na kuitumia:
Kubadilisha mipangilio hii, ikiaminika mtu ana haki za utawala wa kikoa au sawa nazo, amri ifuatayo inaweza kutekelezwa kutoka kwenye kituo chochote cha kazi:
Ili kulemaza usanidi huu katika mazingira yako, bendera inaweza kuondolewa kwa:
Baada ya sasisho za usalama za Mei 2022, vyeti vipya vilivyo na kificho cha usalama kitajumuisha kipanuzi cha usalama ambacho kinajumuisha mali ya objectSid
ya mwombaji. Kwa ESC1, SID hii inatokana na SAN iliyotajwa. Hata hivyo, kwa ESC6, SID inaakisi objectSid
ya mwombaji, siyo SAN.
Ili kutumia ESC6, ni muhimu kwa mfumo kuwa na uwezekano wa ESC10 (Vipimo Dhaifu vya Vyeti), ambavyo vinapendelea SAN kuliko kipanuzi kipya cha usalama.
Kudhibitiwa kwa Mamlaka ya Cheti Inayoweza Kudhurika - ESC7
Shambulizi 1
Maelezo
Kudhibitiwa kwa ufikiaji wa mamlaka ya cheti unadumishwa kupitia seti ya ruhusa zinazosimamia hatua za CA. Ruhusa hizi zinaweza kuonekana kwa kupitia certsrv.msc
, kubonyeza kulia CA, kuchagua mali, na kisha kutembea kwenye kichupo cha Usalama. Aidha, ruhusa zinaweza kuhesabiwa kwa kutumia moduli ya PSPKI kwa amri kama vile:
Hii hutoa ufahamu kuhusu haki kuu, yaani ManageCA
na ManageCertificates
, zinazohusiana na majukumu ya "msimamizi wa CA" na "Meneja wa Cheti" mtawalia.
Mabaya
Kuwa na haki za ManageCA
kwenye mamlaka ya cheti inamwezesha mkuu kubadilisha mipangilio kijijini kwa kutumia PSPKI. Hii ni pamoja na kubadilisha bendera ya EDITF_ATTRIBUTESUBJECTALTNAME2
kuruhusu maelezo ya SAN katika kigezo chochote, sehemu muhimu ya ukuaji wa uwanja.
Kusahilisha mchakato huu kunaweza kufikiwa kupitia matumizi ya amri ya PSPKI ya Enable-PolicyModuleFlag, kuruhusu marekebisho bila mwingiliano wa GUI moja kwa moja.
Umiliki wa haki za ManageCertificates
unarahisisha idhini ya maombi yanayosubiri, ikiruhusu kuepuka kizuizi cha "idhini ya msimamizi wa cheti cha CA".
Kombinisheni ya moduli za Certify na PSPKI inaweza kutumika kuomba, kuidhinisha, na kupakua cheti:
Shambulizi 2
Maelezo
Katika shambulizi lililopita Manage CA
ruhusa ilitumika kuwezesha bendera ya EDITF_ATTRIBUTESUBJECTALTNAME2 kutekeleza shambulizi la ESC6, lakini hii haitakuwa na athari yoyote mpaka huduma ya CA (CertSvc
) irejeshwe. Wakati mtumiaji ana haki ya ufikiaji wa Manage CA
, mtumiaji pia ameruhusiwa kuanzisha upya huduma. Hata hivyo, hii haimaanishi kwamba mtumiaji anaweza kuanzisha upya huduma kijijini. Zaidi ya hayo, ESC6 huenda isifanye kazi kiotomatiki katika mazingira mengi yaliyosasishwa kutokana na sasisho za usalama za Mei 2022.
Hivyo basi, shambulizi lingine limewasilishwa hapa.
Mahitaji:
Ruhsa ya
ManageCA
pekeeRuhsa ya
Manage Certificates
(inaweza kutolewa kutoka kwaManageCA
)Kigezo cha cheti cha
SubCA
lazima kiwe kimeanzishwa (inaweza kuwezeshwa kutoka kwaManageCA
)
Mbinu hii inategemea ukweli kwamba watumiaji wenye ufikiaji wa Manage CA
na Manage Certificates
wanaweza kutoa maombi ya cheti yaliyoshindwa. Kigezo cha cheti cha SubCA
kina udhaifu wa ESC1, lakini waendeshaji tu wanaweza kujiandikisha kwenye kigezo hicho. Hivyo, mtumiaji anaweza kuomba kujiandikisha kwenye SubCA
- ambayo itakataliwa - lakini kisha kutolewa na msimamizi baadaye.
Mabaya
Unaweza kujipa ruhusa ya Manage Certificates
kwa kuongeza mtumiaji wako kama afisa mpya.
Kiolesha cha SubCA
kinaweza kuwezeshwa kwenye CA kwa kutumia parameter ya -enable-template
. Kwa chaguo-msingi, kiolesha cha SubCA
kimezimwa.
Ikiwa tumekamilisha mahitaji ya shambulio hili, tunaweza kuanza kwa kuomba cheti kulingana na kiolesura cha SubCA
.
Ombi hili litakataliwa, lakini tutahifadhi ufunguo wa kibinafsi na kumbuka kitambulisho cha ombi.
Kwa Manage CA
na Manage Certificates
yetu, tunaweza kisha kutoa ombi la cheti lililoshindwa kwa amri ya ca
na parameter -issue-request <ombi la ID>
.
Na mwishowe, tunaweza kupata cheti kilichotolewa kwa kutumia amri ya req
na parameter ya -retrieve <ombi la kitambulisho>
.
NTLM Relay kwa Vipengele vya HTTP vya AD CS - ESC8
Maelezo
Katika mazingira ambapo AD CS imewekwa, ikiwa kuna kituo cha uendeshaji wa wavuti kilichoweza kudhuriwa na angalau kiolesura cha cheti kimechapishwa kinachoruhusu usajili wa kompyuta za kikoa na uthibitishaji wa mteja (kama templeti ya cheti ya msingi ya Machine
), inawezekana kwa kompyuta yoyote yenye huduma ya spooler kuathiriwa na mshambuliaji!
Mbinu kadhaa za usajili zinazotegemea HTTP zinasaidiwa na AD CS, zinapatikana kupitia majukumu ya seva ya ziada ambayo waendeshaji wanaweza kufunga. Interface hizi za usajili wa cheti zinazotegemea HTTP zinaweza kushambuliwa na mashambulizi ya NTLM relay. Mshambuliaji, kutoka kwa mashine iliyodhuriwa, anaweza kujifanya kuwa akaunti yoyote ya AD inayothibitisha kupitia NTLM. Wakati akijifanya kuwa akaunti ya mwathirika, interface hizi za wavuti zinaweza kufikiwa na mshambuliaji kuomba cheti cha uthibitishaji wa mteja kwa kutumia templeti za cheti za User
au Machine
.
Interface ya usajili wa wavuti (programu ya zamani ya ASP inayopatikana kwa
http://<caserver>/certsrv/
), ina mipangilio ya msingi ya HTTP tu, ambayo haitoi ulinzi dhidi ya mashambulizi ya NTLM relay. Aidha, inaruhusu tu uthibitishaji wa NTLM kupitia kichwa chake cha HTTP cha Uthibitishaji, ikifanya njia za uthibitishaji zaidi salama kama Kerberos kutumika.Huduma ya Usajili wa Cheti (CES), Sera ya Usajili wa Cheti (CEP) Huduma ya Wavuti, na Huduma ya Usajili wa Kifaa cha Mtandao (NDES) kwa msingi hutoa uthibitishaji wa majadiliano kupitia kichwa chake cha HTTP cha Uthibitishaji. Uthibitishaji wa majadiliano unasaidia Kerberos na NTLM, kuruhusu mshambuliaji kudhoofisha hadi NTLM wakati wa mashambulizi ya relay. Ingawa huduma hizi za wavuti zinaruhusu HTTPS kwa msingi, HTTPS pekee haisaidii dhidi ya mashambulizi ya NTLM relay. Ulinzi dhidi ya mashambulizi ya NTLM relay kwa huduma za HTTPS ni lazima iwe wakati HTTPS inachanganywa na kufunga kwa njia. Kwa kusikitisha, AD CS haiweki Ulinzi wa Kupanuliwa kwa Uthibitishaji kwenye IIS, ambayo inahitajika kwa kufunga kwa njia.
Shida kuu ya mashambulizi ya NTLM relay ni muda mfupi wa vikao vya NTLM na uwezo wa mshambuliaji kuingiliana na huduma zinazohitaji saini ya NTLM.
Walakini, kikwazo hiki kinaondolewa kwa kuchexploitisha mashambulizi ya NTLM relay kupata cheti kwa mtumiaji, kwani muda wa halali wa cheti unadhibiti muda wa kikao, na cheti kinaweza kutumika na huduma zinazohitaji saini ya NTLM. Kwa maelekezo juu ya kutumia cheti lililorushwa, tazama:
pageAD CS Account PersistenceKikwazo kingine cha mashambulizi ya NTLM relay ni kwamba mashine iliyo chini ya udhibiti wa mshambuliaji lazima ithibitishwe na akaunti ya mwathirika. Mshambuliaji anaweza kusubiri au kujaribu kulazimisha uthibitisho huu:
pageForce NTLM Privileged AuthenticationMatumizi
Certify’s cas
inahesabu vifaa vya HTTP vya AD CS vilivyoruhusiwa:
Mali ya msPKI-Enrollment-Servers
hutumiwa na Mamlaka za Cheti za biashara (CAs) kuhifadhi vituo vya Huduma ya Usajili wa Cheti (CES). Vituo hivi vinaweza kuchambuliwa na kuorodheshwa kwa kutumia zana Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Matumizi Mabaya na Kuthibitisha
Matumizi mabaya na Certipy
Ombi la cheti hufanywa na Certipy kwa msingi wa kigezo cha Machine
au User
, kulingana na ikiwa jina la akaunti linalotumika linamalizika kwa $
. Ufafanuzi wa kigezo mbadala unaweza kufikiwa kupitia matumizi ya parameter -template
.
Mbinu kama PetitPotam inaweza kutumika kwa kushinikiza uthibitisho. Wakati unashughulika na wadhibiti wa kikoa, ufafanuzi wa -template DomainController
unahitajika.
Hakuna Kifaa cha Usalama - ESC9
Maelezo
Thamani mpya CT_FLAG_NO_SECURITY_EXTENSION
(0x80000
) kwa msPKI-Enrollment-Flag
, inayojulikana kama ESC9, inazuia uingizaji wa mzizi mpya wa usalama wa szOID_NTDS_CA_SECURITY_EXT
katika cheti. Bendera hii inakuwa muhimu wakati StrongCertificateBindingEnforcement
inawekwa kama 1
(chaguo msingi), ikilinganishwa na kuwekwa kama 2
. Umuhimu wake unakuwa mkubwa katika mazingira ambapo upatanishi dhaifu wa cheti kwa Kerberos au Schannel unaweza kutumiwa (kama katika ESC10), ikizingatiwa kwamba kutokuwepo kwa ESC9 haitabadilisha mahitaji.
Mazingira ambayo kuwekwa kwa bendera hii kunakuwa muhimu ni pamoja na:
StrongCertificateBindingEnforcement
haijaongezwa hadi2
(ambapo chaguo msingi ni1
), auCertificateMappingMethods
inajumuisha bendera yaUPN
.Cheti limetambuliwa na bendera ya
CT_FLAG_NO_SECURITY_EXTENSION
ndani ya mipangilio yamsPKI-Enrollment-Flag
.Kibali cha
GenericWrite
kinapatikana juu ya akaunti yoyote kwa kusudi la kuhatarisha nyingine.
Kesi ya Matumizi Mabaya
Fikiria John@corp.local
ana kibali cha GenericWrite
juu ya Jane@corp.local
, na lengo la kuhatarisha Administrator@corp.local
. Kigezo cha cheti cha ESC9
, ambacho Jane@corp.local
ameruhusiwa kusajiliwa, kimeboreshwa na bendera ya CT_FLAG_NO_SECURITY_EXTENSION
katika mipangilio yake ya msPKI-Enrollment-Flag
.
Kwa kuanzia, hash ya Jane
inapata kutumia Vitambulisho vya Kivuli, shukrani kwa GenericWrite
ya John
:
Baadaye, Jane
's userPrincipalName
inabadilishwa kuwa Administrator
, kwa makusudi kutoa sehemu ya kikoa ya @corp.local
:
Mabadiliko haya hayakiuki vikwazo, ikizingatiwa kuwa Administrator@corp.local
inabaki tofauti kama userPrincipalName
ya Administrator
.
Kufuatia hili, kiolesura cha cheti cha ESC9
, kilichobainishwa kuwa hatarini, kinahitajika kama Jane
:
Inaonekana kwamba userPrincipalName
ya cheti inaonyesha Administrator
, bila "object SID".
userPrincipalName
ya Jane
kisha irudishwa kwa yake ya awali, Jane@corp.local
:
Kujaribu uthibitisho na cheti kilichotolewa sasa kunazalisha NT hash ya Administrator@corp.local
. Amri lazima ijumuishe -domain <domain>
kutokana na kutokuwepo kwa maelezo ya kikoa kwenye cheti:
Mappingsi Dhaifu ya Vyeti - ESC10
Maelezo
Thamani mbili za funguo za usajili kwenye kisanduku cha kudhibiti kikoa zinahusishwa na ESC10:
Thamani ya chaguo-msingi kwa
CertificateMappingMethods
chini yaHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
ni0x18
(0x8 | 0x10
), hapo awali iliyowekwa kama0x1F
.Mipangilio ya chaguo-msingi kwa
StrongCertificateBindingEnforcement
chini yaHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
ni1
, hapo awali0
.
Kesi 1
Wakati StrongCertificateBindingEnforcement
inaundwa kama 0
.
Kesi 2
Ikiwa CertificateMappingMethods
inajumuisha biti ya UPN
(0x4
).
Kesi ya Mabaya 1
Ukiwa na StrongCertificateBindingEnforcement
iliyoandaliwa kama 0
, akaunti A yenye ruhusa za GenericWrite
inaweza kutumiwa kudukua akaunti yoyote B.
Kwa mfano, ukiwa na ruhusa za GenericWrite
juu ya Jane@corp.local
, mkaidi ananuia kudukua Administrator@corp.local
. Mchakato unafanana na ESC9, kuruhusu templeti yoyote ya cheti kutumika.
Kwanza, hash ya Jane
inapata kutumia Sera za Kivuli, kwa kutumia GenericWrite
.
Baadaye, userPrincipalName
ya Jane
imebadilishwa kuwa Administrator
, kwa makusudi ikikosa sehemu ya @corp.local
ili kuepuka kukiuka kizuizi.
Kufuatia hilo, cheti kinachowezesha uthibitishaji wa mteja kinahitajika kama Jane
, ukitumia kigezo cha Mtumiaji
cha msingi.
userPrincipalName
ya Jane
kisha irudishwa kwenye hali yake ya awali, Jane@corp.local
.
Kuhalalisha kwa cheti kilichopatikana kutatoa NT hash ya Administrator@corp.local
, ikilazimisha kutaja kikoa katika amri kutokana na kutokuwepo kwa maelezo ya kikoa kwenye cheti.
Kesi ya Matumizi 2
Kwa CertificateMappingMethods
inayo UPN
bit flag (0x4
), akaunti A yenye ruhusa za GenericWrite
inaweza kuhatarisha akaunti yoyote B ambayo haina mali ya userPrincipalName
, ikiwa ni pamoja na akaunti za mashine na msimamizi wa domain aliyejengwa Administrator
.
Hapa, lengo ni kuhatarisha DC$@corp.local
, kuanzia na kupata hash ya Jane
kupitia Shadow Credentials, kwa kutumia GenericWrite
.
userPrincipalName
ya Jane
inawekwa kuwa DC$@corp.local
.
Cheti cha uthibitishaji wa mteja kinahitajika kama Jane
kwa kutumia kigezo cha Mtumiaji
cha msingi.
userPrincipalName
ya Jane
inarudishwa kwa hali yake ya awali baada ya mchakato huu.
Kutambulisha kupitia Schannel, chaguo la -ldap-shell
la Certipy hutumiwa, ikionyesha mafanikio ya kutambulisha kama u:CORP\DC$
.
Kupitia kabibi ya LDAP, amri kama vile set_rbcd
huwezesha mashambulizi ya Uteuzi uliopunguzwa kwa Msingi wa Raslimali (RBCD), hivyo kuhatarisha udhibiti wa kikoa.
Hii udhaifu pia unahusisha akaunti yoyote ya mtumiaji ambayo haina userPrincipalName
au ambapo haifanani na sAMAccountName
, na chaguo-msingi la Administrator@corp.local
likiwa lengo kuu kutokana na mamlaka yake ya LDAP iliyoinuliwa na kutokuwepo kwa userPrincipalName
kwa chaguo-msingi.
Kusambaza NTLM kwa ICPR - ESC11
Maelezo
Ikiwa Seva ya CA haijaundwa na IF_ENFORCEENCRYPTICERTREQUEST
, inaweza kufanya mashambulizi ya kusambaza NTLM bila kusaini kupitia huduma ya RPC. Marejeleo hapa.
Unaweza kutumia certipy
kutafuta ikiwa Enforce Encryption for Requests
imelemazwa na certipy itaonyesha Udhaifu wa ESC11
.
Skenario la Mabaya
Inahitaji kuweka seva ya kuhamisha:
Kumbuka: Kwa watumiaji wa kudhibiti uwanja, lazima tueleze -template
katika DomainController.
Au kutumia fork ya sploutchy ya impacket:
Upatikanaji wa Shell kwa ADCS CA na YubiHSM - ESC12
Maelezo
Waadiministrata wanaweza kuweka Mamlaka ya Cheti kuihifadhi kwenye kifaa cha nje kama "Yubico YubiHSM2".
Ikiwa kifaa cha USB kimeunganishwa kwenye seva ya CA kupitia bandari ya USB, au seva ya kifaa cha USB katika kesi ambayo seva ya CA ni mashine ya kivitual, ufunguo wa uthibitishaji (mara nyingi huitwa "nywila") unahitajika kwa Mtoaji wa Uhifadhi wa Ufunguo ili kuzalisha na kutumia funguo kwenye YubiHSM.
Ufunguo/nywila hii imehifadhiwa kwenye usajili chini ya HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
kwa maandishi wazi.
Rejea katika hapa.
Skenario ya Mabaya
Ikiwa funguo ya kibinafsi ya CA imehifadhiwa kwenye kifaa cha USB cha kimwili unapopata upatikanaji wa shell, ni rahisi kupata funguo hicho.
Kwanza, unahitaji kupata cheti cha CA (hiki ni cha umma) na kisha:
Kufikia hatua hii, tumia amri ya -sign
ya certutil kuunda cheti mpya cha kubahatisha kwa kutumia cheti cha CA na ufunguo wake wa kibinafsi.
-sign
ya certutil kuunda cheti mpya cha kubahatisha kwa kutumia cheti cha CA na ufunguo wake wa kibinafsi.Maelezo
Sifa ya msPKI-Certificate-Policy
inaruhusu sera ya utoaji kuongezwa kwenye templeti ya cheti. Vitu vya msPKI-Enterprise-Oid
vinavyohusika na sera za utoaji zinaweza kupatikana katika Muktadha wa Kutaja Usanidi (CN=OID,CN=Public Key Services,CN=Services) ya chombo cha PKI OID. Sera inaweza kuunganishwa na kikundi cha AD kwa kutumia sifa ya msDS-OIDToGroupLink
ya kipengele hiki, ikiruhusu mfumo kuidhinisha mtumiaji ambaye anawasilisha cheti kana kwamba yeye ni mwanachama wa kikundi hicho. Marejeo hapa.
Kwa maneno mengine, wakati mtumiaji ana idhini ya kujiandikisha kwa cheti na cheti kimeunganishwa na kikundi cha OID, mtumiaji anaweza kurithi mamlaka ya kikundi hiki.
Tumia Check-ADCSESC13.ps1 kwa ajili ya kutafuta OIDToGroupLink:
Skenario la Mabaya
Pata idhini ya mtumiaji inayoweza kutumia certipy find
au Certify.exe find /showAllPermissions
.
Ikiwa John
ana idhini ya kujiandikisha kwa VulnerableTemplate
, mtumiaji anaweza kurithi mamlaka ya kikundi cha VulnerableGroup
.
Yote inayohitajika kufanya ni kutaja kiolezo, atapata cheti lenye haki za OIDToGroupLink.
Kuvunja Misitu na Vyeti Vilivyoelezewa kwa Kisarufi
Kuvunja Uaminifu wa Misitu kwa Kutumia CAs Zilizodhulumiwa
Usanidi wa usajili wa msitu wa msitu unafanywa kuwa rahisi. Cheti cha CA cha msingi kutoka kwa msitu wa rasilimali huchapishwa kwa misitu ya akaunti na wahariri, na vyeti vya CA ya kampuni kutoka kwa msitu wa rasilimali huongezwa kwenye kontena za NTAuthCertificates
na AIA katika kila msitu wa akaunti. Ili kufafanua, makubaliano haya yanatoa udhibiti kamili kwa CA katika msitu wa rasilimali juu ya misitu mingine yote ambayo inasimamia PKI. Ikiwa CA hii itadukuliwa na wachomaji, vyeti vya watumiaji wote katika misitu ya rasilimali na akaunti vinaweza kudanganywa na wao, hivyo kuvunja kizuizi cha usalama wa msitu.
Haki za Usajili Zilizotolewa kwa Mawakala wa Kigeni
Katika mazingira ya misitu mingi, tahadhari inahitajika kuhusu CA za Kampuni ambazo huchapisha templeti za vyeti ambazo huruhusu Watumiaji waliothibitishwa au mawakala wa kigeni (watumiaji/vikundi vya nje ya msitu ambao CA ya Kampuni inahusiana nao) haki za usajili na kuhariri. Baada ya uthibitisho kupitia uaminifu, SID ya Watumiaji waliothibitishwa inaongezwa kwa token ya mtumiaji na AD. Hivyo, ikiwa kikoa kina CA ya Kampuni na templeti inayoruhusu haki za usajili kwa Watumiaji waliothibitishwa, templeti inaweza pia kusajiliwa na mtumiaji kutoka msitu tofauti. Vivyo hivyo, ikiwa haki za usajili zinatolewa wazi kwa mawakala wa kigeni kupitia templeti, uhusiano wa kudhibiti upatikanaji wa msitu wa msitu unatengenezwa, kuruhusu mawakala kutoka msitu mmoja kusajili katika templeti kutoka msitu mwingine.
Mifano yote inasababisha ongezeko la eneo la shambulio kutoka msitu mmoja hadi mwingine. Mipangilio ya templeti ya cheti inaweza kutumiwa na mchomaji kupata mamlaka zaidi katika kikoa cha kigeni.
Last updated