Tausende etcd-Server leaken Passwörter und Keys

Unschöne Geschichte: Sicherheitsforschern ist über die Suchmaschine Shodan aufgefallen, dass Tausende etcd-Server unsicher konfiguriert sind. Dritte können so Kennwörter und Schlüssel abgreifen. Ein gefundenes Fressen für Cyber-Kriminelle.

Ich denke, es wird nicht so viele Blog-Leser/innen treffen – sondern höchstens Leute im Administratorenumfeld von Firmen tangieren. Zur Sicherheit nehme ich aber die Info hier im Blog auf, bevor ihr möglicherweise ins Osterwochenende entschwindet. Falls ihr etcd-Server betreibt, kontrolliert, ob die gegenüber dem Internet abgesichert sind.

Kubernetes und etcd-Server

Betroffene können mit dem Stichwort etcd-Server etwas anfangen. Für die restlichen Blog-Leser eine kurze Erläuterung. Ein heißes Thema sind Container-Anwendungen (Stichwort: Docker). Zur Bereitstellung, Skalierung und Verwaltung kommt das ursprünglich von Google entwickelte Open-Source-System Kubernetes zum Einsatz. Laut Wikipedia wird die Orchestrierung mittels Kubernetes von führenden Cloud-Plattformen wie Microsofts Azure, IBMs Bluemix, Red Hats OpenShift und Amazons AWS unterstützt.

Mit Kubernetes lassen sich auch Cluster verwalten. Der Master in Kubernetes steuert mit seinen Komponenten die Nodes (Minions), auf denen dann die Docker-Container ausgeführt werden. Zur Speicherung der Konfiguration von Kubernetes Clustern kommt die von CoreOS entwickelte Key-Value-Datenbank etcd zum Einsatz.

Absicherung in etcd

Bereits am 16. März 2018 hat der Software-Entwickler Giovanni Collazo aus Puerto Rico in seinem persönlichen Blog elweb den Artikel The security footgun in etcd veröffentlicht. Das von ihm gewählte Eingangsbild zeigt drastisch die Situation.

(Screenshot der elweb-Seite zu etcd)

Aus Sicht der Anwendungssicherheit sind Datenbanken die wertvollsten Bestandteile aller Systeme. Sie speichern die Daten, die für Anwendungen und Unternehmen wertvoll sind. Daher sollten diese Daten sicher vom Zugriff unbefugter Dritter gehalten werden. Grundsätzlich sind sich Software-Entwickler und Datenbank-Administratoren dessen bewusst. Für MySQL-, PostgreSQL- und MongoDB-Datenbanken werden erfahrene Administratoren darauf achten, dass diese gegen Fremdzugriff abgesichert sind. Und     trotzdem werden immer wieder Pannen und Administrationsfehler bekannt.

Aber was passiert mit Datenbanken, die sich nicht wie "normale Datenbanken" anfühlen? Stichwörter sind Memcached, Redis und natürlich etc. Diese Art von Datenbanken werden oft für einen einzigen Anwendungsfall verwendet und ohne große Sorgfalt behandelt. Und damit nimmt das Unheil seinen Lauf.

Als Giovanni Collazo sich kürzlich mit der CoreOS-Dokumentation befasste, stieß er auf etcd. Die Datenbank etcd ist im Kontext von CoreOS integraler Bestandteil des oben erwähnten Kubernetes Clustering-Systems. Kubernetes benutzt es für die Orchestrierung und vieles mehr.

Collazo schreibt, dass er etcd wirklich cool findet. Es benutzt den RAFT-Konsens-Algorithmus, um alle Knoten synchron zu halten. Es habe ein sehr einfach zu bedienendes CLI-Tool und eine HTTP-API. Er geht davon aus, dass er etcd in naher Zukunft für einige bei seinem Arbeitgeber verwendete Orchestrierungslösungen einsetzen wird.

Beim Lesen der etcd-Dokumentation erinnerte er sich aber an die Meldungen über nicht abgesicherte MongoDB-Datenbanken. Deren Betreiber stellten diese ohne Authentifizierung (diese ist standardmäßig nicht aktiviert) online, so dass Dritte problemlos auf die Datenbanken zugreifen konnten. Bei etcd ist eine Authentifizierung erst ab Version 2.1 möglich. Aus Kompatibilitätsgründen zu früheren Versionen ist die Authentifizierung aber standardmäßig deaktiviert (siehe).

etcd before 2.1 was a completely open system; anyone with access to the API could change keys. In order to preserve backward compatibility and upgradability, this feature is off by default.

Riecht nach Unheil, und ist es auch. Eine einfache Abfrage der Suchmaschine Shodan ergab, dass 2.284 offene und nicht abgesicherte etcd-Server über das Internet erreichbar sind. Diese Abfrage ergibt aktuell aber eine Fehlermeldung, da nur angemeldete Benutzer Ergebnisse angezeigt bekommen. Hier ist eine Twitter-Meldung zum Thema.

2,000+ publicly accessible etcd installations yielded 8,781 passwords. @gcollazo details what he found here: https://t.co/tRxNlo8q5J

It really is as simple as http://<IP address of etcd instance>:2379/v2/keys/?recursive=true

Here's an example MySQL password found: pic.twitter.com/F3cyWj19P8

— Bad Packets Report (@bad_packets) 18. März 2018

Collazo hat sich dann den Shodan-Bericht herunter geladen und ein Script geschrieben, über welches er die REST API der etcd-Server ansprechen konnte. Da die Schlüssel-Wertepaare im JSON-Format gespeichert sind, konnte er sehr schnell Daten extrahieren. Was er dann bekam, war folgendes:

Er keine der Referenzen getestet, geht aber davon aus, dass zumindest ein paar davon funktionieren sollten. Jeder, der nur wenige Minuten Zeit hat, kann eine Liste mit Hunderten von Datenbank-Anmeldeinformationen erhalten, mit denen Daten gestohlen oder Lösegeld-Angriffe durchgeführt werden können. 

Falls ihr also Kubernetes oder etcd-Server für sonstige Zwecke im Einsatz habt und für deren Administration verantwortlich seid: Führt euch die etcd-Dokumentation zu Gemüte und prüft, ob die Datenbank abgesichert ist. Abschließende Frage: Irgend jemand von euch, der etcd-Datenbanken oder Kubernetes administriert? (via)