MongoDB: Darum waren Millionen sensible Daten versehentlich online einsehbar [Interview]

(Bild: Shutterstock)

Drei Studenten hatten vor einigen Tagen per Zufall tausende Online-Datenbanken des Anbieters der nach eigenen Angaben führenden NoSQL-Datenbank MongoDB entdeckt: Offen wie ein Scheunentor und sogar veränderbar (wir berichteten). Darin befanden sich Millionen Kundendaten, die neben Name, Anschrift und E-Mail-Adresse auch Kreditkartennummern beinhalteten. Marc Schwering von MongoDB nahm in einem Interview mit uns nun Stellung zu dem Vorfall und erklärte unter anderem, warum solch sensible Daten derart ungeschützt im Internet zu finden waren.

Viele verwalten online ihr hart erarbeitetes Vermögen, sichern die privaten Fotos der Familie und wollen möglichst einfach möglichst alles im Internet kaufen können. Damit all dies funktioniert, werden die persönlichen Daten, die es für diese Vorgänge nun einmal braucht, gespeichert. Und zwar, wie auch das gute Geld, in einer Bank. Genauer gesagt: Einer Datenbank. Jeder Nutzer erhält dort einen Eintrag für all die Daten, die er im Laufe der Zeit angegeben hat, ganz gleich ob Lieblingsgemüse oder Finanztransfers.

Was man so alles an unbekannten und weit entfernten Plätzen speichert, möchte man eigentlich gar nicht wissen. Und selbst wenn man es weiß, heißt das trotzdem noch nicht, dass man sich auch vorstellen kann, was das bedeutet. Darum vertraut die große Mehrheit schlichtweg auf die Sicherheitssysteme solcher Datenbanken, doch was, wenn dieses Vertrauen gar nicht gerechtfertigt ist? Der jüngste Vorfall im Zusammenhang mit der eigentlich sehr an Sicherheit interessierten Datenbank MongoDB, der auch deutsche und französische Betreiber kompromittierte, offenbarte als eines von vielen Datenlecks die Schwierigkeiten und stellte gleichzeitig auch das Vertrauen in Frage.

„Der Fehler ist nicht kompliziert, seine Wirkung ist jedoch katastrophal“, so Michael Backes, Direktor des Saarbrücker Kompetenzzentrum für IT-Sicherheit (CISPA) zu den Millionen online sicht- und editierbaren Kundendaten. Wie lässt sich so ein Datenleck erklären? Wer hat eigentlich Schuld? In einem Interview nahm Marc Schwering, Senior Solutions Architect bei MongoDB, dazu Stellung.

Herr Schwering, was verbirgt sich eigentlich hinter MongoDB?

Das Produkt unserer Firma ist eine dokumentorientierte Datenbank, das heißt, wir sind in der Lage, Daten, die in einer standardmäßigen relationalen Datenbank in Zeilen und Spalten abgelegt sind, angereichert mit Unterobjekten zu speichern. Das heißt, seine Anwendungen, die man in der objektorientierten Welt programmiert, kann man so direkt in der Datenbank sichern.

MongoDB als Technologie ist Open-Source verfügbar, als Firma MongoDB Incorporation entwickeln wir die Datenbank und die Treiber weiter. Das Ganze kann dann kostenlos heruntergeladen werden. Unser Geld verdienen wir, ähnlich wie Red Hat, mit einer Enterprise Version und außerdem über Support, Service und Beratung.

Vor kurzem gab es den angesprochenen Fall, bei dem Studenten einige Datenbanken zufällig einsehen und auch verändern konnten. Als Grund wurde ja ein Konfigurationsfehler bei MongoDB angeführt. Wie sah dieser Fehler aus?

Die Crux, die wir als Open-Source-Anbieter ja haben, ist, dass wir unsere Nutzer zum Teil nicht kennen. Wir haben zwar viele Großunternehmen sowie kleine Firmen, zu denen wir sehr viel direkten Kontakt haben, aber bei mittlerweile insgesamt über neun Millionen Downloads gibt es auch sehr viele unbekannte Nutzer.

Wir versuchen natürlich sicherzustellen, dass die Benutzer unsere Instructions befolgen. Neben den Standard-Instructions, die man generell hat, wenn man Software übers Internet betreibt, haben wir dazu noch ReadMe, Konfigurationsschritte und Security-Informationen. Viele Security-Einstellungen sind aber optional. Das heißt, der Package Installer, über den man die Datenbank für gewöhnlich herunterlädt, fragt nach den Security-Informationen – das kann man aber natürlich auch verneinen, um lokal ohne große Schwierigkeiten arbeiten zu können.

Stellen Sie sich vor, Ihr Auto parkt vor der Haustür und Sie wollen sehr viel einladen. Sie sperren Ihr Auto nicht ständig auf und ab, sondern beladen Ihr Auto, lokal sozusagen. So ist das bei der Datenbank auch, wenn man als Entwickler in seiner lokalen Umgebung, auf seinem Rechner, arbeitet.

Das sollte man aber natürlich nicht bei einem Live-System im Internet machen. Es geht dann darüber hinaus, dass die Datenbank überhaupt erreichbar ist. Das sind ja zwei paar Schuhe: Erreichbarkeit und Zugriffserlaubnis.

Man kann im Internet über die Ports auf die Daten zugreifen – in der Regel Port 80 oder 8080 – und alles andere sollte man sofort deaktivieren. Zum Einen haben die Nutzer das nicht gemacht und ihre Rechner falsch konfiguriert, zum Anderen wurden für die Datenbanken einfach keine Usernamen und Passwörter verwendet.

