Lektionen aus dem “weltweit ersten tödlichen Hackerangriff” auf das Uniklinikum Düsseldorf
Nüchtern analysiert, ist “mehr patchen!” nicht die Antwort.
Es war, als hätten die Menschen nur darauf gewartet, bis sie endlich — und zurecht! — darüber schreiben können, dass ein Mensch unmittelbar aufgrund eines Hackerangriffs gestorben ist.
Das stimmt natürlich, und es ist tragisch.
Auch hat es niemanden, der in der IT-Sicherheit von kritischen Infrastrukturen arbeitet, wirklich überrascht. Trotzdem springen die hastigen Schlüsse, die schadenfroh das Klischee unserer schlecht aufgestellten kritischen Infrastrukturen bestätigen, zu kurz.
Kommen Sie, wir regen uns ab, stecken den erhobenen Zeigefinger wieder ein und analysieren mal, was wir eigentlich wissen.
Es war im September schwierig, daran vorbeizukommen: Das Universitätsklinikum Düsseldorf (kurz UKD), kritische Infrastruktur im Sektor Gesundheit, hatte einen Ransomware-Vorfall. Als Folge konnte eine Frau nicht notfallbehandelt werden und starb nach der um eine Stunde verspäteten Behandlung im 30 km entfernten Wuppertaler Krankenhaus — oder verkürzt in den Schlagzeilen: Tod durch Ransomware. Die Meldung machte als “erstmals Tote durch einen Hackerangriff” weltweit die Runde.
Das UKD ist nur eine halbe Stunde Fahrtzeit von meinem Wohnort entfernt, meine Mutter hat dort studiert, ich habe dort Reiseimpfungen bekommen und Verwandte im Krankenhaus besucht. Man kann also sagen, dass ich die Klinik ein bisschen kenne — aber das ist nicht relevant für diesen Text und es ist nicht der Grund, warum ich in den letzten Wochen genauer hingeschaut habe, wenn es um Meldungen über den Ransomware-Vorfall am UKD ging. Es hätte jedes beliebige Krankenhaus sein können.
Aber das UKD gehört zu den kritischen Infrastrukturen im Sektor Gesundheit (der Schwellenwert liegt bei 30.000 stationären Fällen pro Jahr, die Klinik hat etwa 50.000) und fällt damit unter das IT-Sicherheitsgesetz, was bedeutet, dass sie alle zwei Jahre nachweisen muss, dass sie Security-Maßnahmen gemäß Stand der Technik erfüllt, damit ihre “kritische Dienstleistung” nicht beeinträchtigt wird. Man darf wohl sagen, dass die Notaufnahme zu schließen als Unterbrechung der kritischen Dienstleistung eines Krankenhauses durchgeht.
Um Transparenz zu wahren: Auch wenn ich beruflich in der Security für kritische Infrastrukturen arbeite, war ich in keiner Weise an der Vorfallsbehandlung des UKD beteiligt, und ich habe keinen Deut mehr Einblicke in die IT-Infrastruktur des Krankenhauses als die breite Öffentlichkeit.
Also schauen wir mal, was wir, die breite Öffentlichkeit, über den Vorfall wissen und welche Schlussfolgerungen wir, die sich beruflich IT-Sicherheit für kritische Infrastrukturen beschäftigen, ziehen können — über “mehr patchen!” hinaus. Zu allen dargelegten Fakten sind im Folgenden die Quellen verlinkt.
Was wir wissen
Gemäß einem Bericht des nordrhein-westfälischen Justizministers Peter Biesenbach wurde das UKD in den frühen Morgenstunden des 10. September Opfer eines Ransomware-Angriffs, der etwa 30 Server verschlüsselte. Als Konsequenz meldete sich das Krankenhaus von der Notversorgung ab, sodass Rettungswagen es nicht mehr anfuhren.
Zwei Nächte später, in der Nacht auf den 12. September, wurde eine Frau lebensbedrohlich erkrankt in die Notaufnahme eingewiesen. Da das UKD ja seine Notversorgung abgemeldet hatte, musste sie in ein weiter entferntes Krankenhaus in Düsseldorf gebracht werden und starb aufgrund der Verzögerung der Behandlung — etwa eine Stunde mehr hatte es gedauert.
Nun zu den technischen Details: Das Einfallstor war nach Angaben des Bundesamts für Sicherheit in der Informationstechnik (BSI) die Citrix-VPN-Schwachstelle CVE-2019–19781, auch liebevoll “Shitrix” genannt. Shitrix ist eine Directory-Traversal-Schwachstelle, öffentlich bekannt seit Dezember 2019, Exploit bekannt seit Mitte Januar 2020, Patch verfügbar seit Ende Januar 2020.
Bevor wir nun einstimmen in den Chor der Stimmen, die rufen “Siehste! Sie haben kritische Schwachstellen nicht gepatcht, und das bei Systemen, die im Internet stehen!!”, lassen Sie uns schnell den nächsten Fakt auf den Tisch legen:
Gemäß einer Pressemitteilung der UKD ist die Schwachstelle am selben Tag im Januar gepatcht worden, als das Patch verfügbar war.
Ziemlich vorbildlich, oder? Wie konnte die Schwachstelle dann im September als Einfallstor dienen?
Die Geschichte geht weiter. Zwischen Ende 2019 und Anfang 2020, also in der Zeitspanne zwischen dem Publikwerden von Shitrix und der Verfügbarkeit des Patches, sind Citrix-Systeme systematisch kompromittiert worden, um Hintertüren für den späteren Gebrauch zu installieren — also den Gebrauch auch dann noch, wenn die Shitrix-Schwachstelle gepatcht wäre.
Das BSI hat vor dieser Angriffswelle im Januar gewarnt und dringend empfohlen, den Workaround zu implementieren, den Citrix angeboten hatte. Der Workaround filtert manipulierte HTTP/HTTPS-Anfragen, die für die Ausnutzung der Schwachstelle notwendig sind. Allerdings funktionierte der Workaround gemäß heise.de nur für bestimmte Firmware-Versionen.
In einem auf golem.de veröffentlichten Kommentar Mitte Januar wurde dann Tacheles geredet: Wer jetzt den Workaround noch nicht implementiert habe, könne sicher sein, dass seine Systeme kompromittiert seien. “Jetzt hilft nur noch abschalten und neu aufsetzen”.
Was auch immer das UKD im Januar gemacht hat (wir schauen uns das gleich genauer an) — seine Citrix-Systeme wurden kompromittiert, bevor der Patch installiert wurde, und im September luden die Angreifer dann den Trojaner DoppelPaymer nach, der schlussendlich die Server verschlüsselte.
Was wir lernen können
Mit diesen Fakten im Hinterkopf können wir ein paar Lektionen ableiten, die über das omnipräsente Patch-Mantra hinausgehen.
Lektion 1: Keine Gnade für möglicherweise kompromittierte Systeme
Also, bringen wir das hinter uns: Patchen war nicht das Problem. Das Patch wurde zügig eingespielt.
In diesem Fall war das Problem eher, dass ein potenziell kompromittiertes System nur gepatcht wurde (und auch das ist noch nicht die ganze Wahrheit, aber dazu später).
Also — auch, wenn es weh tut und der Aufwand in den Mühlen des Alltags unverhältnismäßig groß aussieht: Beim kleinsten Verdacht auf kompromittierte Systeme, zum Beispiel weil sie lange mit offener Schwachstelle im Netz standen, ist die komplette Neuinstallation (und dann mit Patch) keine “Geschmackssache”, oder “übertriebene Vorsicht” sondern Mindestmaßnahme.
Natürlich ist all das keine Entschuldigen dafür, dass Citrix eine bekannte kritische Schwachstelle einen Monat lang ungepatcht belassen hat, aber das ist eine andere Geschichte.
Lektion 2: “Security-Experten” können Organisationen nicht um ihre Security-Verantwortung erleichtern
Nun, da wir das geklärt haben, können wir uns dem nächsten Teil der UKD-Pressemitteilung widmen.
Gemäß eigenen Aussagen hat die Klinik bereits im Dezember 2019 gehandelt und die Empfehlungen des BSI befolgt: “Die Empfehlungen des Herstellers der damals fehlerhaften Soft- und Hardwarekomponente wurden durch das UKD in Zusammenarbeit mit darauf spezialisierten Servicefirmen vollständig umgesetzt.”
Wenn wir also diese Aussage in Kombination mit usnerem Hintergrundwissen zu Shitrix kombinieren, bedeutet das, dass der empfohlene Workaround umgesetzt wurde bevor das Patch eingespielt wurde.
Es wird noch besser: “Darüber hinaus hat das UKD zusätzlich zwei Spezialfirmen mit der Überprüfung des Systems beauftragt. Im Ergebnis ergaben diese Untersuchungen zu dieser Sicherheitslücke nach damaligem Kenntnisstand keinen Hinweis auf eine Gefährdung.”
Und dann folgt das letzte Armutszeugnis für die involvierten “Spezialfirmen”: Im Frühsommer 2020 wurde ein Penetrationstest durchgeführt — ohne Ergebnisse, die mit dieser Schwachstelle zu tun haben.
Lassen wir das mal eine Weile sacken. Wenn wir alle Details in der Pressemitteilung so glauben, dann bleibt nicht viel übrig, was uns zu hämischen Kommentaren, Schuldzuweisungen oder zum Lamentieren über verwundbare, ignorante und sich nicht um Security scherende kritische Infrastrukturen berechtigen würde.
Jetzt mal Butter bei die Fische, liebe Security-Kollegen: Wenn ihr mit der Beratung des UKD beauftragt gewesen wärt und sie hätten euch so beschrieben, wie sie mit der Shitrix-Schwachstelle umgegangen sind — hättet ihr darauf bestanden, dass sie noch irgendwas darüber hinaus hätten tun müssen? Ist das wirklich, was wir einen schlechten Security-Zustand nennen würden? Hätte Lektion 1 überhaupt gezogen, das heißt, hättet ihr wirklich immer noch angenommen, dass die Systeme kompromittiert sein könnten und deswegen komplett neu aufgesetzt werden müssen?
Natürlich erzählt die Pressemitteilung nur die öffentliche Version, wir kennen die Details nicht. Wir wissen nicht, ob der Scope des Pentests überhaupt geeignet war, um die Hintertüren zu finden. Wur wissen nicht, ob ein Risiko in dem Security-Report vermerkt wurde, aber eben einfach akzeptiert. Wir wissen nicht, wann der Workaround umgesetzt wurde, und ob in der Pressemitteilung überhaupt dieser Workaround gemeint war.
Aber eines wissen wir sicher: Welche Maßnahmen auch immer das UKD ergriffen hat — sie waren am Ende nicht ausreichend. Die Systeme waren kompromittiert, und keiner der externen Security-Spezialisten hat das UKD darauf aufmerksam gemacht.
“Überprüfungen” (was auch immer das heißt) und ein Penetrationstest wurden durchgeführt. Was, wenn man ehrlich ist, in diesem Fall das falsche Werkzeug war. Es brauchte keinen Ethical Hacker, um die Systeme als kompromittiert anzusehen — eine Person, die die öffentlich verfügbaren Informationen liest, hätte ausgereicht, sei es ein UKD-interner Mitarbeiter oder ein externer Dienstleister. Und wer auch immer sich in Deutschland Security-Spezialist nennt, von dem kann definitiv erwartet werden, dass er golem.de liest — das hätte in diesem Fall vollkommen ausgereicht, keine Dark-Net-Geheimagententechnik notwendig.
Informiert zu bleiben und sorfältiges Security Engineering ist nicht so sexy wie Hacker für einen Pentest zu beauftragen, hätte aber in diesem Fall zum besseren Ergebnis geführt. Es brauchte keine Hacker, um die Hintertür zu finden (die sie auch nicht gefunden haben). Man konnte in den Nachrichten lesen, dass sie wahrscheinlich da war.
Der Pentest war außerdem das falsche Werkzeug, weil es wirklich keinen Unterschied machte, auf welche Art die Systeme kompromittiert waren. Es hätte ausgereicht, anzunehmen, dass sie es waren, und sich an die unsexy Fleißarbeit aus Lektion 1 zu machen: Abreißen und neu machen. Der Penetrationstest hatte nichts gebracht außer einem falschen Gefühl von Sicherheit.
Ich schreibe dies obwohl (eigentlich: weil!) ich selbst ein “Security-Experte” bin, aber das Fazit aus dieser Lektion ist:
Security-Experten können keinen internen IT-Mitarbeiter um seine Verantwortung für die Security seiner Systeme erleichtern. Am Ende wissen nur die internen Mitarbeiter, wie wichtig welche System sind, was an den Systemen bereits durchgeführt wurde und was nicht — und sie sind verantwortlich, wenn die Systeme versagen.
Für Security-Berater bedeutet das: Wir müssen Mitarbeiter in kritischen Infrastrukturen befähigen und nicht von uns abhängig machen. Wir müssen sie in die Security-Denkweise coachen und ihnen nicht mit Hacking-Skills den Kopf verdrehen. Das sollte Ehrensache sein, aber natürlich weiß jeder in der Security-Branche, dass dem nicht so ist.
Lektion 3: Kritische Systeme müssen so IT-unabhängig wie möglich arbeiten können
Auch über den tragischen Todesfall hinaus hat der Ransomware-Angriff Auswirkungen auf die Patientenversorgung.
Direkt am 10. September bat das UKD seine Patienten, ihre Termine nicht wahrzunehmen und verschob alle “planbaren” Behandlungen. In einer heise/dpa-Meldung von Mitte September wird angegeben, dass zeitweise nur noch 10–15 statt wie sonst 70–120 Patienten täglich operiert, die stationäre Patientenzahl schrumpfte auf 550 statt 1000. Daten und Untersuchungsergebnisse konnten nicht mehr elektronisch erfasst werden — eine Rückkehr zu Zettel und Stift, aber “einzelne Geräte wie Röntgen funktionierten”.
Es ist wenig überraschend, dass kein Bericht Details dazu angibt, warum genau die Notversorgung ohne die 30 Server nicht gewährleistet werden konnte.
Es gibt jedoch einen Hinweis in der UKD-Pressemitteilung vom 23. September, als die Notversorgung wieder aufgenommen wurde: “Für die Öffnung der Notfallversorgung war eine der wichtigsten Voraussetzungen, dass der Zugriff auf die bildgebenden Verfahren, wie CT- oder Röntgenaufnahmen, wieder in allen Bereichen möglich ist.”
Ohne sich Spekulationen hinzugeben, kann man es so sagen: Als letzter Rettungsanker hätte der Tod der Frau (und die Einschränkungen für die Versorgung hunderter weiterer Patienten) vermieden werden können, wenn die Notfallversorgung auch ohne die 30 verschlüsselten Server hätte aufrecht erhalten können.
Ich bin kein Krankenhaus-IT-Spezialist und wir haben nicht genug Informationen, um bewerten zu könenn, ob die IT-Netzwerke des Krankenhauses resilient ausgelegt waren, deswegen beschränke ich mich in dieser Lektion auf einen allgemeinen Kommentar: Wenn Systeme kritisch sind, und es gibt wahrscheinlich keine höhere Kritikalitätsstufe als “lebensrettend”, sollte fast jeder Aufwand gerechtfertigt sein, um sie so unabhängig wie möglich arbeiten zu lassen — oder zumindest sicherzustellen, dass sie es im Notfall könnten. Das kann auch bedeuten, dass alternative, IT-unabhängige Prozesse mitgedacht werden, und sie dem Personal auch präsent zu halten.
Lektion 4: Man muss nicht auf der Zielscheibe sein, um Ziel zu werden
Besonders bitter an der ganzen Geschichte: Es gibt Hinweise darauf, dass die Angreifer gar nicht das UKD treffen wollten, oder überhaupt irgendein Krankenhaus, sondern die Düsseldorfer Heinrich-Heine-Universität — zumindest war das Erpresserschreiben an diese gerichtet.
Nachdem die Polizei die Hacker darauf hingewiesen hatte, dass sie ein Krankenhaus getroffen hatten, übermittelten sie ohne Lösegeldzahlung den Key zum Entschlüsseln.
Eine traurige Variation von “es macht einen Security-Angriff nicht besser, wenn du nicht Ziel, sondern nur Kollateralschaden bist”.
Und jetzt?
Mittlerweile nimmt die UKD wieder Notfälle auf — seit dem 23. September, was insgesamt einen Ausfall der Notfallversorgung von 14 Tagen ergibt.
Gegen die Angreifer werden Ermittlungen eingeleitet. Es wird geprüft, ob aufgrund der verstorbenen Frau wegen fahrlässiger Tötung ermittelt werden kann. Wie üblich dürften die Täter wohl unbekannt bleiben, auch wenn es aufgrund der nachgeladenen Schadsoftware DoppelPaymer Spekulationen gibt, dass eine russische Hackergruppe hinter dem Angriff steht.
Die Landesregierung will künftig mehr Geld für IT-Sicherheit in Krankenhäusern zur Verfügung stellen — bislang sind es 2 Mio. Euro jährlich pro Uniklinik.
Hoffen wir, dass das zusätzliche Geld investiert wird, um klinikinternes IT-Personal zu befähigen, Verantwortung für ihre eigenen Systeme zu übernehmen, statt noch mehr externe Experten zu beauftragen, die IT-Verantwortliche in einer Sicherheit wiegen, die nicht gerechtfertigt ist. Externe Experten können ja auch coachen statt predigen.
Dies bringt uns zur letzten Lektion für heute:
