Springe zum Inhalt

Kategorie: Allgemein

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 Der wohl sperrigste aller Sperrgründe

Wenn man ein Zertifikat sperrt (manche sagen auch "widerruft", vom englischen revocation), dann gehört es zum guten Ton, einen Sperrgrund anzugeben. Damit kann der geneigte Leser der CRL dann einschätzen, ob ein potenziell panikauslösendes Sicherheitsproblem vorliegt (Sperrgründe: keyCompromise, cACompromise oder für Attributzertifikate, die in der Praxis praktisch nicht verwendet werden: aACompromise).

Oder ob -wie in der Mehrzahl der Fälle- das Zertifikat einfach vorzeitig ersetzt wurde, der Server abgebaut, ein Name oder eine E-Mail-Adresse geändert, der Zertifikatsinhaber gekündigt hat oder dergleichen - weswegen aber noch nicht gleich die Alarmglocken schrillen sollten.

Zu diesem Zweck haben die Schöpfer von X.509 in der Version von 1997 erst acht, im Jahr 2000 dann zwei weitere Zahlenwerte spendiert, die jeweils für einen vordefinierten Sperrgrund stehen. Die 0 ist dabei der Notausgang für Bequemlichkeit oder Unwissen: unspecified. Und interessanterweise wurde die 7 nie offiziell vergeben, was vielleicht mit dem Sonderstatus der 8 zu tun hat, auf die wir gleich noch zu sprechen kommen werden.

Ein Spezialfall ist der Sperrgrund certificateHold (die 6, manchmal auch nur kurz "Hold" genannt). Er kommt aus dem Kontext von Zertifikaten auf Smartcards, Token, Ausweisen und dergleichen. Wie ich vor Jahren aus gut unterrichteten (Werkschutz-)Kreisen gehört habe, ist in etwa 40% der Fälle, in denen ein Betriebsausweis an der Pforte als verlustig gemeldet wird, dieser Ausweis nicht tatsächlich für immer verloren. Sondern taucht binnen ein oder zwei Wochen aus seinem Versteck in einer Manteltasche, hinter einem Sofa oder wo auch immer wieder auf. In solchen Fällen spart es spürbar an Prozesskosten für Personalisierung und Neuausgabe, wenn der Ausweis nicht sofort annulliert, sondern erst einmal für einige Tage deaktiviert und ein günstigerer temporärer Ersatzausweis ausgegeben wird. Taucht der Originalausweis nicht mehr auf, wird er endgültig gesperrt und neu ausgegeben - wird er aber gefunden, dann kann man ihn einfach wieder zulassen und weiter nutzen.

Damit dies auch für etwaige Zertifikate auf dem Ausweis oder Token funktioniert gibt es den Sperrgrund certificateHold, die temporäre Suspendierung. Er ist der einzige Grund, bei dem ein Zertifikat erlaubterweise wieder entsperrt werden darf.
Ein Problem ergab sich dabei aber für die optionalen Delta-CRLs, über die einer vollständigen Base-CRL zwischenzeitlich gesperrte Zertifikate hinzugefügt werden können (ähnlich wie bei einem inkrementellen Backup die neu angelegten Dateien). Wie sagt man, dass ein bestimmter Eintrag aus der Delta-CRL der Base-CRL nicht hinzugefügt, sondern -sofern das Zertifikate dort als certificateHold suspendiert ist- für die Sperrprüfung wieder aus ihr entfernt werden soll? Über den titelgebenden sperrigen Sperrgrund Nummer 8 - removeFromCRL, der strenggenommen eher ein Ent-Sperrgrund ist.

 

Veröffentlicht am Hinterlasse einen Kommentar zu Wie schreibt man eigentlich „Public Key Infrastruktur“?

Diese Frage ist ja nicht so ganz unwichtig für ein Blog, das sich diesem Thema widmen will.

Laut Duden Regel 42 (welche Nummer auch sonst??) werden Aneinanderreihungen und Zusammensetzungen mit Wortgruppen aus Fremdwörtern mit Bindestrich geschrieben. Korrekt hieße es also "Public-Key-Infrastruktur".
Das sieht aber je nach Auge des Betrachters nicht nur ungewohnt bis hässlich aus, diese Schreibweise hat sich auch so im deutschen Sprachraum
nie wirklich eingebürgert.

Also will ich es in diesem kleinen Blog so halten, wie es auch das Bundesamt für Sicherheit in der Informationstechnik höchstoffiziell unter dem Bundesadler und dem schwarz-rot-goldenen Säulenelement tut und die übliche getrennte Schreibweise "Public Key Infrastruktur" verwenden.