Sicherheitsvorfall durch schadhafte Drittanbietersoftware

Die Wochen zwischen Oktober und November 2021 waren für unser Security Team eine aufregende Zeit: Gleich drei weit verbreitete NPM Pakete wurden innerhalb von nur drei Wochen von unbekannten Kriminellen infiltriert und mit Malware verseucht.

Wie konnte der Vorfall entstehen? 

Bei NPM Paketen handelt es sich um Drittanbietenden-Software, die in JavaScript Projekten verwendet werden. Die Nutzung solcher Pakete ist weit verbreitet und meistens sinnvoll: Entwickler*innen müssen nicht mehr jeden einzelnen Aspekt eines Projekts selbst bauen, sondern können sich auf standardisierte und erprobte Lösungen verlassen, wodurch sie mehr Zeit für die eigentliche Business Logic gewinnen. Auch aus Security-Sicht ist dieser Ansatz in der Regel nützlich, denn je verbreiteter ein Drittanbietenden-Paket ist, desto erprobter ist es in der Praxis, womit die Wahrscheinlichkeit für unentdeckte Lücken drastisch sinkt. Sollte doch einmal eine solche Lücke entdeckt werden, wird sie von der Community meist schnell entdeckt, gemeldet und behoben. 

Da auch Entwickler*innen von NPM Paketen nicht alles von Grund auf selbst programmieren, haben die Pakete ihrerseits Abhängigkeiten zu weiteren Paketen, welche wiederum ihre eigenen Abhängigkeiten haben. Somit importiert man mit einem NPM Paket nicht nur das Paket selbst, sondern einen ganzen Baum von Abhängigkeiten, der nur noch schwer zu überblicken ist. Gerade Pakete, die grundlegende Funktionalitäten bereitstellen und damit sehr weit verbreitet sind, sind daher beliebte Ziele für sogenannte Supply-Chain-Attacks in denen Schwachstellen von Drittanbietendensoftware ausgenutzt werden.

Was ist passiert? 

In den beiden kürzlich aufgetretenen Fällen handelte es sich nicht um eine unbeabsichtigte Sicherheitslücke, sondern um einen gezielten Angriff. Die Täter*innen konnten sich auf bisher ungeklärte Weise Zugriff auf die NPM Accounts der Betreibenden verschaffen, welche nicht durch Multi-Factor-Authentication gesichert waren. So konnten sie einen Trojaner einschleusen, der über den Installationsprozess der Pakete auf die Zielsysteme gebracht wurde. Von dort aus fing die Software an, nach gespeicherten Passwörtern und Zugangsdaten zu suchen, und diese an einen externen Server zu senden. In einem Fall wurde zusätzlich ein Crypto-Mining-Programm installiert. 

Auch wenn die kompromittierten Versionen nur wenige Stunden online waren, bevor sie entdeckt und ersetzt wurden, besteht eine ernstzunehmende Wahrscheinlichkeit, dass ein*e Mitarbeiter*in die Software innerhalb dieser Zeit im Zuge eines Routine-Updates der Packages installiert hat. Es wurde daher ein Incident Response Team erstellt, das sich einen Überblick der Situation sowie möglicherweise notwendiger Gegenmaßnahmen verschaffen soll. 

Wie haben wir reagiert? 

Das Incident Response Team arbeitet nach einem formalisierten Ablaufplan, welcher aus folgenden Schritten besteht: 

• Identifikation und Abwägung des Risikos (Identification / Triage) 

• Eingrenzung der schadhaften Komponenten (Containment) 

• Auslöschen der Bedrohung (Eradication) 

• Wiederherstellung der betroffenen Systeme (Recovery) 

• Abschlussbesprechung (Post Mortem) 

Der erste Schritt bestand also darin, herauszufinden welche Rechner überhaupt betroffen waren. Hierfür wurde eine firmenweite Nachricht verschickt, welche genaue Anleitungen enthielt, um den eigenen Rechner auf Vorkommen der entsprechenden Pakete zu prüfen. Personen mit positivem Testergebnis sollten sich umgehend beim Incident Response Team melden. Gleichzeitig wurden die in den betroffenen Paketen eingeschleusten Code-Zeilen analysiert, um eine genauere Einschätzung des Risikos zu erhalten. 

Wir konnten so innerhalb kurzer Zeit feststellen, dass zwar mehrere Rechner das betroffene Paket installiert hatten, diese allerdings glücklicherweise nicht kompromittiert wurden, da es sich um Apple Rechner handelte und die Schadsoftware ausschließlich Windows und Linux betraf. 

In diesem Fall hatten wir Glück und konnten, nachdem alle Rechner geprüft wurden, direkt zur Abschlussbesprechung übergehen. Wäre dies nicht der Fall gewesen, so hätte unser Plan aus folgenden Schritten bestanden: 

• Short Term Containment: Der betroffene Rechner wird sofort vom Internet getrennt, um weiteres Abwandern von Daten zu unterbinden. 

• Long Term Containment: Da die Möglichkeit bestand, dass auf dem Rechner gespeicherte Passwörter ausgelesen werden konnten, müssen alle Passwörter als kompromittiert angesehen und ersetzt werden. 

• Eradication/Recovery: Der betroffene Rechner wird vollständig gelöscht und neu aufgesetzt.  

Ein weiterer Punkt, der zur Phase „Eradication“ gehört, ist die Sicherstellung, dass die entsprechenden Pakete nicht mehr installiert werden können. Diese Maßnahme wurde bereits von den jeweiligen Betreibenden der Pakete durchgeführt. 

Eine Bedrohung für unsere Server bestand nicht, da diese keine Paketinstallationen vornehmen. Die Build-Agents nehmen zwar Installationen vor, beinhalten allerdings keine sensitiven Daten und werden als Container direkt nach einem erfolgreichen Build wieder entsorgt. 

Was haben wir gelernt? 

Auch wenn die schnelle Abfolge dieser beiden Attacken besorgniserregend ist, brachte dieser Umstand dem Incident Response Team eine wichtige Einsicht. Denn während es beim ersten Incident mehrere Tage dauerte, bis alle Mitarbeitenden den entsprechenden Fragebogen eingereicht hatten, waren es beim zweiten Incident nur wenige Stunden. Wir konnten daran erkennen, wie wichtig es ist, solche Vorfälle regelmäßig zu üben, um im Ernstfall rechtzeitig handeln zu können. Außerdem wurde ein dedizierter Kommunikationskanal eingerichtet, der eine priorisierte Nachricht an alle Mitarbeitenden versenden kann. 

Es wurde außerdem ein IP Filter eingerichtet, der Datenverkehr nach Osteuropa und Russland abfängt. Hier waren in beiden Fällen die entsprechenden Server lokalisiert, von denen die Pakete die Malware während des Installationsprozesses heruntergeladen wurde. 

Als Maßnahme um zukünftige Supply-Chain-Attacks zu unterbinden, wird außerdem aktuell an einem Proxy für NPM Pakete gearbeitet, welcher neue Versionen für einen definierten Zeitraum zurückhalten kann, um das Risiko von unbemerkten Package-Infiltrationen zu verringern.