Schwachstelle Open-Source DB
Über die Sicherheitsanfälligkeit von Open-Source Datenbanken
Redis und MongoDB
Open-Source-Datenbanken haben möglicherweise ein wachsendes Sicherheitsproblem. Zum zweiten Mal in nur zwei Jahren wurden beliebte Open-Source-Datenbanken in großem Umfang mit Kryptowährungs-Malware infiziert. Ende 2016 war der Infektionsvektor MongoDB, und die Malware-Quelle Ransomware. In diesem Jahr steht Redis im Visier, eine weitere populäre Open-Source-Datenbank, die zunehmend mit Krypto-Mining-Malware infiziert wird.
Entwickler lieben Open-Source-Datenbanken aufgrund ihrer Flexibilität, aber die letzten zwei großen Vorfälle in so kurzer Zeit geben durchaus zu denken auf. Welche strukturellen Mängel machen diese Datenbanken so anfällig – und was können Sicherheitsfachkräfte tun, um die Schwachstellen einzudämmen?
Eine aktuelle Studie des Sicherheitsunternehmens Incapsula hat ergeben, dass 75% der Redis-Server mit Krypto-Mining Malware infiziert sind. Die Zeit zwischen der Einrichtung eines solchen Servers bis zu einer möglichen Infektion beträgt mittlerweile weniger als 24 Stunden. Dabei wurden nicht nur die Server selbst infiziert, sondern auch als Launchpads missbraucht, um andere Dienste anzugreifen.
Ein erster rätselhafter Faktor war die Tatsache, dass Redis-Server ursprünglich eigentlich nicht öffentlich erreichbar sein sollten. Mit anderen Worten, ein zufälliger Benutzer von außerhalb eines Unternehmensnetzwerks sollte nicht in der Lage sein, direkt über das öffentliche Internet zu einer Redis-Implementierung zu navigieren. Die Tatsache, dass trotzdem eine große Anzahl von Redis-Servern unabhängig von der Öffentlichkeit erreichbar sind, scheint auf mögliche Fehler der Admins zurückzuführen. Viele Redis-Distributionen von Drittanbietern werden standardmäßig offen ausgeliefert. Wie es scheint haben sich einige Admins nicht darum gekümmert die DBs in den privaten Modus umzustellen.
Diejenigen, die Redis gerade ausführen, sollten ihre Server auf Malware prüfen und gegebenenfalls neu aufsetzen. Obwohl Redis nicht mit robusten Sicherheitstools ausgeliefert wird (da es eigentlich nur für die Verwendung in einem LAN konzipiert ist), ist es möglich, eine Authentifizierungsebene zu aktivieren, Redis mit einem SSL-Proxy zu kombinieren, Standardbefehle zu ändern und nur mit privilegierten Benutzer auszuführen. Diese kombinierten Maßnahmen sollten Redis eigentlich sicherer machen – trotzdem wird damit das grundlegende Sicherheitsproblem nicht behoben.
Lehren aus MongoDB?
Ende 2016 und Anfang 2017 haben Ransomware-Gruppen massenweise öffentliche MongoDB-Implementierungen übernommen. Über 30.000 Datenbanken wurden durch Ransomware infiziert und gelöscht. Dabei wurden über 680 TB Daten gestohlen und veröffentlicht. Wie Redis hat MongoDB wenig integrierte Sicherheitsmechanismen. Sobald es gelingt auf die Datenbank zuzugreifen, kann sie auch geändert werden. Im Gegensatz zu Redis wurde MongoDB standardmäßig für den öffentlichen Zugang über das Internet konzipiert. Dadurch ist es in vielerlei Hinsicht noch unsicherer als sein Gegenstück.
Die MongoDB-Verstöße sollten eigentlich eine Lektion für Administratoren sein – eine einfache, schmerzhafte Lektion. Kurz gesagt: "Lassen Sie Ihre unternehmenskritischen Datenbanken nicht offen, wo sie von irgendjemandem geändert werden können." In MongoDB, Redis und sogar in manchen AWS-Implementierungen können Admins diesen kritischen Fehler jedoch nicht selber überprüfen oder korrigieren. Was kann also getan werden?
Ohne Ausnahmen alles sperren?
Ein durchschnittliches Unternehmen führt hunderte von Anwendungen aus, die jeweils eigene Berechtigungen für den Zugriff auf das Internet haben. Obwohl Redis und MongoDB aufgrund der Datenwerte die sie speichern, Ausreißer sind, stellt jede dieser Anwendungen eine Sicherheitsanfälligkeit dar, wenn sie auf die Öffentlichkeit ausgerichtet ist. Mit anderen Worten, dies ist ein weiteres Problem, bei dem Administratoren zu viele Anwendungen überwachen müssen und ein einziger Fehler eine mögliche Datenverletzung nach sich ziehen kann.
Wie kann man diesem Dilemma begegnen? – Alles dicht machen? Mit der Safe-T Safe-T Software-Defined Access Lösung können Administratoren jede einzelne Ihrer Anwendungen vom öffentlich zugänglichen Internet aus blockieren – ohne die Konnektivität zu deaktivieren. Mit dem Zero-Trust-Netzwerksegmentierungsmodell können die Firewalls zu 100% geschlossen werdne – mit all Ihren Anwendungen dahinter. Trotzdem können die Benutzer, Kunden und Anbieter weiterhin auf die Tools zugreifen, als wären diese auf "public" gesetzt.
Zur Trial Version
