Metabase: el panell de dades que també era el clauer

El 3 d'agost algú va entrar a instàncies de Metabase allotjades pel mateix fabricant i es va endur dades dels seus clients. No hi va haver phishing, ni contrasenya filtrada, ni administrador descurat. Hi va haver una petició POST a /api/session/reset_password —l'endpoint del «he oblidat la contrasenya», l'únic que per definició ha de respondre sense sessió— que acceptava SQL. L'avís va sortir el 6 d'agost amb un CVSS de 10.0, el màxim de l'escala. Framework i Tally ja han avisat els seus usuaris. I el detall que converteix això en una cosa més gran que un pedaç urgent: el que un atacant s'endú d'un Metabase compromès no són els gràfics.

Què hi ha dins d'un panell de BI

Metabase és un visor. No és on viuen les teves dades: és el que les consulta. Per poder consultar-les desa, dins de la seva pròpia base de dades d'aplicació, les dades de connexió de cada base de dades que li hagis endollat: host, port, usuari i contrasenya. I la injecció d'aquest avís va exactament contra aquesta base de dades d'aplicació. No contra el magatzem de dades: contra la llibreta on hi ha apuntades les claus del magatzem.

L'avís del fabricant ho enumera sense adorns: un atacant en una instància compromesa pot canviar la configuració de l'aplicació, robar les credencials desades de les bases de dades connectades, llegir qualsevol dada accessible a través d'aquestes connexions i exportar-la. Llegeix-ho un altre cop amb la teva instal·lació al cap i fes el compte de quantes bases de dades té connectades el teu Metabase. Aquest número no és «quants orígens tinc». És quants sistemes es comprometen alhora.

Hi ha una capa més, i és la que molta gent descobreix aquesta setmana: aquestes credencials no estan xifrades per defecte. La documentació de Metabase presenta el xifratge dels detalls de connexió com una cosa que actives tu, creant una clau i posant-la a la variable d'entorn MB_ENCRYPTION_SECRET_KEY. Si ningú la va posar el dia del desplegament —i en un desplegament fet amb pressa ningú no la posa—, hi són, tal qual.

Ara el matís, que ens importa més que el titular: posar-la no t'hauria salvat, però t'hauria salvat la meitat. La injecció va contra la base de dades d'aplicació, no contra l'entorn del procés: si els detalls estan xifrats, el que surt d'aquella taula és un bloc AES inútil sense la clau, i això sí que li treu a l'atacant la contrasenya en clar que s'endú posada per a després. El que no evita és que, ja a dins com a administrador, demani al mateix Metabase que executi la consulta: el panell desxifra, connecta i li ensenya les dades igualment. Xifrar no tanca la finestra d'aquest incident, però redueix molt el que l'atacant conserva quan la finestra es tanca, que és justament la part cara, com es veu més avall. Que la posi qui no la tingui.

El compte de servei que ningú no ha tornat a mirar

La connexió es crea el primer dia, quan la prioritat és que el gràfic surti. Es fa servir l'usuari que hi havia a mà, o se'n crea un de nou amb permisos amples «perquè es vegin totes les taules i no haver-hi de tornar». Ningú no hi torna, efectivament. Dos anys després aquest usuari continua tenint lectura sobre tot l'esquema, i ara la seva contrasenya ha estat en un lloc on s'hi arribava sense autenticar-se.

I hi ha un multiplicador poc comentat: un administrador de Metabase pot escriure SQL natiu contra les connexions. És a dir, l'atacant que es promociona a administrador no necessita conèixer el teu model de dades, ni endevinar noms de taula, ni portar-se eines. Ho pregunta al panell, que per això hi és, i el panell li ho ensenya ordenat i amb un botó d'exportar. Si la teva connexió fa servir un usuari de només lectura acotat a un esquema concret, el dany s'acota amb ella. Això no és hardening avançat: és com s'hauria d'haver creat la connexió el primer dia.

Un forat que el teu inventari de pedaços no veu

La fallada es va publicar com a avís de seguretat de GitHub, GHSA-vwf4-m7j8-wcjf, i en el moment d'escriure això no té CVE assignat. Val la pena aturar-se aquí, perquè té conseqüències operatives concretes: si el teu procés de gestió de vulnerabilitats consisteix a rebre un butlletí de CVE i creuar-lo amb una llista de productes, aquest forat de puntuació 10.0 i explotat a la vida real no hi apareix. No hi ha res per creuar. Per al teu procés, no existeix.

No és una raresa d'aquest cas. Els projectes allotjats a GitHub hi publiquen els seus avisos, i el CVE és un tràmit a part que de vegades arriba tard i de vegades no arriba: aquest, amb un 10.0 i explotació confirmada, encara no en tenia quan vam escriure això. La diferència pràctica és què vigiles: qui vigila versions —un inventari amb el que hi ha instal·lat i una comparació periòdica contra les notes de publicació del fabricant— se n'assabenta el mateix dia. Qui vigila CVE, se n'assabenta quan algú l'hi explica.

Mira bé el número abans de dir que no t'afecta