Wir haben Kunden, die brauchen das eventuell auch nicht, da von Außen niemand aufs Rechenzentrum kommt. Nichtsdestotrotz empfehlen wir natürlich die Mindestanforderungen, also Ports blocken, Username/Passwort oder auch erweiterte Systeme, die im Enterprise-Produkt enthalten sind.

Die Verantwortung obliegt also dem Kunden. Wird den Nutzern der Datenbank das, sowie entsprechende Sicherheitseinstellungen, auch vor Augen geführt?

Nach dem Bekanntwerden der Datenlecks haben wir alle uns bekannten Nutzer darauf hingewiesen. Unser CTO hat dazu auch einen Blogpost veröffentlicht (mehr Informationen hier), wir haben auch die ReadMe dementsprechend angepasst, um es noch klarer zu machen, und werden darüber hinaus auf verschiedenen Ebenen konstant – das ist der Klassiker in der Security – darauf hinweisen. 

Das Problem haben quasi alle Firmen in diesem Bereich. Eine Datenbank ist aber auch kein einfaches Werkzeug, selbst wenn man sie relativ einfach einsetzt und sehr einfach starten kann. Die Verantwortung der Daten liegt nichtsdestotrotz, sowohl privat, als auch im Unternehmen, bei demjenigen, der das Rechenzentrum beziehungsweise die Rechner zur Verfügung stellt und betreut.

Es ist eben jeder Nutzer für sich selbst verantwortlich.

Genau. Wenn Sie den einfachsten Weg gehen wollen und nichts installieren wollen, können Sie auch auf Amazon gehen und das sogenannte AWS-Image aktivieren. Wenn man dort beispielsweise CALs so konfiguriert, dass sie frei verfügbar sind, kriegt man die Meldung: „Achtung, frei von außen zugänglich.“ Man muss aber nicht über dieses User Interface gehen, sondern kann auch alles von der Kommandozeile aus machen. Dann kommt diese Nachricht eventuell nicht. 

Das heißt, es gibt viele verschiedene Kanäle, auf die wir als Hersteller nur bedingt Einfluss haben. Wir sind aber trotzdem dazu angehalten, die Nutzer zu informieren. In unserem Fall geschieht das über Webinare, über allgemeine User-Gruppen, in denen die Security-Fahne hochgehalten wird. Wir sind darüber hinaus auch bei der Bitcom sowie der Big-Data-Arbeitsgruppe aktiv.

Das selbe Problem kann aber auch bei Konkurrenz-Datenbanken auftreten?

Ja. Da kann genau das gleiche passieren. Die normalen Package Installer, zum Beispiel Ubuntu oder Red Hat, fragen nach Username und Passwort, was man aber auch verneinen kann. Komplexere Systeme wie eine Oracle-Datenbank lassen einen mehr oder weniger direkt drüber stolpern und auch bei MySQL sowie im NoSQL-Umfeld kann das passieren und ist bereits passiert.

Neben Namen, Anschrift und E-Mail-Adressen wurden auch Kreditkarteninformationen offen einsehbar in den Datenbanken gelistet. War diese Bankdaten bei allen Nutzern vorhanden?

 Man muss zunächst zwischen Kunde und Kunde des Kunden unterscheiden. Den genannten Vorfällen sind wir natürlich direkt nachgegangen, hatten auch Kontakt mit der entsprechenden Forschergruppe und auch unseren Kunden. Die Unternehmen, mit denen wir in Deutschland in Kontakt traten, hatten keine Probleme, schließlich gibt es ja auch EU-Forderungen für große Unternehmen, die eigene Security-Officer usw. erfordern. Innerhalb der uns bekannten Kunden haben wir aber keine Probleme festgestellt.

Andererseits können wir aber natürlich nicht für die Leute sprechen, die wir nicht kennen, aber trotzdem unser System nutzen. Dort können tatsächlich Daten frei einsehbar gewesen sein, wobei es ja auch sein könnte, dass die Kreditkarteninformationen, die frei zugänglich waren, nicht echt sind und – Stichwort: Honeypot – dazu da waren, Cyberkriminellen auf die Spur zu kommen.

Glücklicherweise haben die Studenten, die die frei zugänglichen Datenbanken entdeckten, den Fall gemeldet. Woher weiß man, dass zuvor nicht schon längst Andere die Daten gesehen, verändert und womöglich kopiert haben?

Leider ist das oftmals nicht nachvollziehbar. Manche Kunden, beispielsweise Otto.de, besitzen aber entsprechende Mechanismen, die genau verfolgen, welche Daten wohin wandern. Dort wäre ein solches Datenleck beinahe unmöglich, da sämtliche Zugriffe und Veränderungen von Datenbankkonfiguration über Ports und Auditing aufgezeichnet werden.

Wenn man ein System aber der Öffentlichkeit zur Verfügung stellt und dann beispielsweise kein Login aktiviert ist, können wir nicht nachvollziehen, wer darauf zugegriffen hat. Da müsste man schon sehr aufwendige forensische Methoden einsetzen oder eventuell über die Provider gehen. Wir als Hersteller haben da aber überhaupt keine Möglichkeit.

Herr Schwering, vielen Dank für das nette Gespräch.

Dass MongoDBs Technologie nicht Grund für die ungesicherten Instanzen war, stellten mittlerweile auch die Studenten, die das Datenleck entdeckten und meldeten, klar. Kunden von MongoDB können über diesen Link weitere Informationen zu den Sicherheitseinstellungen einsehen, um unter anderem ihre eigenen Settings anzupassen. Darüber hinaus steht man bei Fragen unter support@mongodb.com zur Verfügung.

Lies auch: Identitätssicherheit im Netz auf ewig eine Sisyphos-Arbeit?

Tags :Quellen:(Bild: Shutterstock)

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Advertising