Der MongoDB-Hack und die Bedeutung sicherer Standardeinstellungen

Wenn Sie MongoDB installiert haben, sollten Sie jetzt überprüfen, ob die Installation sicher ist. Seit kurz vor Weihnachten wurden über 28.000 öffentlich zugängliche MongoDB-Installationen gehackt. Die Angreifer halten die erbeuteten Daten als Geiseln und verlangen von den Unternehmen Bitcoins, damit sie ihre Daten zurückbekommen. Offenbar haben bislang mindestens 20 Unternehmen nachgegeben und das Lösegeld gezahlt. In diesem Beitrag erfahren Sie, wie der Hack funktioniert, wie Sie sich schützen können und was wir daraus lernen können.

Der Hack im Detail

Der Hack selbst ist alarmierend einfach. In Versionen ab 2.6.0 enthält MongoDB eine Standardkonfigurationsdatei, die MongoDB standardmäßig an 127.0.0.1 bindet. Dadurch akzeptiert die Datenbank nur lokale Verbindungen.

Vor Version 2.6.0 war das anders. Standardmäßig war MongoDB für Remote-Verbindungen geöffnet. Auch eine Authentifizierung ist standardmäßig nicht erforderlich. Das bedeutet, dass MongoDB-Installationen vor Version 2.6.0 nicht authentifizierte Remote-Verbindungen ohne Weiteres akzeptieren.

Nutzer konnten den Zugriff trotzdem auf lokale Verbindungen beschränken, wenn sie sich die Zeit nahmen, die Installation zu konfigurieren. Dazu mussten sie jedoch manuell eine Zeile in die Datei mongodb.conf einfügen. Da dies nicht der Standardkonfiguration entsprach, fehlte dieser wichtige Schritt bei vielen bestehenden Installationen.

Erschwerend kommt hinzu, dass potenzielle Angriffsziele mit MongoDB leicht zu finden sind. Der Standardport von MongoDB ist 27017. Mit einer Suchmaschine wie ZoomEye können Sie nach MongoDB-Installationen suchen, herausfinden, über welchen Port sie erreichbar sind, und rund 100.000 verwundbare Systeme finden.

Die Schwachstelle ist keineswegs neu. Das Problem wurde erstmals 2012 angesprochen und etwa 2015 veröffentlicht. Anfang 2015 sorgte John Matherly außerdem für Aufsehen, als er meldete, rund 30.000 unsichere MongoDB-Installationen gefunden zu haben. Mit anderen Worten: Davon hätten alle schon seit einiger Zeit wissen können.

Das Problem mit unsicheren Standardeinstellungen

Unsichere Standardeinstellungen sind kein geringfügiges Problem. Eine Studie nach der Studie nach der Studie hat gezeigt, dass die meisten Menschen die Standardeinstellungen eines Systems beibehalten. Standardeinstellungen sind wichtig.

Manche mögen argumentieren, dass bestimmte unsichere Standardeinstellungen einen Kompromiss zwischen Benutzerfreundlichkeit und Sicherheit darstellen und auf nachvollziehbaren Annahmen beruhen. Wenn Sie beispielsweise davon ausgehen können, dass eine Datenbank in den allermeisten Fällen sicher hinter einer Firewall installiert wird, könnten Sie entscheiden, dass es eine sinnvolle Standardeinstellung wäre, die Datenbank nicht an lokale Verbindungen zu binden.

Solche Annahmen sind jedoch gefährlich, denn wenn jemand etwas tut, das diese Annahme widerlegt – und nicht nur falls jemand es tut –, ist das System angreifbar. Möglicherweise bemerkt die Person das nicht einmal. Die potenziellen Sicherheitsrisiken solcher Standardeinstellungen sind nicht gerade allgemein bekannt. Wenn ein Unternehmen nicht über Sicherheitsexperten verfügt, die jede Entscheidung überprüfen (was sinnvoll, aber nicht selbstverständlich ist), können diese unsicheren Standardeinstellungen übersehen werden – und werden es oft auch.

Unsichere Standardeinstellungen erkennen

Das Problem mit unsicheren Standardeinstellungen wird noch größer.

Nehmen wir an, Sie sind eine verantwortungsbewusste Organisation und verwenden ein Tool wie Snyk, um Ihre Tools und Abhängigkeiten auf Schwachstellen zu überprüfen. Diese Tools melden das Problem nicht, denn unsichere Standardeinstellungen gelten in der Regel nicht als Schwachstellen. Der Grund: Es handelt sich nicht um einen Fehler oder eine Schwachstelle im Code selbst, sondern um ein Konfigurationsproblem.

Das ist bis zu einem gewissen Grad nachvollziehbar, wirft aber die Frage auf: Sollte es eine offizielle Kennung und Datenbank für unsichere Standardeinstellungen geben?

Einerseits würde ein Dienst, der unsichere Standardeinstellungen meldet, zweifellos einiges an Rauschen verursachen. Es gibt zahlreiche unsichere Standardeinstellungen, und manche Organisationen haben bereits Gegenmaßnahmen ergriffen. Sie müssten herausfinden, ob das Problem sie weiterhin betrifft – was nicht immer einfach ist. Ist das nicht der Fall, könnten sie den Hinweis bedenkenlos ignorieren und weitermachen.

Für Nutzer, die solche Risiken noch nicht erkannt haben, könnte die Meldung unsicherer Standardeinstellungen jedoch von unschätzbarem Wert sein. Sie könnte sie auf Sicherheitsrisiken aufmerksam machen, die sonst möglicherweise jahrelang unbemerkt und unbehandelt blieben – wie im Fall des MongoDB-Problems.

Bekannte unsichere Standardeinstellungen in einer Open-Source-Datenbank zu kennzeichnen (so wie wir bekannte Schwachstellen kennzeichnen) hätte diesen Angriff nicht verhindert, aber zumindest einige der Datenbanken vor dem Angriff schützen können.

Wie geht es jetzt weiter?

Zunächst einmal: Sichern Sie Ihre MongoDB-Installation. Wir warten.

Willkommen zurück. Dieser Hack zeigt, wie enorm wichtig sichere Standardeinstellungen sind. Sicherheit ist zu wichtig, um sie dem Zufall zu überlassen. So wie sich in der Branche zunehmend die Erkenntnis durchsetzt, dass Websites standardmäßig über HTTPS bereitgestellt werden sollten, sollten Paketautoren alles daransetzen, ihre Pakete standardmäßig sicher zu machen. Eine unsichere Standardeinstellung kann genauso großen Schaden anrichten wie eine bekannte Schwachstelle. Es ist verständlich, dass die Entwickler dieser Tools eine Installation mit möglichst wenigen Hürden als Standard anbieten möchten. Ist diese Standardeinstellung jedoch unsicher, entstehen Situationen wie die, mit der MongoDB-Nutzer jetzt konfrontiert sind.

Diese Angriffe werfen außerdem die Frage auf, ob es an der Zeit ist, unsichere Standardeinstellungen in einer Open-Source-Datenbank zu erfassen. Bei Snyk diskutieren wir immer wieder darüber, ob wir solche Fehler als Schwachstellen kennzeichnen sollten, und werden das vermutlich noch lange tun. Wenn Sie dazu eine klare Meinung haben, lassen Sie es uns wissen – per E-Mail oder auf Twitter. Wenn Sie in der Zwischenzeit herausfinden möchten, ob Ihre Abhängigkeiten sicherheitsrelevante Überraschungen bereithalten, überprüfen Sie Ihre Repositories schnell mit Snyk.