Das Zertifikat hinter Ihrem Schloss-Symbol hatte die Seite schon verraten, bevor sie live war
Ein Mitbewerber startet genau dieselbe Stadt eine Woche, nachdem das Team sie still und leise fertig getestet hat, noch bevor auch nur eine Anzeige gekauft oder ein Link veroeffentlicht wurde. Ein Betreiber erfaehrt von einem Fremden in einem Forum, dass jemand eine Login-Seite entdeckt hat, von der ausserhalb des Unternehmens niemand wissen sollte. Keiner dieser beiden Faelle sieht nach einem Leak durch einen Mitarbeiter, einem gehackten E-Mail-Konto oder reinem Zufall aus. Beide lassen sich meist auf etwas viel Banaleres zurueckfuehren: ein automatisch ausgestelltes Sicherheitszertifikat, das genau das tut, wofuer es gebaut wurde.
Der Mechanismus heisst Certificate Transparency und hat nichts mit einem Hackerangriff zu tun. Es ist ein oeffentliches, dauerhaftes Register fuer HTTPS-Zertifikate, das seit 2018 existiert, kostenlos durchsuchbar ist und bereits die vollstaendige Geschichte jedes Hostnamens enthaelt, den diese oder irgendeine andere Website jemals hinter ein Zertifikat gestellt hat, das ohne Browserwarnung funktionierte. Fast kein Betreiber hat je den eigenen Eintrag darin nachgeschaut. Genau das ist die Luecke, die es hier zu schliessen gilt, keine Sicherheitsluecke im ueblichen Sinn, sondern ein Register, das die ganze Zeit oeffentlich war und nie so behandelt wurde.
Was ein Zertifikat im Stillen wird, in dem Moment, in dem es ausgestellt wird
Seit 2018 muss ein oeffentlich vertrauenswuerdiges Zertifikat, also eines, bei dem Chrome und Safari ein einfaches Schloss-Symbol statt einer Warnung anzeigen, in einem der Certificate-Transparency-Logs erfasst werden, sonst vertrauen diese Browser ihm nicht. Apple fuehrte dieselbe Pflicht fuer Safari spaeter im selben Jahr ein. Das zielte nicht gezielt auf Erwachsenenseiten oder Kleinanzeigenportale, sondern sollte verhindern, dass jemand heimlich ein gefaelschtes Zertifikat fuer die Domain eines anderen ausstellt und dessen Datenverkehr abfaengt. Der Nebeneffekt ist, dass das Log auch jedes echte Zertifikat erfasst, das eine Website fuer sich selbst erhaelt, und dieses Register war nie dafuer gedacht, privat zu bleiben.
Das Log listet namentlich jeden Host auf, den ein Zertifikat tatsaechlich abdeckt. Ein Zertifikat fuer admin.beispiel.com zeigt genau diesen Namen, im Klartext, fuer immer. Es spielt keine Rolle, ob die dahinterliegende Seite jemals im Menue der Website verlinkt, in einer Sitemap erwaehnt oder von einer Suchmaschine indexiert wurde. Die Zertifizierungsstelle hat ihn in dem Moment erfasst, in dem sie ihn ausgestellt hat, egal ob es sich um Let's Encrypt, Cloudflare oder den automatischen Zertifikatsmanager handelte, der in den meisten Hosting-Panels eingebaut ist, denn alle folgen denselben Browserregeln.
Das zu pruefen kostet nichts und dauert weniger als eine Minute. Ein kostenloses Tool namens crt.sh laesst jeden eine Domain eingeben und jedes jemals dafuer registrierte Zertifikat sehen, ohne Konto, ohne Anmeldung. Die Domain eines Mitbewerbers einzugeben funktioniert genauso gut wie die eigene, und genau das macht aus einem routinemaessigen technischen Register ein geschaeftliches Risiko. Jeder Betreiber, der dies liest, kann diese Seite jetzt sofort oeffnen und zum ersten Mal sehen, was die eigene Domain der Welt bereits verraten hat.
Es gibt eine echte Ausnahme, und sie ist fuer alles Folgende wichtig: Ein Wildcard-Zertifikat, das ein ganzes Muster wie *.beispiel.com abdeckt statt eines exakten Namens, erfasst im Log nur dieses Muster. Die konkreten Hostnamen, die es tatsaechlich nutzen, neuestadt.beispiel.com oder staging.beispiel.com, erscheinen nicht namentlich im Register. Ein eigenes Zertifikat fuer eine exakte Subdomain dagegen erscheint immer namentlich. Genau dieser Unterschied ist der Hebel, den ein Betreiber tatsaechlich in der Hand hat, und darauf kommt dieser Text weiter unten zurueck.
Was das einem Fremden tatsaechlich in die Hand gibt, auf drei konkrete Arten
Der erste Punkt ist das Timing einer Expansion. Eine neue Stadt- oder Laenderseite wird fast immer auf einer eigenen Subdomain gebaut und getestet, Tage oder Wochen bevor das Marketing bereit ist, sie anzukuendigen, und das Testen ueber HTTPS bedeutet, dass das zugehoerige Zertifikat genau in dieser stillen Phase ausgestellt wird, nicht am Tag des Starts. Es gibt kostenlose Monitoring-Tools, die auf demselben oeffentlichen Register aufbauen und jemanden innerhalb von Minuten bis wenigen Stunden benachrichtigen, sobald ein neues Zertifikat fuer eine beobachtete Domain auftaucht. Ein Mitbewerber, der die Hauptdomain bereits kennt, die per Definition oeffentlich ist, muss den Namen der neuen Stadt nicht erraten. Er muss nur beobachten, und das Register liefert ihn, bevor die Ankuendigung ueberhaupt rausgeht.
Der zweite Punkt ist die Landkarte der internen Werkzeuge. Ein Verzeichnis dieser Groesse betreibt meist eine Login-Seite fuer das Personal, eine Warteschlange fuer diejenigen, die Anzeigen pruefen, vielleicht ein separates Panel fuer einen externen Zahlungsanbieter. Wenn jedes davon sein eigenes Zertifikat mit einem eigenen, beschreibenden Namen bekommen hat, admin, moderation, abrechnung, liest sich das Register inzwischen wie ein Gebaeudeplan. Dieser Plan ist genau der Ausgangspunkt fuer die Art von Einbruch, die hier bereits behandelt wurde, bei der der uebliche Weg hinein kein spektakulaerer Exploit ist, sondern ein wiederverwendetes Passwort, das gegen die am leichtesten zu findende Login-Seite ausprobiert wird. Eine namentlich beschreibende Subdomain verursacht diesen Einbruch nicht allein, aber sie entfernt den einen Schritt, die Login-Seite ueberhaupt erst zu finden, der einen Angreifer sonst aufgehalten haette.
Der dritte Punkt ist eine Geschichte, die niemand zurueckholen kann. Das Register vergisst nichts. Eine Test-Subdomain von vor drei Jahren, eine kurzlebige Seite fuer einen Partner, den es nicht mehr gibt, eine Staging-Kopie, die ein Entwickler loeschen wollte und vergessen hat: all das bleibt fuer immer im Register, auch nachdem das Zertifikat ablaeuft, auch nachdem der DNS-Eintrag, der darauf zeigte, entfernt wurde. Eine Domain heute auf crt.sh zu suchen, kann Namen zutage foerdern, an deren Erstellung sich niemand im aktuellen Team erinnert. Die gefaehrliche Seite daran ist nicht der Eintrag selbst, sondern die Moeglichkeit, dass der Server, der unter dieser Adresse antwortete, immer noch dort steht, nie aktualisiert, weil alle angenommen haben, dass das Entfernen des Links dasselbe ist wie das Abschalten.
Nichts davon erfordert ein Koennen, das die meisten Menschen Hacking nennen wuerden. Es braucht nur das Wissen, dass ein kostenloses Suchfeld existiert, und das Eintippen eines Domainnamens, und genau deshalb lohnt es sich, das ernst zu nehmen, statt es als Sicherheitsproblem fuer jemand anderen abzulegen.
Was nichts davon stoppt, und was tatsaechlich hilft
Es ist verlockend, zu denselben Werkzeugen zu greifen, mit denen gesteuert wird, wie Suchmaschinen eine Website sehen, aber keines davon greift hier. Die Entscheidungen, die dieses Verzeichnis bereits darueber trifft, welche Crawler welche Seiten sehen duerfen, laufen ueber robots.txt und die Indexierung durch Suchmaschinen, ein voellig anderes System, von dem ein Zertifikatsregister noch nie etwas gehoert hat. Einen Bot zu blockieren, eine Seite aus dem Index zu nehmen oder sie als noindex zu markieren, aendert nichts daran, ob ihr Zertifikat im Register auftaucht, denn das Register erfasst das Zertifikat selbst, nicht die Sichtbarkeit der Seite fuer Suchmaschinen.
Es gibt auch keine legitime Moeglichkeit, ein Zertifikat zu bekommen, das im Browser eines Besuchers ohne Warnung funktioniert, und es gleichzeitig aus dem Register herauszuhalten. Einen Hosting-Anbieter oder eine Zertifizierungsstelle um eine Ausnahme zu bitten, heisst, etwas zu verlangen, das es fuer ein oeffentlich auftretendes Geschaeft nicht gibt: Die einzigen Zertifikate, die von der Erfassung ausgenommen sind, stammen von einer privaten, internen Zertifizierungsstelle, der die Browser gewoehnlicher Besucher ueberhaupt nicht vertrauen, was sie fuer alles nutzlos macht, was ein Kunde oder Inserent tatsaechlich oeffnen muss.
Eine Subdomain im Nachhinein umzubenennen oder zu loeschen, behebt ebenfalls nichts, denn der alte Eintrag im Register bleibt genau dort, wo er war. Es gibt keine nachtraegliche Bereinigung fuer einen Namen, der auf diese Weise bereits erfasst wurde: Das Einzige, was ein Betreiber tatsaechlich aendern kann, ist, was ab jetzt passiert.
Was tatsaechlich hilft, ist das oben beschriebene Wildcard-Zertifikat, bewusst eingesetzt. Interne Werkzeuge, Staging-Kopien und alles, was vor einem oeffentlichen Start getestet wird, sollten hinter einem einzigen Zertifikat laufen, das ein ganzes Muster abdeckt, statt jedes Mal hinter einem neuen, namentlich ausgestellten Zertifikat. Die meisten Hosting-Panels und Content-Delivery-Netzwerke stellen standardmaessig automatisch ein namentliches Zertifikat aus, sobald eine neue Subdomain hinzugefuegt wird, weil diese Voreinstellung einfacher zu bauen ist, nicht weil sie die sicherere Wahl waere. Den Hoster oder Entwickler zu bitten, genau diese Einstellung fuer alles zu aendern, was keine oeffentliche Marketingseite ist, ist eine konkrete, ueberpruefbare Frage, keine vage Bitte um mehr Sicherheit.
Die zweite echte Loesung besteht darin, sich nicht mehr auf einen unauffaelligen Namen zu verlassen, als waere er ein Schloss. Eine Login-Seite, eine Moderationswarteschlange oder ein Abrechnungspanel brauchen eine echte Passwortpruefung und, wo moeglich, eine Beschraenkung auf einen bekannten Kreis von Buero- oder Mitarbeiteradressen, egal wie sie heissen, denn der Name war nie der einzige Weg, sie zu finden: Es gibt andere technische Methoden, um die Subdomains einer Website aufzudecken, die mit Zertifikaten nichts zu tun haben. Einen schwer zu erratenden Namen als Hauptverteidigung zu behandeln, ist der eigentliche Fehler hier, nicht die Zertifikatswahl an sich. Die Zertifikatswahl entscheidet nur, ob dieser Name kostenlos preisgegeben wird, bevor ihn ueberhaupt jemand suchen muss.
Was diese Woche tatsaechlich zu pruefen ist
Der erste Schritt kostet nichts und dauert fuenf Minuten: crt.sh oeffnen, die eigene Domain dieser Website eingeben und die vollstaendige Liste von allem lesen, was zurueckkommt. Jeder nicht wiedererkannte Eintrag verdient eine direkte Frage an die Person, die das Hosting verwaltet: Laeuft das noch, und wenn ja, warum kennt das oeffentliche Internet seine Adresse heute.
Fuer alles auf dieser Liste, das sich als tote Funktion, abgeschlossener Test oder Projekt fuer einen nicht mehr existierenden Partner herausstellt, besteht die Loesung nicht nur darin, den DNS-Eintrag zu entfernen. Was auch immer hinter dieser Adresse stand, sollte auf Serverebene abgeschaltet werden, mit der Bestaetigung, dass es ueberhaupt nicht mehr auf eine Anfrage antwortet, statt es still weiterlaufen zu lassen, waehrend nur das Schild entfernt wird, das darauf zeigte.
Fuer den naechsten Start einer neuen Stadt oder eines neuen Landes sollte die Testphase unter einem Wildcard-Zertifikat oder einem gemeinsamen internen Zertifikat laufen statt unter einem Zertifikat mit dem genauen Namen dieser Stadt, damit das Register die Expansion nicht vor dem Marketing ankuendigt. Das ist eine einzige Einstellung, die vor dem naechsten Start mit einem Entwickler oder Hosting-Anbieter zu klaeren ist, kein Umbau von etwas, das bereits live ist.
Fuer jede bereits aktive interne Login-, Moderations- oder Abrechnungsseite lautet die Frage nicht, ob ihr Name schwer zu erraten ist. Sie lautet, ob davor unabhaengig vom Namen ein echtes Passwort und, wo moeglich, eine Adressbeschraenkung steht, denn genau das ist der Teil, der wirklich haelt, sobald der Name selbst bereits oeffentlich ist, was er nach einem Blick auf crt.sh hoechstwahrscheinlich bereits ist.
