Egy második lengyel egészségügyi szoftverszolgáltatót ért támadás heteken belül. A támadók egy SQL-injekciós sebezhetőséget kihasználva loptak el páciensadatokat a Medyc platformról, amelyet a QBUSoft értékesít orvosi rendelők és klinikák számára. A lengyelországi Medyc adatvédelmi incidens, amely PESEL-számok érintettségét is jelenti, egy sokkal nagyobb augusztusi eseményt követ, és együtt megmutatják, mekkora kockázatot hordoznak a klinikai szoftverek mögötti szállítók, nem pedig azok a páciensek, akiknek az adatait tárolják. Az alábbi részletek a Help Net Security beszámolójából származnak. Az eredeti összefoglaló egyes részei csonkoltak voltak, ezért ez a bejegyzés csak a megerősített információkra szorítkozik. ## Mit loptak el a Medyc-től A Medyc egy olyan platform, amelyet orvosi rendelők és klinikák használnak a páciensek regisztrációjának, adatainak és receptjeinek kezelésére. A jelentés szerint a hackerek egy SQL-injekciós sebezhetőséget kihasználva loptak el páciensadatokat a szolgáltatótól. A beszámoló szerint az ellopott információk közé tartoznak az elérhetőségi adatok és a PESEL-számok, amelyek Lengyelországban használt nemzeti azonosító számok. A Medyc-ellopás teljes terjedelme, beleértve azt is, hogy hány páciens érintett, nem volt elérhető a rendelkezésre bocsátott részletben, ezért nem fogunk találgatni egy számot illetően. A PESEL-számok azért fontosak, mert hosszú életű azonosítók. A jelszóval ellentétben az ember nem tudja könnyen megváltoztatni. Amikor egy névvel és elérhetőségi adatokkal kombinálják, felhasználható arra, hogy a megszemélyesítési kísérletek hitelesebbnek tűnjenek. ## Hogyan készítette elő a terepet a MyDr incidens A Medyc eset nem elszigetelten történt. Augusztusban a támadók csaknem 19 millió ember adatait lopták el a MyDr-től, egy varsói székhelyű cégtől, amelynek szoftverét mintegy 12 000 egészségügyi intézmény használja. A kiszivárgott adatbázis ott is PESEL-számokat tartalmazott. A lépték a fontos rész. Egyetlen szállító, amely több ezer intézményt szolgál ki, egy ország lakosságának jelentős részének adatait egy helyen tárolja. Amikor ezt a szállítót kompromittálják, minden klinika, amely rá támaszkodik, egyszerre érintetté válik, és a pácienseknek gyakran fogalmuk sincs arról, milyen szoftvert használ az orvosuk rendelője. A Medyc eset egy második adatpontot ad hozzá. Két különböző szállító, két incidens, és mindkettő ugyanazokat az érzékeny azonosítókat érinti. Ez a minta arra utal, hogy a támadók hatékony célpontoknak tekintik az egészségügyi szoftverszolgáltatókat, mivel egyetlen sikeres behatolás sok klinika adatait eredményezheti. ## Miért sújtja folyamatosan az SQL-injekció az egészségügyi szállítókat Az SQL-injekció az egyik legrégebbi és legjobban ismert webes sebezhetőség. Akkor fordul elő, amikor egy alkalmazás a felhasználó által megadott bemenetet megfelelő adat- és parancsszétválasztás nélkül adja át egy adatbázis-lekérdezésnek. A támadó ezután olyan bemenetet készíthet, amely megváltoztatja a lekérdezést, és ráveszi az adatbázist, hogy olyan információkat adjon vissza, amelyeket nem kellene. A javítás jól ismert: paraméterezett lekérdezések, bemenet-ellenőrzés, minimális jogosultságú adatbázis-fiókok és rendszeres tesztelés. Mégis, a hiba folyamatosan megjelenik, különösen olyan szoftverekben, amelyek sok éven át növekedtek, vagy amelyek sok integrációt kezelnek. Az egészségügyi platformok gyakran megfelelnek ennek a leírásnak, mivel regisztrációs űrlapokat, recepteket és adatkereséseket dolgoznak fel webes felületen keresztül. Ugyanez a sebezhetőségi osztály az orvostudományon kívül is megjelenik. A [támadók által kihasznált, javítatlan GeoServer SQL-injekciós zero-dayről szóló tudósításunk](/en/attackers-exploit-unpatched-geoserver-sql-injection-zero-day) megmutatja, hogyan lehet egyetlen hibatípust nagyon különböző platformok ellen használni. A tanulság következetes: amikor egy internetre kapcsolt alkalmazás adatbázissal kommunikál, a nem biztonságos lekérdezések komoly kockázatot jelentenek. ## Mit jelent ez az Ön számára Ha Ön Lengyelországban páciens, valószínűleg nem tudja megállapítani, hogy a klinikája a Medyc-et, a MyDr-t vagy egy másik rendszert használja-e. Ez a fő probléma. Az adatai egy olyan harmadik félnél vannak, amelyet nem Ön választott, és a saját biztonsági szokásai alig befolyásolják azt, hogy ez a harmadik fél hogyan írja a kódját. A VPN titkosítja a forgalmat az eszköze és egy szerver között. Nem védi meg azt az adatbázist, amelyet egy szállító tárol, és amelyet egy támadó a szállító saját alkalmazásában lévő hiba révén ér el. Ugyanez igaz az eszköztitkosításra és az erős jelszavakra is: hasznosak, de nem akadályozzák meg a szállító oldalán bekövetkező incidenseket. Amit tehet, az a kár csökkentése, ha visszaélnek az adataival: - Kezelje gyanakvással a váratlan hívásokat, szöveges üzeneteket vagy e-maileket, amelyek az egészségére, a receptjeire vagy a PESEL-számára hivatkoznak, még akkor is, ha úgy tűnik, hogy ismernek személyes adatokat. - Ne ossza meg a PESEL-számát vagy orvosi információit kéretlen megkeresés során. Vegye fel a kapcsolatot a klinikával egy Ön által kikeresett telefonszámon. - Figyelje a klinikájától vagy a szabályozó hatóságoktól érkező hivatalos értesítéseket arról, hogy érintett-e az adatai. - Használjon erős, egyedi jelszavakat és kétfaktoros hitelesítést az e-mail- és pénzügyi fiókjain, mivel ezek gyakori célpontok a személyazonossági adatok kiszivárgása után. - Ellenőrizze pénzügyi és hitellel kapcsolatos nyilvántartásait az Ön által nem ismert tevékenységek után kutatva. ## Fő tanulságok A lengyelországi Medyc adatvédelmi incidens, amely a csaknem 19 millió embert érintő MyDr-szivárgás után következett be, PESEL-kitettséget mutat, és azt jelzi, hogy a koncentrált egészségügyi szoftverszállítók egyetlen meghibásodási pontot jelentenek. Az olyan személyes eszközök, mint a VPN, érdemesek a privát böngészéshez, de nem tudják kijavítani a szállító adatbázisában lévő hibát. Ezért a felelősség a szolgáltatókat terheli, akiknek javítaniuk kell az olyan alapvető problémákat, mint az SQL-injekció, valamint az őket felügyelő szabályozókat. Az olvasók számára a gyakorlati lépés az éberség a kiszivárgott azonosítókat felhasználó megszemélyesítéssel és adathalászattal szemben. Hogy lássa, hogyan használják ki ugyanezt a hibatípust máshol, olvassa el a [GeoServer SQL-injekciós zero-dayről szóló jelentésünket](/en/attackers-exploit-unpatched-geoserver-sql-injection-zero-day).