Unfassbar, aber wahr: Auch in Deutschland kommt die Digitalisierung an. Mittlerweile sogar in Arztpraxen. Termine buchen, Akten durchsuchen, Krankschreibungen und Abrechnungen ausstellen – das alles kann mit einer Software erledigt werden. Die kennt dann Praxen und Patient*innen sehr gut – sehr, sehr gut sogar. Genauso unfassbar, aber leider auch wahr: Als wir uns eine dieser Softwarelösungen für Arztpraxen mal genauer angeschaut haben, hat sie sehr viele Daten verloren. Sehr, sehr viele: Von mehr als einer Million Patient*innen.

Fast zwei Jahre lang sind wir jetzt zusammen neugierig 🎉 und haben schon viel problematische Software gesehen. Sehr, sehr viel. Aber mehr als eine Million Datensätze, die auf einmal verloren gehen - und zwar sensibelste Patient*innen-Daten inklusive Behandlungsverlauf – das hatten wir bisher auch noch nicht.

Dabei ist es immer wieder das Gleiche: Wir haben ein schlechtes Bauchgefühl. Wir hoffen, dass wir falsch liegen und die Entwickler*innen sorgfältig gearbeitet haben und es nichts zu befürchten gibt.

Wir schreiben miteinander Nachrichten. Wir probieren aus. Wir finden eine Sicherheitslücke und ärgern uns, jetzt schon wieder wenig schlafen zu können – denn dann sind wir wieder eine ganze Nacht lang beschäftigt, Sicherheitslücken zu dokumentieren.

Alle schlimmen Dinge beginnen im Chat

Heute nehmen wir euch mit auf diesem Weg vom Bauchgefühl, zum Arzt und zur nachgewiesenen Sicherheitslücke - und zeigen euch auch unsere Chatnachrichten. Natürlich gekürzt und kuratiert, aber sehr nah an der Realität.

Mein Hausarzt darf keine Blutwerte etc. per E-Mail verschicken und nutzt deshalb ein “Gesundheitsportal”. Das sieht auf den ersten Blick schon so aus, als wäre das bestimmt kaputt.

👀👀

Also öffnen wir einen Browser und darin die Entwicklungstools. Damit können wir uns anschauen, was die Webseite so treibt. In diesem Fall geht es um die Praxissoftware “InSuite” von DocCirrus. Dort fallen uns sofort einige merkwürdige Dinge auf.

es lädt auf jeder Seite Google Maps? #yolo

Und da wird minified javascript-code in json payloads returned???

Das ist alles keine Sicherheitslücke, aber schon seltsam.

Schock 1: Ich sehe was, was du deinen Ärzt*innen schreibst

So auch hier: Das zweite zerforschi hatte noch nicht mal Zeit, einen Laptop aufzuklappen, um sich in der Software anzumelden, da heißt es schon:

Sie leaken die SMTP-Zugangsdaten der Arztpraxis oh boi oh boi oh shit
Damit könnte man bestimmt auch E-Mails abrufen

Was war passiert?

Nachdem man sich auf der Website angemeldet hat, bekommt man eine Liste der Praxen angezeigt, bei denen man registriert ist.

Angezeigt werden dabei nur harmlose Informationen: Wo ist die Praxis? Wann hat sie offen?

Doch in den Entwickler*innen-Tools unseres Browsers sehen wir, dass nicht nur diese Informationen übertragen werden, sondern noch mehr Details. Viel viel mehr Details. Darunter viel Harmloses, wie die Bankverbindung der Praxis, die E-Mail-Signatur der Ärzt*innen und welche Drucker es in der Praxis so gibt. Aber eben auch die Zugangsdaten zum Versenden von E-Mails.

Uffff

Puuuh

Belastend

was jetzt?

Ja ich seh schon, da müssen wir nochmal genau drauf schauen

Zuerst hoffen wir natürlich, dass das Zugangsdaten für ein extra Postfach sind, über das nur E-Mails versendet werden können. Dann könnten wir mit diesen Zugangsdaten zwar im Namen der Praxis Mails versenden, aber immerhin nicht mehr.

