Anstieg von Datenlecks in Japan durch Angriffe auf APIs und Metabase

Von Juli bis September 2026 waren japanische Organisationen mit einem starken Anstieg von Lecks personenbezogener Daten über Websysteme konfrontiert: Nach Angaben von Macnica wurden in nur drei Quartalen bereits 119 Vorfälle registriert, während es im gesamten Jahr 2025 84 waren. Einzelne Fälle (Park24, Monogatari) führen zur Kompromittierung von Dutzenden Millionen Datensätzen; JPCERT/CC bringt die Welle mit massivem Missbrauch mobiler und interner APIs sowie mit der Ausnutzung der kritischen Schwachstelle CVE-2026-72898 in Metabase in Verbindung. Daher müssen Betreiber von Webdiensten, mobilen Anwendungen und BI-Systemen dringend alle aus dem Internet erreichbaren APIs inventarisieren und Metabase auf mindestens die sicheren Versionen aktualisieren.

Technische Details der Vorfälle

Ausmaß und Chronologie

Die Analyse des Macnica-Zentrums zeigt, dass bis zum 6. Oktober 2026 in Japan 119 öffentlich bekannt gewordene Vorfälle registriert wurden, bei denen Daten über Websysteme abgeflossen sind. Dabei gilt:

• 62 Vorfälle im Jahr 2024;
• 84 im Jahr 2025;
• bereits 119 im Jahr 2026, davon 81 seit Juli, was auf einen starken Anstieg hinweist.

Die Serie umfasst weder Ransomware noch andere „klassische“ Angriffe – es geht ausdrücklich um die Kompromittierung der Web- und API-Schichten. JPCERT/CC vermerkt in seiner Mitteilung vom 8. Oktober 2026 (offizieller JPCERT/CC-Alarm) eine Welle von Vorfällen, die sich „einer nach dem anderen“ im Zeitraum um den September ereignen.

Charakteristische größere Fälle:

• Park24 (Times Car): Unbefugter Zugriff auf Daten von etwa 6,6 Mio. Accounts des Carsharing-Dienstes, zusätzlich ein Leak von Ausweisfotos von rund 1,6 Mio. Nutzern.
• Monogatari (App Yakiniku King): Leak von 10.788.963 Datensätzen aus dem Mitgliedersystem.

Die Ursache dieser Vorfälle wird offiziell noch untersucht, vom Umfang und Profil her passen sie jedoch in die von Macnica beschriebene Serie.

Wesentliche Angriffsvektoren auf APIs

JPCERT/CC hebt mehrere sich wiederholende Muster des Missbrauchs von API-Schnittstellen mobiler und Webanwendungen hervor:

1. Analyse der mobilen Anwendung und Extraktion daraus:
   • einer Liste von Backend-API-Endpoints;
   • im Application-Binary hart kodierter API-Schlüssel und -Tokens.

   Der Angreifer formt daraufhin direkte HTTP-Anfragen an diese Endpoints, teilweise so, dass der Traffic normaler Nutzung ähnelt, was das Erkennen erschwert.

2. Zugriff auf „interne“ API-Funktionen, die nicht in der Benutzeroberfläche der Anwendung dargestellt sind:
   • Änderung der Benutzerberechtigungsstufen;
   • Erstellung unbefugter Benutzerkonten;
   • Testen des Serververhaltens bei Modifikation von Headern, Entfernen eines Tokens oder Senden eines beschädigten Authentifizierungs-Tokens;
   • Suche nach Kontodetails über eine „blinde“ NoSQL injection.
3. Wiederverwendung gestohlener API-Schlüssel, die in anderen Systemen kompromittiert wurden.

Typische Fehler auf Seiten der zu schützenden Systeme:

• Endpoints liefern mehr Daten zurück, als für die konkrete Operation erforderlich sind;
• die API führt Operationen mit übermäßigen Privilegien aus;
• Funktionalität für Mitglieder ist für anonyme Nutzer zugänglich;
• Fehler in der Autorisierungslogik und im Sitzungsmanagement.

Macnica betont zusätzlich, dass geheime API-Schlüssel und Datenbankpasswörter, die in die Client-Anwendung oder in Browsercode eingebettet sind, selbst aus minimiertem oder obfuskiertem Code leicht extrahiert werden können. Solche Praktiken sind daher unzulässig (Analyse von Macnica).

Ausnutzung von CVE-2026-72898 in Metabase

Ein weiterer Vektor sind Angriffe auf Metabase, ein populäres BI-Tool, über die kritische SQL injection CVE-2026-72898 mit einem CVSS-Score von 10,0 (NVD-Eintrag zu CVE-2026-72898). Die Schwachstelle ist:

