Ein zweiter polnischer Anbieter von Medizinsoftware wurde innerhalb weniger Wochen getroffen. Angreifer nutzten eine SQL-Injection-Schwachstelle, um Patientendaten von Medyc zu stehlen, einer Plattform, die QBUSoft an Arztpraxen und Kliniken verkauft. Die Medyc-Datenpanne in Polen mit PESEL-Exposition folgt auf einen weitaus größeren Vorfall im August, und zusammen zeigen sie, wie viel Risiko bei den Anbietern hinter der Praxissoftware liegt – und nicht bei den Patienten, deren Daten sie speichern.

Die folgenden Details stammen aus der Berichterstattung von Help Net Security. Einige Teile der ursprünglichen Zusammenfassung waren abgeschnitten, daher beschränkt sich dieser Beitrag auf das, was bestätigt wurde.

Was aus Medyc gestohlen wurde

Medyc ist eine Plattform, die Arztpraxen und Kliniken zur Verwaltung von Patientenanmeldung, Patientenakten und Rezepten nutzen. Dem Bericht zufolge stahlen Hacker Patientendaten des Anbieters, indem sie eine SQL-Injection-Schwachstelle ausnutzten.

Der Bericht deutet darauf hin, dass die gestohlenen Informationen Kontaktdaten und PESEL-Nummern umfassen, die in Polen verwendeten nationalen Identifikationsnummern. Der vollständige Umfang des Medyc-Diebstahls, einschließlich der Zahl der betroffenen Patienten, war in dem bereitgestellten Auszug nicht verfügbar, daher werden wir keine Zahl raten.

PESEL-Nummern sind wichtig, weil sie eine langlebige Kennung sind. Anders als ein Passwort kann eine Person sie nicht einfach ändern. Wenn sie mit einem Namen und Kontaktinformationen kombiniert wird, kann sie dazu verwendet werden, Identitätstäuschungsversuche überzeugender erscheinen zu lassen.

Wie die MyDr-Datenpanne den Boden bereitete

Der Medyc-Vorfall geschah nicht isoliert. Im August stahlen Angreifer Daten von fast 19 Millionen Menschen von MyDr, einem in Warschau ansässigen Unternehmen, dessen Software von etwa 12.000 Gesundheitseinrichtungen genutzt wird. Die dort durchgesickerte Datenbank enthielt ebenfalls PESEL-Nummern.

Dieser Umfang ist der wichtige Teil. Ein einzelner Anbieter, der Tausende von Einrichtungen bedient, speichert die Daten eines großen Teils der Bevölkerung eines Landes an einem Ort. Wenn dieser Anbieter kompromittiert wird, ist jede Klinik, die sich auf ihn verlässt, gleichzeitig betroffen, und Patienten haben oft keine Ahnung, welche Software die Praxis ihres Arztes verwendet.

Der Medyc-Fall liefert einen zweiten Datenpunkt. Zwei verschiedene Anbieter, zwei Datenpannen, und beide betreffen dieselbe Art sensibler Identifikatoren. Dieses Muster deutet darauf hin, dass Angreifer Anbieter von Medizinsoftware als effiziente Ziele betrachten, da ein erfolgreicher Einbruch Datensätze aus vielen Kliniken liefern kann.

Warum SQL-Injection weiterhin Anbieter im Gesundheitswesen trifft

SQL-Injection ist eine der ältesten und am besten verstandenen Web-Schwachstellen. Sie tritt auf, wenn eine Anwendung vom Benutzer gelieferte Eingaben in eine Datenbankabfrage übergibt, ohne Daten ordnungsgemäß von Befehlen zu trennen. Ein Angreifer kann dann Eingaben konstruieren, die die Abfrage verändern und die Datenbank dazu bringen, Informationen zurückzugeben, die sie nicht zurückgeben sollte.

