Compliance und Risiko
8.000 ungesicherte Redis-Instanzen als Einfallstor
Die Sicherheitsforscher von Trend Micro entdeckten 8.000 Redis-Instanzen, die in verschiedenen Teilen der Welt ungesichert betrieben werden, einige sogar in öffentlichen Clouds.
Save to Folio
Originalartikel von David Fiser, Sicherheitsforscher
Die Sicherheitsforscher von Trend Micro entdeckten 8.000 Redis-Instanzen (Open-Source In-Memory-Schlüsselwert-Datenstrukturspeicher), die in verschiedenen Teilen der Welt ungesichert betrieben werden, sogar welche in öffentlichen Clouds. Die Instanzen liefen ohne Transport Layer Security (TLS)-Verschlüsselung und ohne Passwort-Schutz. Dabei ist Redis, den Entwicklern zufolge, ursprünglich allein auf den Einsatz in vertrauenswürdigen Umgebungen ausgerichtet worden. Wird die In-Memory-DB ungeschützt und mit dem Internet verbunden oder in Internet of Things (IoT)-Geräte integriert betrieben, so können Cyberkriminelle Redis-Server dazu missbrauchen, um Angriffe zu fahren, wie etwa über SQL Injection, Cross-Site Scripting, dem Hochladen bösartiger Dateien oder andere Mittel. Bedrohungsakteure können auch Daten in exponierten Instanzen ansehen, darauf zugreifen oder sie modifizieren. In der Vergangenheit hatte es schon Angriffe dieser Art auf Linux-Server gegeben. Wie groß ist die Bedrohung, und was ist zu tun?
Redis steht für Remote Dictionary Server und ist ein weit verbreiteter Open Source In-Memory Schlüsselwert-Datenstrukturspeicher, der als Datenbank, Cache und Message Broker eingesetzt wird. Das offizielle Docker-Hub-Image der Software zählt derzeit über eine Milliarde Downloads und wird von Unternehmen wie GitHub, Craigslist und Twitter eingesetzt. Auch wird Redis in Cloud-Umgebungen betrieben.
In zunehmendem Maße verwenden auch DevOps-Teams Redis für Microservices und Container. 2018 liefen 900 Mio. Container mit Redis - im Vergleich dazu: 650 Mio. laufen mit MongoDB. Über DevOps können Entwickler und IT-Teams richtlinienkonforme und sichere Anwendungen erstellen, und dafür muss jede Schicht des Produktions- und Bereitstellungsprozesses - einschließlich Datenstrukturen wie Redis - abgesichert werden.
Bild 1. Shodan Scan-Ergebnisse für nicht gesicherte Cloud-Installationen von Redis (ohne TLS-Verschlüsselung, Passwortschutz oder beides) Achtung: Es sind nur diejenigen Cloud Provider berücksichtigt worden, die 50 oder mehr ungesicherte Instanzen betreiben
Nach Rücksprache erklärte Redis, es gibt seit 2017 seit Redis 4.0 eine Protected Mode-Konfiguration. Diese spezielle Konfiguration wurde auch auf die frühere Version 3.2.0 rückportiert. Im geschützten Modus reagiert Redis nur auf Anfragen, die von der Loopback-Schnittstelle kommen, andere Clients erhalten eine Fehlermeldung. Weitere Einzelheiten liefert der Originalbeitrag und die offizielle Dokumentation von Redis.
Empfehlungen
Zur Sicherung von Redis-Instanzen empfiehlt Trend Micro folgende Schritte:
Die Sicherheitsforscher von Trend Micro entdeckten 8.000 Redis-Instanzen (Open-Source In-Memory-Schlüsselwert-Datenstrukturspeicher), die in verschiedenen Teilen der Welt ungesichert betrieben werden, sogar welche in öffentlichen Clouds. Die Instanzen liefen ohne Transport Layer Security (TLS)-Verschlüsselung und ohne Passwort-Schutz. Dabei ist Redis, den Entwicklern zufolge, ursprünglich allein auf den Einsatz in vertrauenswürdigen Umgebungen ausgerichtet worden. Wird die In-Memory-DB ungeschützt und mit dem Internet verbunden oder in Internet of Things (IoT)-Geräte integriert betrieben, so können Cyberkriminelle Redis-Server dazu missbrauchen, um Angriffe zu fahren, wie etwa über SQL Injection, Cross-Site Scripting, dem Hochladen bösartiger Dateien oder andere Mittel. Bedrohungsakteure können auch Daten in exponierten Instanzen ansehen, darauf zugreifen oder sie modifizieren. In der Vergangenheit hatte es schon Angriffe dieser Art auf Linux-Server gegeben. Wie groß ist die Bedrohung, und was ist zu tun?
Redis steht für Remote Dictionary Server und ist ein weit verbreiteter Open Source In-Memory Schlüsselwert-Datenstrukturspeicher, der als Datenbank, Cache und Message Broker eingesetzt wird. Das offizielle Docker-Hub-Image der Software zählt derzeit über eine Milliarde Downloads und wird von Unternehmen wie GitHub, Craigslist und Twitter eingesetzt. Auch wird Redis in Cloud-Umgebungen betrieben.
In zunehmendem Maße verwenden auch DevOps-Teams Redis für Microservices und Container. 2018 liefen 900 Mio. Container mit Redis - im Vergleich dazu: 650 Mio. laufen mit MongoDB. Über DevOps können Entwickler und IT-Teams richtlinienkonforme und sichere Anwendungen erstellen, und dafür muss jede Schicht des Produktions- und Bereitstellungsprozesses - einschließlich Datenstrukturen wie Redis - abgesichert werden.
Bild 1. Shodan Scan-Ergebnisse für nicht gesicherte Cloud-Installationen von Redis (ohne TLS-Verschlüsselung, Passwortschutz oder beides) Achtung: Es sind nur diejenigen Cloud Provider berücksichtigt worden, die 50 oder mehr ungesicherte Instanzen betreiben
Nach Rücksprache erklärte Redis, es gibt seit 2017 seit Redis 4.0 eine Protected Mode-Konfiguration. Diese spezielle Konfiguration wurde auch auf die frühere Version 3.2.0 rückportiert. Im geschützten Modus reagiert Redis nur auf Anfragen, die von der Loopback-Schnittstelle kommen, andere Clients erhalten eine Fehlermeldung. Weitere Einzelheiten liefert der Originalbeitrag und die offizielle Dokumentation von Redis.
Empfehlungen
Zur Sicherung von Redis-Instanzen empfiehlt Trend Micro folgende Schritte:
- Festlegen, wo Redis betrieben werden soll (Cloud, in einem Kubernetes Cluster etc.) und wer darauf in welcher Rolle Zugriff haben soll.
- Sicherstellen, dass die Umgebung entsprechende Schutzmaßnahmen beinhaltet, wobei Interferenzen anderer Installationen mit Redis zu vermeiden sind, etwa durch Dumping der Prozess-Memory.
- Einsatz von TLS zusammen mit Passwortauthentifizierung.
- Überwachen der Ausführung von Befehlen. Befehle wie DEBUG SEGFAULT und MONITOR dürfen nicht in einer Produktionsumgebung ausgeführt werden.
- Auf die richtige Netzwerksegmentierung achten, wenn Container verwendet werden. Redis-Instanzen sollten nicht anderen Containern zugänglich sein, wenn diese keinen Zugriff auf sie benötigen.
- Redis nicht in der Frontend-Entwicklung einsetzen, so dass die DB böswilligen Akteuren ausgesetzt ist. Redis sollte innerhalb eines Browsers keine Verbindung mittels JavaScript haben. Stattdessen empfiehlt sich die Verwendung von Redis im Backend.
Tags