• ohne Benutzerkonto ausnutzbar;
• ermöglicht eine SQL injection in die eigene Metabase-Datenbank;
• erlaubt dem Angreifer, Administratorrechte in Metabase zu erlangen;
• von dort kann der Angreifer gespeicherte Zugangsdaten angeschlossener Datenbanken auslesen und Zugriff auf deren Inhalte erhalten.

Metabase meldete am 6. August 2026 einen Vorfall in seinem Cloud-Service und veröffentlichte ein Sicherheitsupdate (Update vom 6. August). Später veröffentlichte das Unternehmen eine erweiterte Liste der minimal sicheren Versionen für verschiedene Produktzweige (Security-Release vom 12. August) und eine zusätzliche Warnung zu mehreren kritischen Problemen (Security Advisory auf GitHub).

Zentrales Anzeichen für die Ausnutzung von CVE-2026-72898 laut Metabase:

• im Serverlog wird ein POST /api/session/reset_password mit Antwortcode 400 protokolliert;
• darauf folgt ein GET /api/user/current mit Antwortcode 200.

Eine Übergangsmaßnahme für alle, die nicht sofort aktualisieren können, besteht darin, den Endpoint /api/session/reset_password auf Ebene des Webservers oder des Web Application Firewalls zu blockieren. Metabase beschreibt dies ausdrücklich als temporären Workaround, nicht als vollwertige Lösung.

IOC von JPCERT/CC und Macnica

JPCERT/CC hat eine Reihe von Indikatoren einer Kompromittierung veröffentlicht (sie sind als Orientierung zu verstehen, nicht als „Blacklist“, da die Adressen inzwischen auch für legitimen Traffic verwendet worden sein können).

Verdächtige API-Aktivität (um September 2026)

• IP: 3.112.252[.]14
• IP: 54.95.112[.]6
• IP: 69.10.51[.]162
• IP: 172.86.91[.]7
• IP: 210.149.87[.]120
• User-Agent: curl/7.88.1
• User-Agent: python-requests/2.34.2
• User-Agent: Mozilla/5.0 ... Chrome/126.0 Safari/537.36

Ausnutzung von Metabase (Anfang August – Anfang September 2026)

• IP: 213.163.202[.]171
• IP: 221.216.140[.]49
• IP: 221.216.140[.]129
• User-Agent: python-requests/2.33.1
• User-Agent: Metabase-GHSA-vwf4/2.0

Macnica hebt die IP-Adressen 210.149.87[.]120 und 69.10.51[.]162 gesondert als besonders prüfungswürdig hervor und betont, dass Zugriffe von diesen Adressen lediglich ein Anlass für eine vertiefte Log-Analyse sind, aber keinen direkten Beweis für einen Angriff darstellen.

Bedrohungskontext und geografische Verteilung

Obwohl JPCERT/CC und Macnica die Serie der Datenlecks keiner bestimmten Gruppe zuordnen, ist ein einheitlicher Stil erkennbar: Die Angreifer „sondieren“ massenhaft beliebige öffentliche Websysteme, in denen personenbezogene Daten vorliegen könnten, und nutzen jede gefundene Schwäche bei Authentifizierung, Autorisierung, Konfiguration oder bekannten Schwachstellen aus.

Die Liste der betroffenen Systeme geht weit über Online-Shops hinaus: Mitgliederservices, Geschäftssysteme, Kundensupport, Bibliothekskataloge, Buchungssysteme für touristische Züge. Macnica fand außerdem 99 ähnliche Vorfälle in 13 Ländern und Regionen außerhalb Japans (darunter 30 in Südkorea, 11 in Frankreich und 8 in Polen), was auf den globalen Charakter des Vorgehens der Angreifer hindeutet.

Der Einsatz von Automatisierung (bis hin zu KI-gestützter Schwachstellensuche) ist bislang nicht bestätigt: In den Logs gibt es keine direkten Hinweise auf eine solche Nutzung. Umfang und Intensität des Scans lassen jedoch einen vollständig manuellen Ansatz als unwahrscheinlich erscheinen – ein wichtiger Hinweis darauf, den Umfang der geprüften Szenarien bei Sicherheitsaudits neu zu bewerten.

Bewertung der Auswirkungen für Organisationen

Am stärksten gefährdet sind:

• Organisationen mit massenhaft genutzten Consumer-Mobile-Apps (Banking, Einzelhandel, Transport, Unterhaltung);
• Dienste mit dem Modell „Konto + Bonus/Abonnement“, in denen Kontaktdaten, Bestellhistorien und Nummern von Loyalty-Karten gespeichert werden;
• Unternehmen, die Metabase einsetzen, insbesondere wenn Dashboard und API direkt aus dem Internet erreichbar sind;
• Strukturen, in denen BI-Plattformen Zugriff auf produktive Datenbanken mit personenbezogenen Informationen haben.

Mögliche Folgen bei Untätigkeit:

