Metabase Zero-Day mit CVSS 10 trifft Framework und Metabase Cloud

Stellen Sie sich eine Bank vor, deren Eingangstür aus gehärtetem Stahl besteht, der Tresor biometrische Schlösser hat und die Wachleute im Vier-Stunden-Rhythmus wechseln. Und nun stellen Sie sich die Seitentür vor, beschriftet mit „Passwort zurücksetzen" – aufgehalten von einem Ziegelstein. Genau das ist das Bild, das der diese Woche veröffentlichte Metabase-Zero-Day zeichnet, und der Ziegelstein lag lange genug da, damit jemand hindurchgehen konnte.

Metabase, das Open-Source-BI-Tool, das viele Engineering-Teams stillschweigend direkt mit ihren Produktionsrepliken verbinden, warnt vor einer Pre-Auth-Schwachstelle mit einem CVSS-Score von 10,0 – ohne zugewiesene CVE-Nummer. Das Unternehmen bestätigt, dass Metabase Cloud selbst betroffen war. Framework, der Hersteller modularer Laptops, zählt auf Kundenseite zu den bestätigten Opfern.

Was geschah

Wie The Hacker News berichtete, gab Metabase bekannt, dass sein Cloud-Angebot von jemandem angegriffen wurde, der einen unbekannten Zero-Day in Versionen 1.58 und höher ausnutzte. Die Schwachstelle ermöglicht es einem unauthentifizierten Remote-Angreifer, beliebiges SQL direkt in die Metabase-Anwendungsdatenbank einzuschleusen – also jene Datenbank, die Nutzer, Sitzungen, Berechtigungen und Verbindungsstrings für alle angebundenen Data Warehouses speichert.

Von dort aus verschafft sich der Angreifer Administratorzugang zur Instanz. Das bedeutet: App-Konfigurationen ändern, gespeicherte Zugangsdaten für verbundene Datenbanken stehlen, alles lesen, was diese Verbindungen einsehen können, und es exportieren. Es ist die vollständige Beute.

Metabase Cloud wurde bereits aktualisiert. Self-hosted-Nutzer müssen sofort handeln. Die bereinigten Versionen sind x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 und x.63.5. Alle älteren Versionen in diesen Zweigen sind exponiert. Der temporäre Workaround, falls ein Patchen heute Nacht nicht möglich ist, besteht darin, den Endpunkt /api/session/reset_password am Ingress zu blockieren. Diese einzelne Maßnahme verrät mehr über den Ursprung des Fehlers als das Advisory selbst.

Auf der Kundenseite informierte Framework seine Käufer darüber, dass Namen, Login-IPs, Adressen, Telefonnummern und E-Mail-Adressen während des Angriffs abgezogen wurden – das berichtete Engadget. Auf Bestell- oder Zahlungsdaten wurde nicht zugegriffen, was die einzige kleine Erleichterung in einem sonst schwierigen Wochenende für das Trust-and-Safety-Team des Unternehmens darstellt.

Die unbequeme historische Fußnote: Genau vor drei Jahren patchte Metabase CVE-2023-38646, eine Pre-Auth-RCE mit einem Score von 9,8. Dieselbe Fehlerklasse, dieselbe Angriffsoberfläche vor dem Login. Eine andere Tür, derselbe Ziegelstein.

Technische Anatomie

Die von Metabase veröffentlichten Kompromittierungsindikatoren erzählen jedem, der schon einmal nachts um 2 Uhr Web-App-Logs durchforstet hat, die ganze Geschichte. Das Muster ist ein POST /api/session/reset_password mit Rückgabe 400, gefolgt von einem GET /api/user/current mit Rückgabe 200. Auf Deutsch: Eine fehlerhafte Passwort-Reset-Anfrage wird gesendet, dann wird geprüft, ob man nun als jemand eingeloggt ist. Wenn der zweite Aufruf 200 zurückgibt, ohne dass ein regulärer Login dazwischen lag, stellt der Reset-Endpunkt nicht nur Passwörter zurück – er erstellt Sitzungen.

