Beveiligingsevaluatie: certificaten

In dit artikel wordt Microsoft Defender voor het beveiligingspostuurbeoordelingsrapport certificaten van identiteit beschreven.

Opmerking

Test uw instellingen in een gecontroleerde omgeving voordat u ze inschakelt in productie. Terwijl evaluaties in bijna realtime worden bijgewerkt, worden scores en statussen elke 24 uur bijgewerkt. Hoewel de lijst met betrokken entiteiten binnen enkele minuten na het implementeren van de aanbevelingen wordt bijgewerkt, kan de status nog steeds enige tijd duren totdat deze is gemarkeerd als Voltooid.

Versleuteling afdwingen voor RPC-certificaatinschrijvingsinterface (ESC11)

Beschrijving

Active Directory Certificate Services (AD CS) ondersteunt certificaatinschrijving met behulp van het RPC-protocol, met name met de MS-ICPR-interface. In dergelijke gevallen bepalen de CA-instellingen de beveiligingsinstellingen voor de RPC-interface, inclusief de vereiste voor pakketprivacy.

Als de IF_ENFORCEENCRYPTICERTREQUEST vlag is ingeschakeld, accepteert de RPC-interface alleen verbindingen met het RPC_C_AUTHN_LEVEL_PKT_PRIVACY verificatieniveau. Dit is het hoogste verificatieniveau en vereist dat elk pakket is ondertekend en versleuteld om elk type relay-aanval te voorkomen. Dit is vergelijkbaar met SMB Signing in het SMB-protocol.

Als de RPC-inschrijvingsinterface geen pakketprivacy vereist, wordt deze kwetsbaar voor Relay-aanvallen (ESC11). De IF_ENFORCEENCRYPTICERTREQUEST vlag is standaard ingeschakeld, maar is vaak uitgeschakeld om clients toe te staan die het vereiste RPC-verificatieniveau niet kunnen ondersteunen, zoals clients met Windows XP.

Opmerking

Deze evaluatie is alleen beschikbaar voor klanten die een sensor op een AD CS-server hebben geïnstalleerd. Zie Nieuw sensortype voor Active Directory Certificate Services (AD CS) voor meer informatie

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor het afdwingen van versleuteling voor RPC-certificaatinschrijving.

   

2. Onderzoek waarom de IF_ENFORCEENCRYPTICERTREQUEST vlag is uitgeschakeld.

3. Schakel de IF_ENFORCEENCRYPTICERTREQUEST vlag in om het beveiligingsprobleem te verwijderen.

   Als u de vlag wilt inschakelen, voert u het volgende uit:

   certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
   

   Als u de service opnieuw wilt starten, voert u het volgende uit:

   net stop certsvc & net start certsvc
   

Test uw instellingen in een gecontroleerde omgeving voordat u ze inschakelt in productie.

IIS-eindpunten voor onveilige ADCS-certificaatregistratie bewerken (ESC8)

Beschrijving

Active Directory Certificate Services (AD CS) ondersteunt certificaatinschrijving via verschillende methoden en protocollen, waaronder inschrijving via HTTP met behulp van de Certificate Enrollment Service (CES) of de webinschrijvingsinterface (Certsrv).

Als het IIS-eindpunt NTLM-verificatie toestaat zonder protocolondertekening (HTTPS) af te dwingen of zonder uitgebreide beveiliging voor verificatie (EPA) af te dwingen, wordt het kwetsbaar voor NTLM-relayaanvallen (ESC8). Relay-aanvallen kunnen leiden tot volledige domeinovername als een aanvaller erin slaagt om het te verwijderen.

Opmerking

Deze evaluatie is alleen beschikbaar voor klanten die een sensor op een AD CS-server hebben geïnstalleerd. Zie Sensoren configureren voor AD FS, AD CS en Microsoft Entra Connect voor meer informatie.

Implementatie

Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor onveilige IIS-eindpunten voor AD CS-certificaatregistratie.

De evaluatie bevat de problematische HTTP-eindpunten in uw organisatie en richtlijnen voor het veilig configureren van de eindpunten.

