Comodo: Zertifikatsausstellung mit HTML-Injection ausgetrickst

Eine Sicherheitslücke der TLS-Zertifizierungsstelle Comodo hat es unter Umständen erlaubt, Zertifikate für fremde Domains auszustellen. Angriffspunkt waren dabei die Verifikationsmails, die an den Domaininhaber gesendet werden.

Artikel veröffentlicht am 30. Juli 2016, 13:36 Uhr, Hanno Böck

Bei Comodo bekommt man kostenlose Test-Zertifikate für 30 Tage - bis vor kurzem sogar für fremde Domains. (Bild: Comodo)

Der Sicherheitsforscher Matthew Bryant hat eine kritische Sicherheitslücke im Zertifikatsausstellungsprozess von Comodo entdeckt. In Verifikationsmails, die dazu dienen, den Domaininhaber zu authentifizieren, lässt sich HTML-Code einschleusen. Damit kann man ein Opfer dazu bringen, den Domainverifikationscode an den Angreifer zu verschicken.

Domain-Inhaberbestätigung via E-Mail

Bei der Ausstellung von TLS-Zertifikaten muss zunächst nachgeprüft werden, ob dem Antragsteller die Domain, für die er ein Zertifikat bekommen möchte, auch gehört. Dafür gibt es verschiedene Verfahren, beispielsweise kann dies durch eine spezielle Datei mit einem Code geschehen, die auf dem Webserver abgelegt wird, oder über einen DNS-Record. Sehr üblich ist aber auch eine Verifikationsmethode via E-Mail: Dabei wird ein Verifikationscode an eine E-Mail-Adresse geschickt, die entweder in den Whois-Daten der Domain steht oder die mit einem von fünf reservierten Local-Parts beginnt (postmaster@, hostmaster@, admin@, administrator@, webmaster@).

Bei Comodos Verifikationsprozess werden vor dem Verschicken der Verifikationsmail einige Daten des Kunden abgefragt, unter anderem der Firmenname. Anschließend landen diese Daten - ungefiltert - in der Verifikationsmail. Das ermöglicht mehrere Angriffsszenarien.

Üblicherweise erlauben Mailclients das Verwenden von Javascript in Mails nicht, daher ist eine schlichte Cross-Site-Scripting-Attacke (XSS) nicht möglich. Doch Bryant beschreibt eine andere Methode, mit der sich dies ausnutzen lässt: In das Feld des Firmennamens fügte er ein HTML-Formular ein, das einen Button anzeigt, welcher vorgibt, den Antrag auf ein Zertifikat zurückzuziehen. Die Idee: Erhält jemand eine Mail, in der ein Zertifikat bestellt wurde, dass derjenige überhaupt nicht bestellt hat, klickt er möglicherweise auf einen Button, der diesen Vorgang abbricht. In Wahrheit schickt der Klick auf den Button jedoch Daten an einen Server des Angreifers.

Das Ende des HTML-Formulars enthält einen geöffneten Textarea-Tag, der nicht geschlossen wird. Dadurch wird der gesamte Rest der Mail Teil der Formulardaten. Den fehlenden schließenden Tag ignorieren HTML-Parser von Mailclients und Browser, da sie darauf ausgelegt sind, auch defekten HTML-Code lesen zu können. Durch diesen Trick erhält der Angreifer nun den Inhalt der Mail samt Verifikationscode und kann selbst ein Zertifikat für die Domain beantragen. Comodo wurde am 4. Juni über die Sicherheitslücke informiert, am 25. Juli wurde sie geschlossen.

HTML-Mails als Risiko

Dass die Domaininhaberverifikation ein sehr sensibler Schritt bei der Zertifikatsausstellung ist, dürfte klar sein. Daher erscheint es fragwürdig, dass Comodo hier überhaupt HTML-Mails einsetzt. Andere Zertifizierungsstellen setzen hier schlicht auf reine Textmails, was derartige Angriffe von vornherein vereitelt. Unabhängig davon erscheint es auch riskant, vom Nutzer zur Verfügung gestellte Daten in der Verifikationsmail zu verschicken, da es dafür eigentlich keinen Grund gibt.

Die Domaininhaberverifikation von Zertifizierungsstellen war schon öfter ein Angriffsvektor für Sicherheitslücken. Vor kurzem gab es etwa eine Lücke beim Service Start Encrypt, der ein eigenes Protokoll zur Inhaberverifikation nutzte. Immer wieder gibt es auch Mailanbieter, die die reservierten Mailadressen nicht sperren.

Unabhängig von derartigen Lücken ist der gesamte Zertifikatsausstellungsprozess problematisch, da die Feststellung des Domaininhabers nicht kryptographisch abgesichert ist. Das ist allerdings ein kaum lösbares Problem, da die Zertifikate ja gerade dazu dienen, kryptographische Verbindungen zu ermöglichen und vorab keine kryptographische Bestätigung des Domaininhabers vorhanden ist. Im vergangenen Jahr zeigten Sicherheitsforscher auf der Black-Hat-Konferenz einen Angriff mittels BGP-Routing.