Original-URL des Artikels: https://www.golem.de/news/certificate-transparency-webanwendungen-hacken-bevor-sie-installiert-sind-1707-129116.html    Veröffentlicht: 29.07.2017 00:56    Kurz-URL: https://glm.io/129116

Certificate Transparency

Webanwendungen hacken, bevor sie installiert sind

Mit Certificate Transparency werden HTTPS-Zertifikate in öffentlichen Logs gespeichert. Das bringt mehr Sicherheit im TLS-Ökosystem, es führt aber auch zu überraschenden Gefahren für Webanwendungen wie Wordpress.

This text is also available in English.

Das von Google entwickelte System Certificate Transparency ist inzwischen zu einem wichtigen Teil des TLS-Ökosystems geworden. In öffentlichen und kryptographisch verifizierbaren Logs werden Webseitenzertifikate gespeichert und können von jedem dort eingesehen werden. Das hat viel zur Aufklärung von Vorfällen wie den falsch ausgestellten Zertifikaten von Symantec beigetragen.

Doch Certificate Transparency hat auch Auswirkungen, die bislang kaum bedacht wurden. Die Zertifikate enthalten Informationen, die aus vielerlei Hinsicht interessant sein können - auch für Angreifer.

Hostnamen lassen sich nicht mehr geheim halten

Ein Webseitenzertifikat enthält üblicherweise einen Hostnamen. Damit kann es Aufschluss über Subdomains geben. So kann man beispielsweise die Certificate-Transparency-Suchmaschine crt.sh nutzen, um nach Subdomains einer Domain zu suchen. Hilfreich, wenn man beispielsweise nach allen Subdomains einer Firma suchen möchte, um sie nach Sicherheitslücken abzuklappern.

Ganz praktisch heißt das, dass Subdomains in aller Regel nicht mehr geheim sind - mit der Ausnahme von Wildcard-Zertifikaten oder wenn man die umstrittene Möglichkeit von Redacted-Labels in Certificate Transparency nutzt.

Interne Services unter nicht zu erratenden, "geheimen" Subdomains zu betreiben, war zwar schon immer eine schlechte Idee, da Subdomains immer unverschlüsselt im Datenverkehr mitgelesen werden können, aber durch Certificate Transparency wird das noch mal verdeutlicht.

Manche Zertifizierungsstellen tragen schon heute alle Zertifikate automatisch in öffentliche Logs ein. Symantec wurde von Google nach den ersten größeren Sicherheitsvorfällen 2015 dazu gezwungen. Sogenannte Extended-Validation-Zertifikate müssen sowieso in Logs eingetragen werden. Let's Encrypt trägt ebenso wie Cloudflare freiwillig alle ausgestellten Zertifikate in Logs ein.

Doch auch, wer nicht selbst loggt, findet üblicherweise seine Zertifikate schnell in den Logs wieder, denn der Crawler der Google-Suchmaschine trägt Zertifikate automatisch dort ein.

Bald werden sowieso alle Zertifikate geloggt. Ursprünglich hatten die Chrome-Entwickler angekündigt, das ab September zu verlangen, inzwischen die Deadline aber auf April 2018 verschoben. In der Praxis landen aber schon heute sehr viele Zertifikate schnell in Logs.



Webanwendungen mit ungesicherten Installationsroutinen

Für selbstgehostete Webanwendungen wie Wordpress, Joomla, Nextcloud und ähnliche kann Certificate Transparency zum Problem werden. Die Installation von Webanwendungen funktioniert üblicherweise so, dass ein Nutzer den PHP-Code der Software auf einen Webserver hochlädt und anschließend den Installer über die Webseite aufruft. Dort werden Dinge wie die Datenbankeinstellungen eingetragen und meist ein initialer Admin-Nutzeraccount erstellt.

Das Risiko hier: Diese Installation findet bei den meisten Webanwendungen ohne jegliche Authentifizierung statt. Findet ein Angreifer eine uninstallierte Webanwendung, dann kann er üblicherweise trivial Code auf dem Server ausführen.

Bislang waren die ungeschützten Installer kein großes Problem, denn ein Angreifer müsste schon den genauen Zeitpunkt kennen, an dem ein Webmaster seine Anwendung installiert. Problematisch waren daher in erster Linie Installer, die liegengelassen wurden und die man beispielsweise irgendwann über eine Google-Suche finden konnte.

