vectorfusionart - Fotolia
Wildcard-Zertifikate richtig nutzen und Risiken reduzieren
Kostenlose Wildcard-Zertifikate sind für IT-Abteilungen durchaus attraktiv. Durch unsachgemäßen Einsatz entstehen jedoch Schwachstellen, die Angreifer leicht ausnutzen können.
Eine gute Verschlüsselung sollte längst schon zum Standardrepertoire der Datensicherheit zählen. Da Let’s Encrypt seit März 2018 auch Wildcard-Zertifikate vergibt, sind die Hürden für die Erstellung und Validierung von Zertifikaten so niedrig wie nie zuvor. Administratoren sollten allerdings genau hinterfragen, wo und wie sie diese universellen Zertifikate einsetzen.
Auf den ersten Blick scheint ihr Gebrauch ausgesprochen vorteilhaft zu sein, um Zeit und Ressourcen zu sparen, indem eine Domain und alle ihre Subdomains mit einem einzigen Zertifikat abgesichert werden, anstatt jeweils ein neues Zertifikat anzufordern und implementieren zu müssen. Allerdings kann der unsachgemäße Gebrauch der Zertifikate bedeuten, dass neue und vermeidbare Schwachstellen entstehen, die von möglichen Angreifern leicht ausgenutzt werden können.
Schlüssel und Zertifikate sind oft unzureichend gesichert
Ein unsachgemäßer Umgang mit Wildcard-Zertifikaten, die eine Domain und alle Subdomains umfassen, stellt ein Sicherheitsrisiko dar, das in der Praxis bereits weit verbreitet ist: Oft lässt sich beispielsweise beobachten, dass die kryptografischen Schlüssel und die darauf aufbauenden Zertifikate in .p12-Dateien oder pkcs12-Containern in Filesharing-Systemen abgelegt werden. Bei dieser Form der Ablage vertrauen die Verantwortlichen darauf, dass die Daten sicher sind, weil die Zugriffsrechte stark eingeschränkt wurden. Übersehen wird oft, dass es relativ einfach ist, durch Privilege Escalation Zugang (Rechteerhöhung) zu erlangen und mit einem Brute-Force-Angriff die Schlüssel und Zertifikate zu extrahieren.
Mit diesen können böswillige Hacker anschließend Man-in-the-Middle-Angriffe innerhalb der betroffenen Organisation durchführen. Für diese Attacke können sie sich als ein beliebiger Server des Netzwerks ausgeben, weil sie sowohl den benötigten Schlüssel als auch ein universelles Zertifikat haben, um sich zu legitimieren. Noch einfacher wird der Datendiebstahl, wenn der Administrator die Dateien einfach per E-Mail oder FTP-Server an Kollegen und Partner weitergibt und lediglich die Verbindung ausspioniert werden muss.
In der Praxis werden Wildcard-Zertifikate oft mit einem einzigen Schlüsselpaar erstellt und schnell auf 20 oder 30, in Spitzen sogar auf 3.000 und mehr Servern eingesetzt. Technisch ist das einfach und kostengünstig. Das bedeutet aber umgekehrt, dass, sobald ein privater Schlüssel kompromittiert wird, die gesamte Infrastruktur betroffen ist. Dabei verfolgen viele Administratoren oft eine ganz andere Absicht und implementieren die Zertifikate zunächst nur auf einer ausgewählten Seite. Im Alltag geschieht es dann oft, dass neue Zertifikate sehr kurzfristig angefragt werden und es für den Administrator leichter ist, den .p12-Container zu verschicken, als ein neues Zertifikat anzufordern. Ermöglicht wird das durch Zertifikate der Form „*.beispiel.com“, die bei der Erfindung der Wildcards nicht vorgesehen wurden.
Der Einsatz von Wildcard-Zertifikaten sollte gut abgewogen werden
Wildcard-Zertifikate wurden für bestimmte Anwendungsfälle entwickelt, die zu dieser Zeit eine besondere Herausforderung waren: darunter Sonderzeichen und Load-Balancer. Die Browser waren nicht in der Lage, Zertifikate zu verarbeiten, die Sonderzeichen wie das Et-Zeichen (ugs. „Kaufmanns-Und“) – dass oft ein „und“ in Unternehmensnamen ersetzt – zu verarbeiten. Beim Einsatz der Load-Balancer werden wiederum Spitzen im Online-Traffic auf verschiedene Server mit derselben Domain verteilt. Das führt zu einer Vielzahl individuellen Domainnamen wie „www1.beispiel.com“ oder „www2.beispiel.com“. In beiden Fällen ist es eine große Erleichterung, für einzelne Zeichen einen universellen Platzhalter im Zertifikat angeben zu können. Das vermeidet, dass beispielsweise bei neuen Servern ein neues Zertifikat für die Lastenverteilung angefordert werden muss, weil die neue Adresse „www3.beispiel.com“ noch nicht abgedeckt wurde. Durch Zertifikate für Domains wie „www*.beispiel.com“ wird die Schlüssel- und Zertifikatsverwaltung stark erleichtert.
Die Wildcards sind zwar weit davon entfernt, ihre Berechtigung zu verlieren, allerdings gibt es mittlerweile Szenarien, in denen andere Arten besser wären. Die Schwierigkeiten beginnen mit Zertifikaten in der Form *.beispiel.com. Beispielsweise können mehrere Domains auf einem Subject Alternate Name (SAN)-Zertifikat eingetragen werden, um Situationen abzudecken, in denen Load-Balancer eingesetzt werden. Das erfordert eine genauere Planung, weil die Adressen vorab eingetragen werden müssen und nachträgliche Ergänzungen umständlich sind. In vielen Fällen sind SAN-Zertifikate allerdings sehr sinnvoll und vermeiden Möglichkeiten für potenzielle Angreifer, die beim Einsatz eines Wildcard-Zertifikats entstehen würde. In solchen Fällen ist es je nach Anzahl dieser Zertifikate und ihrer Gültigkeitsdauer in der Regel sicherer, eine Management-Lösung zur Verwaltung der Zertifikate einzusetzen, welche die zeitaufwendigen Routineaufgaben automatisiert – als auf Wildcards auszuweichen.
„Die Wildcards sind zwar weit davon entfernt, ihre Berechtigung zu verlieren, allerdings gibt es mittlerweile Szenarien, in denen andere Arten besser wären.“
George Parsons, Venafi
Ob der Einsatz eines Wildcard-Zertifikats notwendig und der Nutzen in einem gesunden Verhältnis zu den möglichen Risiken steht, sollte in jedem Einzelfall genau abgewogen werden. In der Praxis führen allerdings Personal-, Ressourcen- und Zeitmangel oft dazu, dass ein Wildcard-Zertifikat eher gewählt wird, weil es bequem ist und nicht, weil es notwendig wäre. Dieser Trend könnte sich durch die kostenlosen Zertifikate von Let’s Encrypt verstärken, weil das Budget als Entscheidungsinstanz entfällt. Umso wichtiger ist es, dass die Administratoren für die Sicherheitsaspekte von Zertifikaten sensibilisiert werden. Außerdem sollten ihnen das notwendige Know-how und die richtigen Tools bereitgestellt werden, um ihre Arbeit so weit zu erleichtern, dass die Bequemlichkeit nicht mehr das ausschlaggebende Argument ist.
Fazit
Es ist verständlich, dass Menschen unter Zeitdruck die einfachste und schnellste Möglichkeit wählen, die ihnen zur Verfügung steht. Kostenlose Wildcard-Zertifikate sind deshalb für IT-Administratoren sehr attraktiv und bieten ihnen in der Praxis oft einige kurzfristige Vorteile. Dadurch, dass sie allerdings oft anders als vorgesehen Verwendung finden und häufig wiederbenutzt oder ohne die notwendigen Sicherheitsmaßnahmen weitergegeben werden, sinkt der Mehrwert langfristig deutlich. Statt mehr Sicherheit durch die verschlüsselte Kommunikation zu ermöglichen, stellen unsachgemäße eingesetzte Wildcard-Zertifikate neue Angriffsflächen dar.
Die Security-Verantwortlichen sollten deshalb sicherstellen, dass ihre IT-Administratoren die Zertifikate nur in geeignete Szenarien verwenden. Allerdings müssen sie ihnen auch die notwendigen Ressourcen zur Verfügung stehen, Zertifikate jeder Art in ihrem Netzwerk angemessen zu verwalten. Das heißt im Umkehrschluss: Ihnen eine Lösung und die Ressourcen zur Verfügung stellen, den Lebenszyklus von Schlüsseln und Zertifikaten – von der Erstellung bis zum Austausch – zu automatisieren. Eine solche Lösung nimmt den Administratoren bereits einen wesentlichen Teil ihrer Arbeit bei der Verwaltung von Zertifikaten ab, stellt sicher, dass der Umgang mit den Zertifikaten den genehmigten Richtlinien und Prozessen entspricht, und vor allen Dingen: Die schnellen und unkomplizierten Verwaltungsmöglichkeiten helfen dabei, dass Bequemlichkeit und Zeitmangel keine Gründe mehr sind, Wildcard-Zertifikate unsachgemäß einzusetzen.
Über den Autor:
George Parsons ist Senior Director of Security Architects bei Venafi und Erfinder des Wildcard-Zertifikats.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
