Thought Leadership
Die Sicherheitsforscher vom JFrog Research Team haben kürzlich einen ausgeklügelten und schwerwiegenden Angriff auf .NET-Entwickler über das NuGet-Repository identifiziert, wobei ausgeklügelte Typosquatting-Techniken verwendet wurden. Die entdeckten Pakete – die im vergangenen Monat 150.000 Mal heruntergeladen wurden (bevor sie aus dem NuGet-Repository entfernt wurden) – enthielten eine Art „Download & Execute“-Schadcode.
Die Pakete enthielten zudem ein PowerShell-Skript, das bei der Installation ausgeführt wird und den Download von Schadcode der zweiten Stufe auslöst, die aus der Ferne ausgeführt werden kann. Bei der zweiten Stufe handelt es sich um eine benutzerdefinierte, komplexere ausführbare Datei.
NuGet ist immer noch anfällig für Angriffe mit bösartigen Paketen
Obwohl die entdeckten bösartigen Pakete inzwischen von NuGet entfernt wurden, sind .Net-Entwickler nach wie vor einem hohen Risiko durch bösartigen Code ausgesetzt, da solche Pakete noch immer die Möglichkeit bieten, Code unmittelbar nach der Paketinstallation auszuführen. In älteren Visual Studio Versionen konnten Entwickler ein PowerShell Script im „tools“ Verzeichnis eines NuGet Paketes hinterlegen, das ohne Einschränkungen bei bestimmten Events ausgeführt wird – z. Bsp. bei Paket Installationen, De-Installation, beim Visual Studio Start etc. Derzeit scheint es, dass Microsoft die Entwickler dazu drängt, diese Option zu vernachlässigen, da die Skriptoptionen install.ps1 und uninstall.ps1 ignoriert werden. In der aktuellen Dokumentation werden diese Skripte quasi nicht erwähnt. Obwohl es veraltet ist, wird das Skript init.ps1 von Visual Studio weiterhin beachtet und ohne Warnung ausgeführt, wenn ein NuGet-Paket installiert wird. Es ist wichtig zu beachten, dass die automatische Ausführung des init-Skripts bei Verwendung der NuGet-CLI nicht erfolgt.
Welche bösartigen Pakete wurden entdeckt?
Die Top drei Pakete: Coinbase.Core, Anarchy.Wrapper.Net und DiscordRichPresence.API wurden unglaublich oft heruntergeladen – dies könnte ein Hinweis darauf sein, dass der Angriff sehr erfolgreich war und eine große Anzahl von Rechnern infiziert hat. Allerdings sind die Downloadzahlen allein kein zuverlässiger Indikator für den Erfolg des Angriffs, da die Angreifer die Anzahl der Downloads automatisch (mit Bots) aufgebläht haben könnten, um die Pakete legitimer erscheinen zu lassen. Zudem wurden noch zehn weitere manipulierte Pakete gefunden.
Indikatoren für bösartige Aktivitäten
Der wichtigste bösartige Indikator in den oben genannten Paketen ist das init.ps1-Skript, das bei der Installation ausgeführt wird und sofort eine .EXE-Binärdatei herunterlädt und auf der Workstation des Opfers ausführt.
Die folgenden Methoden wurden angewandt, um die Nutzer zum Herunterladen des Pakets zu verleiten:
- Die Verwendung von „Typosquatting“ – die Zuweisung von Namen für die Pakete, die legitimen Paketen extrem ähnlich sind, zum Beispiel „Coinbase.Core“.
- Legitime Namen der Paketeigentümer – Begriffe, die versuchen, das Paket legitim erscheinen zu lassen (BinanceOfficial, NuGetDev, OfficialDevelopmentTeam).
- Pakete mit irreführenden Metadaten – wie z.B. „Microsoft“ als Autor und eine vage Beschreibung, da Nuget keinen Verifizierungsprozess für das Attribut „Autor“ in der .nuspec-Metadatendatei hat.
- Pakete definieren andere als Abhängigkeiten – einige Pakete enthielten keine direkte bösartige Nutzlast. Stattdessen definierten sie andere Pakete als Abhängigkeiten, die dann ihrerseits das bösartige Skript enthielten.
- Legitim erscheinende Autoren – z. B. mit dem Autorennamen „joelverhagen“, bei dem es den Anschein hat, dass es sich um den Kontonamen eines Softwareentwicklers von Microsoft handelt, der an NuGet arbeitet.
Die bösartige Nutzlast ist ungewöhnlich raffiniert
Alle beobachteten bösartigen Pakete hatten dasselbe Nutzlastskript (entweder direkt oder als Abhängigkeit). Zunächst änderte das Nutzlastskript die laufende Konfiguration von PowerShell so, dass der aktuelle Benutzer PowerShell-Skripte ohne Einschränkungen ausführen konnte. Es ist auch erwähnenswert, dass die Download- und Ausführungs-Nutzlast eine HTTP-URL (ohne TLS) verwendet. Dies ist besonders gefährlich, da Angreifer in lokalen Netzwerken, die keine Kontrolle über die ursprüngliche Command & Control-Domäne haben, die Download-Anforderung mithilfe eines Man-in-the-Middle-Angriffs abfangen könnten. Auf diese Weise könnten sie die Nutzdaten nach Belieben ändern und die vollständige Kontrolle über den Rechner erlangen, auf dem das bösartige NuGet-Paket installiert wurde.
Wie man sich vor bösartigen NuGet-Paketen schützt
In erster Linie sollten Entwickler auf Tippfehler in importierten und installierten Paketen achten. Wie man sehen kann, versuchen einige dieser Pakete, die Namen legitimer, bekannter Pakete zu imitieren, in der Hoffnung, dass ein Entwickler sie versehentlich in seinem Projekt installiert oder als Abhängigkeit erwähnt.
Eine weitere Möglichkeit, die Installation bösartiger Pakete zu vermeiden, besteht darin, manuell zu überprüfen, dass sie keine verdächtigen Installations- oder Initialisierungsskripte enthalten. Es wird empfohlen, die Pakete vor der Installation mit dem NuGet-Paket-Explorer zu überprüfen, der auf der Seite eines Pakets im Menü auf der rechten Seite verfügbar ist. Nutzer sollten den Inhalt der Skripte init.ps1, install.ps1 oder uninstall.ps1 im Verzeichnis tools überprüfen und Ausschau halten nach Skripten, die Ressourcen aus externen Quellen herunterladen.
Fazit
Die Ergebnisse dieser Untersuchung beweisen, dass kein Open-Source-Software-Repository für immer sicher ist. Obwohl im NuGet-Repository keine früheren Angriffe mit bösartigem Code beobachtet wurden, konnten wir Hinweise auf mindestens eine aktuelle Kampagne finden, bei der Methoden wie Typosquatting zur Verbreitung von bösartigem Code eingesetzt wurden. Wie bei anderen Repositories sollten in jeder Phase des Softwareentwicklungszyklus Sicherheitsmaßnahmen getroffen werden, um die Sicherheit der Software-Lieferkette zu gewährleisten.
Das JFrog Security Research Team überwacht das NuGet Repository regelmäßig auf bösartige Pakete, einschließlich der manuellen Analyse von verdächtigem Code. Diese bösartigen Pakete werden häufig über die Open-Source-Paket-Repositories NPM und PyPI verbreitet, wobei nur wenige andere Repositories betroffen sind. Insbesondere gab es keine öffentlichen Hinweise auf schwerwiegende bösartige Aktivitäten im NuGet-Repository, abgesehen von Spam-Paketen, die zur Verbreitung von Phishing-Links verwendet wurden.
Weitere Informationen:
Die detaillierten Ergebnisse der Untersuchung des JFrog Research Teams finden Sie hier.
jfrog.com
