blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info service-database-cve

Schwachstellen in Datenbanken (MySQL, PostgreSQL, MongoDB, Redis)

Eine Datenbank-CVE wiegt nicht wegen des Dienstes selbst, sondern wegen dessen, was darin liegt. Die Frage "vom Internet erreichbar?" ist wichtiger als die CVE-Liste.

Die Leitfrage

Meldet der Scanner eine CVE in einem Datenbankserver, ist die relevante Frage selten “wie ernst ist der Bug?”, sondern “warum ist diese Datenbank von dort erreichbar, von wo der Scanner sie erreicht hat?”

Produktiv-Datenbanken haben im offenen Internet nichts zu suchen. Punkt. Die Historie ist eindeutig:

  • MongoDB-Ransomware-Wellen 2017–2019. Zehntausende internet-sichtbarer MongoDB-Instanzen mit Default-ohne-Auth wurden gedroppt und durch Lösegeld-Notes ersetzt. Keine CVE nötig.
  • Elasticsearch-Open-Cluster-Leaks. Dasselbe Muster mit Elasticsearch / Kibana. Milliarden-Datensatz-Breaches bei Anbietern, die Port 9200 offen ließen.
  • Redis für Cryptojacking. Offenes Redis dient seit fast einem Jahrzehnt dazu, Miner per Config-and-Save-Trick auf Server zu schieben.
  • MySQL auf Port 3306 mit schwachen Passwörtern. Credential-Stuffing gegen exponierte MySQL-Accounts läuft bis heute.

Wenn der Scanner Ihre Datenbank von außen sieht, ist das CVE-Patching der zweite Job. Der erste: die Datenbank aus dem öffentlichen Internet nehmen, auf ein privates Interface binden, hinter VPN stellen, IP-Firewall enger ziehen.

Hinweise je Datenbank

  • PostgreSQL. Kurze CVE-Liste, ausgereifte Codebasis, Sicherheits-Releases zügig und gut dokumentiert. Die meisten PostgreSQL-CVEs sind authentifizierte Bugs (Privilege-Escalation zwischen Rollen), nur mit gültigem Login erreichbar. Pre-Auth-Bugs sind selten. Version gegen postgresql.org/support/security/ prüfen.
  • MySQL / MariaDB. Lange CVE-Historie. Viele betreffen bestimmte Storage-Engines oder Features, die Sie vielleicht nicht nutzen; das Advisory genau lesen, ob Ihre Konfiguration tatsächlich verwundbar ist. Oracles vierteljährliches Critical Patch Update ist die maßgebliche Quelle für MySQL.
  • MongoDB. Kürzere CVE-Liste, aber: Konfiguration schlägt CVEs als Risikofaktor. Auf localhost oder ein privates Netz binden, Authentifizierung setzen, rollenbasierten Zugriff aktivieren. Default-Konfigurationen vor MongoDB 3.6 hatten keine Auth; moderne Versionen verlangen sie.
  • Redis. Dito. Die Lua-Sandbox-Flucht 2022 (CVE-2022-0543) war die seltene In-Protokoll-RCE; die meisten Redis-Vorfälle sind konfigurationsbasiert: protected-mode no, kein requirepass, vom Internet erreichbar.
  • Microsoft SQL Server. Patch-Tuesday-Rhythmus. Aktuell halten. Vorsicht bei in Legacy-Installationen aktiviertem xp_cmdshell.

Beim Patchen prüfen, was wirklich läuft

Der blueredix-Scanner liest die Version aus dem Protokoll-Handshake. Das ist die Server-Version, nicht zwingend die gepatchte Version einer Distro-Installation. Derselbe Hinweis wie bei OpenSSH und Webservern gilt: wenn Ihr PostgreSQL oder MySQL aus dem Paketmanager Ihrer Distribution kommt, schauen Sie in den Distro-Sicherheits-Tracker statt in die Upstream-CVE-Liste.

Bei MongoDB, Redis und Elasticsearch aus Upstream-Paketen oder Docker-Images ist die Version die Version: gegen den Upstream-Tracker prüfen.

Härtung unabhängig von CVEs

Grobe Priorität:

  1. Auf localhost oder ein privates Interface binden. bind_ip in MongoDB, bind in Redis, listen_addresses in PostgreSQL, bind-address in MySQL. Die wirksamste einzelne Maßnahme.
  2. Authentifizierung aktivieren, starke Passwörter setzen. Auch in privaten Netzen, laterale Bewegung ist real. MongoDB --auth, Redis requirepass, MySQL/PostgreSQL beim Setup die Anonyme wegwerfen.
  3. Minimal-Privilegien-Modell. Die Anwendung verbindet mit einem Account, der nur Zugriff auf das eigene Schema hat. Backups laufen aus einem anderen Account. Replikation aus einem dritten.
  4. Verschlüsselte Verbindungen. TLS zwischen Anwendung und Datenbank ist kein Aufwand mehr; PostgreSQL und MySQL können das nativ. MongoDB: --tlsMode requireTLS.
  5. Keine Backup-Dateien im Web-Root. Erstaunlich viele Datenlecks kamen aus database.sql.gz unter https://example.com/backup/database.sql.gz.

Wie blueredix Datenbank-Befunde meldet

Datenbank-Dienste werden auf Standardports erkannt (3306 MySQL, 5432 PostgreSQL, 27017 MongoDB, 6379 Redis, 1433 MSSQL), plus Versions-Fingerprint aus dem Protokoll-Handshake. Befunde zeigen:

  • Allein die Tatsache offener Ports ist für jede Produktiv-Datenbank, die von außen erreichbar ist, schon ein prominenter Befund, auch ohne CVE-Match.
  • CVEs gegen die laufende Version, mit Anwendbarkeits-Filter gegen die Wildcard-CPE-Falschpositiven, die ältere Datenbanken erzeugen.

Die Netzwerk-Exposition zu schließen, ist fast immer dringender als die CVE-Liste abzuarbeiten.

Mehr dazu