Laut OPSSHIELD verschaffte sich der Angreifer um 02:06 UTC mit kompromittierten Zugangsdaten Zugriff auf das Update-System. Das Skript wurde mit den cPGuard-Versionen 5.88.12 bis 5.88.19 verteilt. Innerhalb von zwölf Stunden nach Auslieferung dieser Versionen sei der Angriff entdeckt worden. Das Unternehmen hat die Zugangsdaten seiner Infrastruktur zurückgesetzt und die weitere Verbreitung des Skripts gestoppt. Wie der Angreifer an die Zugangsdaten gelangte, wird noch untersucht.

Wie viele Server eine der betroffenen Versionen installiert haben, hat OPSSHIELD nicht mitgeteilt. Da Server nur in Intervallen nach Updates suchen, haben manche das Skript möglicherweise nie ausgeführt.

Ab Version 5.88.25 entfernt cPGuard die Backdoor und die vom Skript hinterlassenen Dateien. Kopierte Zugangsdaten bleiben jedoch auch nach dem Update gültig – betroffene Server benötigen deshalb neue Passwörter und Schlüssel.

Gesammelte Daten

Nach Erkenntnissen von OPSSHIELD griff das Skript folgende Daten ab:

  • /etc/shadow und /etc/passwd
  • die MariaDB- bzw. MySQL-Konfiguration von root (my.cnf)
  • die Shell-History von root
  • die SSH-Authorization- und Known-Hosts-Dateien von root

Nicht von jedem Server seien zwangsläufig alle Dateien erfasst worden; welche Daten jeweils abgeflossen sind, wird noch ermittelt. In /etc/shadow liegen Einweg-Hashes der Passwörter: Schwache, gängige oder bereits geleakte Passwörter lassen sich daraus offline durch Durchprobieren rekonstruieren, starke Passwörter müssen dennoch zurückgesetzt werden. Geheimnisse in der Datenbankkonfiguration oder der Shell-History sind gar nicht durch Hashing geschützt.

Das Skript lud die gesammelten Daten über ein kompromittiertes Konto auf einen Lizenzserver von OPSSHIELD selbst hoch, damit der Angreifer sie später abholen konnte. Das Konto wurde inzwischen abgesichert. Nach einer Schätzung von OPSSHIELD vom späten 2. November (UTC) hat der Angreifer 32 Dateien von diesem Server abgezogen, jede davon einem Kundenserver zugeordnet. Die Zahl erfasst nur Dateien, deren Abfluss bekannt ist, und kann sich ändern; sie sagt nichts über die Gesamtzahl betroffener Server aus. Über die Datensammlung und die Backdoor hinaus hat OPSSHIELD bislang keine weiteren schädlichen Aktivitäten gefunden – ein Befund, den das Unternehmen ausdrücklich als nicht abschließend bezeichnet.

Prüfung und hinterlassene Dateien

Ob ein Server eine betroffene Version installiert hat, lässt sich im Update-Log prüfen:

grep ‘Successfully updated’ /opt/cpguard/logs/install_log

Ein Eintrag für eine Version zwischen 5.88.12 und 5.88.19 belegt die Installation eines betroffenen Updates – nicht aber, dass das Skript ausgeführt wurde oder Daten abgeflossen sind. Der Server gilt trotzdem als potenziell kompromittiert, auch wenn inzwischen 5.88.25 oder neuer läuft. Umgekehrt kann ein Server ohne passende Einträge oder mit fehlendem bzw. unvollständigem Log das Skript dennoch ausgeführt haben; in Zweifelsfällen verweist OPSSHIELD auf seinen Support.

OPSSHIELD nennt folgende Dateien:

  • cpguard-v58812-i91511.sh (das Schadskript)
  • /var/tmp/.cpg91511_sh (Backdoor-Shell)
  • /var/tmp/.cpg91511 (Sammelverzeichnis)
  • /var/tmp/.cpg91511/loot.tgz (vorbereitetes Archiv)

Da das Update die Backdoor-Shell und das Sammelverzeichnis entfernt, ist deren Fehlen nach dem Update kein Beleg dafür, dass das Skript nicht lief.

Empfohlene Maßnahmen

OPSSHIELD fordert Administratoren auf, jeden cPGuard-Server sofort zu aktualisieren und die Version zu kontrollieren: mit cpgcli update –start das Update anstoßen und mit cpgcli –version prüfen, dass 5.88.25 oder neuer gemeldet wird. Schlägt das Update fehl oder ist die Version niedriger, soll der Support kontaktiert werden.

Für jeden Server, auf dem das Skript lief oder gelaufen sein könnte, empfiehlt das Unternehmen zusätzlich:

  • aus einer vertrauenswürdigen Wiederherstellungsumgebung die Passwörter von root und allen weiteren lokalen Linux-Konten mit Passwort zurücksetzen
  • von einem vertrauenswürdigen Gerät aus alle diese Passwörter ändern, die auch auf anderen Systemen genutzt werden
  • Datenbankpasswörter, S3-Zugriffsschlüssel, DigitalOcean-Token und alle in der Shell-History von root auftauchenden Geheimnisse rotieren
  • die privaten SSH-Schlüssel unter /root/.ssh ersetzen und die zugehörigen alten öffentlichen Schlüssel von allen vertrauenden Systemen entfernen

Einen vollständigen Reset oder Neuaufbau des Betriebssystems empfiehlt OPSSHIELD derzeit nicht als Standardmaßnahme, hält aber eine Änderung dieser Einschätzung im Lauf der Untersuchung für möglich. Wer weitere Anzeichen einer Kompromittierung findet oder die Sauberkeit eines Servers nicht bestätigen kann, soll eine Einzelfallprüfung beim Support anfragen, die zu einem Neuaufbau führen kann.

Unabhängig davon veröffentlicht OPSSHIELD vorsorglich ein weiteres Update, das die eigenen Support-Zugangsschlüssel von jenen cPGuard-Servern entfernt, auf denen sie zuvor hinterlegt wurden. Der Support-Zugang ist eine cPGuard-Funktion, mit der Kunden OPSSHIELD-Mitarbeitern zur Fehlersuche Zugriff gewähren; dabei wird laut Dokumentation des Unternehmens ein öffentlicher SSH-Schlüssel von OPSSHIELD in die authorized_keys-Datei von root eingetragen. Ob der passende private Schlüssel bei dem Angriff offengelegt wurde, hat OPSSHIELD nicht mitgeteilt.