Moderne Software wird nicht mehr am Stück geschrieben, sondern zusammengesetzt. Ein durchschnittliches Web-Projekt bindet Dutzende fertiger Bausteine ein, die wiederum eigene Bausteine mitbringen. Das ist effizient — und es bedeutet, dass Vertrauen weitergereicht wird wie ein Container im Hafen: Man verlässt sich darauf, dass drin ist, was draufsteht.
Am 4. August wurde dieses Vertrauen im grossen Stil ausgenutzt. Angreifer übernahmen das Entwicklerkonto hinter mehreren sehr weit verbreiteten Bausteinen und veröffentlichten manipulierte Versionen. Innerhalb einer Stunde hatte sich der Schadcode selbstständig auf über 440 weitere Pakete ausgebreitet — zusammen mehr als zwei Milliarden Installationen pro Monat. Die Fachwelt kennt die Angriffsfamilie inzwischen unter dem Namen «Shai-Hulud»; es war bereits die dritte Welle desselben Baukastens in diesem Jahr.
Besonders unangenehm war die Machart: Der eigentliche Programmcode blieb unverändert. Der Schadcode steckte in einem Installationsschritt, der automatisch abläuft, wenn ein Entwickler die Bausteine herunterlädt — noch bevor die Anwendung überhaupt startet. Wer die Bibliothek nach der Aktualisierung geprüft hätte, wäre nicht fündig geworden.
Was der Code suchte, waren Zugangsdaten: Schlüssel für Paketverzeichnisse und Code-Plattformen, Cloud-Zugänge, Datenbankpasswörter aus Konfigurationsdateien, SSH-Schlüssel. Mit den erbeuteten Schlüsseln infizierte er dann weitere Pakete — daher die rasante Ausbreitung.
Jetzt die Frage, die Sie eigentlich interessiert: Betrifft das Ihre Firmenwebsite?
Direkt betroffen war das Ökosystem rund um JavaScript, das vor allem beim Bau moderner Webanwendungen zum Einsatz kommt. Eine klassische Joomla- oder WordPress-Seite lädt diese Bausteine im laufenden Betrieb nicht. Das Muster dahinter kennt die PHP-Welt aber genauso: Ein übernommenes Entwicklerkonto, ein manipuliertes Plugin-Update, und der Schadcode landet mit dem nächsten Klick auf «Aktualisieren» auf Tausenden von Websites. Genau so laufen die meisten Angriffe auf WordPress-Erweiterungen ab.
Wie wir aufgestellt sind: Unsere eigene Website kommt ohne Paketverwaltung im laufenden Betrieb aus. Die verwendeten Bibliotheken liegen als feste, versionierte Dateien auf unserem Server — bei einer Veröffentlichung wird nichts nachgeladen. Ein Installationsschritt wie der beschriebene kann hier gar nicht erst ausgelöst werden, weil es ihn nicht gibt.
Bei den Websites, die wir für Kunden betreuen, greifen drei Vorkehrungen ineinander. Erstens spielen wir Updates kontrolliert ein statt automatisch: Wir sehen, was sich ändert, und halten im Zweifel kurz inne, statt jede frische Version blind zu übernehmen. Zweitens überwacht unser Monitoring die Dateien — taucht plötzlich Code auf, der dort nicht hingehört, fällt das auf, unabhängig davon, über welchen Weg er hineingekommen ist. Drittens prüfen wir Backups auf Integrität, damit im Ernstfall ein sauberer Stand zum Zurückspielen bereitsteht.
Was wir nicht behaupten: Kein Verfahren der Welt verhindert, dass irgendwo ein Entwicklerkonto übernommen wird. Beeinflussen lässt sich etwas anderes — wie schnell so etwas auffällt und wie weit es sich ausbreiten kann, bevor jemand eingreift. Genau das ist der Zweck von SLA & Monitoring: nicht das Versprechen völliger Sicherheit, sondern kurze Wege zwischen Vorfall und Reaktion.
Wie eng die Zeitfenster inzwischen sind, hat vor wenigen Wochen die Angriffswelle auf WordPress gezeigt: Zwischen dem Sicherheitsupdate und den ersten Angriffen lagen keine Tage, sondern Stunden.
Falls Sie unsicher sind, wie Ihre Website aufgestellt ist — welche Erweiterungen sie mitbringt, wer sie aktualisiert und ob jemand hinsieht, wenn sich etwas verändert: Melden Sie sich. Wir schauen es uns an und sagen Ihnen ehrlich, wo Sie stehen. Besteht bereits ein Verdacht, hilft die Hack- & Malware-Bereinigung weiter.