Besmette GitHub Actions stonden negen dagen weer open met malware uit mei erin

Twee GitHub Actions die in mei werden gekaapt tijdens de Mini Shai-Hulud-campagne, zijn door hun beheerder opnieuw geactiveerd zonder dat de besmette release-tags waren opgeschoond. Negen dagen lang haalden workflows die naar die tags verwijzen de oude malware weer binnen en voerden die uit. Dat blijkt uit onderzoek van securitybedrijf Socket, dat werd opgetekend door BleepingComputer.

Wat er in mei gebeurde

De twee getroffen Actions zijn actions-cool/issues-helper en actions-cool/maintain-one-comment, allebei hulpmiddelen voor het opruimen en beheren van issues. Ze raakten op 18 mei besmet. Het securityteam van GitHub haalde ze daarna offline, waardoor workflows die ernaar verwezen de malware niet meer konden downloaden.

Die verwijdering hoorde bij de bredere Mini Shai-Hulud-aanval, een supplychainincident dat volgens het bericht 323 packages en 639 package-versies op npm raakte. De ingesloten malware was gericht op tokens, inloggegevens en CI/CD-secrets van ontwikkelaars: precies het materiaal waarmee een aanvaller zich verder door een pipeline heen kan werken.

Heropend, maar niet opgeschoond

Op 16 september werden beide repositories weer toegankelijk. Het probleem is dat de release-tags niet eerst zijn opgeruimd. "They still point to the malicious content introduced on May 18, so any workflow that references either action by a version tag resumed downloading and executing the payload on its next run", schrijft Socket.

De onderzoekers stelden vast dat de release-tags verwezen naar een commit waarin een versluierde payload in het bestand index.js zat. Het blootstellingsvenster begon op 16 september tussen 11:09 en 18:16 in de Nederlandse tijdzone. Waarom de repositories zonder schoonmaak weer opengezet zijn, is niet duidelijk.

Op 25 september bleken beide Actions opnieuw uitgeschakeld. Workflows die ernaar verwijzen falen sindsdien, in plaats van de payload uit te voeren.

Hoe groot is de schade

De dependency graph van GitHub telt ongeveer 15.000 repositories die van issues-helper afhangen. Dat betekent niet dat ze allemaal besmet zijn. Socket heeft naar eigen zeggen nog niet vastgesteld hoeveel van die repositories de Action via een verplaatsbare versietag aanroepen in plaats van via een vastgepinde commit-hash. Alleen de eerste groep loopt risico.

Wel wijzen de onderzoekers erop dat dit type Action bijna dagelijks draait, omdat issue-onderhoud nu eenmaal doorlopend werk is. Wie de Action met een tag gebruikt, heeft in die negen dagen dus waarschijnlijk meerdere runs gehad.

Wat je nu moet doen

Socket adviseert vier stappen. Zoek in je repositories naar verwijzingen naar beide Actions. Verwijder ze, of pin ze vast op een commit waarvan is geverifieerd dat die schoon is. Loop de workflow-runs sinds 16 september na. En roteer alle secrets waar workflows bij konden die in die periode een getroffen tag hebben gedraaid.

Dat laatste is de kern: zelfs als de Action inmiddels weer geblokkeerd is, blijven gelekte tokens geldig tot je ze intrekt. Het incident onderstreept meteen waarom het vastpinnen van Actions op een commit-hash in plaats van op een tag als @v3 geen overdreven voorzichtigheid is. Een tag kan naar nieuwe inhoud gaan wijzen zonder dat er in jouw repository iets verandert.