Es gibt Angriffe, gegen die kein Passwort hilft, weil sie eine Ebene tiefer ansetzen. Dieser hier ist so einer. Angreifer haben nicht den Hersteller gehackt. Sie haben den Weg zum Hersteller umgeleitet — und danach ganz normal aussehende Updates ausgeliefert. Mit einer Hintertür darin.
WAS PASSIERT IST
Betroffen ist Virtualizor, ein Verwaltungspanel von Softaculous, mit dem Hoster virtuelle Server anlegen, verkaufen und betreuen. In der Kette zwischen dir und deinem VPS-Anbieter sitzt es oft ganz oben.
Laut Warnung des Herstellers hat ein Angreifer zwischen dem 28. August, 20:57 Uhr UTC, und dem 30. August, 06:10 Uhr UTC, einen ganzen IP-Block umgeleitet. Konkret: Das autonome System AS62390 (NexonHost) kündigte über AS6204 (Zet.net) das Netz 162.55.80.0/24 an — ein bei Hetzner liegender Adressbereich, über den Softaculous seine Update- und Abrechnungssysteme betreibt. Wer in diesem Zeitfenster ein Update anstieß, landete nicht beim Hersteller, sondern beim Angreifer.
DER FEHLER, DER ALLES ERMÖGLICHTE
Das eigentlich Bittere steht in der Stellungnahme des Herstellers selbst: Die Update-Klienten haben die Pakete nicht kryptografisch geprüft. Kein signiertes Paket, keine Prüfung gegen einen bekannten Schlüssel. Es reichte, den Datenverkehr umzubiegen und ein gültiges TLS-Zertifikat vorzuweisen — also genau das, was jeder bekommt, der eine Domain kurzzeitig kontrolliert.
Danach lief der Code des Angreifers mit root-Rechten. Auf einem Hostsystem, unter dem die virtuellen Maschinen fremder Kunden liegen.
WAS DER SCHADCODE ANSTELLTE
Zwei Dinge fallen auf. Erstens wurden fremde öffentliche SSH-Schlüssel hinterlegt — der klassische Dauerzugang, der auch ein Update oder einen Neustart übersteht. Zweitens tauchte eine auffällige systemd-Einheit auf: /etc/systemd/system/java-jre-update.service. Der Name klingt nach Routine. Dahinter steckte eine Java-basierte Ausführungskomponente des Angreifers.
Softaculous spricht von einer kleinen Zahl betroffener Installationen. Das ist beruhigend und trügerisch zugleich: Eine einzige betroffene Hostmaschine kann Dutzende Kundenserver tragen.
SO PRÜFST DU DEIN SYSTEM
1. Zeitfenster abgleichen. Hast du zwischen dem 28. und 30. August ein Virtualizor-Update ausgeführt? Wenn nein, ist die Wahrscheinlichkeit gering. Wenn ja oder unklar: weiterprüfen.
2. Nach der systemd-Einheit suchen. Prüfe, ob eine Datei mit dem oben genannten Namen existiert und ob der zugehörige Dienst läuft.
3. SSH-Schlüssel kontrollieren. Jede authorized_keys auf dem Host durchgehen — auch für Dienstkonten. Alles, was du nicht selbst eingetragen hast, fliegt raus.
4. Konten und geplante Aufgaben. Neue Benutzer, veränderte Cronjobs, unbekannte Timer.
5. Ausgehende Verbindungen beobachten. Ein Hostsystem, das plötzlich mit unbekannten Adressen spricht, ist ein deutliches Signal.
6. API-Zugänge erneuern und einschränken. Der Hersteller empfiehlt ausdrücklich, alle Zugangsschlüssel zu tauschen und ihre Reichweite zu begrenzen.
WAS DU DARAUS MITNEHMEN SOLLTEST
Auch wenn du kein Virtualizor betreibst: Die Lehre gilt für jede selbst gebaute Update-Automatik im Homelab. Ein Update-Kanal ohne Signaturprüfung ist eine offene Tür, die nur so lange geschlossen wirkt, wie niemand das Routing anfasst. Wenn ein Skript bei dir regelmäßig etwas herunterlädt und als root ausführt, ist heute ein guter Tag, um zu prüfen, ob es die Herkunft überhaupt kontrolliert.
FAZIT: Vertrauen ist keine Prüfsumme
BGP-Entführungen galten lange als Thema für Netzbetreiber. Dieser Fall zeigt, wie direkt sie im Serverraum ankommen — und dass die eigentliche Schwachstelle nicht das Routing war, sondern eine fehlende Signaturprüfung.