Doch wir sehen schnell: In den allermeisten Fällen sind das tatsächlich die vollständigen Zugangsdaten zum allgemeinen E-Mail-Postfach der Praxis (z.B. info@PRAXISNAME.de). Mit denen könnten wir nun also auch alle E-Mails lesen, die die Praxis bekommt – und darin stehen nicht selten privateste Informationen über Patient*innen.

Schock 2: Ente-zu-Ente-Verschlüsselung: Alles nur quak 🦆

Eine Faustregel, die sich leider viel zu oft bewahrheitet hat, ist: Wo eine derart simple Lücke besteht, wurde vielleicht an noch mehr Stellen unsauber gearbeitet.

Also haben wir uns bei nächster Gelegenheit, es war mal wieder mitten in der Nacht, zusammentelefoniert und die Features systematischer angesehen und ausprobiert.

wenn ihr wollt, können wir gerne einen Call starten, kann eh nicht schlafen

Wollte eigentlich bald schlafen gehen, aber was solls

DocCirrus wirbt damit, dass die Patient*innen-Daten und Dokumente nicht zentral bei ihnen gespeichert werden, sondern nur in der Praxis - auf einem kleinen Server, den sie den Arztpraxen als “Datensafe” verkaufen. Dieser ist auch erstmal absichtlich nicht “von außen” erreichbar.

Das wirkt auf den ersten Blick gut: Wenn Daten nicht über das Internet erreichbar sind, können sie auch nicht aus der Ferne unberechtigt abgerufen werden. Zudem liegen die Daten dann nicht zentral in einer Cloud eines Anbieters, die alle Daten auf einmal verlieren könnte.

Aha, und das soll funktionieren? 🧐

Auf den zweiten Blick wirkt das aber auch seltsam: Über DocCirrus sollen Patient*innen eigentlich auf ihre eigenen Daten Zugriff haben, damit sie nicht mehr über unverschlüsselte E-Mails verschickt werden müssen. Wie passt das zusammen?

Der Hersteller DocCirrus sagt: Mit ein bisschen Cloud und Ende-zu-Ende-Verschlüsselung zwischen Praxis und Patient*in¹!

Das soll dann so funktionieren: Die Patient*innen loggen sich in einen zentralen Dienst bei DocCirrus ein – das Gesundheitsportal. Dieses läuft auf einem Server von DocCirrus, der aus dem Internet erreichbar ist, und hält eine ständige Verbindung zu allen dezentralen Servern in den Praxen. Wenn nun Daten aus der Praxis gebraucht werden, schickt der Webbrowser der Patient*innen eine Anfrage an den zentralen Server, und der leitet es dann an den Datensafe in der Praxis weiter. Diesen Dienst nennt DocCirrus “blindproxy”.

Und damit dieser blindproxy nicht mitlesen kann, was Patient*in und Praxis so miteinander für Daten austauschen, verschlüsseln Patient*innen-Browser und Praxis-“Datensafe” die Daten nochmal so, dass nur diese beiden sie lesen können – und der blindproxy nur unverständliche Zeichenketten durchleiten kann.

Aber funktioniert das wirklich? Wir schauen uns näher an, wie die Dokumente übermittelt werden. Dabei geht es um sehr sensible Informationen, beispielsweise um die Ergebnisse von Bluttests oder Befunde von sexuell übertragbaren Krankheiten.

Wir öffnen also einen Browser und loggen uns wieder im Gesundheitsportal von DocCirrus ein. Dort werden alle unsere Dokumente aufgelistet. In den Entwickler*innen-Tools stellen wir zuerst fest: Die Liste der Dokumente mit IDs und Abruf-Links wird verschlüsselt übertragen. Rufen wir ein Dokument ab, sehen wir dann aber: Die Dokumente selbst werden gar nicht Ende-zu-Ende-verschlüsselt übertragen, anders als DocCirrus das behauptet.

