Zeroday in analysetool Metabase legt klantgegevens bij Framework bloot

Een zeroday in analysetool Metabase gaf aanvallers toegang tot de klantendatabase van laptopmaker Framework, dat daarop al zijn klanten waarschuwde voor een lek met namen, adressen en telefoonnummers.

Daarmee is dit geen laptopverhaal maar een leveranciersverhaal. Metabase is een business-intelligencetool: hij bezit zelf nauwelijks data, maar bewaart wel de inloggegevens van elke database die eraan hangt. Wie de tool overneemt, leest mee in alles waar hij op is aangesloten. En draai je Metabase op je eigen server, dan zit precies dezelfde fout in elke versie vanaf 1.58.

Wat er gebeurde

Metabase ontdekte op maandag 3 augustus dat zijn cloudomgeving was aangevallen via een tot dan toe onbekende kwetsbaarheid in versies 1.58 en hoger. Het bedrijf blokkeerde de gebruikte endpoints en bracht een patch uit. Op donderdag 6 augustus, om 9.00 uur Pacific Time, kreeg Framework bericht. Framework mailde zijn klanten diezelfde dag.

Om welke gegevens het gaat, is vrij precies bekend: volledige naam, e-mailadres, login-IP-adressen, verzend- en factuurgegevens, land, adres, woonplaats, postcode, telefoonnummer en bedrijfsnaam. Bestelgeschiedenis, betaalinformatie en identiteitsbewijzen zaten er niet bij. Bij zakelijke afnemers kunnen daarnaast btw-nummers, Amerikaanse EIN-nummers en facturatie-e-mailadressen zijn ingezien. Hoeveel klanten het precies betreft, maakte Framework niet bekend. Beide bedrijven zeggen dat de aanvaller de gegevens heeft ingezien; of ze ook zijn gekopieerd of gedownload, is niet vastgesteld.

Het lek: SQL-injectie zonder in te loggen

De kwetsbaarheid zit in het endpoint /api/session/reset_password. Een aanvaller kan daar zonder inloggegevens willekeurige SQL injecteren in de applicatiedatabase van Metabase, wat beheerdersrechten op de hele installatie oplevert. De fout scoort 10.0 op de CVSS-schaal, het maximum.

Vanaf die beheerdersrechten kan een aanvaller de configuratie aanpassen, de opgeslagen inloggegevens van gekoppelde databases stelen, alle data lezen die via die koppelingen bereikbaar is en die data exporteren. Dat is de kern: het lek zit in het dashboard, de buit ligt in de systemen erachter.

Kwetsbaar zijn de versies 58.0 tot en met 58.23, 59.0 tot en met 59.20, 60.0 tot en met 60.16, 61.0 tot en met 61.10, 62.0 tot en met 62.8 en 63.0 tot en met 63.3. De veilige uitgaven zijn 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 en 0.63.5. Draai je een versie onder 58, dan ben je niet kwetsbaar. Klanten van Metabase Cloud zijn al bijgewerkt.

Wat een eigen installatie nu moet nalopen

Metabase geeft een herstellijst voor iedereen bij wie het reset-password-endpoint vanaf internet bereikbaar is. Werk eerst bij naar de veilige uitgave, en loop daarna dit af:

• Sessies intrekken. Verwijder alle rijen in de tabel core_session van de applicatiedatabase.
• API-sleutels opschonen. Controleer de lijst en verwijder elke sleutel die je niet herkent.
• Beheerdersaccounts controleren op wijzigingen die niemand heeft aangevraagd.
• Wachtwoorden roteren van elke database die aan Metabase gekoppeld is.
• Logs teruglezen van je datawarehouse en van de zoek- en querygeschiedenis in Metabase.

Er is ook een concreet spoor om op te zoeken. Metabase omschrijft het aanvalspatroon als een aanroep van POST /api/session/reset_password met statuscode 400, direct gevolgd door GET /api/user/current met statuscode 200. Staat die combinatie in je applicatie- of ingresslogs, dan is je installatie waarschijnlijk gecompromitteerd. Lukt bijwerken niet meteen, dan is het endpoint tijdelijk blokkeren de aangeraden noodmaatregel.

Vind je dat spoor terug en staan er persoonsgegevens in de gekoppelde databases, dan wordt het ook een AVG-zaak. De meldtermijn bij de Autoriteit Persoonsgegevens loopt vanaf jouw eigen redelijke zekerheid, niet vanaf het definitieve rapport van je leverancier.

Waarom aanvallers hier terechtkomen

Metabase claimt zelf dat ruim 100.000 organisaties de tool gebruiken. Dat is precies wat gedeelde software aantrekkelijk maakt als doelwit: één fout levert toegang tot duizenden losse klantomgevingen, elk met hun eigen databasekoppelingen. Bij afpersgroep Cl0p draaien de campagnes al jaren op één applicatie tegelijk, van MOVEit Transfer tot Oracle E-Business Suite, zonder dat er ooit een bedrijf werd uitgekozen. Bij LastPass liep het via een vergeten inloggegeven uit 2022 bij dienstverlener Klue.

Het scherpste antwoord komt van Framework zelf. Het bedrijf roteerde alle databasewachtwoorden richting Metabase en stelde vast dat er buiten Metabase niets was aangeraakt. In de klantmelding schrijft het daarnaast de toegang van business-intelligenceplatforms terug te schroeven tot alleen de kolommen die voor de analyse nodig zijn. Dat verschuift de vraag die na zo'n lek telt. Niet welke analysetool je vertrouwt, maar hoeveel kolommen die tool ooit nodig had.