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.
