cPGuard ist eine Sicherheitssoftware für Webserver. Sie sucht nach Schadcode, wehrt Angriffe auf Websites ab und sperrt Adressen, die Passwörter durchprobieren. Eingesetzt wird sie vor allem von Hostern, auf Servern, auf denen viele Websites von Kunden liegen. Damit sie ihre Arbeit tun kann, läuft sie mit vollen Rechten und aktualisiert sich selbst.
Am 2. November um 3:06 Uhr Schweizer Zeit hat sich jemand mit gestohlenen Zugangsdaten Zugang zu dem System verschafft, über das der Hersteller OPSSHIELD seine Updates verteilt. Über diesen Weg ging ein Skript an die Server der Kunden.
Was das Skript tat
Laut dem Hinweis des Herstellers sammelte es genau das, was man braucht, um einen Server dauerhaft zu übernehmen:
die Passwort-Datei des Systems, aus der sich Passwörter knacken lassen,
die Zugangsdaten des Datenbank-Administrators,
den Befehlsverlauf des Administrators, in dem oft Passwörter und Schlüssel stehen,
die SSH-Dateien, die festlegen, wer sich ohne Passwort anmelden darf.
Dazu legte es eine Hintertür an. Die gesammelten Daten lud es ausgerechnet auf den Lizenzserver des Herstellers hoch, wo der Angreifer sie abholte. Nach vorläufigem Stand wurden 32 solcher Pakete abgerufen, jedes von einem anderen Server.
Entdeckt wurde der Angriff nach weniger als zwölf Stunden. Betroffen sind die Versionen 5.88.12 bis 5.88.19. Der Hersteller schreibt ausdrücklich, dass das Fehlen der Spuren nicht beweist, dass ein Server verschont blieb.
Ein Detail am Rande
In seinem Hinweis kündigt der Hersteller ein weiteres Update an. Es entfernt die Zugangsschlüssel, die sein eigener Support auf Servern von Kunden hinterlegt hatte.
Das ist vernünftig, und es zeigt, worum es in diesem Fall eigentlich geht: Auf einem Server haben mehr Leute einen Schlüssel, als man denkt. Der Hoster, der Hersteller der Verwaltungssoftware, der Hersteller der Sicherheitssoftware, vielleicht dessen Support. Jeder dieser Schlüssel ist sicher, solange der, der ihn hat, sicher ist.
Auf unserer Supportseite steht, dass Fernzugriff nur stattfindet, wenn der Vorgang vom Kunden ausging. Bei Servern gilt dieselbe Überlegung: Ein Schlüssel, den niemand braucht, gehört nicht dorthin.
Betrifft uns das?
Auf unseren eigenen Servern läuft cPGuard nicht, wir haben am 4. November nachgesehen. Für Betriebe, die ihre Website bei einem Hoster haben, ist die Frage nicht, ob sie selbst cPGuard installiert haben. Sie haben es nicht. Die Frage ist, ob ihr Hoster es tut.
Wenn ja und wenn sein Server betroffen war, liegen dort nicht nur die Passwörter des Hosters. Es liegen auch die Zugangsdaten der Datenbanken, in denen die Websites ihre Inhalte und Kundendaten speichern.
Was jetzt zu tun ist
Beim Hoster nachfragen. Setzt ihr cPGuard ein, und lief auf unserem Server am 2. November eine der Versionen 5.88.12 bis 5.88.19? Wenn ja: Was habt ihr seither unternommen?
Die Antwort bewerten. Eine gute Antwort nennt, ob Passwörter, Datenbankzugänge und SSH-Schlüssel ersetzt wurden. «Wir haben das Update eingespielt» genügt nicht, denn die Daten sind vielleicht schon weg.
Eigene Zugänge ändern, wenn es Sie betrifft. Datenbank-Passwort der Website, FTP- und SSH-Zugänge, und alles, was im selben Konto gespeichert ist. Ein Passwort, das auch anderswo verwendet wird, gehört überall geändert.
Die grundsätzliche Frage stellen. Wer hat einen Zugang zu unserem Server, und welche Software darf sich dort selbst aktualisieren? Das muss nicht jede Woche geklärt werden. Aber einmal sollte jemand die Liste aufgeschrieben haben.