Sicherheitszwischenfälle können auch ihre guten Seiten haben: Wenn die Opfer der Angriffe ausführlich über ihre Erfahrungen berichten, lernen Admins etwas. So wie im Fall des Matrix.org-Hacks.

In einem so genannten Post Mortem berichten die Macher des dezentralen Kommunikationsnetzwerks ausführlich über den Einbruch in den Matrix.org Home-Server. Insbesondere für Admins, die eine Infrastruktur schützen müssen, eine interessante Lektüre.

Tatsächlich, und das ist dem Projekt wichtig, basierte der Angriff nicht auf Schwächen im Matrix-Protokoll, sondern auf einer veralteten Infrastruktur mit ungeschütztem Jenkins und schlechten Sicherheitsentscheidungen.

Schnellschuss

Das gehackte Setup stammte demnach vom August 2017 und war Folge eines übereilten Umzugs aufgrund eines auslaufenden Fundings. Den Umzug der 30 Hosts umspannenden Infrastruktur übernahm das Team, das sich gewöhnlich um den Riot-Client und den Synapse-Server kümmert. Ein reguläres Ops-Team sollte später das Setup “härten”, was aber nie passierte.

Das Team traf in der Eile ein paar Entscheidungen, die ihm später auf die Füße fielen: Dazu gehörte zum Beispiel ein unsicher konfiguriertes SSH statt VPN-Zugängen. Das Team verwendete Standard-Debian-Images, die Root-Access per SSH und SSH-Agent-Forwarding erlaubten. Zugleich setzte es auf ein offenes Jenkins, das über das Internet erreichbar war.

Wie so oft, halten Provisorien länger als geplant. Das Matrix-Team erhielt einen Riesenauftrag aus Frankreich und versank über beide Ohren in Arbeit. Ein neues Ops-Team wurde zwar tatsächlich etabliert, aber direkt auf eine dringend benötigte neue Infrastruktur mit Modular.im-Hosts angesetzt. Die sollte die alte Infrastruktur ablösen, letztere existierte aber weiter.

Der Angriff

Am 9. April warnte ein Sicherheitsforscher, dass dem verwendeten Jenkins ein Sicherheitsupdate fehlte. Als die Admins die Sache am 10. April anschauten, stellte sich heraus, dass jemand die Lücke über das CVE-2019-1003000 ausgenutzt hatte, um auf einem Jenkins-Slave einen eigenen SSH-Key zu installieren. Dank der schlechten SSH-Voreinstellungen (SSH-Agent-Forwarding) gelangte der Angreifer dann auf die anderen Hosts. Details liefert der Blogpost.

Das Matrix-Team tauschte daraufhin die Schlüssel aus, isolierte alte Hosts und setzte neue Hosts mit neuen Secrets auf. Am 11. April wurde schließlich die Nachricht zum Security-Zwischenfall veröffentlicht. doch die Angreifer gaben noch nicht auf. Aufgrund eines falsch ausgetauschten Cloudflare-API-Keys konnten sie noch ein Defacement der Webseite starten, indem sie den DNS-Eintrag von Cloudflare auf eine Github-Seite umleiteten. Auch dieses Problem ließ sich recht schnell beheben, indem das Team den tatsächlich Cloudflare-Admin-API-Key änderte.

Auf die harte Tour

Mittlerweile steht die Infrastruktur von Matrix.org wieder auf festen Füßen, mit einigen zentralen Änderungen. So ist der SSH-Zugang stark eingeschränkt, mit 2FA abgesichert und Ansible verwaltet Secrets in einem verschlüsselten Vault. Buildkite ersetzt Jenkins und anstelle von WordPress verwenden die Projektmitarbeiter nun eine statische Webseite. Gitlab löst Cgit ab, zudem gibt es eine neue und neu abgesicherte Paketinfrastruktur.

Der Blogpost fasst am Ende vorbildlich die aus dem Zwischenfall gelernten Erkenntnisse zusammen, vor allem jene über die Folgen eines falsch konfigurierten SSH. Admins, die unsicher über ihr eigenes SSH-Setup sind, können also künftig von den dort zusammengetragenen Informationen profitieren. Auch um die neue Netzwerk-Infrastruktur haben sich die Admins von Matrix.org Gedanken gemacht. Die finden sich ebenfalls in dem Blogpost wieder neben Überlegungen, wie sich solche Einbrüche in Zukunft abwehren und melden lassen.