Was ist Typosquatting und wie führen Typosquatting-Angriffe zu schädlichen npm-Modulen?

Vielleicht haben Sie in verschiedenen Zusammenhängen schon von schädlichen Paketen gehört, etwa von einem schädlichen Docker-Container oder einem schädlichen Open-Source-Paket in einem öffentlichen Registry eines Ökosystems. Snyk hat sogar umfangreiche Untersuchungen zu Malware in mobilen Anwendungen veröffentlicht, die den Namen SourMint trägt.

Wir haben einige dieser Sicherheitsvorfälle bereits früher beleuchtet. Sie betreffen mehr als nur ein Ökosystem:

• Typosquatting-Angriffe in der PyPI-Registry von Python

• Der bekannte Vorfall mit event-stream: eine schädlich veröffentlichte Version im JavaScript-npm-Ökosystem

• Schädliche Remote-Code-Ausführung in den beliebten Ruby-Gem-Projekten bootstrap-sass und strong_password

Allerdings sind nicht alle schädlichen Pakete gleich. Im Hinblick auf Ökosystem-Registries lassen sie sich grob in eine der folgenden Kategorien einteilen:

• Typosquatting-Angriffe – Angreifer veröffentlichen schädliche Pakete in einer Registry und hoffen, Nutzerinnen und Nutzer dazu zu bringen, sie zu installieren. Solche Pakete haben wir sowohl in den PyPI- als auch den Node.js-Registries gesehen. Besonders erwähnenswert ist crossenv. Der Name ähnelte dem des beliebten Pakets cross-env. Es bot dieselbe Funktionalität, erfasste aber zusätzlich Umgebungsvariablen und sendete sie an einen vom Angreifer kontrollierten Remote-Server.

• Kompromittierte Konten – Maintainer von Open-Source-Projekten verfügen möglicherweise nicht über mehr Sicherheitswissen als andere Entwickler. Das kann dazu führen, dass sie Geheimnisse im Zusammenhang mit ihren Veröffentlichungsrechten unsicher handhaben. Noch komplizierter wird es, wenn ein Projekt mehrere Maintainer hat und Projektregeln für alle Mitglieder durchgesetzt werden müssen. Kompromittierte Konten können auch auf fehlende geeignete Authentifizierungskontrollen in manchen Registries zurückzuführen sein. Dennoch können sie schwerwiegende Sicherheitsvorfälle verursachen, weil die von diesen Konten betreuten Projekte potenziell sehr beliebt sind und sich ein Vorfall unmittelbar auf das jeweilige Ökosystem auswirkt.

• Social Engineering statt Abhängigkeiten im Dependency-Graph – Open Source lebt von Zusammenarbeit und begrüßt sie uneingeschränkt. Eine schädliche Codezeile in einem Pull Request fällt jedoch wahrscheinlich vielen Menschen schnell auf. Wird eine schädliche Codezeile dagegen einer Abhängigkeit eines Projekts hinzugefügt, sieht die Sache anders aus.

Typosquatting-Angriffe

Von den oben genannten Arten schädlicher Pakete und Versionen, die in Repositories veröffentlicht werden, ist Typosquatting eine der häufigsten. Die Einstiegshürde für Angreifer ist sehr niedrig, und es gibt nur wenige Gegenmaßnahmen.

Was sind Typosquatting-Angriffe?

Bei Typosquatting-Angriffen veröffentlichen Angreifer schädliche Pakete in einer Registry und hoffen, Nutzerinnen und Nutzer zur Installation zu verleiten. Öffentliche Software-Registries wie npm oder PyPI sind Beispiele für Ökosysteme, in denen wir solche Versuche bereits beobachtet haben.

Das ähnelt Phishing-Angriffen auf Websites, bei denen Tippfehler von Personen ausgenutzt werden, die versehentlich eine falsche Adresse eingeben – zum Beispiel https://bankofamerca.com statt https://bankofamerica.com. Wenn die erste Domain-Adresse von einem Angreifer kontrolliert würde, könnte dieser eine gefälschte Website erstellen, die wie das Original aussieht, und vertrauliche Finanzinformationen wie Zugangsdaten oder Bankkontodaten stehlen.

Beispiele für schädliche Typosquatting-Module aus der Snyk-Schwachstellendatenbank, mit einer Reihe von Schwachstellen, die bis ins Jahr 2017 zurückreichen:

Und falls Sie denken, Typosquatting sei 2020 ausgestorben: Denken Sie noch einmal nach.

Die Geschichte von crossenv

Ein besonders bemerkenswerter Typosquatting-Angriff betraf crossenv. Der Angreifer verwendete einen ähnlichen Namen wie das beliebte Paket cross-env und übernahm sogar exakt die Funktionalität des ursprünglichen Moduls, damit es den Anschein erweckte, wie erwartet zu funktionieren. Tatsächlich erfasste es jedoch zusätzlich Umgebungsvariablen und sendete sie an einen vom Angreifer kontrollierten Remote-Server.

Am 19. Juli veröffentlichte der npm-Nutzer hacktask crossenv als eines von mehr als 30 weiteren schädlichen Paketen, mit denen Umgebungsvariablen von Opfern gestohlen wurden, die zur Installation verleitet worden waren.

Wie C J Silverio in seinem Blog berichtet, finden Sie hier die vollständige Liste der Pakete mit der jeweiligen Gesamtzahl der Downloads während ihrer Verfügbarkeit in der öffentlichen npm-Registry:

