AD-tanúsítványszolgáltatások: Kockázatos beállítások és azok orvoslása

Az Active Directory Certificate Services már régóta létezik, de a tanuláshoz nem elegendőek az erőforrások. Ennek eredményeként gyakran olyan hibás konfigurációkat tartalmaz, amelyek egyre nagyobb támadást jelentenek. Valójában a SpecterOps kiadott egy fehér könyvet, amely számos hibás konfigurációt és lehetséges támadást részletezett, és keményítő tanácsokat ad. Ebben a blogban bemutatok néhány rosszul konfigurált beállítást és azok észlelésének módját, számos lehetőséget kínálok a biztonság további fokozására, és elmagyarázom, hogyan használhatunk ingyenes eszközt a környezet ellenőrzésére.

Háttér

Ha hitelesítésen alapuló tanúsítványt adnak ki egy identitásnak, a tanúsítvány használható a hitelesítésre, mint az alany alternatív nevében (SAN) beállított azonosság; ez általában egy UPN vagy DNS név. A tanúsítványt ezután jelszó helyett használják a kezdeti hitelesítéshez. A kezdeti hitelesítés műszaki hivatkozása az RFC4556, ha további részleteket szeretne megtudni.

A hitelesített alapú tanúsítvány kibocsátása után visszavonásig vagy lejáratig használható alanyként történő hitelesítésre. Ez megkerüli az olyan incidensre adott választerveket, amelyek olyan stratégiákra támaszkodnak, mint például a felhasználó jelszavának visszaállítása a támadó kirúgása érdekében; a támadó folyamatosan hozzáférhet a fiókhoz, kivéve, ha a tanúsítványokat is visszavonják.

Kockázatos sablonbeállítások

Íme néhány tanúsítványsablon-beállítás, amelyek hibás konfigurációkhoz vezethetnek.

Hitelesítés alapú EKU-k

Először keresse meg az Enhanced Key Usages (EKU-kat), amelyek bármilyen tartományszintű hitelesítést tesznek lehetővé. Íme egy rövid lista:

• Bármilyen célú (2.5.29.37.0)
• SubCA (nincs)
• Ügyfél hitelesítés (1.3.6.1.5.5.7.3.2)
• PKINIT kliens hitelesítés (1.3.6.1.5.2.3.4)
• Intelligens kártya bejelentkezés (1.3.6.1.4.1.311.20.2.2)

Az ezt lehetővé tevő összes tanúsítványsablon kézi megkeresésének legegyszerűbb módja, ha megnyitja a Tanúsító hatóság MMC beépülő modulját, csatlakozik a tanúsító hatósághoz, megnézi a Tanúsítványsablon részt, és bevizsgálja a Rendeltetésszerű oszlopot, hogy keresse bármelyik hitelesítési EKU-t. Az alábbi ábra például azt mutatja, hogy a Számítógép, az Intelligens kártya bejelentkezés másolata és mindkét Tartományvezérlő-sablon tartalmazza legalább az egyik PKU-t.

Miután foglalkozott a talált sablonokkal, ne feledje, hogy a normál tanúsítványokkal is vissza lehet élni. Például a PoshADCS Get-SmartCardCertificate funkciója módosíthat egy sablont, tanúsítványokat kérhet hozzá, majd visszaállíthatja a sablon módosításait.

„Beiratkozott kellékek tárgya” zászló

Ha a CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT jelző szerepel az mspki-certificate-name-flag tulajdonságban, a tanúsítvány regisztrálója megadhatja a saját alternatív tárgynevét a tanúsítvány-aláírási kérelemben. Ez azt jelenti, hogy minden olyan felhasználó, aki jogosult tanúsítványt regisztrálni ezzel a beállítással, kérhet tanúsítványt a hálózat bármely felhasználójaként, beleértve a kiváltságos felhasználókat is.

Ezt a jelzőt a Tanúsítványsablon konzolban ellenőrizheti; ez a Tárgy neve lapon található a „Kiadás a kérésben” rádióbeállításként:

Alternatív megoldásként használhat egy PowerShell-parancsot, például az alábbihoz hasonló sablonokat az AD-ből, és ellenőrizze, hogy a zászló be van-e állítva a tanúsítványban:

Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }

A kockázat további csökkentése

A tanúsítványok hibás konfigurációinak kijavításán kívül fontolja meg a következő lehetőségek használatát a tanúsítványok kiadásának szabályozására.

CA tanúsítványkezelő jóváhagyása vagy felhatalmazott aláírások

Az első és talán a legfontosabb, hogy minden tanúsítványnál tekintse meg a Kibocsátási követelmények fület, és nézze meg, hogy szükséges-e a tanúsítvány hatóság (CA) menedzsere vagy egy vagy több felhatalmazott jóváhagyása.

E beállítások egyikének vagy mindkettőnek engedélyezése nagymértékben csökkentheti a kockázatot azáltal, hogy a tanúsítványok kiadása előtt ellenőrzéseket ír elő. Ha nem biztos abban, hogy megköveteli-e a jogosult aláírásokat, legalább kérje a CA tanúsítványkezelő jóváhagyását; majd minden alkalommal, amikor egy tanúsítványt kérnek, az a tanúsító hatósághoz kerül kézi ellenőrzésre, mielőtt kiadná.

Beiratkozási engedélyek

Másodszor, nézze meg az egyes sablonokban található regisztrációs engedélyeket, amelyek a Biztonság lapon találhatók. Sok hibás konfiguráció csak akkor kritikus, ha általános megbízók vagy nagy csoportok rendelkeznek ezekkel az engedélyekkel. Különösen ellenőrizze a hitelesített felhasználókat, a tartományfelhasználókat és a felhasználók bármely nagy csoportját, akik nem kérhetnek tanúsítványokat; ha megtalálja őket, fontolja meg a regisztrációs vagy automatikus regisztrációs engedélyeik visszavonását.

EDITF_ATTRIBUTESUBJECTALTNAME2 rendszerleíró kulcs

Végül ellenőrizze az EDITF_ATTRIBUTESUBJECALTNAME2 beállításjegyzék-beállítást. Ez a beállítás az egyik legérdekesebb: Ha engedélyezve van a CA-n, akkor bármely hitelesített alapú tanúsítványt, amelyet kiállítottak (beleértve azokat a tanúsítványokat is, amelyeknél az alany automatikusan Active-ból épül fel Directory) felhasználó által meghatározott értékei lehetnek a SAN-ban.

A beállítás ellenőrzéséhez futtassa ezt a parancsot:

certutil –getreg policyEditFlags

Ha az EDITF_ATTRIBUTESUBJECALTNAME2 szerepel a kimeneti listában, akkor a következő paranccsal távolítsa el:

certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2

A beállítással kapcsolatos további útmutatás itt található.

Kockázatos beállítások ellenőrzése a PSPKIAudit segítségével

A PSPKIAudit eszköz segíthet a PKI-infrastruktúra auditálásában. A PSPKIAudit használatához egyszerűen töltse le az eszközt a GitHub webhelyről, importálja a modult, és futtassa az Invoke-PKIAudit parancsot. Ez felsorolja az Active Directory tanúsító hatóságát, majd lekérdezi néhány alapértelmezett beállítást.

Az alábbiakban néhány képernyőképet láthat, amelyek az eszköz kimenetét mutatják, amely egy rosszul konfigurált tanúsítványt és a CA hibás konfigurációit mutatja. Ha a PSPKIAudit olyan hibás konfigurációt észlel, amely nem szerepel ebben a bejegyzésben, nézze meg a SpecterOps papírt a javítási tanácsokért.

Következtetés

Egyre több támadásra számítok az Active Directory tanúsítványszolgáltatásai ellen. Valójában egy PetitPotam ADCS NTLM Relaying támadással már megjelent a SpecterOps papír megjelenése óta, és a SpecterOps kiadja a ForgeCert, az Arany Tanúsítványjegyet a 2021-es BlackHat alkalmából. Ezért sürgősen ellenőrizni kell, hogy nincs-e helytelen konfiguráció a környezetében, és orvosolni kell. haladéktalanul, majd rendszeresen ismételje meg a folyamatot.