Doch mit Certificate Transparency ändert sich das. Denn dem Angreifer steht dadurch indirekt ein Feed mit vielen gerade neu erstellten Hostnamen zur Verfügung. Viele Webhoster unterstützen inzwischen standardmäßig HTTPS und erstellen automatisch Zertifikate, wenn man einen neuen Hostnamen anlegt.

Backdoor mittels Plugin hochladen

Ein Angreifer kann nun die Certificate-Transparency-Logs beobachten und die Webseiten zu allen dort neu eingetragenen Zertifikate abrufen. Die abgerufenen Seiten werden mit den Installationsroutinen von gängigen Webapplikationen verglichen. Mit etwas Glück trifft der Angreifer genau den richtigen Zeitpunkt, zu dem gerade die Installation durchgeführt wird.

Wenn ein Angreifer dabei einen Installer beispielsweise von einem Wordpress findet, kann er diesen direkt übernehmen. Zunächst installiert er die Anwendung. Für den Datenbankzugang kann er eine externe Datenbank nutzen, beispielsweise von einem kostenlosen MySQL-Hosting-Service.

<#youtube id="yzLdmUQAn1g">

Wenn man die Installation selbst durchgeführt hat ist es bei den meisten Webanwendungen kein Problem, auch Code direkt auszuführen. Üblicherweise geht das, indem man ein dafür ein Plugin installiert. So kann der Angreifer beispielsweise eine PHP-Shell hochladen.

Anschließend kann er die Installation wieder rückgängig machen. Dafür reicht es in der Regel, die Konfigurationsdatei zu löschen, die bei der Installation angelegt wurde. Wenn man das alles schnell durchführt - beispielsweise indem man es automatisiert - merkt der Besitzer der Webapplikation überhaupt nichts, da die Installation danach wieder wie gewohnt zur Verfügung steht.

Der Angreifer hat jetzt eine Hintertür, über die er nach Belieben Code ausführen kann. Die kann er später für alles mögliche nutzen, beispielsweise für ein Defacement der Webseite, um Spam zu verschicken oder um Phishing-Seiten auf dem Webserver abzulegen.

5.000 übernommene Wordpress-Installationen in drei Monaten

Der Autor hat über drei Monate ein Testskript laufen lassen, das die Transparency-Logs beobachtet und die entsprechenden Webseiten nach Installern absucht. Der letzte Schritt, das eigentliche Übernehmen der Webanwendung, wurde dabei natürlich ausgelassen.

Mit Abstand am häufigsten fanden sich dabei wenig überraschend Installer für Wordpress. Etwa 5.000 Wordpress-Installationen hätte man übernehmen können. Bei Joomla waren es immerhin noch knapp 500, bei Nextcloud 120. Andere Webanwendungen traten vergleichsweise selten auf.

Ein solcher Angriff könnte weiter optimiert werde. Das Skript prüfte jeden Host nur einmal pro Zertifikat. Ein Angreifer könnte aber alle neuen Zertifikats-Hostnamen, auf denen noch kein Inhalt hinterlegt ist, für mehrere Tage regelmäßig prüfen. Das verwendete Testskript hatte zudem recht knappe Timeouts, die dazu führten, dass Drupal-Installationen häufig nicht erkannt wurden, da der Installer relativ langsam antwortet.

Installer ohne Authentifizierung als Risiko

Um sich vor solchen Angriffen zu schützen, sollten Webanwendungen eine Authentifizierung des Nutzers als Teil der Installationsroutine einführen. Dafür gibt es verschiedene Möglichkeiten, so könnte der Installer etwa eine Datei mit einem geheimen Token anlegen, das der Nutzer anschließend herunterladen und in ein Formular eingeben muss. Doch viele Webanwendungen wollen ungern einen solchen zusätzlichen Authentifizierungschritt einführen, da sie den Installer möglichst einfach gestalten wollen.

Erwähnenswert ist, dass einige Anwendungen nicht für einen solchen Angriff verwundbar sind, da ihr Installationsmechanismus anders funktioniert. Eine solche Software ist das von Wikipedia verwendete System Mediawiki. Der Installer von Mediawiki erzeugt eine Konfigurationsdatei. Die wird allerdings nicht direkt installiert, sondern muss vom Nutzer heruntergeladen und anschließend wieder ins Webverzeichnis hochgeladen werden.

Der Mediawiki-Installer erlaubt es allerdings, eine SQLite-Datenbank zu nutzen. Die wird vom Installer erstellt. Damit kann ein Angreifer, der einen Mediawiki-Installer findet, eine SQLite-Datei auf dem System anlegen. Bösartig ausnutzen lässt sich das aber vermutlich nicht.