babelcli: 42
cross-env.js: 43
crossenv: 679
d3.js: 72
fabric-js: 46
ffmepg: 44
gruntcli: 67
http-proxy.js: 41
jquery.js: 136
jquery.js: 136
mariadb: 92
mongose: 196
mssql-node: 46
mssql.js: 48
mysqljs: 77
node-fabric: 87
node-opencv: 94
node-opensl: 40
node-openssl: 29
node-sqlite: 61
node-tkinter: 39
nodecaffe: 40
nodefabric: 44
nodeffmpeg: 39
nodemailer-js: 40
nodemailer.js: 39
nodemssql: 44
noderequest: 40
nodesass: 66
nodesqlite: 45
opencv.js: 40
openssl.js: 43
proxy.js: 43
shadowsock: 40
smb: 40
sqlite.js: 48
sqliter: 45
sqlserver: 50
tkinter: 45

Wie sieht ein schädliches Paket wie crossenv aus?

Um den Fall des schädlichen Pakets crossenv zu untersuchen, beginnen wir mit der Datei package.json:

Sehen wir uns einige Dinge an, die beim Blick auf die Datei package.json verdächtig wirken:

• Zeile 2: Der Paketname ist offensichtlich falsch – nehmen wir jedoch an, dass dies unbemerkt blieb.

• Zeile 13: enthält das echte Paket cross-env, das, wie Sie sehen, eine andere Version (5.0.1) als das Modul selbst hat (6.1.1 in Zeile 3).

• Zeile 8: Hier sollten die Alarmglocken läuten. Was steckt in package-setup.js und welche Einrichtung ist für dieses Paket erforderlich?

Bevor wir uns die ganze Geschichte hinter node package-setup.js ansehen, machen wir einen Schritt zurück und erklären, warum diese Zeile so wichtig ist. Das Run-Script postinstall ist einer der integrierten npm-Paket-Lifecycle-Hooks. Es wird automatisch ausgeführt, wenn ein Paket installiert wird.

Jeder Befehlswert in einem postinstall-Run-Script wird von einem npm install-Vorgang ausgeführt – unabhängig davon, ob Ihr eigener Code das Script benötigt oder nicht.

Akt 1: Die schädliche Payload des npm-Pakets

Setzen wir unsere Untersuchung fort und sehen uns den Inhalt der Datei package-setup.js an, offenbart sich ein Abgrund des Bösen:

Da dieses Script während eines Teils des npm-Paketinstallationsprozesses ausgeführt wird, sammelt es mit process.env alle Umgebungsvariablen, wandelt sie in eine Base64-kodierte Payload um und sendet sie per HTTP-POST-Anfrage an einen vom Angreifer kontrollierten Remote-Server.

Die schädliche Aktion wird einmalig während der Installation ausgeführt. Danach bietet das Paket crossenv weiterhin die Funktionalität, für die es ursprünglich installiert wurde, indem es das echte Paket cross-env umschließt – und bleibt so unentdeckt.

Akt 2: Welche Folgen schädliche Pakete haben können

Diese Sicherheitslücke zu finden und öffentlich zu machen, ist wichtig, reicht aber nicht aus. Um den möglichen Schaden und die Folgen eines solchen Angriffs zu verstehen, sollten wir uns einen Moment Zeit nehmen und einige Fragen betrachten:

1. Welche Informationen speichern wir in unseren Umgebungsvariablen?

2. Was wäre passiert, wenn ein Entwickler dies in einen Branch gemergt und auf einem CI-Server ausgeführt hätte? Und was wäre geschehen, wenn es anschließend auf einem Produktionsserver gelandet wäre?

3. Welche Folgen hätte das für Sie, wenn der Angriff nicht beim Auslesen der Umgebungsvariablen Halt gemacht, sondern weitere schädliche Schritte unternommen hätte – etwa Backdoors installiert, Umgebungen mit sich selbst replizierenden Würmern infiziert und weitere solche Albträume ausgelöst hätte?

Epilog: Wie haben wir dieses schädliche Paket auf npm entdeckt?

Oscar Bolmsten, ein schwedischer Softwareentwickler, veröffentlichte einen Tweet über mögliche schädliche Aktivitäten im Zusammenhang mit dem Paket crossenv. Offenbar war das Paket zwei Wochen lang unentdeckt geblieben:

https://twitter.com/o\_cee/status/892306836199800836?ref\_src=twsrc%5Etfw

Was können wir dagegen tun?

• Speichern Sie keine vertraulichen Informationen in Umgebungsvariablen.

• Verbinden Sie Ihr Repository mit Snyk, damit wir die Abhängigkeiten Ihres Projekts täglich überwachen und Sie benachrichtigen können, wenn wir schädliche Pakete oder andere Schwachstellen finden. Lässt sich eine gefundene Sicherheitslücke beheben, erstellen wir automatisch einen Pull Request (oder Merge Request) in Ihrem Repository.

• Informieren Sie sich vor der Installation von Paketen im Snyk Advisor über den allgemeinen Zustand, die Beliebtheit, Wartung, Sicherheit und weitere Merkmale des Pakets.

• Verwenden Sie bei der Paketinstallation das npm-CLI-Flag --ignore-scripts, um zu verhindern, dass Scripts von Paketen Dritter während der Installation ausgeführt werden.

• Sie können auch npq verwenden, um Pakete sicher zu installieren. Das Tool sammelt Informationen zum Zustand eines Pakets, bevor Sie es tatsächlich installieren.

Weitere Best Practices und Tipps zur npm-Sicherheit finden Sie in unserem npm-Sicherheitsleitfaden.