Eine kritische Sicherheitslücke im beliebten In-Memory-Datenspeicher Redis erlaubt Angreifern unter bestimmten Bedingungen die Ausführung von Schadcode. Besonders betroffen: Systeme mit unzureichend konfigurierter oder veralteter Redis-Installation. Wir zeigen, was hinter der Schwachstelle steckt – und wie Sie Ihre Systeme jetzt absichern sollten.
Schwachstelle: CVE-2024-28890 bedroht Redis-Netzwerke weltweit
Im März 2024 wurde eine schwerwiegende Sicherheitslücke in Redis bekannt: Die als CVE-2024-28890 registrierte Schwachstelle ermöglicht Remote-Code-Ausführung (RCE) unter bestimmten Konfigurationen, insbesondere wenn Redis im sogenannten cluster mode oder mit aktivem replicaof-Befehl betrieben wird. Angreifer können über manipulierte Replikationsnachrichten eigene Befehle auf dem Host-System ausführen, wenn bestimmte Schutzmechanismen – wie Authentifizierung oder Netzwerksegregation – fehlen.
Die verwundbare Funktionalität betrifft Redis-Versionen bis einschließlich 7.2.4. Laut dem offiziellen Security Advisory im Redis-Github-Repository ist die Lücke durch das fehlerhafte Parsen von Replikationsdatenströmen entstanden: Der Master akzeptiert vom Replica-Client gesendete Daten – auch wenn dieser manipulierte Inhalte sendet. Diese werden ohne ausreichende Validierung verarbeitet.
Nutzer, die Redis in offenen Netzwerken ohne TLS-Absicherung betreiben oder administrative Kommandos nicht einschränken, gehen ein besonders hohes Risiko ein. Laut einer Analyse von Censys.io sind weltweit über 59.000 Redis-Instanzen ohne Authentifizierung über das öffentliche Internet erreichbar (Stand: August 2024).
Technische Analyse: So funktioniert der Angriff
Die Wurzel der Schwachstelle liegt im Replikationsmechanismus von Redis. Replikate verbinden sich mit einem primären Master-Server und senden nach erfolgreicher Authentifizierung Befehle und Statusinformationen. Wird jedoch diese Verbindung von einem Angreifer initiiert – beispielsweise durch eine böswillige Instanz mit replicaof – lassen sich manipulierte Payloads einschleusen.
Konkret: Redis erwartet ein Format namens RDB (Redis Database File Format). Wird das System dazu gebracht, ein manipuliertes RDB-File zu laden, das speziell präparierte Module (Redis unterstützt dynamische Erweiterungen seit Version 4.0) enthält, können native Systemfunktionen aufgerufen werden – mit anderen Worten: Angreifer erhalten Zugriff auf Shell-Kommandos oder können beliebige Binärdateien ausführen.
Ein Proof-of-Concept (PoC) für diesen Angriff ist öffentlich einsehbar, unter anderem im Repository des Sicherheitsforschers jas502n, was das Risiko für aktives Exploiting dramatisch erhöht. Bereits wenige Tage nach Veröffentlichung der Lücke wurde diese in mehreren Honeypot-Netzwerken aktiv gescannt und angegriffen. Laut Rapid7 wurden in der Woche nach dem Advisory mehr als 19.300 versuchte Exploit-Angriffe weltweit erfasst (Quelle: Rapid7 Threat Report, Mai 2024).
Wer ist betroffen?
Besonders gefährdet sind Unternehmen, deren Redis-Services ohne Rückgriff auf Access Controls, TLS-Verschlüsselung oder Authentifizierung im Netz operieren. Auch Cloud-Umgebungen – etwa selbstverwaltete Redis-Cluster auf AWS, Azure oder GCP – sind verwundbar, wenn Standardkonfigurationen beibehalten wurden.
Die Redis-Projektwartung betont im offiziellen Advisory, dass Systeme mit folgenden Eigenschaften gefährdet sind:
- Redis-Versionen vor 7.2.5
- Aktiviertes Replica-Setup oder Cluster-Mode
- Keine aktiven Authentifizierungsmechanismen (z. B. requirepass)
- Offen erreichbare Redis-Ports ohne Firewall-Einschränkungen
Deployment-as-Code-Umgebungen wie Terraform oder Docker-Compose sind zusätzlich gefährdet, da sie häufig auf vordefinierte Images zurückgreifen, die möglicherweise nicht standardmäßig abgesichert sind, etwa das Redis:latest-Docker-Image vor Mai 2024.
Patch verfügbar – aber nicht flächendeckend ausgerollt
Mit der Veröffentlichung von Redis 7.2.5 wurde CVE-2024-28890 adressiert. Die Entwickler haben die Replikationslogik so angepasst, dass Replikationsclients nun strenger validiert werden. Auch RDB-Dateien durchlaufen nun eine zusätzliche Prüfung, bevor sie importiert werden.
Trotzdem gibt es in der Praxis ein erhebliches Verbreitungsproblem veralteter Installationen. Laut einer Analyse von Shodan.io wurden im September 2024 noch über 36% aller öffentlich erreichbaren Redis-Instanzen mit Versionen älter als 7.2.5 betrieben.
Unternehmen, die Redis in produktiven Infrastrukturen einsetzen, sollten daher zeitnah prüfen, ob folgende Maßnahmen umgesetzt worden sind.
Vier Säulen zur Absicherung von Redis-Installationen
Ein mehrschichtiger Sicherheitsansatz ist zwingend erforderlich, um Redis-Systeme nachhaltig zu schützen. Neben dem Patch sollten zusätzliche Maßnahmen implementiert werden:
- Zugriffsregeln und Authentifizierung aktivieren: Verwenden Sie requirepass und gegebenenfalls dynamische ACLs (ab Redis 6.0), um den Zugriff zu begrenzen.
- Netzwerksegmentierung umsetzen: Redis sollte ausschließlich im internen Netzwerk betrieben werden. Nutzen Sie Sicherheitsgruppen, VPCs und Firewalls.
- Modul-Loading deaktivieren: Falls nicht benötigt, deaktivieren Sie das MODULE LOAD-Feature vollständig (nur ab Version 6.2+ möglich).
- Nur signierte Module erlauben: Redis 7.2+ unterstützt signierte Module; setzen Sie diese ein, um modulare Erweiterungen abzusichern.
Zusätzlich empfehlen die Redis-Entwickler die Verwendung von TLS für die Kommunikation zwischen Clients und Servern sowie Logging-Mechanismen zur Erkennung ungewöhnlicher Replikationsanfragen.
Best Practices: So schützen Sie sich langfristig
Neben kurzfristigen Patches ist eine strategische Governance entscheidend. Beziehen Sie Redis in bestehende SIEM-Lösungen ein, führen Sie regelmäßige Loganalysen durch und integrieren Sie Redis-Sicherheitsrichtlinien in Ihre CI/CD-Pipeline.
Folgende Maßnahmen haben sich laut OWASP- und CIS-Benchmarks in der Redis-Praxis bewährt:
- Regelmäßige Sicherheits-Scans: Automatisierte Schwachstellenscans mit Tools wie RedisAuditor oder Lynis erkennen Fehlkonfigurationen frühzeitig.
- Immutable Infrastruktur: Deployen Sie Redis über Read-Only-Container und verbieten Sie Shell-Zugriffe auf Runtime-Ebene.
- Monitoring & Alerting: Überwachen Sie Systemressourcen, Verbindungsversuche und fehlerhafte Authentifizierungen über Grafana, Prometheus oder ELK Stack.
Fazit: Sicherheitslücke als Weckruf
Die Redis-Sicherheitslücke CVE-2024-28890 zeigt, wie gefährlich systemnahe Schwachstellen in populären Open-Source-Komponenten sein können – insbesondere bei unzureichendem Patch-Management und schwacher Netzwerksegregation. Wer Redis verwendet, sollte jetzt handeln: Patches installieren, Konfiguration prüfen und Sicherheitsrichtlinien verschärfen.
Die Community ist gefragt: Wie sichern Sie Ihre Redis-Umgebungen? Nutzen Sie Containertechnologie, Härtungsskripte oder Monitoring-Tools? Diskutieren Sie mit Fachkollegen und helfen Sie mit, Best Practices weiterzugeben. Denn Sicherheit beginnt mit Wissen – und endet mit Kooperation.