Eenmaal afgehandeld, wordt het esc8-aanvalsrisico beperkt, waardoor uw kwetsbaarheid voor aanvallen aanzienlijk wordt verminderd.

Eigenaar van onjuist geconfigureerde certificaatsjablonen bewerken (ESC4)

In dit artikel vindt u een overzicht van Microsoft Defender voor het evaluatierapport van de beveiligingspostuur van de identiteit van de eigenaar van certificaatsjablonen (ESC4).

Beschrijving

Een certificaatsjabloon is een Active Directory-object met een eigenaar, die de toegang tot het object en de mogelijkheid om het object te bewerken beheert.

Als de machtigingen van de eigenaar een ingebouwde, niet-gemachtigde groep verlenen met machtigingen waarmee wijzigingen in sjablooninstellingen kunnen worden toegestaan, kan een kwaadwillende persoon een onjuiste configuratie van de sjabloon introduceren, bevoegdheden escaleren en het hele domein in gevaar brengen.

Voorbeelden van ingebouwde, niet-gemachtigde groepen zijn Geverifieerde gebruikers, Domeingebruikers of Iedereen. Voorbeelden van machtigingen die wijzigingen in sjablooninstellingen toestaan, zijn Volledig beheer of SCHRIJF-DACL.

Implementatie

1. Controleer de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor een onjuist geconfigureerde certificaatsjablooneigenaar.

   

2. Onderzoek waarom de sjablooneigenaar mogelijk onjuist is geconfigureerd.

3. Herstel het probleem door de eigenaar te wijzigen in een bevoegde en bewaakte gebruiker.

ACL voor onjuist geconfigureerde certificeringsinstantie bewerken (ESC7)

Beschrijving

Certificeringsinstanties (CA's) onderhouden toegangsbeheerlijsten (ACL's) met een overzicht van rollen en machtigingen voor de CA. Als toegangsbeheer niet correct is geconfigureerd, kan elke gebruiker de CA-instellingen verstoren, beveiligingsmaatregelen omzeilen en mogelijk het hele domein in gevaar komen.

Het effect van een onjuist geconfigureerde ACL varieert afhankelijk van het type machtiging dat is toegepast. Bijvoorbeeld:

• Als een niet-gemachtigde gebruiker het recht Certificaten beheren heeft, kan deze in behandeling zijnde certificaataanvragen goedkeuren, waarbij de goedkeuringsvereiste voor manager wordt overgeslagen.
• Met het recht CA beheren kan de gebruiker CA-instellingen wijzigen, zoals het toevoegen van de vlag Gebruiker specificeert SAN (EDITF_ATTRIBUTESUBJECTALTNAME2), waardoor een kunstmatige onjuiste configuratie wordt gemaakt die later kan leiden tot een volledige domeininbreuk.

Vereisten

Deze evaluatie is alleen beschikbaar voor klanten die een sensor op een AD CS-server hebben geïnstalleerd. Zie Nieuw sensortype voor Active Directory Certificate Services (AD CS) voor meer informatie.

Implementatie

1. Controleer de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor onjuist geconfigureerde ACL's van certificeringsinstantie. Bijvoorbeeld:

   

2. Onderzoek waarom de CA-ACL onjuist is geconfigureerd.

3. Los de problemen op door alle machtigingen te verwijderen die niet-gemachtigde ingebouwde groepen verlenen met ca-beheermachtigingen en/of certificaten beheren .

ACL voor onjuist geconfigureerde certificaatsjablonen bewerken (ESC4)

Beschrijving

Certificaatsjablonen zijn Active Directory-objecten met een ACL die de toegang tot het object beheert. Naast het bepalen van inschrijvingsmachtigingen, bepaalt de ACL ook de machtigingen voor het bewerken van het object zelf.

Als er om wat voor reden dan ook een vermelding in de ACL is die een ingebouwde, niet-gemachtigde groep verleent met machtigingen die wijzigingen in sjablooninstellingen toestaan, kan een kwaadwillende persoon een onjuiste configuratie van een sjabloon introduceren, bevoegdheden escaleren en het hele domein in gevaar brengen.

