SleeperGem kaprer sovende RubyGems-kontoer og planter bakdør på utviklermaskiner

En RubyGems-konto som ikke har sluppet en ny versjon på sju år ser ikke farlig ut for noen. Det er nettopp derfor den er verdt å kapre. Sikkerhetsselskapet StepSecurity kaller kampanjen SleeperGem, etter at tre gems fikk ondsinnede versjoner publisert til RubyGems 18. og 19. juli.

Den mest åpenbare av dem, git_credential_manager, utgir seg for å være Microsofts offisielle Git Credential Manager. De to andre, Dendreo og fastlane-plugin-run_tests_firebase_testlab, hadde ligget stille siden henholdsvis 2020 og 2019. Ingen av de nye versjonene har en tilhørende commit eller tag i kildeprosjektet, og det er signaturen på at de aldri kom fra det ekte prosjektet. Forskerne bekreftet dem ved å sammenligne publiseringstidslinjen på RubyGems mot release-taggene på GitHub.

«En RubyGems-konto som har vært stille i seks eller sju år ser ikke risikabel ut for noen. Det er akkurat den profilen som er verdt å ta over.» — Charlie Eriksen, sikkerhetsforsker i Aikido Security

Det taktisk interessante er at malwaren aktivt unngår CI. Etter installasjon skanner den rundt 30 miljøvariabler knyttet til GitHub Actions, GitLab, CircleCI, Travis, Jenkins og Vercel, og avslutter umiddelbart hvis den finner noen av dem. Målet er utviklermaskinen, ikke den kortlevde byggeserveren, fordi det er der legitimasjonen faktisk ligger lagret over tid. Nyttelasten hentes fra en Forgejo-instans angriperen kontrollerer, og etablerer persistens både som cron-jobb og som systemd-brukertjeneste. Kan du kjøre sudo uten passord, kjører skriptet seg selv på nytt som root og legger igjen et setuid-skall forkledd som et nettverksverktøy.

Spredningen er verdt å merke seg for deg som drar inn gems indirekte: git_credential_manager er lagt inn som avhengighet i fem andre pakker, deriblant de to andre kompromitterte. At de involverte pakkene tilhører to ulike vedlikeholderkontoer tyder på at mer enn én konto ble overtatt.

Hva bør du gjøre?

1. Kjør gem list og se etter de tre navnene. Du kan ha fått git_credential_manager indirekte gjennom en avhengighet.
2. Let etter daemonen i ~/.local/share/gcm/, fjern cron- og systemd-persistensen, og sjekk om det ligger et setuid-skall på /usr/local/sbin/ping6.
3. Roter alt maskinen har hatt tilgang til. StepSecurity anbefaler å behandle enhver berørt utviklermaskin og alle nåbare hemmeligheter som kompromittert.