Damit die Liste verschlüsselt werden kann, sendet der Browser mit, an wen verschlüsselt werden soll. Ganz naiv probieren wir aus, was passiert, wenn wir diese Information weglassen. Wir hätten erwartet, dass der Server hier einen Fehler anzeigt und wir nicht weiter kommen – doch stattdessen wird die Anfrage einfach beantwortet. Unverschlüsselt. 😱

Das führt das ganze Prinzip der Ende-zu-Ende-Verschlüsselung ad absurdum.

Schock 3: Wir kennen alle Dokumente deiner Ärzt*innen

Doch zurück zur Website: Nachdem wir nun unsere Daten auch ohne Verschlüsselung abrufen können, beginnen wir, die Anfragen ein bisschen zu verändern².

Die ursprüngliche Anfrage, um die eigenen Dokumente abzurufen, sieht in etwa so aus:

{
        "patientregid": null,
        "remoteurl": "/1/document/:patientDocument",
        "remoteparams": "{}",
        "remotemethod": "GET"
}

Der dabei auf dem Praxisserver aufgerufene Endpunkt ist /1/document/:patientDocument. Also probieren wir aus, was passiert, wenn wir /1/document aufrufen.
Was dann passierte, hat uns schockiert: Zurück kommt eine Liste aller Dokumente, die unsere Praxis gespeichert hat: Krankschreibungen, ausgestellte Rezepte, Diagnosen, Überweisungen an andere Ärzt*innen… wirklich ALLES.

{
  "meta": {
    "errors": [],
    "warnings": [],
    "query": {},
    "itemsPerPage": null,
    "totalItems": 77447,
    "page": null,
    "replyCode": 200
  },
  "data": [...]
}

Wenn hinter document eine Liste der Dokumente liegt, überlegen wir uns mal was es in einer Praxis noch geben könnte. Na klar! Patient*innen. Also probieren wir weiter und tauschen document durch patient aus.

Und wieder antwortet der Server: Diesmal mit einer Liste aller Patient*innen, die der Praxis bekannt sind – viele tausend Einträge.

{
    "meta": {
        "errors": [],
        "warnings": [],
        "query": {},
        "itemsPerPage": 1000,
        "totalItems": 17041,
        "page": 1,
        "replyCode": 200
    },
    "data": [
        {
            "_id": "██████████████████",
            "talk": "MR",
            "title": "",
            "firstname": "OTTO",
            "lastname": "TEST",
            "middlename": "",
            "nameaffix": "",
            "patientNo": "999999",
            "importId": "1",
            "gender": "MALE",
            "kbvDob": "13.09.1936",
            "dob": "1936-09-13T10:00:00.000Z",
            "dob_DD": "13",
            "dob_MM": "09",
            "primaryDoc": "██████████████",
            "accounts": [],
            "affiliates": [],
            "addresses": [
                {
                    "street": "Am Baum",
                    "houseno": "34",
                    "zip": "12345",
                    "city": "Berlin",
                    "country": "Deutschland",
                    "countryCode": "0",
                    "addon": "Test Hallo"
                }
            ],
            "images": [],
            "insuranceStatus": [
                {
                    ...
                    "insuranceNo": "█████████",
                    "insuranceId": "104940005",
                    "insuranceName": "BARMER"
                    ...
                }
            ],
            "isDeceased": false,
            ...
        },
        ...
    ]
}

In der Liste steht zu den Patient*innen:

• Name
• Adresse
• Geburtsdatum
• Versicherungsstatus (mit Versicherung, Versicherungsnummer, …)
• Telefonnummer
• E-Mail-Adresse
• teilweise verordnete Medikamente

Nach dem gleichen Schema wie document und patient gibt es noch eine Reihe weiterer Datensätze, die wir abrufen können. Dazu gehören

• Rechnungen, die die Praxis ausgestellt hat
• Alle “Aktivitäten” (der Sammelbegriff für Einträge in der Patient*innen-Akte)
  • Hier stehen auch Diagnosen, Überweisungen zu anderen Ärzt*innen
• Zertifikate für die Kommunikation mit dem TI-Konnektor (für die Abrechnung mit den Krankenkassen)

