Kompromittierung von aquila.uberspace.de
tl;dr: Wir informieren heute über ein Security-Problem auf unseren Servern, das wir am Mittwoch, dem 08.11.2023 entdeckt haben. Das Problem haben wir gleich am selben Tag behoben. Die direkt betroffenen User haben wir schon einen Tag später am Donnerstag informiert. In diesem Text findet ihr die technischen Details.
Am 8. November wurde einer unserer Server - aquila - routinemäßig automatisiert neu gestartet. Kurz nach dem Reboot war der node_exporter-Service, der bei uns einige Monitoringaufgaben übernimmt bzw. dazu Daten bereitstellt, nicht mehr verfügbar, sodass einer von uns einen Blick auf den Server geworfen hat. Im Log fand sich dazu folgende Meldung:
Nov 08 15:10:11 aquila.uberspace.de sh[3327]: /bin/sh: /home/XXX/up.sh: No such file or directory
Die zugehörige systemd-Konfigurationsdatei sah so aus:
[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/node_exporter
ExecStart=/usr/bin/node_exporter $NODE_EXPORTER_OPTS
ExecStartPre=/bin/sh /home/XXX/up.sh
Restart=always
Bevor also wie vorgesehen das node_exporter-Binary gestartet wird, soll zuerst das Script “up.sh” aus einem User-Account XXX ausgeführt werden. Beides mit vollem root-Zugriff. Ihr könnt euch vorstellen, dass das nicht unserer Standard-Config entspricht. Dementsprechend ist unser Puls in die Höhe gegangen.
Was genau das Script “up.sh” ausgeführt hat, können wir nicht mehr sagen. Der betreffende User-Account wurde am 28.05. erstellt und schon am 04.07. wegen Geldmangels automatisiert deaktiviert und am 02.09. gelöscht.
Nun sollte ja niemand außer uns Schreibrechte für globale Konfigurationsdateien haben. Wie ist diese Zeile in die Datei gekommen? Zunächst hatten wir eher komplexe Szenarien wie einen unberechtigten Zugriff auf den systemd-Socket im Kopf. Die Lösung war jedoch ganz einfach:
-rw-rw-rw-. 1 root root 352 Jun 2 09:56 /usr/lib/systemd/system/node_exporter.service
Alle Accounts hatten Lese- und Schreibrechte auf diese Datei. So durfte dann auch jeder beliebige Uberspace-Account in die Datei schreiben und so - über Umwege aber doch - beliebige Skripte oder Programme ausführen.
Damit das auch wirklich klappt, muss zunächst ein systemctl daemon-reload ausgeführt werden, um die neue Konfiguration zu laden, gefolgt von einem systemctl restart node_exporter, um die Datei auszuführen. Alternativ tut es auch ein Reboot, der quasi beides auf einmal erledigt.
Für aquila konkret gab es im relevanten Zeitraum keine Reboots. Ob ein daemon-reload + Service-Restart gelaufen ist, können wir anhand der Logs nicht mehr nachvollziehen.
Wie kam es aber zu diesen Datei-Rechten? Das Paket node_exporter kommt aus unserer Feder. Gebaut wird es in einer GitLab-CI ungefähr so:
mv node_exporter.service /usr/lib/systemd/systemmv node_exporter.sysconfig /etc/sysconfig/node_exporterfpm (...) --config-files /etc/sysconfig/node_exporter /usr/bin/node_exporter /usr/lib/systemd/system/node_exporter.service /etc/sysconfig/node_exporter
Es werden also die node_exporter.service und weitere Dateien an die richtigen Stellen kopiert und anschließend mit fpm in ein RPM verwandelt. Dabei behält fpm, entgegen unserer Annahmen, die Dateirechte einfach bei und nimmt nicht etwa die des Parent-Verzeichnisses. Gitlab vergibt für Dateien aus Repos in der CI 777 als Rechtebündel und so haben wir den Salat: Die großzügigen Rechte aus der CI sind dann auch gleich die auf den Hosts.
Wir haben das Problem gleich nach Bekanntwerden am Donnerstag am Paket vorbei gefixt. Anschließend haben wir einen nachhaltigen Fix in das node_exporter-Paket sowie zwei weitere Pakete eingebaut. Bei den anderen beiden Paketen war die Lücke jedoch nicht in der Form ausnutzbar. Zusätzlich haben wir alle Dateien auf den produktiven Hosts auf globale Schreibrechte geprüft und dabei nichts Relevantes gefunden.
Inzwischen haben wir in unsere Prozesse zum Paketbau einen Test integriert, der die Gitlab Pipeline bei falschen Berechtigungen auf entsprechende Dateien abbricht und somit dieses Paket nicht veröffentlicht. Außerdem werden wir mit zusätzlicher Software auf den Hosts falsche Berechtigungen und Änderungen an Dateien, wie bei diesem Vorfall passiert, monitoren und daraus entsprechende Alerts generieren.
Wir bitten um Entschuldigung für den Fehler. Es handelt sich dabei um ein Standard-Thema, das eigentlich nicht auftreten darf. Mit den Gegenmaßnahmen können wir uns jedoch sicher sein, dass es kein zweites Mal vorkommt.
Update 16.11.: Während unserer Recherchen haben wir auch eine manipulierte Datei auf dem Host canopus.uberspace.de entdeckt, da diese aber zu einem inaktiven Service gehörte konnte dies nicht ausgenutzt werden um schadaften Code zu starten. Wir haben dennoch am Tag der Benachrichtigung der Accounts auf aquila.uberspace.de kurzfristig entschieden auch alle Accounts von canopus.uberspace.de mit dem gleichen Mailtext anzuschreiben.
Header credit: CC BY 2.0 DEED lyudagreen.