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

Datenbank-Schwachstellen

Bei einer Datenbank-CVE ist die wichtigere Frage meist, ob die Datenbank überhaupt aus dem Internet erreichbar sein sollte. Wie MySQL-, Postgres-, Mongo- und Redis-CVEs zu lesen sind.

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 überhaupt von dort erreichbar, wo der Scanner sie erreicht hat?”

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

  • MongoDB-Ransomware-Wellen 2017–2019. Zehntausende internet-sichtbarer MongoDB-Instanzen mit Default-ohne-Auth wurden gelöscht und durch Lösegeldforderungen 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 die Konfiguration ist der größere 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. Dasselbe Muster. Der Lua-Sandbox-Escape 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. Folgt dem Patch-Tuesday-Rhythmus von Microsoft und sollte aktuell gehalten werden. 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 sinnvoll, weil sich Angreifer nach einem Einbruch lateral weiterbewegen. MongoDB --auth, Redis requirepass, MySQL/PostgreSQL beim Setup die anonymen Konten entfernen.
  3. Minimal-Privilegien-Modell. Die Anwendung verbindet sich über einen Account, der nur Zugriff auf das eigene Schema hat, Backups laufen über einen zweiten Account und Replikation über einen 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