Mehr zu den Ausfällen der Zahlungsterminals und der Infrastrukturkatastrophe IT

Endlich etwas Licht im Dunkel.

Ein Leser hat mir einen Link auf den Artikel von Golem.de geschickt, die das mal etwas recherchiert haben.

Ich lag da wohl richtig mit der Einschätzung, dass die Annahme, ein Krypto-Zertifikat sei unbemerkt abgelaufen, zu kurz gegriffen ist.

Im Rückblick kristallisierte sich schnell heraus, dass Verifone H5000 Girokarten-Terminals die Ursache für diese Großstörung sind. […]

Bei der Recherche stellte sich heraus, dass das Verifone H5000 Kartenterminal Ende 2011/Anfang 2012 erstmals im deutschen Handel zum Einsatz kam. Vom Hersteller selbst wurde das Kartenlesegerät bereits 2019 abgekündigt. Dem Autor dieses Artikels bestätigten verschiedene Quellen, mehrfach von Dienstleistern informiert worden zu sein, dass das Gerät auszutauschen sei.

Der Hintergrund ist, dass der vom Verifone H5000 unterstützte Standard PCI 3 (Payment Card Industry Data Security) zum 30. April 2021 ausgelaufen ist und die Geräte im Bestand nur noch aufgrund einer Übergangsregelung in Deutschland verwendet werden dürfen (PDF).

Das End-of-Service-Datum wurde auf April 2023 festgelegt, in ganz wenigen Sonderfällen ist im Rahmen eines Extended Support der Einsatz bis Anfang 2025 zulässig. Unter dem Strich heißt dies, dass der Typ dieses Zahlungsterminals längst ausgemustert sein sollte, was aber manche Ketten nicht davon abhielt, die Kartenlesegeräte weiter in neuen Läden einzusetzen.

Aufgrund des am 30. April 2021 ausgelaufenen PCI 3-Standards stellte der Gerätehersteller ein Update bereit, welches die weiter in Benutzung befindlichen Geräte für die genannten Übergangsfristen ertüchtigen sollte. Nach Informationen von Golem.de sollte dieses Firmware-Update für das Verifone H5000 Kartenterminal zum 25. Dezember 2021 auf alle Geräte ausgerollt werden. Viele Geräte erhielten genau dieses Update jedoch nicht, so dass es am 24. Mai 2022 zum großflächigen Ausfall kam.

Ungeklärt ist, ob die fehlende Update-Installation ein Versäumnis des Herstellers, der Dienstleister, die die Terminals bei Kunden bereitstellen, oder der Kunden selbst ist. Auffällig ist allerdings, dass die IT großer Handelsketten wie DM, Kik, Aldi-Nord etc. dieses Thema “nicht auf dem Radar hatten” und die Update-Installation versäumten.

Sie verweisen außerdem auf die Blogartikel, die ich schon zitiert hatte.

Zwar kommt in diesem ganzen Kuddelmuddel wohl irgendwo auch tatsächlich irgendein Zertifikatsproblem vor, das Gesamtproblem ist aber deutlich komplexer.

Versteht mich nicht falsch: Es ist völlig richtig, bei einem solchen Fehlerbild zuerst ein abgelaufenes Zertifikat im Verdacht zu haben und zuerst darauf zu prüfen, weil es der häufigste Fehler ist, der zu einem solchen Fehlerbild führt. Es ist aber falsch, diesen Fehler anzunehmen und als Ursache zu unterstellen, bevor man es nicht positiv überprüft hat, dass a) dieser Fehler überhaupt vorliegt und er b) alleinkausal war, mit dessen Behebung also das Fehlerbild verschwindet. In so einem Fall zu sagen „prüft zuerst mal das Zertifikat“ ist also richtig. Es aber anzunehmen, dass das die Ursache ist, bevor man es verifiziert hat, das ist so provinzadminmäßig.

