Un secondo fornitore polacco di software medico è stato colpito nel giro di poche settimane. Gli attaccanti hanno sfruttato una vulnerabilità di SQL injection per rubare dati dei pazienti da Medyc, una piattaforma venduta da QBUSoft a studi medici e cliniche. La violazione dei dati di Medyc in Polonia con esposizione dei PESEL segue un incidente molto più ampio ad agosto, e insieme mostrano quanta parte del rischio ricada sui fornitori dietro il software delle cliniche, non sui pazienti i cui dati sono in loro possesso.

I dettagli seguenti provengono dal reportage di Help Net Security. Alcune parti del riepilogo originale erano troncate, quindi questo articolo si attiene a ciò che è stato confermato.

Cosa è stato rubato da Medyc

Medyc è una piattaforma che gli studi medici e le cliniche utilizzano per gestire la registrazione dei pazienti, le cartelle e le prescrizioni. Secondo il rapporto, gli hacker hanno rubato i dati dei pazienti dal fornitore sfruttando una vulnerabilità di SQL injection.

Il reportage indica che le informazioni rubate includono dati di contatto e numeri PESEL, i numeri di identificazione nazionale utilizzati in Polonia. La portata completa del furto di Medyc, incluso il numero di pazienti coinvolti, non era disponibile nell'estratto fornito, quindi non azzarderemo una cifra.

I numeri PESEL contano perché sono un identificatore di lunga durata. A differenza di una password, una persona non può cambiarli facilmente. Quando vengono combinati con un nome e informazioni di contatto, possono essere usati per rendere più convincenti i tentativi di impersonificazione.

Come la violazione di MyDr ha preparato il terreno

L'incidente di Medyc non è avvenuto in isolamento. Ad agosto, gli attaccanti hanno rubato i dati di quasi 19 milioni di persone da MyDr, un'azienda con sede a Varsavia il cui software è utilizzato da circa 12.000 strutture sanitarie. Anche il database trapelato conteneva numeri PESEL.

È la scala che conta. Un singolo fornitore che serve migliaia di strutture detiene le cartelle di una larga fetta della popolazione di un paese in un unico posto. Quando quel fornitore viene compromesso, ogni clinica che si affida a lui viene colpita contemporaneamente, e i pazienti spesso non hanno idea di quale software utilizzi lo studio del loro medico.

Il caso Medyc aggiunge un secondo dato. Due fornitori diversi, due violazioni, ed entrambe coinvolgono lo stesso tipo di identificatori sensibili. Questo schema suggerisce che gli attaccanti vedono i fornitori di software medico come obiettivi efficienti, poiché una singola intrusione riuscita può produrre cartelle da molte cliniche.

Perché la SQL injection continua a colpire i fornitori sanitari

La SQL injection è una delle vulnerabilità web più antiche e meglio comprese. Si verifica quando un'applicazione passa input forniti dall'utente in una query di database senza separare adeguatamente i dati dai comandi. Un attaccante può quindi creare un input che modifica la query e fa restituire al database informazioni che non dovrebbe.

La soluzione è ben nota: query parametrizzate, validazione dell'input, account di database con privilegi minimi e test regolari. Eppure la falla continua a comparire, specialmente in software che si è sviluppato nell'arco di molti anni o che gestisce molte integrazioni. Le piattaforme sanitarie spesso corrispondono a questa descrizione, poiché elaborano moduli di registrazione, prescrizioni e ricerche di cartelle attraverso componenti esposti al web.

La stessa classe di vulnerabilità si manifesta ben al di fuori della medicina. La nostra copertura di attaccanti che sfruttano una SQL injection zero-day non corretta in GeoServer mostra come un tipo di falla possa essere usato contro piattaforme molto diverse. La lezione è coerente: quando un'applicazione esposta a internet comunica con un database, le query non sicure sono un rischio serio.

Cosa significa per te

Se sei un paziente in Polonia, probabilmente non puoi sapere se la tua clinica usa Medyc, MyDr o un altro sistema. Questo è il problema centrale. I tuoi dati si trovano presso una terza parte che non hai scelto, e le tue abitudini di sicurezza personali hanno poca influenza su come quella terza parte scrive il proprio codice.

Una VPN cripta il traffico tra il tuo dispositivo e un server. Non protegge un database che un fornitore conserva e che un attaccante raggiunge attraverso una falla nell'applicazione del fornitore stesso. Lo stesso vale per la crittografia del dispositivo e le password robuste: sono utili, ma non fermano una violazione dal lato del fornitore.

Quello che puoi fare è ridurre i danni se i tuoi dati vengono usati impropriamente:

  • Tratta con sospetto chiamate, messaggi o email inaspettati che menzionano la tua salute, le prescrizioni o il PESEL, anche se sembrano conoscere dettagli personali.
  • Non condividere il tuo PESEL o le tue informazioni mediche in contatti non richiesti. Contatta la clinica tramite un numero che cerchi tu stesso.
  • Fai attenzione agli avvisi ufficiali della tua clinica o delle autorità di regolamentazione su un eventuale coinvolgimento dei tuoi dati.
  • Usa password robuste e uniche e l'autenticazione a due fattori su email e conti finanziari, poiché sono obiettivi comuni dopo le fughe di dati identitari.
  • Controlla i tuoi registri finanziari e creditizi per attività che non riconosci.

Punti chiave

La violazione dei dati di Medyc in Polonia con esposizione dei PESEL, arrivata dopo la fuga di MyDr che ha colpito quasi 19 milioni di persone, mostra che i fornitori concentrati di software sanitario sono singoli punti di guasto. Strumenti personali come una VPN valgono la pena di essere usati per la navigazione privata, ma non possono risolvere una falla all'interno del database di un fornitore. La responsabilità di ciò ricade sui fornitori, che devono correggere problemi di base come la SQL injection, e sulle autorità di regolamentazione che li supervisionano.

Per i lettori, il passo pratico è la vigilanza contro impersonificazione e phishing che usano identificatori trapelati. Per vedere come lo stesso tipo di falla viene sfruttato altrove, leggi il nostro report sulla SQL injection zero-day di GeoServer.