Nur Joomla hat bisher reagiert

Der Autor hat dieses Problem schon vor Monaten an die Entwickler der wichtigsten Webanwendungen gemeldet. Die Reaktionen waren äußerst verhalten. Die Entwickler vonTypo3, Drupal und Owncloud antworteten nicht einmal. Von Wordpress und Nextcloud kam zunächst zumindest Interesse an einer Diskussion, aber das verebbte auch schnell wieder, verändert wurde dort bislang nichts.

Einzig Joomla hat seinen Installationsmechanismus geändert. Dort gibt es künftig einen zusätzlichen Authentifizierungsschritt, allerdings nur, wenn die MySQL-Datenbank auf einem externen Server liegt. In dem Fall muss der Nutzer ein Verzeichnis mit einem zufällig erzeugten Namen entfernen, um die Installation fortzusetzen.

Die Idee dabei: Ein Angreifer hat in aller Regel keine Zugangsdaten für den lokalen MySQL-Server. Absolut sicher ist das allerdings nicht. Ein Angreifer könnte etwa Zugangsdaten für die Server von beliebten Hosting-Providern sammeln und trifft mit Glück manchmal einen Server, für den er bereits Zugangsdaten besitzt.

Vorstellbar ist auch eine Kombination: Ein Angreifer führt den Angriff gegen verschiedene Webanwendungen durch. Wenn er eine Anwendung übernehmen kann, hat er anschließend auch die Möglichkeit, von der später von ihrem Besitzer installierten Anwendung die MySQL-Zugangsdaten zu klauen.

Sich als Nutzer zu schützen, ist kompliziert

Sich als Nutzer gegen ein solches Szenario zu schützen, ist schwierig. Bei einem Apache-Webserver ist es denkbar, eine htaccess-Datei hochzuladen, die den Installer mit einem Passwort schützt. Allerdings nutzen viele Webanwendungen selbst htaccess-Dateien, es kann also passieren, dass die sich in die Quere kommen. Umgehen kann man dieses Problem, indem man die htaccess-Datei im übergeordneten Verzeichnis ablegt. Das geht aber nur, wenn der Webhoster einem auch Schreibzugriff auf dieses Verzeichnis gibt.

Weiterhin möglich ist es, die Installation zunächst auf einem lokalen Testserver durchzuführen und anschließend hochzuladen. Das ist aber recht aufwendig.

Theoretisch kann man natürlich auch die Installation sehr schnell durchführen. Denn in aller Regel brauchen die Zertifikatslogs etwa eine halbe Stunde, bis die Zertifikate öffentlich sind. Allerdings kann man sich darauf nicht verlassen und es ist natürlich denkbar, dass zukünftige Zertifikatslogs schlicht schneller arbeiten.

Bislang keine Hinweise auf Angriffe

Bleibt zuletzt die Frage, ob Angreifer diese Möglichkeit schon kennen und von ihr Gebrauch machen. Der Autor hat dafür mehrere Subdomains mit Let's-Encrypt-Zertifikaten aufgesetzt, die niemandem sonst bekannt sind.

In den Logdateien der entsprechenden Hosts tauchte neben den Zugriffen des eigenen Testskripts bislang nur ein Zugriff von der Firma Netcraft auf. Netcraft erstellt Statistiken über das Web und nutzt dabei offenbar die Certificate-Transparency-Logs.

Zugriffe, die auf einen Angriff hindeuten, gab es bisher keine. Das kann sich aber bald ändern. Dass die überwiegende Mehrzahl der Webanwendungen ihre Nutzer bislang vor einem solchen Angriff nicht schützt, ist schwer zu verstehen.

Der Autor des Texts hat diesen Angriff auf der Def-Con-Konferenz in Las Vegas vorgestellt.  (hab)


Verwandte Artikel:
HTTPS: Fritzbox bekommt Let's Encrypt-Support und verrät Hostnamen   
(15.12.2017, https://glm.io/131705 )
Webframework: Rails 4.1 beschleunigt Tests und Rake   
(09.04.2014, https://glm.io/105747 )
Fahrzeugsicherheit: Kartendienst Here kauft Anbieter für Online-Updates   
(28.11.2017, https://glm.io/131371 )
Open Hardware: Selbstbaurechner kommt ohne Firmware-Blobs aus   
(01.08.2017, https://glm.io/129229 )
Security: Blizzard installiert selbstsigniertes Zertifikat mit Root   
(22.12.2017, https://glm.io/131828 )

© 1997–2018 Golem.de, https://www.golem.de/