Una delle piattaforme di business intelligence più diffuse al mondo è finita al centro di un attacco che ha già prodotto vittime eccellenti. Metabase ha confermato che una vulnerabilità di gravità massima (CVSS 10.0), al momento senza identificativo CVE, è stata sfruttata in rete come zero-day: una SQL injection senza autenticazione che permette a un attaccante remoto di iniettare codice SQL arbitrario nel database applicativo e di ottenere i privilegi di amministratore sull'istanza.

Cosa è successo

L'azienda ha scoperto l'attacco il 3 agosto, quando qualcuno ha colpito la piattaforma gestita Metabase Cloud sfruttando la falla, presente in tutte le versioni dalla x.58.0 in poi. Con i privilegi di amministratore l'attaccante può modificare la configurazione dell'applicazione, leggere ed esportare qualsiasi dato raggiungibile attraverso le connessioni configurate e, soprattutto, rubare le credenziali memorizzate dei database collegati: il vero bottino, perché consente di attaccare direttamente le fonti dati anche dopo la bonifica di Metabase.

Le versioni corrette sono x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 e x.63.5. Le istanze Metabase Cloud sono già state aggiornate automaticamente; chi usa la versione self-hosted deve aggiornare subito. Come mitigazione temporanea, Metabase consiglia di bloccare l'endpoint /api/session/reset_password, usato nella catena di attacco.

La compromissione lascia una firma riconoscibile nei log: una chiamata POST /api/session/reset_password che restituisce un errore 400, seguita da una GET /api/user/current che risponde 200. Se questo pattern compare nei log applicativi o del reverse proxy, l'istanza va considerata con ogni probabilità compromessa.

Le conseguenze sono già concrete. Framework, il produttore americano di laptop modulari, ha avvisato tutti i suoi clienti che nomi, email, indirizzi IP di accesso, indirizzi di fatturazione e spedizione, numeri di telefono e ragioni sociali sono stati esposti attraverso la sua istanza Metabase; i dati di pagamento non sono stati toccati. Un incidente analogo è stato comunicato anche da Tally. Non è la prima volta per Metabase: nel 2023 la piattaforma aveva corretto la CVE-2023-38646, una falla da 9.8 che consentiva l'esecuzione di codice remoto senza autenticazione.

Cosa significa per le aziende italiane

Metabase è popolarissimo anche in Italia, soprattutto tra startup e PMI: è open source, gratuito nella versione base e si installa in pochi minuti sopra il database di produzione. Ed è proprio questo il punto: uno strumento di BI è un mazzo di chiavi del patrimonio informativo aziendale. Chi lo compromette non viola "un'applicazione di reportistica", ma ottiene accesso a tutto ciò che vi transita: anagrafiche clienti, ordini, fatturato, dati dei dipendenti.

I profili di rischio sono due. Il primo riguarda le istanze self-hosted esposte su internet, spesso su sottodomini dedicati e senza WAF davanti: per una falla pre-autenticazione come questa sono bersagli immediati delle scansioni di massa. Il secondo è la catena di fornitura: il caso Framework dimostra che si può subire un data breach "attraverso" il proprio fornitore, anche quando la propria infrastruttura è intatta. In entrambi gli scenari, verso il Garante e verso gli interessati la responsabilità resta del titolare del trattamento.

Sul piano normativo, se dai log emerge il pattern di compromissione e i dati coinvolti sono personali, scatta la valutazione ex art. 33 GDPR: notifica al Garante entro 72 ore dalla scoperta se c'è un rischio per gli interessati, e comunicazione agli interessati stessi (art. 34) se il rischio è elevato: la lettera che Framework ha inviato a tutti i clienti è esattamente questo adempimento. Se l'istanza è gestita da un fornitore esterno, questi è responsabile del trattamento ex art. 28 e deve segnalare l'incidente al titolare senza ingiustificato ritardo: è il momento di verificare che il contratto lo preveda davvero. Per i soggetti in perimetro NIS2, un accesso abusivo con esfiltrazione può costituire incidente significativo, con pre-notifica al CSIRT Italia entro 24 ore e notifica entro 72.

Cosa fare subito

  • Censire tutte le istanze Metabase in azienda, comprese quelle "di test" dimenticate: sono interessate tutte le versioni dalla x.58 in poi.
  • Aggiornare a x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 o x.63.5; se non è possibile farlo subito, bloccare l'endpoint /api/session/reset_password su WAF o reverse proxy.
  • Cercare nei log il pattern: POST /api/session/reset_password con esito 400 seguito da GET /api/user/current con esito 200.
  • In caso di sospetta compromissione: revocare tutte le sessioni attive (tabella core_session), verificare API key e account amministratore, ruotare le credenziali di tutti i database collegati e analizzare i log del data warehouse alla ricerca di query ed export anomali.
  • Togliere la BI da internet: pubblicarla solo dietro VPN o SSO con MFA, mai direttamente esposta.
  • Se Metabase è fornito da terzi, chiedere formalmente conferma dell'avvenuto aggiornamento e dell'esito delle verifiche sui log.

La lezione è più ampia della singola falla: gli strumenti di analisi dati concentrano un potere di accesso enorme e vanno protetti come i database che interrogano, non come semplici applicazioni web di contorno.