Außerdem finden wir dort das sogennante “Audit-Log”, eine Aufzeichnung aller Aktionen, die in der Software durchgeführt wurden.

\o/ der Dienst hat ein Auditlog

/o\ unsere Requests tauchen nicht darin auf

Diese Aufzeichnung hätte ein nützliches Werkzeug sein können, um nachzuvollziehen, ob die von uns gefundenen Sicherheitslücken bereits vorher entdeckt und ausgenutzt wurden.

Allerdings nützt das in diesem Fall vermutlich sowieso nichts – denn höchstwahrscheinlich können wir die Datensätze nicht nur auslesen, sondern auch verändern. Damit hätte ein*e Angreifer*in also auch ihre Spuren in diesem Audit-Log hinter sich wieder verwischen können.

Wie wir später herausgefunden haben, können wir über den Blindproxy auch beliebige andere Aktionen ausführen, die eigentlich nur die Administrator*innen ausführen können sollten.³

Woran das lag? Der Blindproxy scheint allen Anfragen beim Durchleiten noch volle Zugriffsrechte zu geben. So gibt es einen Endpunkt namens whoami (“wer bin ich?”). Ohne den Blindproxy sagt der Endpunkt uns, als welche*r Nutzer*in wir gerade angemeldet sind. Aber wenn wir unsere Anfrage durch den Blindproxy schicken, antwortet er so:

{
        "meta": {
                "errors": [],
                "warnings": [],
                "query": null,
                "itemsPerPage": null,
                "page": null,
                "replyCode": 200
        },
        "data": {
                "id": "su",
                "identityId": "000",
                "name": "",
                "ip": ""
        }
}

su ist der Superuser, also gewöhnlich der Account, der alles darf. Was wir damit auf den Praxisservern verändern können, probieren wir aber lieber nicht aus.

Bisher können wir schon persönlichste Dokumente von tausenden Personen abrufen – allerdings alle aus einer Praxis. Das ist zwar schlimm genug, aber DocCirrus wird ja in mehr als einer Praxis eingesetzt.

Also ist für uns der nächste Schritt zu schauen, ob wir auch andere Praxen erreichen können. Doch damit uns der Blindproxy mit einer Praxis sprechen lässt, müssen wir in dieser registriert sein. Dafür gibt es auch eine API-Methode, mit dem wir unseren Account in einer neuen Praxis registrieren können.

Dafür brauchen wir allerdings die interne Nummer der Praxis. Um an diese zu kommen, gibt es verschiedene Optionen.

Wenn euch die Details interessieren, könnt ihr sie hier Ausklappen

[...Array(10_000).keys()].forEach(x => 
  Y.doccirrus.jsonrpc.api.patientreg.updatePatient({ data: { customerId: x } })
)

Y = await (new Promise((resolve, reject) => YUI().use(['JsonRpc'], resolve)));
patientregs = await Y.doccirrus.jsonrpc.api.patientreg.read({"itemsPerPage": 100000})

Y.doccirrus.jsonrpc.api.patientreg.read({ "itemsPerPage": 100000 }).then((data) => {
  const pracIds = data.data.map(x => x.customerIdPrac).filter((v, i, a) => a.indexOf(v) === i);
  pracIds.forEach(x => Y.doccirrus.jsonrpc.api.patientreg.updatePatient({ data: { customerId: x } }))
})

Doch egal wie wir es im Detail machen: Wir sind nun in allen Praxen registriert. Das heißt auch: Wir können in allen Praxen die Daten aller Patient*innen abrufen.

Das haben wir natürlich nicht getan – sondern uns für jede Praxis nur angeschaut, wie viele Patient*innen dort im System registriert sind.

ohhhhh fuuuuuuck, ich habe gerade mal die anzahl der patient*innen zusammengezählt

das sind mehr als 1.750.000

„Und jetzt? Richtig. Abschalten!“

