Am 3. Mai wurden Teile unserer Infrastruktur von Freifunk Stuttgart, die Dienste wie das Wiki, die Karte u.a. mehr anbieten, Opfer eines Hacker-Angriffes. Dieser Angriff kam, zum Glück für uns, bei der Umkonfiguration der Firewall durch den Angreifer zum stehen, da die Umkonfiguration fehl schlug und der Angreifer sich selbst aus dem System ausschloss.
Hier finden sich alle Infos zu dem Exploit, welcher auch in Version 1 bei uns genutzt wurde: Salt-Exploit.
Um dem Ideal der Transparenz zu entsprechen können wir aktuell folgende Infos geben. Weitere Updates dazu werden am Ende eingefügt:
Vorwort
Wir verwenden für Teile unserer Infrastruktur ‚salt‚ um eine einheitliche Konfiguration zu ermöglichen. Das ist auf recht niedrigem Niveau einheitlich, aber es sind mindestens alle User-Accounts überall eingerichtet und überall werden die Systemupdates regelmäßig automatisch eingespielt (unattended-upgrades), ausserdem gibt es ein paar Dienste die besser mit Salt integriert sind, z.B. der Reverse Proxy, der mit minimalem Aufwand eine neue Domain mit einer neuen Servicemaschine lernt oder unsere Proxmox-Server, die mit sehr wenig Konfiguration mal eben einen kompletten an unser Namensschema angepassten neuen Gastserver aufsetzen.
Was ist passiert?
Es gibt derzeit zwei Fehler im Salt:
- Authentifizierte User können auf Dinge zugreifen auf die sie eigentlich nicht zugreifen können sollten und haben deshalb root-Rechte auf dem salt-master
- Nicht authentifizierte User werden als authentifizierte User akzeptiert, das macht den 1. Fehler so gefährlich.
In der Folge kann ein Angreifer den salt-master und alle salt-minions steuern. In anderen Worten: die meisten unsere Dienste. Von dem Angriff gibt es mittlerweile mehrere Versionen, wir hatten Glück und wurden gleich von der ersten Version getroffen. Deren Code habe ich mittlerweile auch. Das Ziel war wohl einen Cryptominer laufen zu lassen mit maximal möglicher CPU-Leistung Cryptowährungen zu bekommen. In Version 1 des Angriffs war das alles noch nicht wirklich persistent, nur selinux und apparmor wurden deaktiviert, sowie der nmi-watchdog. Anschliessend wurden bestimmte Prozesse und Dockercontainer gestoppt, die auch CPU brauchen damit der Miner mehr CPU hat. Diese Prozesse liefen bei uns aber gar nicht. Ausserdem hat der Angreifer mittels ‚ufw‘ welche wir nicht verwenden, die Firewall deaktiviert und dann die verbleibenden Regeln mit iptables gelöscht. Unsere Maschinen verwenden Firewall-Code der eine Standardeinstellung von ‚DROP‘ hat, das sollte eigentlich Common Sense sein. Jedenfalls waren danach keine Verbindungen von oder zu den ffs-Hosts mehr erlaubt und so ging der Download des Schadcodes auch schief und der Angriff war zu Ende.
Was haben wir gemacht?
Nach einem längeren Telefonat zwischen zwei Admins von uns haben wir uns entschlossen Zweigleisig zu fahren. Einer bereitet uns einen neuen Salt-Master vor der nicht mehr anfällig ist. Ein anderer hat versucht herauszufinden was genau passiert ist, unter anderem durch den Vergleich der Backups vor und nach dem Angriff. Die Änderungen am System wurden rückgängig gemacht und die salt-minions überall gelöscht. Anschliessend wurden die Systeme wieder hoch gefahren. Salt bleibt noch ein paar Tage aus. Wenn mal ein Fehler in einer Software gefunden wurde ist es nicht so unüblich dass noch weitere hinterher kommen.
Hätten wir den Angriff verhindern können?
Leider nein, nicht mit der realen Installation die wir haben. Wir haben unattended-upgrade am Laufen, welches Systemupdates automatisch macht. Leider in der Konfiguration von uns nur die von Debian kommenden Sicherheitsupdates. Damit werden die von uns für salt verwendeten salt-Repositories nicht berücksichtigt, sondern nur die Debian-Repositories. Debian hat aber das Salt-Paket mit der Priorität ‚mittel‘ zum Zeitpunkt des Angriffs nur auf debian-unstable aktualisiert, wir verwenden debian-stable. Aber selbst wenn die Salt-Repositories von unattended-upgrades berücksichtigt worden wären, wäre das schief gegangen, weil die Repositories hart auf nicht aktualisierte Versionen gezeigt haben. Und da wo das nicht so war, war der Repository-Key ausgetauscht und deshalb kein Update möglich.
Sind Nutzerdaten betroffen?
Nach derzeitigem Stand: nein. Die größte Gefahr besteht für wiki-Zugangsdaten, das läuft aber auf einem LXC und es scheint als wären unsere LXCs vom Angriff übergangen worden. Dass kein lesender Zugriff auf die Nutzerdatenbank satt gefunden hat kann aber nicht vollständig garantiert werden.
7 thoughts to “Angriff auf unsere Infrastruktur”
Toll das ihr das offen kommuniziert, danke dafür.
Leider finde ich es dann etwas verstörend, dass ihr die Schuld auf Flags in den Debian-Paketen schiebt. In den nachfolgenden Sätzen beschreibt ihr dann selbst Dinge die ihr selbst hättet besser machen können, Stichwort Version pinning. 😉
Und mal unter uns: Man stellt zentrale hochkritische Infrastruktur-Komponenten mit Zentralzugang zur gesamten Umgebung NIEMALS ins Internet. 😉
Bitte überdenkt mal eure komplette Infrastruktur und denkt über Verbesserungen wie z.B. ein VPN nach mit dem ihr euren Zugriff auf die Infrastruktur vom Internet trennen könnt.
Meines Wissens ist Freifunk München in Sachen Infrastruktur recht solide aufgestellt. Fragt doch mal dort, wie die das machen. 😉
Ich bin der ursprüngliche Verfasser des Textes und der der da aufgeräumt hat.
Die Infrastruktur ist so wie sie ist weil sie so ist.
Freifunk Stuttgart ist im Gegensatz zu vielen anderen Freifunk Communities sehr dezentral aufgestellt. Es gibt nicht das zentrale Freifunk Stuttgart Infrastruktur Netz und so eines zu erzeugen über ein VPN würde die Vorteile des Salt gerade mal wieder auffressen.
Faktisch machen wir mit salt ein paar Dinge, die allermeisten Dinge aber nicht, schon weil keiner die States schreibt. Und die States die geschrieben sind, sind teilweise eben genau mit so schlechten Dingen wie Version Pinning. Einfach die States von anderen kopieren macht dabei nichts besser weil schlichtweg das Wissen anschließend fehlt was wo warum passiert.
Mir ist das klar dass man Versionen nicht pinnt, wenn man Sicherheitsupdates haben will, aber ich bin nicht alleine und möchte es auch nicht sein. Da muss ich dann leider ab und an mal nicht nur meinen Mist wegräumen sondern auch den von anderen.
Hinterher irgendwo ein ‚NIEMALS‘ schreiben ist ein bisschen arg einfach. Und wenn ‚NIEMALS‘ so ein Konsens wäre, dann würden da jetzt auch nicht ein paar 100 Leute in irgend einem Chat ihre zig tausend über das Internet verstreute Kisten wieder einsammeln. Es gibt immer einen Kontext und eine Risikoabschätzung.
Da Du so auf den Debian-Teil eingehst:
Debian hat ein Security-Team und eine Policy. Pakete haben eine Urgency, wenn die auf critical gesetzt gewesen wäre, wäre schon am 30.04. (Donnerstag) das Paket Richtung buster/security gewandert. So war am Sonntag auch in bullseye noch ein verwundbares Paket. Wir verwenden unglücklicherweise buster, das ist auch heute noch verwundbar und vom 24.05.2019.
Offensichtlich hat das Debian salt Team eine Buildchain aufgebaut die kurzfristig aktuelle Pakete in den normalen Debian Releasezyklus ein bringt. Das ist super. In diesem speziellen Fall hat aber leider keiner gemerkt dass es hier um einen remote Root Exploit geht und da manuell eingegriffen. Das stört mich nicht besonders, das wäre nur eine Möglichkeit gewesen zu verhindern, dass ich das Zeug zusammen räumen musste. Das hab ich auch so geschrieben. Deshalb ist Debian nicht schuld, hätte den Exploit aber verhindern können. Debian bekommt deshalb auch kein Sternchen.
Eine andere Möglichkeit wäre gewesen, den unattended-upgrade Filter vom Normalfall abweichend so zu setzen, dass das salt-Paket vom Salt-Repository aktualisiert wird. Das hätte sogar auf denen geklappt auf denen eine alte Version durch ein hardcoded altes Repository genutzt wird. Das war 2019.2. Dummerweise hat mit den ganzen Automatismen keiner gemerkt, dass da ein Key vom aktuellen apt nicht mehr akzeptiert wird. Deshalb wäre es dann trotzdem schief gegangen. Da ist dann Freifunk Stuttgart schuld. Hätten wir mal nur Leute ran gelassen die wissen was sie tun und genügend Zeit haben um das Wissen auch umzusetzen, hätten wir mal ein Monitoring aufgebaut um den kaputten Key für das Repository zu bemerken, hätten wir einfach auf Salt verzichtet und was genommen wo der Transportweg von etwas mehr Leuten betrachtet wird. Da bekommen wir halt auch kein Sternchen.
Nun sind wir aber alle Menschen die das in ihrer Freizeit machen mit einem eher rudimentären Regelwerk und sehr großer Unabhängigkeit. Wir haben drei voneinander unabhängige Gatewaybetreiber, die die Gateways zwar Interfacekompatibel zueinander bauen, aber doch auf sehr verschiedene Art und Weise. Dazu noch den Verein der auch Betreiber ist und wo sich die Varianten zusammen finden. Mit dem Rest der Infrastruktur ist es ähnlich. Da sind Kisten mit Salt komplett, Kisten mit Salt Basis + Handarbeit, Kisten ohne Salt. Das ist leider der Preis der Freiheit.
Ich bin schwer beeindruckt wie der #Freifunk-Stuttgart hier mit einem Vorfall in der Infrastruktur umgeht:
https://freifunk-stuttgart.de/2020/05/05/angriff-auf-unsere-infrastruktur/
Erstens kann man davon was lernen, zweitens will ich ja definitiv auch so ein Teil und finde das irgendwie motivierend das endlich mal in Angriff zu nehmen 🥰
Ich bin beeindruckt wie der #Freifunk-Stuttgart hier mit einem Vorfall umgeht: freifunk-stuttgart.de/2020/05/05/ang…
1. kann man davon was lernen, 2. will ich ja auch so ein Teil und finde das irgendwie motivierend das endlich mal in Angriff zu nehmen 🥰 (beko.famkos.net/t/TuC)
Ich bin beeindruckt wie der #Freifunk-Stuttgart hier mit einem Vorfall umgeht: https://freifunk-stuttgart.de/2020/05/05/angriff-auf-unsere-infrastruktur/ 1. kann man davon was lernen, 2. will ich ja auch so ein Teil und finde das irgendwie motivierend das endlich mal in Angriff zu nehmen 🥰 (https://beko.famkos.net/t/TuC)
freifunk
Angriff auf unsere Infrastruktur | Freifunk Stuttgart
»Angriff auf unsere Infrastruktur | Freifunk Stuttgart«
freifunk-stuttgart.de/2020/05/05/ang…
„In Angriff nehmen“, soso. Wie passend. 😎