←新闻详情

heise online更新于 10月30日 14:11

JFrog 发现 42 个 GitHub 仓库被植入 npm 蠕虫 testmetest 恶意代码

Gut getarnt: Automatisch startender Wurm bei GitHub ist schwer zu finden | heise online

AI 导读

JFrog 安全研究团队发现 42 个 GitHub 仓库被植入执行钩子和隐藏恶意代码,并将其归入 npm 蠕虫活动 testmetest。这些仓库分属 11 个合法所有者,攻击者通过被盗账号或员工权限注入代码;用户在项目中启动 Claude Code、Gemini 或 Cursor,或以相应设置打开 VS Code 工作区时,相关配置可能执行隐藏文件 .github/init.js。JFrog 列出 15 个至少有一个版本被判定为恶意的 npm 包,并建议检查受影响系统、审查仓库配置与工作流、吊销可能泄露的凭据;SafeDep 称该蠕虫会安装清除程序,在受害者吊销被盗 GitHub token 时删除其主目录。

推荐理由

AI 评分 69

原文披露攻击者借 Claude Code、Gemini、Cursor 的项目配置触发隐藏脚本,为开发者评估本地仓库风险提供了具体线索。

主题

标签

正文

close notice

This article is also available in English.

It was translated with technical assistance and editorially reviewed before publication.

.

JFrog Security Research hat 42 GitHub-Repositories entdeckt, die Angreifer mit Ausführungs-Hooks und verstecktem Schadcode vermint haben. Die Forscher ordnen sie der npm-Wurm-Kampagne „testmetest“ zu. Wie viele Rechner den Schadcode ausgeführt haben und welche Daten abgeflossen sind, ist unklar.

Weiterlesen nach der Anzeige

Laut der JFrog-Analyse verteilen sich die 42 kompromittierten GitHub-Repositories auf 11 legitime Eigentümer. Den Schadcode, dem JFrog eine Ähnlichkeit zu Shai-Hulud-Varianten bescheinigt, konnten die Angreifer dort mittels gekaperter Konten beziehungsweise Mitarbeiter- oder Mitwirkendenrechte einschleusen. Die npm-Seite der Kampagne hatte der Sicherheitsdienstleister SafeDep bereits am 22. Oktober beschrieben, jedoch keine kompromittierten Fremdpakete oder Opfer gefunden.

KI-Assistent und IDE als Zündschnur

In den 42 Repositories platzierten die Angreifer Projektkonfigurationen für Entwicklungswerkzeuge. Starteten Nutzerinnen und Nutzer etwa Claude Code, Gemini oder Cursor im Projekt oder öffneten es unter passenden Einstellungen als VS-Code-Workspace, konnten diese Konfigurationen die versteckte Schadcode-Datei .github/init.js ausführen.

JFrog nennt 15 npm-Pakete, bei denen mindestens je eine Version als schädlich eingestuft wurde: data-pipeline-testmetest, event-bus-lite-testmetest, event-emitter-testmetest, log-rotate-testmetest, log-sink-testmetest, net-codec-testmetest, npm-publish-testmetest, pixel-map-testmetest, retry-utils-testmetest, test-brotli-testmetest, test-brotli2-testmetest, @iobandamwer/cache-helper, @iobandamwer/native-helper, path-stream-utils-testmetest und @testsecuiitytestme/cache-helper.

JFrog empfiehlt, betroffene Systeme zu untersuchen und gegebenenfalls aus vertrauenswürdigen Quellen neu aufzubauen. Betroffene sollten Repository-Konfigurationen und Workflows prüfen und möglicherweise abgeflossene Zugangsdaten widerrufen. Dabei ist Vorsicht geboten: Laut SafeDep installiert der Wurm einen Wiper, der das Home-Verzeichnis löscht, sobald Betroffene das gestohlene GitHub-Token widerrufen.

GitHub- und npm-Zugangsdaten im Visier

Einige der manipulierten npm-Pakete enthalten einen Wurm, der vor allem GitHub- und npm-Zugangsdaten sammelt und seine eigene Weiterverbreitung vorantreiben kann. Daneben fanden die JFrog-Sicherheitsexperten in .github/init.js einen verschleierten Publisher-Schadcode. Er sucht unter anderem nach GitHub-Token und ist darauf ausgelegt, mit verfügbaren npm-Veröffentlichungsrechten manipulierte Paketversionen beispielsweise über GitHub Actions zu veröffentlichen.

Weiterlesen nach der Anzeige

Bei einigen gekaperten Repositories stieß JFrog zudem auf Shellpanel-Workflows, die cPanel-Systeme über die als kritisch eingestufte Sicherheitslücke CVE-2026-41940 angreifen. Eine durchgängige Angriffskette von der npm-Infektion bis zur Ausnutzung der Lücke sehen die Forscher aber nicht belegt.

Verborgen vor der GitHub-Codesuche

Bei der Analyse blieb der Inhalt der Payload-Datei .github/init.js zunächst verborgen, da die Datei je nach Variante 12,9 bis 13,7 MByte groß war und die GitHub-Codesuche so große Dateien nicht indexiert. Auch die übliche Contents API lieferte ihren Inhalt nicht zurück. Fündig wurde das JFrog-Team erst, als es die Verzeichnisbäume der Repositories über die Git Trees API auflistete und .github/init.js anschließend direkt als Git-Blob abrief.

JFrog beschreibt außerdem eine spätere Tarnvariante. Bei den drei untersuchten und erst kürzlich ausgelieferten npm-Paketen @iobandamwer/cache-helper, @iobandamwer/native-helper und path-stream-utils-testmetest liegt der Schadcode nicht als lesbares JavaScript vor. Stattdessen versteckt er sich verschlüsselt in der Datei .napi_cache. Ein ebenfalls im npm-Paket enthaltenes kompiliertes Add-on entschlüsselt sie zur Laufzeit und führt die Payload aus. Zuvor prüft das Add-on allerdings, ob es in einer Analyseumgebung läuft, und bricht gegebenenfalls ab.

Laut einem SafeDep-Update vom 27. Oktober hat ein weiteres npm-Konto das Paket @testsecuiitytestme/cache-helper veröffentlicht, dessen Add-on den Wurm bereits beim Import startet. Die Option --ignore-scripts schützt dann nicht mehr.

Für ihre Kampagneninfrastruktur unterhalten die Bedrohungsakteure eigene Repositories, von denen 17 unter dem GitHub-Konto CementBeetleSteeple laufen. Eines dieser Repositories, stable-scripts-9965, dient laut den Sicherheitsexperten als Datensammelstelle. Dort lagen am 25. Oktober insgesamt 27 Dateien mit mutmaßlich verschlüsselten Datenpaketen nach dem Muster data/snap-*.json. Welche Klartextdaten oder wie viele Betroffene dahinterstehen, bleibt bis auf Weiteres unklar, da sich die Analyse von JFrog auf Metadaten beschränkte und die Entschlüsselung ausklammerte.

(mro)

来源

heise online