Der CVSS-Score von 10 und der Workaround-Hinweis legen eine SQL-Injection im Bereich der Reset-Passwort-Token-Verarbeitung nahe, die es einem Angreifer ermöglicht, in die Session-Tabelle zu schreiben, auf eine Admin-Zeile hochzustufen oder die Anwendung anderweitig davon zu überzeugen, dass der anonyme Aufrufer nun ein privilegierter Nutzer ist. CEO Sameer Al-Sakrans eigene Worte bestätigen das: „Wenn Sie dieses Muster in Ihren Anwendungslogs oder in den Ingress-Logs Ihres Metabase-Servers finden, wurde Ihre Instanz wahrscheinlich kompromittiert." Das ist nicht die Sprache eines subtilen Fehlers. Das ist die Sprache von: „Wir haben gesehen, wie sie die Anfrage geloggt haben, und dann haben wir gesehen, wie sie reingekommen sind."

Was diese Klasse von Schwachstellen in einem BI-Produkt so verheerend macht, ist der Explosionsradius. Eine Metabase-Instanz ist fast immer der Punkt in der eigenen Infrastruktur mit der größten Datenreichweite und der geringsten produktionstauglichen Absicherung. Sie hält langlebige Zugangsdaten zur primären Replik, zum Warehouse, manchmal zum Event Store. Sie läuft hinter einer schicken SSO-Login-Seite, die jeden glauben lässt, es handele sich um ein internes Tool. Sobald jedoch ein Pre-Auth-Pfad diesen Login umgeht, wird jede nachgelagerte Zugangsinformation zur Beute – direkt auf ATT&CK-Techniken für Credential Access und Collection abbildbar.

Wer jemals SELECT * FROM core_session in einem Incident-Call ausgeführt hat, kennt das flaue Gefühl im Magen. Die Session-Tabelle ist das Kronjuwel des Identitätsmodells einer Web-App, und die Tatsache, dass Metabases eigene Remediation-Anleitung dazu auffordert, nach dem Patchen jede Zeile darin zu löschen, sagt alles. Wenn Session-Fälschung nicht möglich wäre, müsste man nicht jede Sitzung weltweit ungültig machen.

Wer betroffen ist

Beginnen wir mit den offensichtlichen Opfern. Framework ist bereits an die Öffentlichkeit gegangen. Jedes Unternehmen, das Metabase selbst gehostet auf einer Version betreibt, die älter als die bereinigten Releases ist und bei dem der Reset-Passwort-Endpunkt vom öffentlichen Internet aus erreichbar ist, sollte eine Kompromittierung annehmen, bis die Logs das Gegenteil beweisen. Nicht „auf Indikatoren überwachen". Annehmen. Das IoC-Muster lässt sich leicht per Grep finden, und wenn man es findet, ist man bereits im Bereich der Offenlegungspflicht.

Die schwierigere Gruppe sind Fintech- und iGaming-Unternehmen. Metabase ist bei Daten-Teams in Payment-Startups, Sportwettenanbietern und Neobanken beliebt, weil es SQL für Produktmanager zugänglich macht, ohne ihnen direkte Warehouse-Zugangsdaten zu geben. Diese Bequemlichkeit kommt daher, dass das Tool diese Zugangsdaten in deren Namen hält. Jeder gespeicherte Verbindungsstring für ein Postgres-Replikat voller Kunden-PANs, KYC-Daten oder Wetthistorien ist nun ein Fragezeichen. Alles rotieren. Alle. Nicht nur die, die kürzlich genutzt wurden.

Ad-Tech-Plattformen befinden sich in einer ähnlichen Lage, mit dem zusätzlichen Problem, dass ihre Warehouses häufig Drittanbieter-Zielgruppendaten mit vertraglichen Benachrichtigungspflichten enthalten. Wenn die Metabase-Instanz einen Snowflake-Schlüssel gespeichert hatte und dieser Schlüssel uneingeschränkte Rollenbindungen besaß, sind in den nächsten 90 Tagen Anwälte genauso gefragt wie Ingenieure.

Krypto- und DeFi-Betreiber, die Metabase gegen ihren Off-Chain-Analytics-Stack betreiben, sollten sich aus einem anderen Grund gleichermaßen Sorgen machen. Gestohlene interne Metriken zu Orderflow, Liquiditätspositionen und Treasury-Salden landen typischerweise innerhalb einer Woche auf X – als Waffe für Wettbewerber oder Leerverkäufer. Das Offenlegungsrisiko ist nicht nur regulatorischer Natur. Es ist reputationsschädigend, und der Markt reagiert schneller als jeder Incident-Response-Plan.