Die Behebung ist wohlbekannt: parametrisierte Abfragen, Eingabevalidierung, Datenbankkonten mit minimalen Rechten und regelmäßige Tests. Dennoch taucht der Fehler immer wieder auf, insbesondere in Software, die über viele Jahre gewachsen ist oder viele Integrationen verarbeitet. Gesundheitsplattformen entsprechen oft dieser Beschreibung, da sie Anmeldeformulare, Rezepte und Aktenabfragen über webbasierte Komponenten verarbeiten.

Dieselbe Schwachstellenklasse zeigt sich auch weit außerhalb der Medizin. Unsere Berichterstattung über Angreifer, die eine ungepatchte GeoServer-SQL-Injection-Zero-Day ausnutzen zeigt, wie eine Art von Fehler gegen sehr unterschiedliche Plattformen eingesetzt werden kann. Die Lehre ist beständig: Wenn eine internetzugewandte Anwendung mit einer Datenbank kommuniziert, sind unsichere Abfragen ein ernstes Risiko.

Was das für Sie bedeutet

Wenn Sie ein Patient in Polen sind, können Sie wahrscheinlich nicht sagen, ob Ihre Klinik Medyc, MyDr oder ein anderes System verwendet. Das ist das Kernproblem. Ihre Daten liegen bei einem Dritten, den Sie nicht ausgewählt haben, und Ihre eigenen Sicherheitsgewohnheiten haben wenig Einfluss darauf, wie dieser Dritte seinen Code schreibt.

Ein VPN verschlüsselt den Datenverkehr zwischen Ihrem Gerät und einem Server. Es schützt keine Datenbank, die ein Anbieter speichert und auf die ein Angreifer durch eine Schwachstelle in der Anwendung des Anbieters selbst zugreift. Dasselbe gilt für Geräteverschlüsselung und starke Passwörter: Sie sind nützlich, aber sie stoppen keine Datenpanne auf Anbieterseite.

Was Sie tun können, ist den Schaden zu begrenzen, falls Ihre Daten missbraucht werden:

  • Behandeln Sie unerwartete Anrufe, Textnachrichten oder E-Mails, die Ihre Gesundheit, Rezepte oder PESEL erwähnen, mit Misstrauen, selbst wenn sie persönliche Details zu kennen scheinen.
  • Teilen Sie Ihre PESEL oder medizinische Informationen nicht bei unaufgefordertem Kontakt. Kontaktieren Sie die Klinik über eine Nummer, die Sie selbst heraussuchen.
  • Achten Sie auf offizielle Mitteilungen Ihrer Klinik oder Aufsichtsbehörden darüber, ob Ihre Daten betroffen waren.
  • Verwenden Sie starke, einzigartige Passwörter und Zwei-Faktor-Authentifizierung für E-Mail- und Finanzkonten, da diese nach Identitätsdatenlecks häufige Ziele sind.
  • Prüfen Sie Ihre Finanz- und kreditbezogenen Unterlagen auf Aktivitäten, die Sie nicht erkennen.

Wichtige Erkenntnisse

Die Medyc-Datenpanne in Polen mit PESEL-Exposition, die nach dem MyDr-Leck mit fast 19 Millionen Betroffenen kam, zeigt, dass konzentrierte Gesundheitssoftware-Anbieter einzelne Ausfallpunkte sind. Persönliche Werkzeuge wie ein VPN sind für privates Surfen sinnvoll, aber sie können einen Fehler innerhalb der Datenbank eines Anbieters nicht beheben. Die Verantwortung dafür liegt bei den Anbietern, die grundlegende Probleme wie SQL-Injection beheben müssen, und bei den Aufsichtsbehörden, die sie beaufsichtigen.

Für Leser besteht der praktische Schritt in Wachsamkeit gegenüber Identitätstäuschung und Phishing, das durchgesickerte Identifikatoren verwendet. Um zu sehen, wie dieselbe Fehlerart anderswo ausgenutzt wird, lesen Sie unseren Bericht über die GeoServer-SQL-Injection-Zero-Day.