Els rangs afectats de l'avís són 58.0 a 58.22, 59.0 a 59.19, 60.0 a 60.15, 61.0 a 61.9, 62.0 a 62.7 i 63.0 a 63.2. Les versions corregides són 58.24, 59.21, 60.17, 61.11, 62.9 i 63.5. I un advertiment sobre aquestes dues llistes: no es toquen. L'avís marca com a afectat tot allò anterior a la 63.3, però corregeix a la 63.5; marca allò anterior a la 62.8, i corregeix a la 62.9. Si el teu número cau en aquest buit —una 62.8, una 63.3, una 63.4— l'avís literalment no diu res de tu. Nosaltres aniríem a la versió corregida i no a la vora del rang: és l'única de les dues llistes de la qual el fabricant afirma que porta l'arreglament a dins.

Aquí hi ha un parany de lectura que farà que algú arxivi l'avís per error. Bona part de la cobertura diu «afecta des de la 1.58», i tu mires el teu contenidor, llegeixes v0.62.4 i respires. No respiris. Metabase anteposa un 0 o un 1 segons l'edició: el 0 és la versió lliure i l'1 la comercial dels plans Pro i Enterprise, amb el mateix número de versió al darrere. Un v0.62.4 i un v1.62.4 són el mateix número de versió en dues edicions: la comercial porta funcions de més, però per mirar el rang d'aquest avís compten igual. Així que «des de la 1.58» i «les branques 0.58 a 0.63» surten exactament els mateixos números.

Les versions anteriors a la 58 no són al rang. Amb un advertiment que diem sense somriure: si el teu consol avui és que fa dos anys que no actualitzes, el teu problema no és més petit, és un altre. I si no pots actualitzar en les pròximes hores, el mateix avís dona la mesura provisional que serveix: bloquejar l'endpoint /api/session/reset_password al proxy o al balancejador que tinguis al davant. Es trenca el «he oblidat la contrasenya» i no es trenca res més.

I hi ha una comprovació que pots fer ara mateix, sense eines: el patró que es va publicar com a indici és un POST a /api/session/reset_password que retorna 400, seguit, des de la mateixa IP i en qüestió de segons, d'un GET a /api/user/current que retorna 200. És a dir: la petició «falla», i tot seguit aquesta mateixa IP està autenticada. Sense correlar per origen i per temps el patró no val res, perquè un 200 a /api/user/current el genera qualsevol navegador amb la sessió oberta. Si guardes els logs del proxy, és una cerca de dos minuts. Si no els guardes, ja has trobat la primera tasca de la llista.

Actualitzar és la meitat fàcil

La llista de després de l'avís —que el fabricant condiciona al fet que el teu endpoint fos accessible des d'internet— té sis punts: esborrar totes les files de la taula core_session a la base de dades d'aplicació, revisar les claus d'API i eliminar les que no reconeguis, repassar els canvis en comptes d'administrador, rotar les credencials de les bases de dades connectades, examinar els registres d'accés del magatzem de dades i revisar l'històric d'activitat i consultes del mateix Metabase. Cinc d'aquests sis es fan en una tarda.

El quart no, i és el que decideix si l'incident es tanca de debò. Rotar la contrasenya de la connexió vol dir tocar la base de dades de producció, coordinar una finestra, avisar qui depèn d'aquests informes i arriscar-se a trencar el quadre de comandament que direcció mira els dilluns. No s'assembla gens a actualitzar un contenidor: són hores de coordinació en comptes de minuts de desplegament, així que s'anota «per a la setmana que ve». I la setmana que ve el Metabase està net, apedaçat, amb els administradors revisats… i l'atacant conserva una credencial vàlida contra la teva base de dades de producció, que és el que es va endur. És el mateix patró que explicàvem amb el servidor de CI/CD que guarda les claus de producció: apedaçar el sistema no rota el que el sistema desava.

De qui és el panell?

Un Metabase gairebé mai no l'instal·la el departament d'IT. El munta l'equip de dades, el de producte o el de màrqueting, perquè necessitaven un gràfic el dijous i era un docker run. És una bona eina i aquesta facilitat és una virtut, no un retret. El problema és el que arrossega: neix fora de l'inventari, fora de la finestra d'actualització, fora de la llista del que s'apedaça, i amb un port publicat «temporalment» perquè el vegi el comercial que és de viatge.

Hi ha una mesura d'això, i no és d'aquesta setmana. Al març del 2026, un estudi d'OX Security comptava més de 17.000 instàncies de Metabase publicades a internet segons Shodan, moltes en versions vulnerables a una fallada d'execució remota del 2023. L'informe no quantifica quantes d'aquestes 17.000 continuaven sense apedaçar, i no inflarem la dada: el que sí que diu és que tres anys després de publicar-se el pedaç, la fallada es continua trobant a internet a milers. Aquest és el terra sobre el qual arriba un avís de puntuació 10.0.

La pregunta operativa és la de sempre, la que ja ens vam fer amb qui manté el teu WordPress: si aquest matí surt un avís crític de la teva eina de BI, a qui li arriba el correu? Si la resposta és «a qui la va instal·lar, si encara és a l'empresa», el problema no és de Metabase. I si la resposta és «no sé si en tenim», aquesta és la troballa d'avui.