Man muss sich klar machen, welche Auswirkungen dieser Denkfehler hat. Das Problem eines abgelaufenen Zertifikats kann man normalerweise auch am Tag vor dem Ablauf noch korrigieren, ohne dass es zu einem Ausfall kommt, weil der Arbeitsaufwand normalerweise klein oder zumindest überschaubar ist (wenn man seine Systeme sonst im Griff hat). Das hier scheint aber ein Problem zu sein, was man einen Tag, eine Woche, einen Monat vor deadend nicht mehr hätte in den Griff bekommen können.

Da haben wirklich die IT-Abteilungen gepennt und geschlampt.

Und das ist ein Versagen, was ich aus der Praxis kenne, dass man da eben immer so vor sich hinbruddelt, läuft doch alles, und keinen Katastrophenplan, keine disaster recovery hat. Auch als Havarieplan bekannt.

Und dazu gehört elementar, dass man sich für seine gesamte IT (und die Daten) mal überlegt und das dokumentiert, was wie lange ausfallen kann, bevor es weh tut. Schmerz normalerweise in Stufen wie „Portokasse“, „Nehmen wir in Kauf“, „Schmerzt sehr“, „Köpfe rollen“, „Gefährdet Aktienkurs“, „Gefährdet Unternehmensbestand“ eingeteilt. Es gibt Unternehmen, die da jedes erdenkliche Risiko allein danach beurteilen, was der finanzielle Schaden ist, der eintreten kann, und das gegen die Kosten der Gegenmaßnahme abwägen.

Freilich kann man in Kauf nehmen, dass man dann halt mal eine Woche lang nichts verkauft und blöd in der Zeitung steht. Es gibt Firmen, denen ist sowas egal. Kann man machen. Dazu muss man es aber erst wissen und sich bewusst entscheiden, das Risiko einzugehen. Wenn Tante Erna selbstgehäkelte Topflappen auf dem Bauernhof verkauft, ist das sicherlich vertretbar, ihr Billig-Kartenzahlungsgerät einfach zu benutzen, bis es nicht mehr geht, und sich ansonsten um nichts zu kümmern, und dann halt irgendwann ein Neues zu kaufen, wenn man eines braucht. Einen Friseur kann ein Zahlungsausfall von zwei Tagen schon in den Ruin stürzen.

Gerade dann, wenn man aber eine Supermarktkette betreibt, wo es nicht nur um richtig viel Geld geht, sondern auch um die Elementarversorgung der Bevölkerung, sollte man aber sehr genau wissen, welche IT-Systeme wie lange ausfallen können, bevor sie den Geschäftsbetrieb gefährden, und entsprechende Kenntnis, Vorsorgepläne, Wartungspläne haben.

Deshalb ist das auch völlig egal, ob in dem Ausfall nun noch ein Zertifikatsproblem mit drin war oder nicht. Das Problem ist, dass die IT-Abteilungen ihre Arbeit nicht gemacht und geschlampt haben. An welchem Detail sich das dann konkret zuerst ausgewirkt hat, ist nachrangig.

Und wenn man dann schwadroniert, dass das Problem ein abgelaufenes Zertifikat sei – und zwar egal, ob es nun technisch stimmt oder nicht – dann ist man Teil des Problems und nicht der Lösung. Weil man nur ein Detail unter dem Mikroskop betrachtet und nicht das ganze Problem. Als ob man bei einem total geschrotteten Unfallwagen sagt, der müsse noch zum TÜV, weil man nur auf das Kennzeichen guckt und sieht, dass der TÜV gerade abgelaufen ist, aber nicht merkt, dass das ganze Auto einen Unfall hatte.

Ich habe das als ISO (Information Security Officer) meist so gehalten, dass a) jedes System registriert und katalogisiert sein muss, b) einen Verantwortlichen haben muss, der regelmäßig überprüft wird, noch real und keine Karteileiche zu sein, und der c) Aussage dazu treffen und dokumentiert festlegen muss, wie lang das System vertretbar ausfallen kann und von welchen anderen Systemen es abhängt.

Und da kann man zu erstaunlichen Ergebnisse kommen.

