Un al doilea furnizor polonez de software medical a fost lovit în câteva săptămâni. Atacatorii au folosit o vulnerabilitate de injecție SQL pentru a fura datele pacienților de la Medyc, o platformă vândută de QBUSoft cabinetelor și clinicilor medicale. Breșa de date Medyc din Polonia cu expunerea PESEL urmează unui incident mult mai mare din august, iar împreună arată cât de mult risc se află la furnizorii din spatele software-ului pentru clinici, nu la pacienții ale căror dosare le dețin.

Detaliile de mai jos provin din reporting-ul Help Net Security. Unele părți ale rezumatului original au fost trunchiate, așa că această postare se limitează la ceea ce a fost confirmat.

Ce a fost furat de la Medyc

Medyc este o platformă pe care cabinetele și clinicile medicale o folosesc pentru a gestiona înregistrarea pacienților, dosarele și prescripțiile. Potrivit raportului, hackerii au furat datele pacienților de la furnizor exploatând o vulnerabilitate de injecție SQL.

Reporting-ul indică faptul că informațiile furate includ date de contact și numere PESEL, numerele de identificare națională utilizate în Polonia. Amploarea completă a furtului de la Medyc, inclusiv câți pacienți sunt afectați, nu era disponibilă în extrasul furnizat, așa că nu vom încerca să ghicim o cifră.

Numerele PESEL contează pentru că sunt un identificator de lungă durată. Spre deosebire de o parolă, o persoană nu îl poate schimba cu ușurință. Când este combinat cu un nume și informații de contact, poate fi folosit pentru a face tentativele de impersonare să pară mai convingătoare.

Cum a pregătit terenul breșa MyDr

Incidentul Medyc nu s-a produs izolat. În august, atacatorii au furat datele a aproape 19 milioane de persoane de la MyDr, o companie cu sediul în Varșovia al cărei software este folosit de aproximativ 12.000 de unități medicale. Baza de date scursă de acolo conținea și numere PESEL.

Această amploare este partea importantă. Un singur furnizor care deservește mii de unități deține dosarele unei mari părți a populației unei țări într-un singur loc. Când acel furnizor este compromis, fiecare clinică care se bazează pe el este afectată deodată, iar pacienții adesea nu au idee ce software folosește cabinetul medicului lor.

Cazul Medyc adaugă un al doilea punct de date. Doi furnizori diferiți, două breșe, ambele implicând același tip de identificatori sensibili. Acest tipar sugerează că atacatorii văd furnizorii de software medical ca ținte eficiente, deoarece o singură intruziune reușită poate produce dosare din multe clinici.

De ce injecția SQL lovește continuu furnizorii din domeniul sănătății

Injecția SQL este una dintre cele mai vechi și mai bine înțelese vulnerabilități web. Apare atunci când o aplicație transmite date introduse de utilizator într-o interogare de bază de date fără a separa corect datele de comenzi. Un atacator poate apoi să creeze date de intrare care modifică interogarea și determină baza de date să returneze informații pe care nu ar trebui să le returneze.

Soluția este bine cunoscută: interogări parametrizate, validarea datelor de intrare, conturi de bază de date cu privilegii minime și testare regulată. Totuși, vulnerabilitatea continuă să apară, mai ales în software-ul care s-a dezvoltat de-a lungul multor ani sau care gestionează multe integrări. Platformele medicale corespund adesea acestei descrieri, deoarece procesează formulare de înregistrare, prescripții și căutări de dosare prin componente expuse pe web.

Aceeași clasă de vulnerabilitate apare mult în afara medicinei. Reportajul nostru despre atacatori care exploatează o vulnerabilitate zero-day de injecție SQL nepatchată în GeoServer arată cum un tip de vulnerabilitate poate fi folosit împotriva unor platforme foarte diferite. Lecția este consecventă: când o aplicație expusă pe internet comunică cu o bază de date, interogările nesigure reprezintă un risc serios.

Ce înseamnă asta pentru tine

Dacă ești pacient în Polonia, probabil nu poți spune dacă clinica ta folosește Medyc, MyDr sau un alt sistem. Aceasta este problema centrală. Datele tale se află la o terță parte pe care nu ai ales-o, iar obiceiurile tale de securitate au puțină influență asupra modului în care acea terță parte își scrie codul.

Un VPN criptează traficul dintre dispozitivul tău și un server. Nu protejează o bază de date pe care un furnizor o stochează și la care un atacator ajunge printr-o vulnerabilitate din aplicația proprie a furnizorului. Același lucru este valabil pentru criptarea dispozitivului și parolele puternice: sunt utile, dar nu opresc o breșă din partea furnizorului.

Ce poți face este să reduci daunele dacă detaliile tale sunt utilizate abuziv:

  • Tratează cu suspiciune apelurile, mesajele text sau e-mailurile neașteptate care menționează sănătatea, prescripțiile sau PESEL-ul tău, chiar dacă par să cunoască detalii personale.
  • Nu împărtăși PESEL-ul sau informațiile medicale prin contact nesolicitat. Contactează clinica printr-un număr pe care îl cauți singur.
  • Urmărește notificările oficiale de la clinica ta sau de la autoritățile de reglementare cu privire la implicarea datelor tale.
  • Folosește parole puternice și unice și autentificarea cu doi factori pentru e-mail și conturile financiare, deoarece acestea sunt ținte comune după scurgerile de date de identitate.
  • Verifică-ți înregistrările financiare și de credit pentru activități pe care nu le recunoști.

Concluzii cheie

Breșa de date Medyc din Polonia cu expunerea PESEL, venind după scurgerea MyDr care a afectat aproape 19 milioane de persoane, arată că furnizorii concentrați de software medical sunt puncte unice de eșec. Instrumentele personale precum un VPN merită folosite pentru navigare privată, dar nu pot remedia o vulnerabilitate din interiorul bazei de date a unui furnizor. Responsabilitatea pentru aceasta revine furnizorilor, care trebuie să remedieze probleme de bază precum injecția SQL, și autorităților de reglementare care îi supraveghează.

Pentru cititori, pasul practic este vigilența față de impersonare și phishing care folosesc identificatori scurși. Pentru a vedea cum același tip de vulnerabilitate este exploatat în altă parte, citește raportul nostru despre vulnerabilitatea zero-day de injecție SQL în GeoServer.