Voorbeelden van ingebouwde, niet-gemachtigde groepen zijn Geverifieerde gebruikers, Domeingebruikers of Iedereen. Voorbeelden van machtigingen die wijzigingen in sjablooninstellingen toestaan, zijn Volledig beheer of SCHRIJF-DACL.

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor een onjuist geconfigureerde certificaatsjabloon-ACL. Bijvoorbeeld:

   

2. Onderzoek waarom de sjabloon-ACL mogelijk onjuist is geconfigureerd.

3. Los het probleem op door vermeldingen te verwijderen die niet-gemachtigde groepsmachtigingen verlenen die manipulatie met de sjabloon toestaan.

4. Verwijder de certificaatsjabloon die niet door een CA wordt gepubliceerd als deze niet nodig is.

Certificaatsjabloon voor onjuist geconfigureerde inschrijvingsagent bewerken (ESC3)

Beschrijving

Gebruikers hebben doorgaans een inschrijvingsagent die hun certificaten voor hen inschrijft. Onder specifieke omstandigheden kunnen inschrijvingsagentcertificaten certificaten inschrijven voor elke in aanmerking komende gebruiker, wat een risico voor uw organisatie met zich mee kan meebrengen.

Wanneer Microsoft Defender voor identiteit rapporteert over certificaatsjablonen voor inschrijvingsagenten die uw organisatie in gevaar brengen, worden riskante inschrijvingsagentsjablonen weergegeven in het deelvenster Beschikbare entiteiten.

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor certificaatsjablonen voor onjuist weergegeven inschrijvingsagent. Bijvoorbeeld:

   

2. Herstel de problemen door ten minste een van de volgende stappen uit te voeren:

   • Verwijder de EKU van de certificaataanvraagagent .
   • Verwijder te permissieve inschrijvingsmachtigingen, waarmee elke gebruiker certificaten kan inschrijven op basis van die certificaatsjabloon. Sjablonen die door Defender for Identity als kwetsbaar zijn gemarkeerd, hebben ten minste één toegangslijstvermelding waarmee inschrijving voor een ingebouwde niet-gemachtigde groep mogelijk is, waardoor dit door elke gebruiker kan worden misbruikt. Voorbeelden van ingebouwde, niet-gemachtigde groepen zijn Geverifieerde gebruikers of Iedereen.
   • Schakel de goedkeuringsvereiste voor CA-certificaatbeheer in.
   • Verwijder de certificaatsjabloon die door een CA wordt gepubliceerd. Sjablonen die niet zijn gepubliceerd, kunnen niet worden aangevraagd en kunnen daarom niet worden misbruikt.
   • Gebruik inschrijvingsagentbeperkingen op het niveau van de certificeringsinstantie. U wilt bijvoorbeeld beperken welke gebruikers mogen fungeren als inschrijvingsagent en welke sjablonen kunnen worden aangevraagd.

Te permissieve certificaatsjabloon bewerken met bevoegde EKU (elk doel of geen EKU) (ESC2)

Beschrijving

Digitale certificaten spelen een essentiële rol bij het tot stand brengen van vertrouwen en het behoud van integriteit in een organisatie. Dit geldt niet alleen voor Kerberos-domeinverificatie, maar ook voor andere gebieden, zoals code-integriteit, serverintegriteit en technologieën die afhankelijk zijn van certificaten zoals Active Directory Federation Services (AD FS) en IPSec.

Wanneer een certificaatsjabloon geen EKU's heeft of een Any Purpose EKU heeft en deze kan worden ingeschreven voor elke onbevoegde gebruiker, kunnen certificaten die op basis van die sjabloon zijn uitgegeven, kwaadwillig worden gebruikt door een kwaadwillende gebruiker, waardoor het vertrouwen wordt aangetast.