Ich habe es mal miterlebt, wie die gesamte wichtige IT eines Unternehmens per Fingerschnipp ausgefallen ist. Ich war zur Überwachung dabei, wie eine externe Firma mit einer Sicherheitsunterschung anfing, mit der man sie beauftragt hatte. Die schlossen also ihren Rechner an das Firmennetz an, fingen mit der Untersuchung an – und nichts ging mehr. Aus allen Zimmern kamen die Mitarbeiter und Admins angerannt und schrien Alarm, weil nichts mehr gehe, und sie sich nirgendwo mehr einloggen könnten. Auf keinen einzigen Server kämen sie noch per ssh rein. Die Webserver antworteten auch nicht mehr.

Die Mitarbeiter der externen Firma beteuerten aber, dass sie mit den Angriffstests noch gar nicht angefangen hätten und auch nicht wüssten, was dafür ursächlich sein könnte.

Wir haben das dann sofort abgebrochen, das Netz beruhigte sich auch wieder, keiner wusste, was passiert war und warum, und ich habe das dann untersucht und Schritt für Schritt nachvollzogen.

Die externe Firma hatte mit ihrer Sicherheitsuntersuchung begonnen, einen sehr leistungsfähigen Notebookrechner mit schnellem Prozessor angeschlossen, und zunächst mal einen „Portscan“ (mit einem Tool ähnlich wie nmap) begonnen. Nun war die Firewall so konfiguriert, dass sie einen großen Teil des Netzes (10.x.*.*) komplett mit reject statt port unreachable blockte. Oder umgekehrt, genau weiß ich es nicht mehr. Ist etwa 15 Jahre her. Das heißt, dass der Rechner, der den scan ausführte, nicht auf irgendwelche Timeouts warten musste, sondern über den gesamten Netzbereich sofort sah, dass da ganz viele Ports „geschlossen“ sind, obwohl da gar kein Rechner war. Und das protokollierte. Der Recher schrieb also in sein Log:

10.x.0.1 Port 1 geschlossen
10.x.0.1 Port 2 geschlossen

und so weiter und so fort, ganz viele. Er schrieb aber noch mehr. Er wollte zu jeder IP-Adresse noch den Hostnamen aufschreiben. also nicht nur beispielsweise 10.5.3.77, sondern auch den Host-Namen dazu.

Und das war fatal. Die Ursache des Totalausfalls war nämlich nicht, wie alle glaubten, der Portscan selbst, sondern dass der Rechner nun für sein Log ganz viele DNS-Anfragen gestellt hatte. Und weil es diese Rechner gar nicht gab, sondern die Firewall über eine Regel deren Antworten nur vorgegaukelt hatte, gab es eben sehr viele Logeinträge in kürzester Zeit. Dazu kam ein Fehler in der Scan-Software. Hat die Software nämlich für „10.5.3.77 Port 1“ keine DNS-Antwort bekommen, weil es den Rechner 10.5.3.77 nicht gab, hat sie sich die negative Antwort nicht gemerkt, sondern für „10.5.3.77 Port 2“ und so weiter immer wieder neu gefragt.

Der Rechner hat also den DNS-Server des Unternehmens mit massiv vielen DNS-Anfragen bombardiert. Der war nun auch noch falsch konfiguriert, und hat alle Fragen, die er nicht beantworten konnte, raus in die Welt weitergeleitet. Während die Portscans selbst völlig harmlos waren, hat die Protokollierung der Portscans den DNS-Server in die Knie gezwungen.

Und was die Admins nicht begriffen hatten: Alle Probleme, die sie beobachtet hatten, waren DNS-Probleme. Dazu kamen enorme Wissenslücken der Admins und Entwickler. Die hatten nämlich nicht begriffen, dass ihre Dienste wie ssh-Server oder Webserver bei jedem Kontakt eine DNS-Anfrage für ihr eigenes Log erstellen. Normalerweise schaltet man sowas aus, um diese Abhängigkeit zu beseitigen. Das wussten sie aber mangels Sachkunde nicht und haben das weder abgeschaltet, noch überhaupt begriffen.

