Springe zum Inhalt

Kategorie: Intune

Veröffentlicht am Hinterlasse einen Kommentar zu Attack of the Invisible RA

Konzepte

Im Bereich PKI wird traditionell unterschieden zwischen der Certification Authority (CA), die Zertifikate und Sperrinformationen bereitstellt und den Private Key besitzt, um Zertifikate und CRLs zu signieren, einerseits und andererseits der Registration Authority (RA), die die (künftigen) Zertifikatsinhaber registriert und individuell festlegt, welchen Zertifikatstyp sie bekommen und welche Namen in Subject Distinguished Name und/oder SAN-Erweiterung des Zertifikats aufgenommen werden.

Bei einer Microsoft ADCS Enterprise-CA ist diese Unterscheidung nicht immer ganz so offensichtlich, weil es keine Komponente namens "RA" gibt. Aber sie ist dennoch vorhanden. Im typischen Fall sind die RA die AD-Domänen-Administratoren, die

  • AD-Benutzer anlegen und AD-Computer ins AD aufnehmen,
  • dabei Common Name, Account-Name, E-Mail-Adresse bzw. DNS-Hostnamen festlegen und dann
  • das Benutzer- oder Computer-Objekt in eine Gruppe aufnehmen, die "Registrieren" (Enroll) Rechte für ein oder mehrere in der Enterprise CA aktive Certificate Templates hat.

Und bei einer Intune-Anbindung über den Intune Certificate Connector (SCEP oder PKCS) ist Intune die RA – damit auch die Administratoren des betreffenden Intune Tenants.

Angriffe

Dass eine böswillige oder kompromittierte RA von der CA missbräuchlich Zertifikate für Inhabernamen erlangen kann, die so nie beabsichtigt waren (und deren zugehörige Private-Keys der Angreifer kontrolliert), ist ebenfalls nicht neu.

Ein prominentes Beispiel dafür war im Jahr 2011 der "Comodo-Hack", bei dem mutmaßlich ein iranischer Hacker den italienischen Reseller (d. h. die regionale RA) von Comodo kompromittieren und so öffentlich gültige Zertifikate u. a. für mail.google.com erlangen konnten.

Und im Falle von Intune als RA geht das z. B. so, wie von Dirk-jan Mollema in seinem kürzlichen Blog-Post beschrieben.

Abwehr

Das beste Abwehrmittel gegen solche RA-seitigen Angriffe, ist es, wenn die CA die RA hinsichtlich der zu beantragenden Zertifikatstypen und Namen möglichst eng einschränkt.

Bei öffentlichen SSL-Zertifikaten geschieht dies u. a. durch die Anfang 2013 – nach dem Comodo-Hack – eingeführte Certification Authority Authorization (CAA), mit der ein Domain-Inhaber im DNS hinterlegen kann, über die RAs welches oder welcher Trustcenter er seine Zertifikate bezieht. Alle anderen öffentlichen CAs dürfen keine Zertifikate für Hostnamen in dieser Domain ausstellen, selbst wenn ihnen eine ihrer RAs einen entsprechenden "geprüften" Zertifikatantrag zuleitet.

Im Fall von Intune bieten die ADCS (vulgo: Microsoft CA) von Hause aus leider nur sehr rudimentäre Möglichkeiten für die Kontrolle und Einschränkung von RAs an. Im Wesentlichen ist es möglich, die RA auf bestimmte Certificate Templates zu beschränken. Bei Enrollment Agents – ebenfalls eine Form von RA 😉 – für Enrollment on Behalf of Others (EOBO) immerhin noch auf bestimmt AD-Gruppen, für die sie ein Zertifikat per EOBO beantragen dürfen.

Wesentlich weitergehende Möglichkeiten zur Beschränkung einer RA wie bspw., aber nicht nur, Intune hat eine Enterprise-CA zur Verfügung, wenn sie Uwe Gradeneggers TameMyCerts Policy-Modul verwendet.

Veröffentlicht am Hinterlasse einen Kommentar zu Grundsätzlich nie…

... sollte  man ein Zertifikat, das nicht mit Sperrgrund certificateHold (siehe den vorigen Blogbeitrag) suspendiert ist, wieder entsperren. Das verstößt gegen PKI-Standards, Best-Practice und die guten Manieren.

[Einschub: Ein bereits abgelaufenes gesperrtes Zertifikat nicht mehr auf einer neuen Sperrliste aufzuführen ist dagegen nicht unbedingt ehrenrührig - zumindest solange es sich nicht um ein Signaturzertifikat handelt.]

Aber wie ich von Juristen gelernt habe, bedeutet "grundsätzlich" in deren Sprachgebrauch, dass begründete Ausnahmen möglich sind. Im Fall von gesperrten Zertifikaten findet sich eine mögliche Ausnahme im Bereich von Device Management Systemen.

Solche Systeme -bspw. Intune, aber auch andere- können oft auch selbsttätig Zertifikate sperren, wenn das Gerät, auf das sie ein bestimmtes Zertifikat ausgerollt haben, als defekt/verloren/gestohlen markiert wird. Das ist generell eine gute Idee.
Leider gehen manche dieser Systeme -bspw. Intune, aber auch andere- dann davon aus, dass sie für die von Ihnen verwalteten Zertifikate keine Sperrlisten oder OCSP-Status mehr prüfen müssen. In der fälschlichen Annahme, dass nur sie selbst diese Zertifikate im Fall des Falles sperren und daher a priori schon über den Sperrstatus Bescheid wissen.
So rollt Intune Zertifikate, die ein angeschlossener PKCS-Connector einmal stellvertretend als PKCS#12-Datei besorgt und zu Intune hochgeladen hat, munter weiter an das betreffende Gerät aus, selbst wenn ein Certificate Manager der zugehörigen CA es gesperrt hat. Natürlich kann das Gerät dann nicht viel mit diesem Zertifikat anfangen, aber das bekommt Intune nicht direkt mit.

In derartigen Fällen kann es das Einfachste sein, wenn der Klügere(?) nachgibt und die CA das Zertifikat entsperrt, damit der echte und der vermeintliche Sperrstatus in der PKI bzw. dem Device Management System wieder konsistent sind. Natürlich sollte man das Zertifikat dann unverzüglich über das Device Management wieder sperren, um die guten Sitten, die Konformität zu PKI-Standards und Best-Practice zu wahren.

Ist die betreffende CA eine Microsoft-CA (vulgo ADCS) gibt es einen einfachen Trick, mit dem man das tun kann:

Der Befehl

CertUtil -revoke <Seriennummer> <Sperrgrund>

ist dazu gedacht, ein Zertifikat per Kommandozeile zu sperren und dabei optional einen Sperrgrund anzugeben. Oder um ein suspendiertes Zertifikat wieder zu entsperren, indem man als Sperrgrund unrevoke oder -1 angibt.

Man kann ihn aber auch dazu nutzen, einem bereits gesperrten Zertifikat einen geänderten Sperrgrund zu verpassen, indem man es noch einmal sperrt.

Dabei hat Microsoft die offensichtlichen Missbrauchsmöglichkeiten abgefangen:

  • unrevoke geht nur, wenn der bestehende Sperrgrund certificateHold (microsoftisch: CRL_REASON_CERTIFICATE_HOLD oder standardkonform kurz 6) ist.
  • Das Ändern eines anderen Sperrgrunds zu CRL_REASON_CERTIFICATE_HOLD geht nicht.

Was aber versehentlich oder bewusst nicht abgefangen wird, ist, einen bestehenden Sperrgrund in removeFromCRL (microsoftisch: CRL_REASON_REMOVE_FROM_CRL oder kurz 8) abzuändern.

Ein Zertifikat mit diesem Sperrgrund taucht durch seinen Status zwar in der CA-Managementkonsole zwar weiterhin unter Revoked Certificates (oder, wenn man es deutsch lokalisiert mag: Gesperrte Zertifikate) auf - aber nicht mehr auf der nächsten erstellten CRL. Für Relying Parties, die diese CRL auswerten, ist es faktisch entsperrt.

Wir merken uns also für Not- und Sonderfälle:

CertUtil -revoke <Seriennummer> 8