Das jüngste, von Bob Diachenko gefundene Datenleck entbehrt nicht einer gewissen Komik. Immerhin handelt es sich um eine Datenbank mit Daten-Lecks, die dann ihrerseits geleckt war.
Prima Datenleck-Übersicht von Keepnet Labs
Sehr sauber strukturiert soll die Elasticsearch-Datenbank aufgebaut gewesen sein, so Diachenko. Akribisch waren darin geleakte Daten aus bereits bekannten Datenbank-Leaks wie denen von Adobe, Tumblr, Linkedin, Twitter und anderen verzeichnet. Die katalogisierten Leaks sollen dabei bis zu sieben Jahre zurückreichen.
Unterlaufen war der Lapsus der britischen Sicherheitsfirma Keepnet Labs, die die Datenbank immerhin innerhalb von einer Stunde nach der Meldung durch Diachenko offline nahm.
Elasticsearch erweist sich erneut als unsicher
Elasticsearch-Datenbanken sind bekannt für ihre Leak-Anfälligkeit. Da sie keine eingebauten Sicherheitsfunktionen haben, können sie nur sicher hinter Firewalls und in passwortgeschützten Bereichen betrieben werden. Das hatte Keepnet Labs im vorliegenden Fall offenbar übersehen.
Panik unnötig: Neu waren die Daten allesamt nicht
Der Fairness halber muss erwähnt werden, dass sämtliche Leaks, die sich fein säuberlich aus der Datenbank lesen ließen, bereits zuvor öffentlich zugänglich gewesen waren. Der einzige Nutzen, den Cyberkriminelle nun aus der neuerlichen Veröffentlichung hätten, wäre der, dass sie eine aufgeräumte Gesamtkollektion zur Grundlage ihres Handelns machen könnten. Neuigkeitswert hatte allerdings keiner der Einträge.
Der Vorfall zeigt erneut, dass Elasticsearch-Server mit besonderer Vorsicht zu betreiben sind. Allerdings, wenn selbst eine Sicherheitsfirma das nicht schafft, wer dann?
Passend dazu: Wurde mein Account gehackt? Mit diesen Websites findest du es heraus
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
> Da sie keine eingebauten Sicherheitsfunktionen haben, können sie nur sicher hinter Firewalls und in passwortgeschützten Bereichen betrieben werden.
> Das hatte Keepnet Labs im vorliegenden Fall offenbar übersehen.
Sorry, aber das ist ausgemachter Blödsinn. Nur weil Keepnet Labs nicht fähig waren, die „nicht eingebauten Sicherheitsfunktionen“ zu nutzen, heißt das nicht, dass diese nicht existieren.
Davon mal abgesehen, dass man keinerlei interne Datenbanken ungeschützt am öffentlichen Internet betreiben sollte.
Viel Spaß beim Lesen:
* https://www.elastic.co/guide/en/elasticsearch/reference/7.x/secure-cluster.html
* https://www.elastic.co/blog/tips-to-secure-elasticsearch-clusters-for-free-with-encryption-users-and-more
Der Kommentar ist ein typisches Beispiel für das Behaupten einer nicht gezogenen Schlussfolgerung und als solches falsch. Ich habe nicht behauptet, dass Keepnet Labs über nicht vorhandene Sicherheitsfunktionen gestolpert ist, sondern dass sie offenbar den Sicherheitsaspekt außer Acht gelassen haben.