Hoewel het certificaat niet kan worden gebruikt voor het imiteren van gebruikersverificatie, brengt het andere onderdelen in gevaar die digitale certificaten ontlasten voor hun vertrouwensmodel. Kwaadwillenden kunnen TLS-certificaten maken en elke website imiteren.

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor te veel toegestane certificaatsjablonen met een bevoegde EKU. Bijvoorbeeld:

   

2. Onderzoek waarom de sjablonen een bevoegde EKU hebben.

3. Ga als volgt te werk om het probleem op te lossen:

   • De machtigingen voor de sjabloon beperken.
   • Dwing indien mogelijk extra risicobeperkingen af, zoals het toevoegen van goedkeurings - en ondertekeningsvereisten voor manager.

Certificaatinschrijving voorkomen met willekeurig toepassingsbeleid (ESC15)

Beschrijving

Deze aanbeveling heeft rechtstreeks betrekking op de onlangs gepubliceerde CVE-2024-49019, waarin de beveiligingsrisico's van kwetsbare AD CS-configuraties worden benadrukt. In deze evaluatie van de beveiligingspostuur worden alle kwetsbare certificaatsjablonen vermeld die zijn gevonden in klantomgevingen vanwege niet-gepatchte AD CS-servers.

Met certificaatsjablonen die kwetsbaar zijn voor CVE-2024-49019 kan een aanvaller een certificaat uitgeven met willekeurig toepassingsbeleid en alternatieve onderwerpnaam. Het certificaat kan worden gebruikt om bevoegdheden te escaleren, mogelijk als gevolg van volledige domeininbreuk. 

Deze certificaatsjablonen stellen organisaties bloot aan aanzienlijke risico's, omdat aanvallers certificaten kunnen uitgeven met willekeurig toepassingsbeleid en alternatieve onderwerpnamen (SAN's). Dergelijke certificaten kunnen worden misbruikt om bevoegdheden te escaleren en mogelijk het hele domein in gevaar te komen. Met deze beveiligingsproblemen kunnen niet-bevoegde gebruikers certificaten uitgeven die zich kunnen verifiëren als accounts met hoge bevoegdheden, wat een ernstige beveiligingsrisico vormt.

Opmerking

Deze evaluatie is alleen beschikbaar voor klanten die een sensor op een AD CS-server hebben geïnstalleerd. Zie Nieuw sensortype voor Active Directory Certificate Services (AD CS) voor meer informatie.

Implementatie

1. Bekijk de aanbevolen actie op Certificaatinschrijving voorkomen met willekeurig toepassingsbeleid (ESC15).

2. Identificeer de kwetsbare certificaatsjablonen:

   • Verwijder de inschrijvingsmachtiging voor onbevoegde gebruikers.
   • Schakel de optie 'Opgeven in de aanvraag' uit.

3. Identificeer de AD CS-servers die kwetsbaar zijn voor CVE-2024-49019 en pas de relevante patch toe.

   

Voorkomen dat gebruikers een certificaat aanvragen dat geldig is voor willekeurige gebruikers op basis van de certificaatsjabloon (ESC1) (preview)

Beschrijving

Elk certificaat is via het onderwerpveld gekoppeld aan een entiteit. Certificaten bevatten echter ook een SAN-veld ( Subject Alternative Name ), waardoor het certificaat geldig kan zijn voor meerdere entiteiten.

Het SAN-veld wordt vaak gebruikt voor webservices die op dezelfde server worden gehost, en ondersteunt het gebruik van één HTTPS-certificaat in plaats van afzonderlijke certificaten voor elke service. Wanneer het specifieke certificaat ook geldig is voor verificatie, door een geschikte EKU te bevatten, zoals Clientverificatie, kan het worden gebruikt om verschillende accounts te verifiëren.

Als voor een certificaatsjabloon de optie Leveren in de aanvraag is ingeschakeld, is de sjabloon kwetsbaar en kunnen aanvallers mogelijk een certificaat inschrijven dat geldig is voor willekeurige gebruikers.

Belangrijk

