Megahack Equifax' war "absolut vermeidbar"
Seite 2: Multiples Versagen Equifax'
Als Einfallstor diente den Hackern im Mai 2017 eine damals seit mehr als zwei Monaten bekannte und bereits fixbare Sicherheitslücke: Am 8. März 2017 hatte das US-CERT (Computer Emergency Readiness Team) Equifax offiziell über eine Sicherheitslücke in der Middleware Apache Struts informiert. Die Warnung wurde Equifax-intern an mehr als 430 Personen und diverse E-Mail-Verteiler weitergeleitet, mit der Anweisung, den verfügbaren Patch binnen 48 Stunden einzuspielen. Verschiedentlich geschah das auch, aber leider nicht auf allen Systemen.
Equifax scannte zudem auf den eigenen Systemen nach unsicheren Struts-Versionen, fand aber nichts. Der Fehler war so banal wie peinlich: Es wurde nur das Root-Verzeichnis durchsucht, nicht aber Unterverzeichnisse.
Zweimal gehackt
Schon am 10. März gab es die ersten Eindringlinge in betroffene IT-Systeme. Equifax bemerkte das aber zunächst nicht, und hängte es auch später nicht an die große Glocke. Ein direkter Zusammenhang mit dem Megahack vom Mai ist nicht erwiesen. Diese Täter kamen am 13. Mai und blieben bis Ende Juli unentdeckt.
Sie hatten eine nicht gepatchte Struts-Version auf jenen Equifax-Servern gefunden, die das "Automated Consumer Interview System" betreiben. Darüber dürfen Kunden sie betreffende Fehler in Equifax Datenbanken monieren. ACIS wurde seit den 1970er-Jahren intern entwickelt und lief auf "komplexen Legacy-Systemen". Die Server stammten noch von Sun Microsystems (heute ein Teil Oracles) und arbeiteten mit dem Betriebssystem Solaris. In "drei bis fünf Jahren" hätte ACIS auf moderne Server umgesiedelt werden sollen.
Die Hacker warteten aber nicht zu und installierten im Mai dreißig verschiedene Webshells, die ihnen fortan als Hintertür dienten. Da Equifax keine Datei-Integritäts-Überwachung laufen hatte, blieben die Webshells unentdeckt.
Passwörter im Klartext
Der Ignoranz nicht genug, Equifax hatte sogar Benutzernamen und Passwörter unverschlüsselt auf einem Netzwerkspeicher abgelegt. Und natürlich fiel dieser Schatz den Hackern in die Hände. Denn Equifax beging einen weiteren Kardinalfehler: Obwohl ACIS nur Zugriff auf drei Datenbanken benötigte, gab es keine Einschränkungen beim Zugriff auf andere Ressourcen.
(Bild: Equifax (Faksimile))
Dadurch bekamen die Hacker Usernamen und Passwörter, sowie Zugriff auf 48 weitere Datenbanken, die mit dem ursprünglich gehackten ACIS nichts zu tun hatten. Ungestört konnten die Angreifer zirka 9.000 Datenbankanfragen durchführen. 265 davon lieferten personenbezogene Daten zurück.
Wertvolle Daten unverschlĂĽsselt gespeichert
Eine Verschlüsselung dieser extrem wertvollen Daten – erraten – gab es nicht.
Die Hacker waren nicht müde, den Datenschatz herunterzuladen. Dieser Datenverkehr sollte eigentlich sofort auffallen, wachen doch Intrusion Detection Systeme über ausgehenden Traffic. Eigentlich. Wenn sie den Datenverkehr mitlesen können.
Auch dafür gibt es bei Equifax ein System, eine so genannte SSL Visibility Appliance. Sie entschlüsselt den Datenstrom und serviert ihn der Intrusion Detection, damit diese gegebenenfalls Alarm schlagen kann. Nur muss die SSL Visibility Appliance auch die passenden SSL-Zertifikate haben, um den Traffic entschlüsseln zu können.
Abgelaufene Zertifikate
Diese Zertifikate waren aber bereits Anfang 2016 abgelaufen und wurden 19 Monate (neunzehn) lang nicht erneuert. Durch dieses Versäumnis legte Equifax seine eigene Intrusion Detection lahm. 76 Tage lang konnten sich die Täter so bei Equifax umsehen und an den Datenbanken bedienen.
Erst am Abend des 29. Juli 2017 wurden 67 von über 300 abgelaufenen SSL-Zertifikaten ausgetauscht; sogleich schlug die Intrusion Detection Alarm, wurden doch gerade Daten an eine verdächtige chinesische IP-Adresse übertragen. Die Equifax-Mitarbeiter sperrten zunächst dem chinesischen ISP, der diese IP-Adresse vergeben hatte, den Zugriff.