Skip to content

Konfigurationsfehler in MongoDB führt zu tausenden offenen Datenbanken

Ein Konfigurationsfehler in MongoDB führt dazu, dass tausende Datenbanken frei aus dem Internet zugänglich sind. Ursache ist ein kleiner Fehler, der zu einem großen Problem führt. Wer Schuld daran ist untersuche ich nebenann.

"Secure by Default" sieht anders aus!

Eigentlich sollte Software heutzutage so ausgeliefert werden, dass die Default-Installation sicher ist. Im Fall von MongoDB ist das nicht automatisch der Fall, wie Jens Heyens, Kai Greshake und Eric Petryka herausgefunden haben.

Die drei sind Studenten am Center for IT-Security, Privacy, and Accountability (CISPA) der Uni des Saarlands in Saarbrücken und haben den weit verbreiteten Konfigurationsfehler während ihrer Forschungsarbeit entdeckt. Ein simpler Portscan reicht aus, um die Server zu finden, danach kann ohne Authentifizierung lesend und schreibend darauf zugegriffen werden.

Auslöser der Schwachstelle sind zwei Punkte:

  1. Die Default-Installation von MongoDB ist darauf ausgelegt, dass die Datenbank auf dem gleichen Server wie die darauf zugreifende (Web-)Anwendung läuft. Sie wird daher so installiert, dass Zugriffe nur vom lokalen System aus möglich sind, auf weitere Schutzmaßnahmen wie eine Authentifizierung wird verzichtet.
  2. Die Dokumentation und Anleitungen zur Installation von MongoDB auf Servern mit Internetzugang oder zum Beispiel in der Cloud weisen nicht ausreichend darauf hin, dass in diesen Fällen die Zugriffskontrolle/Authentifizierung und Verschlüsselung manuell konfiguriert werden müssen

Das führt dazu, dass weniger erfahrene Administratoren die Schutzmaßnahmen nicht aktivieren, so dass nicht nur die Anwendung, sondern jeder auf die Datenbank zugreifen kann. Bei der ersten Suche nach betroffenen Installationen wurden 39.890 solcher Datenbankserver entdeckt. Diese Zahl kann aber falsch sein, da zum einen manche IP-Bereiche vor Portscans geschützt sind, so dass dort betriebene betroffene Datenbanken nicht erfasst werden, zum anderen manche Datenbanken absichtlich ohne Schutzmaßnahmen betrieben werden könnten, zum Beispiel Honeypots.

Betroffene Datenbanken finden und angreifen

Das Finden betroffener Datenbanken ist kinderleicht, der Zugriff darauf noch leichter (wenn das überhaupt geht). Der von MongoDB verwendete Default-Port ist 27017 (TCP), und Server mit offenen Port können ganz einfach mit einem Portscan entdeckt werden. Oder durch eine Anfrage bei der darauf spezialisierten Suchmaschine Shodan.

Das war es dann aber auch schon mit dem Aufwand - einmal gefunden, kann auf die MongoDB-Datenbank sofort zugegriffen werden. Denn Schutzmaßnahmen gibt es ja nicht.

Jens Heyens, Kai Greshake und Eric Petryka haben ihre Ergebnisse anhand einer ausgewählten großen Datenbank überprüft, es könnte ja sein, dass absichtlich auf die Schutzmaßnahmen verzichtet wurde. Beim für die Suche nach den Datenbanken nötigen ersten Handshake werden auch Metainformationen wie die Größe der Datenbank und verschiedene Einstellungen übertragen. So konnten die drei sicher sein, wirklich eine große Datenbank zu testen. Die ausgewählte Test-Datenbank stellte sich als Kundendatenbank eines französischen Telekommunikationsanbieters mit mehr als 8 Millionen Kundeneinträgen heraus. Die sollten wohl kaum absichtlich offen zugänglich sein.

Inzwischen wurden die betroffenen Datenbank-Betreiber mit der Hilfe der zuständigen französischen Datenschutz-Behörde, den verschiedenen CERTs und MongoDB Inc. identifiziert und informiert.

Die korrekte Konfiguration von MongoDB

In der Default-Konfiguration wird MongoDB üblicherweise an den localhost gebunden. Dafür ist folgender Eintrag in der Konfigurationsdatei mongodb.conf zuständig:

bindIp: 127.0.0.1
port: 27017

Dadurch sind nur Zugriffe vom gleichen physikalischen oder virtuellen Host möglich, alle anderen Zugriffe werden abgewiesen. Weitere Schutzmaßnahmen sind, wie oben schon erwähnt, nicht aktiviert.

Wird die Datenbank, wie es allgemein üblich ist, auf einem anderen Server betrieben als auf dem, auf dem die darauf zugreifenden Anwendungen laufen, besteht die einfachste Anpassung der Konfiguration darin, diesen Eintrag entweder auszukommentieren oder zu löschen. Wodurch per Default alle Verbindungen akzeptiert werden. Sofern der Zugriff aus dem Internet möglich ist also von überall. Wenn man das nicht möchte (was im Allgemeinen der Fall sein wird), muss eine Zugriffskontrolle konfiguriert werden. Außerdem empfiehlt sich die Aktivierung der Verschlüsselung, sofern die Daten zwischen Datenbank und Anwendung nicht ausschließlich über lokale Netzwerkverbindungen übertragen werden.

Für die Zugriffskontrolle stehen vier Authentifizierungsmethoden zur Wahl:

  1. "Challenge and Response" (MONGODB-CR, die Default-Methode), die Benutzer weisen sich durch Benutzername und zugehöriges Passwort aus.
  2. "X.509 Certificate Authentication", bei der die Zertifikate einer vorhandenen PKI zur Authentifizierung verwendet werden.
  3. "Kerberos Authentication" (setzt eine Enterprise-Lizenz von MongoDB voraus) zur Nutzung eines vorhandenen Kerberos-Servers.
  4. "LDAP Proxy Authentication" (setzt eine "Enterprise for Linux"-Lizenz von MongoDB voraus, die "Enterprise for Windows"-Lizenz unterstützt LDAP nicht) zur Nutzung eines vorhandenen LDAP-Servers.

Für die Verschlüsselung wird auf SSL/TLS zurück gegriffen, wobei man natürlich sichere Verfahren verwenden sollte. MongoDB erlaubt ab Version 2.6 sowieso nur noch sichere Cipher-Suiten.

Weitere Informationen zur Konfiguration haben Jens Heyens, Kai Greshake und Eric Petryka in ihrem Bericht zusammengefasst.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Der Konfigurationsfehler in MongoDB - Admins, bitte aufwachen!

Vorschau anzeigen
Ein Konfigurationsfehler in MongoDB führt dazu, dass tausende Datenbanken frei aus dem Internet zugänglich sind. Was beweist, dass auch eigentlich kleine Fehler zu einem großen Problem werden können. Sicherheit per Defaul

Dipl.-Inform. Carsten Eilers am : MongoDB ohne Passwort? Da war doch mal was?

Vorschau anzeigen
Aus traurigen aktuellem Anlass und ohne weiteren Kommentar: "Konfigurationsfehler in MongoDB führt zu tausenden offenen Datenbanken" und "Der Konfigurationsfehler in MongoDB - Admins, bitte aufwachen!". Beide vom 10. Februar 20