Begrijpen van het kritieke belang van PKI-beveiliging

Public Key Infrastructure (PKI) is de onzichtbare ruggengraat van vertrouwen in bijna elke digitale interactie, van het versleutelen van webverkeer en signing software releases tot het authenticeren van gebruikers en apparaten via smartcards of Transport Layer Security (TLS) certificaten. De veiligheid van een hele onderneming hangt af van de integriteit van haar Certificaat Authorities (CA's). Als een enkele wortel CA wordt gecompromitteerd, het vertrouwen model instort. Aanvallen kunnen authenticatie tokens vervalsen, decoderen gevoelige communicatie, of teken schadelijke code met de volledige autoriteit van de organisatie. Gezien deze hoge inzet, generieke kwetsbaarheid scanning onvoldoende is. Uitgebreide PKI penetratie testen is een absolute noodzaak voor elke beveiligingsbewuste organisatie. Dit artikel biedt een diepe, procedurele gids voor het uitvoeren van grondige PKI beveiligingsbeoordelingen ontworpen om configuratiefouten, cryptografische zwakheden en logische aanvalspaden die advertenties actief benutten.

Definieer PKI-penetratietesten: verder dan de basisaudits

PKI-penetratietest is een gespecialiseerde offensieve beveiligingsdiscipline gericht op het evalueren van de beveiligingshouding van de gehele levenscyclus van het certificaat. Dit omvat de Certificaat Authorities, Registratie Authorities, cryptografische hardware (HSM's), certificaatsjablonen, intrekkingsmechanismen en de toepassingen die afhankelijk zijn van certificaatgebaseerde authenticatie. In tegenstelling tot een standaard compliance review, een penetratietest actief probeert om beveiligingscontroles te omzeilen, escaleren privileges, en demonstratie real-world impact. In moderne omgevingen, met name die het gebruik van Microsoft Active Directory Certificate Services (AD CS), is deze test een kerncomponent van een uitgebreide Active Directory security assessment geworden.

Differentiatie van kwetsbaarheidsscanning

Een geautomatiseerde kwetsbaarheidsscanner kan ontbrekende patches op een CA-server identificeren of controleren op zwakke cipher suites. Echter, een ervaren penetratie tester gaat veel verder. Ze onderzoeken de logische configuratie van certificaat sjablonen, testen op onveilige inschrijfrechten, analyseren cryptografische randomness, en proberen meerdere kleine foutmeldingen te koppelen aan een volledige domein overname. Deze handleiding, logica-gedreven analyse is de kernwaarde van de speciale PKI-penetratie testen.

Voorverloving: Scoping en regels van betrokkenheid

Voordat een technisch onderzoek begint, moet een duidelijk toepassingsgebied worden vastgesteld. PKI-componenten zijn vaak de meest gevoelige systemen binnen een organisatie. Testen moet een evenwicht vinden tussen de degelijkheid en de operationele stabiliteit.

  • Identificeer de Target CA's: Bepaal of u een interne onderneming CA, een publiek-georiënteerde CA, of een cloud-managed PKI (bijvoorbeeld AWS Private CA, Azure Key Vault Integrated CA) test. Elk heeft een ander aanvalsoppervlak.
  • Bepalen Testgrenzen: Kan het beoordelingsteam rechtstreeks met de root CA communiceren, of is het testen beperkt tot ondergeschikte CA's en het afgeven van servers? Zijn HSM's in de mogelijkheden voor fysieke aanvallen of gewoon logische configuratiecontroles?
  • Active vs. Passieve Testing: Stel regels vast voor certificaatinschrijving pogingen. Actieve inschrijving tegen een productie CA kan de certificaat database vullen of alarmeringen veroorzaken. Sommige tests (zoals ESC8 relaisaanvallen) vereisen netwerk-niveau toegang en specifieke protocol configuraties.
  • Gegevensverwerking: Privésleutels en CA-certificaten die tijdens het testen worden gegenereerd, moeten met uiterste zorgvuldigheid worden behandeld. Bepaal veilige opslag- en onmiddellijke vernietigingsprocedures na voltooiing van de test.

De PKI-penetratietestmethode

Een methodische aanpak zorgt ervoor dat geen component over het hoofd wordt gezien. De volgende fasen vertegenwoordigen een standaard PKI beveiligingsbeoordelingsworkflow.

1. Informatie verzamelen en verkenning

De eerste stap is het in kaart brengen van het PKI-landschap. Dit houdt in dat alle CA's, certificaatsjablonen en vertrouwende partijen binnen de omgeving worden geïdentificeerd.

  • AD CS Discovery: In een Active Directory omgeving kunnen gereedschappen als Certipy[ of Certify alle PKI-objecten opsommen via LDAP-queries. Dit onthult de CA-servers, certificaatsjablonen, inschrijvingsrechten en toegangsbeheerlijsten (ACL's).
  • Certificate Transparency (CT) Logs: Voor publieke CA's kan het zoeken van CT-logs (via tools als ) alle afgegeven certificaten onthullen. Dit helpt om verlopen of foute uitgegeven certificaten te identificeren die nog kunnen worden vertrouwd.
  • Network Probes: Scannen op open poorten op CA-servers (meestal TCP 443 voor Web Inschrijving of TCP 445 voor RPC/DCOM) onthult potentiële aanvalsoppervlakken voor relaisaanvallen (ESC8).

2. Beoordeling van de certificaatautoriteitconfiguratie

Eenmaal ontdekt, wordt de configuratie van de CA zelf onderzocht.

  • Toegangscontrole: Wie heeft administratieve of inschrijvingsrechten op de CA? Te veel permissieve vermeldingen (bijvoorbeeld "Domeingebruikers" die zich in gevoelige sjablonen mogen inschrijven) zijn een klassieke bevinding.
  • Importatiebeleid: Controleer op templates met goedkeuring door de beheerder uitgeschakeld en geautoriseerde handtekeningen niet vereist. Deze "low security" templates zijn vaak de entry vector voor privilege escalatie.
  • Cryptographic Provider: Zorg ervoor dat de CA een sterke, goedgekeurde cryptografische dienstverlener (CSP) of Key Storage Provider (KSP) gebruikt. Legacy providers zoals Microsoft Strong Cryptographic Provider hebben zwakke punten gekend in vergelijking met moderne hardware-backed keys.

3. De AD CS aanvalsmatrix (ESC kwetsbaarheden)

Het meest kritische deel van de moderne interne PKI-test draait rond de "ESC" (Escalation of Privilege) kwetsbaarheden die uitgebreid zijn gedocumenteerd door het SpecterOps onderzoeksteam in hun Certified Pre-Owned whitepaper (Lees het originele SpecterOps Certified Pre-Owned onderzoek)[. Dit zijn misconfiguraties die aanvallers in staat stellen certificaten te smeden voor zeer bevoorrechte accounts.

  • ESC1: De meest voorkomende en gevaarlijke foutconfiguratie. Dit gebeurt wanneer een certificaatsjabloon Inschrijvingsrechten aan gebruikers met een lage achterstand wordt toegekend, Managergoedkeuring[ is uitgeschakeld, Aanvaarde handtekeningen[ is niet vereist, en het sjabloon maakt het mogelijk om een ] Subject Alternatieve naam (SAN) ] aan te melden. Een aanvaller kan een certificaat voor "administrator" of "Domain Controller" aanvragen en als dat account authenticeren.
  • ESC2: Gelijkaardig aan ESC1, maar het sjabloon gebruikt "Any Purpose" (subordinated CA template). Dit kan worden gebruikt om certificaatverzoeken voor elke gebruiker te ondertekenen, waardoor een schurken CA wordt gecreëerd.
  • ESC3: Beschikt over verkeerde inschrijfagent templates. Als een gebruiker rechten heeft op inschrijvingsagent en het CA-beleid toestaat dat er een kruis- of cross-domein inschrijving, kan een aanvaller certificaten aanvragen namens elke gebruiker.
  • ESC4: Zwakke ACL op het certificaat-sjabloonobject zelf. Een aanvaller met schrijftoegang tot het sjabloon kan zijn beveiligingsdescriptoren wijzigen om ESC1 of ESC2 voorwaarden in te voeren, zelfs als het basissjabloon veilig is.
  • ESC8: Een relaisaanval die geen verkeerd geconfigureerd sjabloon vereist. Het is gebaseerd op het Web Inschrijving eindpunt (NDES of CA Web Proxy) om NTLM-authenticatie door te geven. Een aanvaller verplicht een domeincontroller of andere hoogwaardige server om zich te authenticeren op hun relais, die vervolgens de NTLM hash doorstuurt naar de CA om een certificaat voor die machine in te schrijven. Dit kan leiden tot Domain Controller of server compromis.

4. Cryptographic Strength Assessment

Het analyseren van de specifieke algoritmen en belangrijkste managementpraktijken is cruciaal voor de veiligheid op lange termijn.

  • Kenmerken Lengte: Controleer of CA-sleutels ten minste 2048-bit RSA zijn (4096-bit aanbevolen voor wortel CA's). Identificeer eventuele aanhoudende SHA-1 of MD5 hashing algoritmen, die cryptografische gebroken en kwetsbaar zijn voor botsingsaanvallen.
  • Hardware Security Modules: Beoordeel of de CA sleutels in een HSM worden opgeslagen. Het opslaan van sleutels puur in software (op schijf) maakt ze kwetsbaar voor exfiltratie als de server in gevaar is. HSM's bieden een sabotage-resistente sleutelopslag en cryptografische ontladen.
  • Random Number Generation: Zwakke willekeurige getalgeneratoren (RNG's) kunnen leiden tot voorspelbare sleutels. Dit werd in het Debian OpenSSL incident op een beruchte manier uitgebuit. Testers kunnen een steekproef van afgegeven certificaten voor slechte entropie analyseren (al is dit vaak statistische analyse van grote monsters vereist).

5. Man-in-the-middle (MITM) en validatie Bypass

PKI is alleen effectief als vertrouwende partijen certificaten correct valideren. Het testen van validatielogica is een belangrijke taak.

  • Certificate Pinning: Worden toepassingen geïmplementeerd om een certificaat te accepteren dat door een vertrouwde CA is ondertekend, of pinnen ze specifieke sleutels? Zwakke pinning stelt een aanvaller in staat om hun eigen certificaat te vervangen.
  • Revocatie Controle: Worden certificaatherroepingslijsten (CRL's) en Online Certificaat Status Protocol (OCSP) gecontroleerd? Mis geconfigureerde toepassingen slaan vaak intrekkingscontroles volledig over, waardoor aanvallers gestolen maar ingetrokken certificaten kunnen gebruiken.
  • Protocol Downgrade: Kan een client worden misleid om een certificaat met lagere sterkte of een legacy protocol te accepteren? Testen op stripaanvallen op TLS/SSL-verbindingen kan kwetsbaarheden in bedrijfstoepassingen onthullen.

Essentiële hulpmiddelen voor PKI-veiligheidsbeoordelingen

Building a dedicated toolkit for PKI testing enables efficient and thorough assessments.

  • Certip: Een modern Python-instrument dat expliciet is ontworpen voor AD CS-exploitatie en -audit. Het automatiseert de ontdekking van ESC1-ESC8 kwetsbaarheden en kan certificaten aanvragen, SANs specificeren in verzoeken en zelfs het NTLM-relaisgedeelte van ESC8 uitvoeren.
  • OpenSSL: Het Zwitserse Legermes van cryptografie. Gebruikt voor het inspecteren van certificaatgegevens (), het genereren van testcertificaten, het verifiëren van ketens en het testen van TLS-verbindingen (). De officiële OpenSSL-projectsite biedt uitgebreide documentatie voor deze commando's (OpenSSL-documentatie) .
  • Burp Suite: Essentieel voor het testen van TLS validatielogica in webtoepassingen. Een tester kan het verkeer door Burp laten stromen en een zelf- of niet-vertrouwd CA certificaat invoeren om te zien of de toepassing het correct verwerpt of dat het de certificaatketen correct valideert.
  • testsl.sh: Een onschatbaar hulpmiddel voor het beoordelen van de TLS/SSL configuratie van elke dienst. Het controleert op zwakke cipher suites, certificaat geldigheid, protocol ondersteuning (TLS 1.2 vs 1.3), en gemeenschappelijke implementatiefouten.
  • PowerShell (PSPKIAudit/ADCS Audit): Native PowerShell modules zijn uitstekend voor het snel controleren van grote domeinen. De module (geleverd door Microsoft of de PowerShell Gallery) kan alle templates en hun configuratie opsommen.

Analyse van de bevindingen en prioritering van risico

De rapportage is de meest kritieke fase van de betrokkenheid. Technische bevindingen moeten worden vertaald in bedrijfsrisico.

  • Kritisch risico: ESC1 kwetsbaarheid waardoor onmiddellijke domeinbeheersrechten. Een aanvaller met standaard gebruikerstoegang kan binnen enkele minuten een domeincontroller worden. Dit vereist onmiddellijke sanering.
  • High Risk: Zwakke cryptografische sleutelopslag (alleen softwaretoetsen) of ESC8 relaispaden die aanvullende coördinatie vereisen (coercing authenticatie) maar toch leiden tot compromissen tussen de servers.
  • Mediumrisico: Ontbrekende intrekkingscontroles in clienttoepassingen of het gebruik van SHA-1 gebaseerde handtekeningen op interne CA's. Hoewel exploiteerbaar onder specifieke omstandigheden, is de onmiddellijke impact lager.
  • Informatief: CT logs die interne hostnamen blootleggen, of certificaat transparantie configuratie details.

Elke bevinding moet een duidelijke beschrijving, de technische stappen die nodig zijn om deze te reproduceren, de potentiële bedrijfseffecten en een prioritaire aanbeveling voor sanering omvatten.

Beste praktijken voor herstel en verharding

Het identificeren van zwakke punten is slechts de helft van de reis. Het uitvoeren van effectieve controles is essentieel voor de veerkracht van PKI op lange termijn.

Verharding van de certificaatautoriteit

  • Isoleer de CA: De root CA moet offline blijven en luchtafdichting blijven voor maximale beveiliging.Onvervulde CA's moeten worden geplaatst in een beveiligd netwerksegment met strikte firewallregels en minimale administratieve toegang.
  • Gebruik HSM's: Stel hardwarebeveiligingsmodules in voor alle niveau 3+ CA's. Dit beschermt privésleutels tegen exfiltratie, zelfs als de server in gevaar komt.
  • Patch Regelmatig: CA's zijn hoogwaardige doelen. Zorg ervoor dat de onderliggende server OS en CA-applicatie zo snel mogelijk gepatcht worden voor bekende kwetsbaarheden.

Sjablonen voor certificaat beveiligen

  • Sjablonen voor hogeprivilege-accounts (domeinbeheerders, beheerders) moeten expliciet toestemming van de beheerder en toestemming van de beheerder vereisen. De SAN-vlag in het schema moet worden ingesteld op "Dit is een kritieke uitbreiding" om wijziging te voorkomen.
  • Versie 2: Tenuitvoerlegging van de schema's Versie 2 geeft een korrelige beveiliging, inclusief de mogelijkheid om de bouw van de onderwerpnaam te beperken en vereisen officiële ondertekening.
  • Restrict Inschrijvingsmachtigingen: Alleen specifieke beveiligingsgroepen toestaan (bijv. "Helpdesk" voor gebruikerscerts, "Domain Admins" voor admin certs) om zich in te schrijven in gevoelige sjablonen.

Netwerk en protocol harding

  • NTLM Relay Paden uitschakelen: LDAP-ondertekening en LDAP-kanaalbinding inschakelen op domeincontrollers om ESC8-relaisaanvallen te voorkomen. NTLM-authenticatie uitschakelen op CA-servers tenzij absoluut noodzakelijk voor oudere clients.
  • Monitor CRL distributiepunten (CDP's) en OCSP Reponders: Zorg ervoor dat deze zeer beschikbaar en goed geconfigureerd zijn. Een fout in intrekkingscontrole kan toepassingen dwingen ongeldige certificaten te accepteren.

Conclusie: Continue PKI-waakzaamheid

PKI-penetratietest is geen eenmalige doos om te controleren of aan de eisen wordt voldaan. Het is een continue beveiligingspraktijk die zich moet ontwikkelen naast bedreigingen en veranderingen in uw omgeving. Als organisaties migreren naar de cloud en Zero-Trust-architecturen aannemen, breidt de rol van PKI uit, en zo ook het aanvalsoppervlak. Regelmatig geplande beoordelingen .Minstens jaarlijks of na een grote infrastructuurverandering, in combinatie met geautomatiseerde monitoring voor configuratiedrift .Zijn de beste verdediging tegen PKI-gebaseerde aanvallen . Door het aannemen van een rigoureuze, op tegenstander gerichte testmethodologie en prioritering van de harding van certificaatdiensten , kunnen organisaties ervoor zorgen dat hun digitale vertrouwensinfrastructuur ondoordringbaar blijft. De basisbegeleiding door normenorganisaties zoals NIST op sleutelbeheer kan dienen als een lange termijn routekaart voor veilige operaties ](NIST SP 800-57 Aanbeveling voor Key Management)].