• massive Lecks personenbezogener Daten (Namen, Kontaktdaten, Ausweisdaten, Verhaltensdaten);
• aufsichtsrechtliche Sanktionen durch Datenschutzbehörden (in Japan die Personal Information Protection Commission, die bereits einen eigenen Alarm und Leitlinien veröffentlicht hat: PPC-Alert, PPC-Leitfaden);
• Kompromittierung der Business-Analytics und produktiver Datenbanken über Metabase als zentrale Einstiegstelle;
• Imageschäden sowie steigende Kosten für die Benachrichtigung Betroffener und nachfolgende Klagen.

Praktische Empfehlungen zum Schutz

1. Sofortmaßnahmen für Metabase-Betreiber

1. Alle Metabase-Instanzen (on‑premise und in der Cloud) identifizieren, die aus dem Internet erreichbar sind.
2. Die aktuellen Versionen mit den von Metabase veröffentlichten minimal sicheren Versionen vergleichen (Liste sicherer Releases) und sofort mindestens auf einen empfohlenen Release aktualisieren.
3. Bis zum Update den Endpoint /api/session/reset_password von außen als temporäre Risikominderung blockieren.
4. Die Logs auf das Vorhandensein der folgenden Sequenz überprüfen:
   • POST /api/session/reset_password → HTTP 400;
   • GET /api/user/current → HTTP 200.

   Wird eine solche Kette festgestellt, ist der Server als kompromittiert zu betrachten.

5. Für Instanzen, bei denen der Endpoint aus dem Internet erreichbar war, nach dem Update den von Metabase empfohlenen vollständigen Wiederherstellungszyklus durchführen:
   • alle aktiven Benutzersitzungen ungültig machen;
   • verdächtige API-Schlüssel überprüfen und löschen;
   • Administrator-Accounts auditieren;
   • Passwörter und Schlüssel aller angeschlossenen Datenbanken ändern;
   • Logs der Datenspeicher auf ungewöhnliche Abfragen analysieren;
   • Anfragehistorie in Metabase auf unerwartete Abfragen untersuchen.

2. Härtung von APIs und mobilen Backends

Die Empfehlungen von JPCERT/CC und OWASP API Security (OWASP API Security Top 10) definieren ein grundlegendes Mindestmaß an Kontrollen:

• Begrenzung der Anzahl von Requests pro Zeiteinheit (Rate Limiting), insbesondere für:
  • Authentifizierung und Login;
  • Passwort-Reset;
  • Versand von SMS und E-Mail-Benachrichtigungen;
  • Suche und andere ressourcenintensive Funktionen.
• Strikte Autorisierung für jeden Endpoint, einschließlich „nicht öffentlicher“:
  • Prüfung der Rechte nicht nur für Benutzer-, sondern auch für Administrationsoperationen;
  • separate Prüfung zulässiger HTTP-Methoden.
• Prinzip der minimal erforderlichen Rechte:
  • Beschränkung der Datenbereiche für jeden Schlüssel und jedes Token;
  • Verzicht auf „universelle“ Schlüssel mit allen Rechten.
• Strenge Lebensdauerbegrenzung von API-Tokens und Möglichkeit zum schnellen Widerruf im Falle eines Leaks.
• Verbot der Speicherung von Secrets (API-Schlüssel, DB-Passwörter) in mobilen Anwendungen und im Frontend-Code.
• Einbeziehung von Administrationsfunktionen in den Umfang regelmäßiger Schwachstellentests.

3. Monitoring und retrospektive Log-Analyse

Für den kommenden Monat ist eine vertiefte Auswertung der Logdateien von Webservern, API-Gateways und Datenbanken über einen Zeitraum von mindestens 30 Tagen sinnvoll, mit Fokus auf:

• ungewöhnlich hohes Volumen an API-Anfragen von einer einzelnen IP-Adresse;
• Spitzen bei Antworten mit 403, 404, 503 und anderen Fehlercodes;
• Zugriffe auf nicht vorhandene Endpoints und Dateien;
• deutlichen Anstieg der Gesamtzahl von Requests mit Status 200 (Missbrauch „legitimer“ Aufrufe);
• Nutzung von Administrationsfunktionen von untypischen IP-Adressen;
• erhöhte Last auf Datenbank und Session-Pool, die mit Anomalien im Traffic zusammenfällt;
• Zunahme der Login-Versuche.

Die zentrale Schlussfolgerung für betroffene und potenziell verwundbare Organisationen lautet: Es sind eine dringende Überprüfung der eingesetzten Metabase-Versionen und eine Abschottung von Metabase gegen direkten Internetzugriff notwendig, begleitet von der Einführung strenger Zugriffskontrollen und Rate Limits für alle API-Endpoints sowie einer retrospektiven Log-Analyse von mindestens einem Monat anhand der genannten Merkmale, gefolgt von der Neuausstellung kompromittierter Schlüssel und Passwörter.