61 GitHub-repo's aangevallen via verborgen tekst in issues

Onderzoekers van Radware hebben een campagne blootgelegd waarbij 61 publieke GitHub-repositories zijn aangevallen met commando's die verstopt zaten in issues, pull requests en reacties. Onder de doelwitten zitten bekende open source-projecten als Trivy, MLflow, Brave en discord.js. The Register publiceerde het onderzoek vandaag, met interviews met de onderzoekers.

Hoe de keten werkt

De aanvaller plaatst een issue, pull request of reactie waarin kwaadaardige commando's zijn weggestopt in HTML-comments. Daardoor is de inhoud niet te zien op de gerenderde pagina. Is een repository zo ingesteld dat zo'n GitHub-event automatisch een workflow start, dan hoeft de aanvaller daarna niets meer te doen.

"De workflow wordt binnen een seconde automatisch getriggerd, en is die workflow inderdaad kwetsbaar, dan wordt de aanval succesvol uitgevoerd", zegt Radware-onderzoeker Gabi Nakibly tegen The Register. De kwetsbaarheid zit niet in GitHub zelf, maar in workflows die door de aanvaller aangeleverde tekst rechtstreeks in shell-code opnemen. De shell voert het verborgen commando dan uit, harkt de omgevingsvariabelen op en probeert die naar een server van de aanvaller te sturen.

Dat maakt de drempel laag. "De aanvaller hoeft de repository niet te compromitteren en geen toegang tot de codebase te hebben", zegt collega-onderzoeker Zvika Babo. "In feite kan elke gebruiker met een GitHub-account deze aanval proberen."

Omvang en timing

Peildatum 13 oktober identificeerden de onderzoekers 83 GitHub-items met een werkende payload, verspreid over 61 repositories. Opvallend is de timing: 77 van die items werden geplaatst binnen een tijdvak van 43 minuten op 1 september, de overige zes in de twee minuten daarna. Er werden 74 verschillende GitHub-accounts gebruikt, waarvan veel een geloofwaardige ontwikkelhistorie hadden — vermoedelijk overgenomen accounts. Radware vermoedt één persoon achter de campagne.

De getroffen projecten lopen van AI-frameworks tot securitytools en infrastructuur. In het rapport staan onder meer agno-agi/agno (42.700 sterren), ToolJet (41.100), google/langextract (38.900), aquasecurity/trivy (38.400), CopilotKit (38.000), podman-container-tools/podman (33.000), QwenLM/qwen-code (28.500), mlflow (28.400), discordjs/discord.js (26.800), cilium (25.600), brave/brave-browser (23.900), dotnet/maui (23.300), Homebrew/homebrew-cask (22.200), github/docs (21.000), apache/doris (16.000) en PX4-Autopilot (12.800).

In twee gevallen vonden de onderzoekers in de logs bewijs dat het kwaadaardige commando daadwerkelijk in de automatiseringsomgeving heeft gelopen. Of de aanvaller daarmee ook schrijfrechten op een repository kreeg, broncode heeft gewijzigd of software verderop in de keten heeft besmet, kunnen ze niet met zekerheid zeggen. Alle maintainers zijn geïnformeerd; de meeste repositories zijn volgens Radware gedicht of gesloten, maar niet van alle is dat te bevestigen.

Wat je nu kunt doen

De onderzoekers verwachten niet dat dit soort pogingen stopt. "De enige manier is zorgen dat de workflow-code weerbaar is en niet kwetsbaar voor zulke aanvallen", zegt Nakibly. Hun aanbevelingen:

• Geef CI/CD-workflows zo min mogelijk rechten.
• Scheid workflows die door externe events worden getriggerd zo veel mogelijk van jobs met verhoogde rechten.
• Behandel inhoud van buiten als onbetrouwbaar, en neem die nooit ongefilterd op in shell-commando's.
• Beperk welke secrets en omgevingsvariabelen een workflow überhaupt kan zien.

Dat laatste is de kern. Wie een publieke repository heeft met een workflow die op issues of pull requests afgaat, kan dat vandaag nakijken: welke secrets staan in die job, en heeft die job ze echt nodig?