GitHub Actions tauchen mit Mini-Shai-Hulud-Malware wieder auf

Angreifer haben letzte Woche kurzzeitig eine Lieferketten-Bedrohung wiederbelebt, als zwei Drittanbieter-GitHub-Actions, die zuvor in einer Malware-Kampagne im Mai beschlagnahmt worden waren, wieder aktiviert wurden und derselbe Schadcode weiterhin an ihren Release-Tags hing. Die Actions actions-cool/issues-helper und actions-cool/maintain-one-comment waren ab dem 16. September wieder zugänglich und blieben bis zum 25. September aktiv, sodass jeder Workflow, der sie über einen Versions-Tag referenzierte, die alte Nutzlast stillschweigend herunterladen und ausführen konnte.

Dieser Vorfall, der von Forschern des Applikationssicherheitsunternehmens Socket aufgedeckt wurde, geht auf die Mini-Shai-Hulud-Lieferkettenattacke zurück, die im Mai 323 Pakete und 639 Paketversionen im Node-Package-Manager-Index (npm) infizierte. Diese Kampagne zielte auf Entwickler-Token, Zugangsdaten und Secrets für Continuous Integration und Continuous Delivery (CI/CD) ab. Das Sicherheitsteam von GitHub hatte beide Actions nach der ersten Kompromittierung am 18. Mai entfernt, in der Annahme, die Bedrohung sei neutralisiert. Der Maintainer aktivierte die Repositories jedoch später erneut, ohne zuvor die Tags zu bereinigen, die weiterhin auf einen Commit mit einer verschleierten Nutzlast in der Datei index.js verwiesen.

Die Zeitleiste von Socket zeigt, dass die Offenlegung am 16. September zwischen 11:09 und 18:16 GMT+2 begann. Neun Tage lang hätten alle nachgelagerten Projekte, die die Actions über einen veränderlichen Versions-Tag anstatt über einen festgenagelten Commit-Hash verwendeten, beim nächsten Lauf den infizierten Code abgerufen. Die Actions werden häufig für die automatisierte Issue-Verwaltung eingesetzt und laufen daher in vielen Repositories fast täglich. GitHub's eigener Abhängigkeitsgraph listet allein für issues-helper rund 15.000 abhängige Repositories auf, wobei die tatsächliche Zahl derer, die die bösartige Version bezogen haben, unbekannt ist, da die Forscher nicht ermitteln konnten, wie viele Projekte die Actions per Tag oder per fixiertem Commit referenzieren.

Die fragliche Nutzlast ist dasselbe verschleierte Skript vom Mai, das darauf ausgelegt ist, Secrets aus der CI/CD-Pipeline zu stehlen. In der modernen Softwareentwicklung erstellt, testet und deployt eine CI/CD-Pipeline automatisch Code und hat dabei oft Zugriff auf sensible Zugangsdaten wie API-Schlüssel und Datenbankpasswörter. Wenn eine bösartige Action innerhalb dieser Pipeline läuft, kann sie diese Secrets unbemerkt zu einem vom Angreifer kontrollierten Server weiterleiten. Die erneute Aktivierung hat, selbst ohne neuen Angriffscode, die Hintertür für jeden Workflow effektiv wieder geöffnet, der seit der ersten Bereinigung nicht aktualisiert oder überprüft worden war.

Am 25. September wurden beide Actions auf GitHub erneut deaktiviert, was dazu führte, dass Workflows, die noch auf sie verweisen, sofort fehlschlugen, anstatt die Malware auszuführen. Ein fehlgeschlagener Build ist zwar störend, aber sicherer als das unbemerkte Abfließen von Zugangsdaten. Die Sicherheitswarnung von Socket fordert Entwickler auf, alle Verweise auf beide Actions zu prüfen, sie zu entfernen oder auf einen verifizierten sauberen Commit zu fixieren, die zwischen dem 16. und 25. September ausgeführten Workflow-Läufe zu überprüfen und sofort alle Secrets zu rotieren, auf die diese Workflows Zugriff hatten. Für Website-Betreiber, die auf solche automatisierten Integrationen angewiesen sind, bietet eine verwaltete Hosting-Umgebung wie AEU Hosting fortlaufendes Malware-Scanning und Sicherheits-Härtung, um den Auswirkungsradius zu begrenzen, wenn externe Abhängigkeiten kompromittiert werden.

Die Mini-Shai-Hulud-Attacke veranschaulicht, wie Lieferkettenrisiken lange nach der ersten Eindämmung erneut auftauchen können, wenn Maintainer die Repositories nicht gründlich bereinigen. Das npm-Ökosystem, das von JavaScript-Entwicklern breit genutzt wird, ist ein häufiges Ziel, da ein einziges infiziertes Paket in Tausende Projekte durchsickern kann. Dieser Fall erinnert daran, dass es nicht ausreicht, eine Action zu deaktivieren; die Tags und Commits selbst müssen von bösartigen Inhalten gesäubert werden. Verteidigern wird außerdem geraten, Drittanbieter-Actions auf einen bestimmten, geprüften Commit-Hash zu fixieren, anstatt auf einen veränderlichen Tag zu verweisen – eine Maßnahme, die die automatische erneute Bereitstellung der Malware verhindert hätte.