Software::Datenbanken
Der MongoDB-Erpressungstrojaner und die Bedeutung von sicheren Standardeinstellungen
Unsichere Standardeinstellungen machten MongoDB offen für jegliche Angriffe, doch die Einstellungen wurden bereits 2014 mit Version 2.6 geändert. Dennoch war Ende 2016 noch eine große Zahl von MongoDB-Instanzen im Netz verwundbar.
Victor Gevers
Lösegeldforderung in kompromittierter MongoDB-Instanz
Ungefähr seit Weihnachten wurden zahlreiche Betreiber von MongoDB-Datenbanken
Opfer eines Erpressungstrojaners. Dieser löschte alle Daten und bot deren Wiederherstellung gegen Zahlung eines Lösegelds von 0,2 Bitcoins an. Es wird stark davon abgeraten, das Lösegeld zu zahlen, da die Daten anscheinend
trotzdem nicht wieder hergestellt werden.
Die Geschichte ist nun nicht mehr neu, die Frage, wie es dazu kommen könnte, beschäftigt die Branche und die Medien aber weiterhin. Der Erpressungstrojaner konnte nur deshalb Erfolg zeigen, weil es zahlreiche MongoDB-Instanzen im Netz gab, die keinerlei Zugangskontrolle implementiert hatten. Sie waren von jedem Rechner im Netz aus erreichbar und es gab kein Passwort für den Administrator. Das Auslesen sämtlicher Daten war ebenso möglich wie das Verändern oder Löschen.
Ihre Wurzel hat das Problem in den unsicheren Standardeinstellungen von MongoDB. Bis 2014, als Version 2.6 erschien und dem Übel ein Ende bereitete, war eine Standardinstallation von MongoDB über das Netz erreichbar und Zugriffskontrollen wie ein Passwort für den Administrator existierten nicht. Schon im Februar 2015 entdeckte ein Forscherteam, dass rund 40.000 ungesicherte MongoDB-Instanzen im Netz existierten, die teilweise vertrauliche Daten mit Millionen von Datensätzen enthielten, und alarmierten die Betreiber sowie die Behörden. Schon damals könnte durch die ungesicherten Instanzen ein immenser Schaden entstanden sein, denn die Betroffenen waren durchaus nicht alle bedeutungslose kleine Firmen.
Auch wenn die Betroffenen reagiert haben und neue MongoDB-Versionen mit sicheren Standardeinstellungen ausgeliefert werden, scheint es, dass sich insgesamt nicht viel geändert hat. Wie konnte es also dazu kommen, dass Ende 2016 an die 100.000 MongoDB-Instanzen ungesichert im Netz standen? Die meisten davon lagen in öffentlichen Clouds; nur wenige Anwender, die MongoDB in den eigenen Räumen nutzen, werden so dilettantisch vorgehen, dass sie den Zugriff aus dem Internet freigeben und kein Passwort setzen. Besonders hervorgetan hat sich hier wohl Amazon, das in seiner AWS-Cloud den Kunden veraltete unsichere Instanzen von MongoDB zur Verfügung stellte.
Nach verschiedenen Berichten waren 2.000 bis 30.000 MongoDB-Instanzen von dem Erpressungstrojaner betroffen. Mindestens 20 Nutzer haben ein Lösegeld bezahlt, aber anscheinend hat keiner davon seine Daten wieder erhalten. Nur zehn Prozent der Benutzer verfügten über ein aktuelles Backup, der Rest hat seine Daten unwiderruflich verloren. Wie man seine Datenbank sicher installiert und was man nach einem Angriff tun sollte, erläutert MongoDB selbst noch einmal ausdrücklich.
Über MongoDB hinaus existiert das Problem unsicherer Standardeinstellungen potentiell bei vielen Programmen. Entwickler und Distributoren müssen darauf achten, dass ihre Standardeinstellungen sicher sind, fordert beispielsweise der Sicherheitsforscher Tim Kadlec. Für die Anwender ist es natürlich weniger bequem, wenn sie Passwörter vergeben und möglicherweise ihre Konfiguration anpassen müssen, anstatt unmittelbar mit dem Programm loslegen zu können. Aber es ist die einzig sinnvolle Möglichkeit, da Anwender erfahrungsgemäß bei den Standardeinstellungen bleiben, wenn sie diese nicht ändern müssen.
){kind=small}