L'endpoint és públic per disseny; internet no cal que ho sigui

Val la pena fixar-se en on era el forat, perquè no és casualitat. L'endpoint de recuperar contrasenya és, per definició, el que ha de respondre a qui no es pot autenticar. És a la porta, davant del control d'accés, a totes les aplicacions del món. La pregunta interessant no és si aquest endpoint ha d'existir —hi ha de ser—, sinó qui ha de poder cridar-lo.

Un panell de BI és una eina interna. Darrere d'una VPN, o d'un accés publicat per identitat com el que muntem als projectes de Zero Trust, aquesta mateixa fallada passa de «qualsevol amb connexió a internet és administrador del teu panell» a «algú que ja és a dins pot ser-ho». No l'elimina, i no fingirem que sí. Redueix la població d'atacants possibles de diversos milers de milions a la teva plantilla, i converteix una cursa d'hores contra bots en un incident que s'investiga amb noms. Contra l'argument habitual —«és que la gent el consulta des de casa»—: això és una necessitat legítima i té tres o quatre solucions, i cap no és publicar el login a internet.

I després hi ha la part que no decideixes tu

Framework i Tally no surten en aquesta història per descurats. Framework ha explicat que Metabase li va notificar el 6 d'agost que la seva instància havia estat accedida el dia 3, i el que va sortir van ser noms, correus, adreces i telèfons de clients. Tally parla de correus i hashes de contrasenyes. Cap de les dues empreses tenia un servidor sense apedaçar: tenien un proveïdor.

Aquesta és la part incòmoda d'aquesta mena d'incidents, i la que pitjor cobreixen els qüestionaris de proveïdor. Quan preguntes a un tercer «quines eines processen les nostres dades?», la resposta gairebé mai inclou el panell intern amb què el seu equip mira les mètriques del teu compte. No per mala fe: perquè per a ells aquest panell no és un sistema que processi dades de client, és la pantalla on miren com va el mes. Val la pena afegir la pregunta al qüestionari, i val la pena poder-la contestar tu si te la fan.

L'ordre en què ho faríem nosaltres

• Troba els panells. No els de l'inventari: els que hi ha. Un docker ps als servidors de l'equip de dades i una volta pels registres del DNS intern acostumen a donar més d'una sorpresa.
• Compara la versió amb el rang, ignorant el 0 o l'1 del principi. Actualitza a 58.24, 59.21, 60.17, 61.11, 62.9 o 63.5 segons la teva branca.
• Busca el patró 400 i després 200 des de la mateixa IP als logs del proxy, des de principis d'agost cap enrere. I revisa la llista d'administradors nom a nom: la promoció a administrador és l'objectiu de l'atac, i un compte de més n'és la prova.
• Rota les credencials de cada base de dades connectada. Totes. És la tasca cara, la que es posposa i l'única que li treu a l'atacant el que es va endur. Aprofita per canviar-les per usuaris de només lectura acotats, que és la conversa que porta pendent des del primer dia.
• Mira't des de fora. Respon el teu panell des d'una IP d'internet? Si sí, posa-li una porta abans que acabi la setmana.
• I el permanent: que el panell tingui un responsable amb nom i cognom, sigui a l'inventari i que algú rebi les notes de publicació del fabricant. Sense això, del pròxim avís també te n'assabentaràs per la premsa.

Quan això fa menys mal (i quan només ho sembla)

Si fas servir Metabase Cloud, el pedaç no és feina teva: el fabricant va bloquejar els endpoints de l'atac i va actualitzar les instàncies allotjades sense que hi fessis res. Però que el pedaç no sigui teu no et treu de la llista, més aviat al contrari: les dues instàncies compromeses que coneixem amb nom —Framework i Tally— eren instàncies allotjades. Revisa la llista d'administradors, tanca sessions i rota les credencials de les bases connectades exactament igual que si el servidor fos teu. El pedaç tanca la porta; no desfà el que va passar abans de tancar-la. Si ets per sota de la versió 58 no ets en aquest rang, encara que, com dèiem més amunt, això et posa en un altre de pitjor. I si el teu panell no ha estat mai accessible fora d'una xarxa de gestió i la connexió fa servir un usuari de només lectura acotat, actualitza amb calma i rota quan toqui: la teva exposició real és petita i dir-ho és més útil que espantar.

El que no val com a consol és «és que allà només hi ha dades de vendes». Les dades de vendes són noms, correus, telèfons i adreces dels teus clients, i sortir per la porta d'un panell no les converteix en una altra cosa. És exactament el que Framework ha hagut d'explicar als seus aquesta setmana.

Nosaltres no venem Metabase ni cap eina de BI, i això no és un argument en contra: és una bona peça de programari amb una fallada greu i una resposta ràpida del fabricant. La feina que sí que fem és la del voltant —saber quines aplicacions internes hi ha, qui les manté, quines credencials desen i a qui deixem arribar-hi— dins dels projectes de ciberseguretat i de dades i aplicacions del dia a dia. Si no saps quants panells hi ha endollats a les teves bases de dades ni amb quin usuari s'hi connecten, escriu-nos i ho mirem amb tu.