Nachdem wir all diese Lücken gefunden haben, war es 6 Uhr morgens. Sobald wir ausgeschlafen hatten, haben wir die Details zu den Lücken wie immer schnell und sauber aufgeschrieben – diesmal mit noch etwas mehr Zeitdruck als sonst – und am selben Tag noch an den Hersteller, die Berliner Landesdatenschutzbeauftragte sowie das CERTBund beim BSI geschickt.

Was dann passierte, hatten wir bisher nicht erlebt: Das Unternehmen hat das System erstmal abgeschaltet. Bei der Schwere der Sicherheitslücken fanden wir das aber auch angebracht.

Und auch sonst hat sich der Hersteller erstmal gut verhalten: Er hat sich von sich aus bei uns gemeldet, die Lücken bestätigt und angekündigt, die Betroffenen darüber zu informieren, welche Daten abgeflossen sind und welche weiteren Maßnahmen getroffen werden sollen.

Anfang gut, Ende mangelhaft

Wir hatten den Eindruck, dass das Unternehmen wirklich betroffen ist und versucht, sowohl weiteren Schaden zu verhindern als auch den bereits entstandenen einzudämmen.

Nur leider passierte dann nicht mehr viel. Bis heute ist uns nicht bekannt, ob Patient*innen über die Sicherheitslücke und die abgeflossenen Daten informiert wurden. Die Patient*innen, die wir kennen, wurden es auf jeden Fall nicht. Eine der betroffenen Praxen schrieb online, dass das Portal “aufgrund eines Sicherheitsupdates zur Einführung des eRezeptes” nicht zur Verfügung stehe.

Auch scheint das Unternehmen die Lücken unter den Teppich kehren zu wollen. Auf der Website findet sich zu dem Thema bisher nur eine, etwas verstecke Pressemitteilung, aus der die Schwere der Lücken nicht klar hervorgeht.

Forderungen

Die Daten, von denen wir in diesem Artikel reden, sind mal wieder Gesundheitsdaten und damit sehr sensible Daten und zurecht in der DSGVO besonders geschützt⁴. Hierfür vermissen wir bei DocCirrus - aber auch bei anderen Herstellern von Gesundheitssoftware - das nötige Bewusstsein.

Die hier beschriebenen Fehlerquellen gehören zu den offensichtlichsten⁵. Fehler wie diese dürfen eigentlich nicht passieren und zeigen krasse Defizite in den Entwicklungs-Prozessen im Unternehmen auf. Da helfen auch ganz viele Zertifizierungen nicht – von denen das Unternehmen gleich eine ganze Reihe besitzt: ISO9001, ISO27001 und ganz viele verschiedene von der KBV. Doch bei keiner dieser Zertifizierungen wurde das Produkt tatsächlich kritisch überprüft.

Wir fordern daher:

1. Das Unternehmen bzw. die Praxen müssen alle Patient*innen über diese Lücke, die gefährdeten Daten und die damit verbundenen Risiken informieren.
2. Die Datenschutzbehörde muss gegen das Unternehmen vorgehen und empfindliche Strafen verhängen – nach der DSGVO sind hier bis zu 20 Millionen möglich.⁶
3. Datenschutz und insbesondere IT-Sicherheit muss bei Softwareherstellern ganz oben auf die Prioritätenliste. Und so gilt mal wieder: Wenn ein Produkt marktreif genug ist, um persönliche Daten zu speichern muss es auch reif genug sein, diese für sich zu behalten.

• 2022-06-26: Fund der Lücken
• 2022-06-27: Report an Hersteller, Landesdatenschutzbeauftragte und CERTBund beim BSI
• 2022-06-28: Abschaltung des Portals durch den Hersteller
• 2022-07-25: Portal teilweise wieder online; Lücken laut Hersteller behoben
• 2022-08-11: Veröffentlichung

Diese Recherche veröffentlichen wir exklusiv zusammen mit dem NDR und dem WDR, die nochmal einen genaueren Blick auf die Zertifikate geworfen haben. Deren Berichterstattung findet ihr hier:

• Tagesschau.de: Unsichere Praxissoftware - Patientendaten ungeschützt um Netz
• ARD Mittagsmagazin - Sicherheitslücken bei Praxissoftware