Als het certificaat ook is toegestaan voor verificatie en er geen risicobeperkende maatregelen worden afgedwongen, zoals goedkeuring door manager of vereiste geautoriseerde handtekeningen, is de certificaatsjabloon gevaarlijk omdat elke onbevoegde gebruiker hiermee willekeurige gebruikers kan overnemen, inclusief een domeinbeheerder.

Deze specifieke instelling is een van de meest voorkomende onjuiste configuraties.

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor certificaataanvragen voor willekeurige gebruikers. Bijvoorbeeld:

   

2. Voer ten minste een van de volgende stappen uit om certificaataanvragen voor willekeurige gebruikers te herstellen:

   • Schakel Leveren uit in de aanvraagconfiguratie .

   • Verwijder alle EKU's die gebruikersverificatie mogelijk maken, zoals Clientverificatie, Smartcard-aanmelding, PKINIT-clientverificatie of Elk doel.

   • Verwijder te permissieve inschrijvingsmachtigingen, waardoor elke gebruiker een certificaat kan inschrijven op basis van die certificaatsjabloon.

     Certificaatsjablonen die door Defender for Identity als kwetsbaar zijn gemarkeerd, hebben ten minste één vermelding in de toegangslijst die inschrijving ondersteunt voor een ingebouwde, niet-gemachtigde groep, waardoor dit door elke gebruiker kan worden misbruikt. Voorbeelden van ingebouwde, niet-gemachtigde groepen zijn Geverifieerde gebruikers of Iedereen.

   • Schakel de goedkeuringsvereiste voor CA-certificaatbeheer in.

   • Verwijder de certificaatsjabloon die door een CA wordt gepubliceerd. Sjablonen die niet zijn gepubliceerd, kunnen niet worden aangevraagd en kunnen daarom niet worden misbruikt.

Instelling van kwetsbare certificeringsinstantie bewerken (ESC6) (preview)

Beschrijving

Elk certificaat is via het onderwerpveld gekoppeld aan een entiteit. Een certificaat bevat echter ook een san-veld ( Alternatieve onderwerpnaam ), waardoor het certificaat geldig kan zijn voor meerdere entiteiten.

Het SAN-veld wordt vaak gebruikt voor webservices die op dezelfde server worden gehost, en ondersteunt het gebruik van één HTTPS-certificaat in plaats van afzonderlijke certificaten voor elke service. Wanneer het specifieke certificaat ook geldig is voor verificatie, door een geschikte EKU te bevatten, zoals Clientverificatie, kan het worden gebruikt om verschillende accounts te verifiëren.

Onbevoegde gebruikers die de gebruikers in de SAN-instellingen kunnen opgeven, kunnen leiden tot onmiddellijke inbreuk en een groot risico voor uw organisatie.

Als de AD CS-vlag editflags>EDITF_ATTRIBUTESUBJECTALTNAME2 is ingeschakeld, kan elke gebruiker de SAN-instellingen voor de certificaataanvraag opgeven. Dit is op zijn beurt van invloed op alle certificaatsjablonen, ongeacht of de Supply in the request optie is ingeschakeld of niet.

Als er een sjabloon is waarin de EDITF_ATTRIBUTESUBJECTALTNAME2 instelling is ingeschakeld en de sjabloon geldig is voor verificatie, kan een aanvaller een certificaat inschrijven dat elk willekeurig account kan imiteren.

Opmerking

Deze evaluatie is alleen beschikbaar voor klanten die een sensor op een AD CS-server hebben geïnstalleerd. Zie Voor meer informatie: Nieuw in Microsoft Defender voor identiteit

Implementatie

1. Bekijk de aanbevolen actie op https://security.microsoft.com/securescore?viewid=actions voor het bewerken van kwetsbare instellingen voor certificeringsinstanties. Bijvoorbeeld:

   

2. Onderzoek waarom de EDITF_ATTRIBUTESUBJECTALTNAME2 instelling is ingeschakeld.

3. Schakel de instelling uit door het volgende uit te voeren:

   certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
   

4. Start de service opnieuw door het volgende uit te voeren:

   net stop certsvc & net start certsvc
   

Volgende stappen

• Meer informatie over Microsoft Secure Score