Enterprise-Infrastruktur-Teams, die Metabase als internes Metriken-Dashboard betreiben, sind die stillsten Opfer. Der Explosionsradius hier ist die eigene Engineering-Kultur: Wie viele Warehouse-Zugangsdaten hat das Platform-Team in den letzten zwei Jahren in diese Instanz eingefügt, ohne sie zu rotieren? Das möchte an einem Freitag niemand ehrlich beantworten.

Playbook für Security-Teams

Die Reihenfolge der Maßnahmen ist entscheidend. Zuerst auf die bereinigten Branch-Releases patchen: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 oder x.63.5. Falls ein Patchen in der nächsten Stunde nicht möglich ist, /api/session/reset_password am Reverse Proxy blockieren. Nginx, Cloudflare, ALB-Regeln – was auch immer vorhanden ist. Diese eine Blockierung unterbricht die Exploit-Kette vor ungepatchten Instanzen.

Dann das IoC-Grep über Ingress-Logs und App-Logs laufen lassen. Das POST reset_password 400, gefolgt von GET user/current 200, ist ein markanter Fingerabdruck. Das Zeitfenster so weit wie möglich zurückausweiten, wie es die Log-Aufbewahrung erlaubt – denn die Veröffentlichung bezeichnet dies als Zero-Day, was bedeutet, dass die Ausnutzung vor dem Fix begann. Treffer in den kommenden Tagen mit dem CISA KEV Catalog abgleichen, da der Status aktiver Ausnutzung dort wahrscheinlich erfasst werden wird.

Bei Fund des Musters eine Kompromittierung annehmen. Dann Metabases eigene Post-Update-Checkliste abarbeiten: Alle Zeilen in core_session löschen, um aktive Sitzungen zu beenden, unbekannte API-Keys prüfen und bereinigen, alle Administratorkonten auf unbekannte Änderungen prüfen, alle gespeicherten Zugangsdaten für verbundene Datenbanken rotieren und Warehouse-Audit-Logs ziehen, um nachzuvollziehen, wer wann was abgefragt hat. Außerdem Metabases eigene Aktivitäts- und Abfragehistorie auf nicht autorisierte Exporte prüfen.

Was die meisten Teams überspringen werden – und nicht sollten: die Rotation der Warehouse-Zugangsdaten. Wenn ein in Metabase gespeichertes Redshift- oder BigQuery-Dienstkonto zur Datenexfiltration verwendet wurde, liegt der Fingerabdruck im Warehouse-Audit-Log, nicht im Metabase-Log. Dieses ziehen. Lesen. Und dann trotzdem rotieren, weil der Angreifer genug Zeit hatte, sich anderswo zu persistieren.

Wichtigste Erkenntnisse

• Metabase hat eine Pre-Auth-SQL-Injection mit CVSS 10,0 ohne zugewiesene CVE-Nummer offengelegt, die Versionen 1.58 und höher betrifft und in den Releases x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 und x.63.5 behoben wurde.
• Metabase Cloud wurde aktiv ausgenutzt, und Framework hat öffentlich bestätigt, dass Kundennamen, Login-IPs, Adressen, Telefonnummern und E-Mail-Adressen abgegriffen wurden.
• Der IoC ist ein POST an /api/session/reset_password mit Status 400, gefolgt von GET /api/user/current mit Status 200. Dieses Muster in den Logs ist ein starkes Signal für eine Kompromittierung.
• Die Remediation nach dem Patchen umfasst das Leeren der core_session-Tabelle, das Prüfen von API-Keys und Admin-Konten, das Rotieren aller Zugangsdaten für verbundene Datenbanken sowie das Prüfen der Warehouse-Audit-Logs.
• Metabase hat vor genau drei Jahren eine ähnliche Pre-Auth-Schwachstelle gepatcht – CVE-2023-38646 mit CVSS 9,8. Die Seitentür wird immer wieder aufgehalten. BI-Tools müssen als produktionskritische Angriffsfläche behandelt werden, nicht als internes Komfort-Werkzeug.

Der Ziegelstein in der Seitentür ist nun entfernt, und die stählerne Eingangstür war nie das Problem.