Als der Angriff lief, hatte ich gleich so einen Verdacht und auch gleich gemerkt, dass die sich nicht auskannten. Als die Admins nämlich sagten, sie könnten sich nicht einloggen, habe ich erst mal die Standard-Frage an Laien gestellt, was das überhaupt heiße. Ob die Rechner überhaupt eingeschaltet seien und Strom hätten. Ob sie eine Fehlermeldung bekämen. Oder wie sich „Es geht nicht“ überhaupt manifestiere.
Antwort: Ja, es passiert nichts. Frage: Wie lange habt Ihr es denn probiert? Antwort: Ja, es geht halt nicht. Normalerweise geht es sofort, und jetzt geht es halt nicht.

Also hatte ich allen, die sich beschwerten, auch damit die was zu tun haben und beschäftigt sind, die Aufgabe gegeben, es noch einmal zu versuchen und dabei eine Stoppuhr mitlaufen zu lassen. Ich würde erwarten, dass sie nach exakt 60 Sekunden Schlafpause dann eingeloggt wären. Verblüfft kamen sie wieder: Ja, ja, tatsächlich, exakt 60 Sekunden. Woher ich das gewusst hätte.

Das ist der Timeout für eine DNS-Anfrage. Die Leute wussten einfach nicht, dass viele Server wie ssh-Daemon oder Webserver in ihrer Standardeinstellung für jeden Kontakt einen Logeintrag erstellen und dazu normalerweise den DNS-Server anfragen, wie der Rechner, von dem der Request kommt, heißt. Und wenn der DNS-Server nicht antwortet, weil er gerade überlastet ist, läuft das eben in den Timeout, bis der Rechner, der anfragt, aufgibt. Und der ist normalerweise auf 60 Sekunden eingestellt. Also war sofort klar, dass es ein DNS-Problem ist und nicht der – gefühlte – Ausfall des ganzen Rechenzentrums.

Zog eine Schulung nach sich, um den Leuten mal klarzumachen, wie und von was ihre Rechner abhängig sind, und wie man sie konfiguriert, dass sie es nicht mehr sind.

Aber alle, ausnahmslos alle, hatten sie auf den Portscan und die externe Firma geschimpft, weil sie sahen, dass die da mit Scans anfangen und dann einfach alles stehen blieb. Tatsächlich aber konnte man durch einen so banalen Vorgang, für den man nicht einmal einen Account, ein Passwort, eine Sicherheitslücke brauchte, das ganze Rechenzentrum in die Knie zwingen und die Admins in Panik versetzen, aus der sie sich selbst nicht mehr zu helfen wussten.

Und dazu gehört dann eben auch ein Wiederanlaufplan, in dem nach einem Totalausfall das tote Rechenzentrum (in der Luftfahrt gibt es für ein völlig ausgeschaltetes Flugzeug die so schöne Bezeichnung „cold and dark“, um zu bezeichnen, dass man es jetzt von ganz tot aus in den flugbereiten Zustand bringt). Was wird in welcher Reihenfolge eingeschaltet und auf Funktion geprüft?

Oftmals findet man dabei heraus, dass Systeme im Laufe der Zeit so verstrickt sind, dass das keiner mehr weiß oder sogar Zyklen (Henne-Ei-Probleme) in den Abhängigkeiten auftreten und man keine eindeutige Reihenfolge mehr bilden kann.

Viele wissen nicht einmal, wie sie ihren Kram noch eingeschaltet bekommen. Ich hatte mal mit einem Rechenzentrum zu tun, in dem tausende von virtuellen Maschinen liefen, deren Abhängigkeiten kein Mensch mehr benennen konnte. Das Rechenzentrum aus „stromlos“ hochzufahren dauerte Stunden, mehr als einen Arbeitstag, und selbst dann konnte man nicht sagen, ob jetzt alles sauber läuft und sich berappelt hat. Ob man so eine Anlaufzeit auch aushalten und ertragen kann, wusste keiner. Kontrolliertes Anlaufverhalten oder Kenntnis der Abhängigkeiten – Fehlanzeige.

Sowas interessiert heute aber alles nicht mehr. Heute sorgt man sich um Diversität und Gendersprache, dass sich niemand diskriminiert fühlt. Dass alles „inklusiv“ ist und auch auf den Herrentoiletten Tampons gereicht werden.