GitHub wfx-loot kampaņā nozagti CI piekļuves dati

Uz kuriem programmētājiem šis apdraudējums attiecas?

Svarīgi saprast atšķirību starp Git un GitHub. Git ir versiju kontroles sistēma, kas var darboties pilnībā lokāli programmētāja datorā, savukārt GitHub ir tiešsaistes platforma programmatūras koda glabāšanai, koplietošanai un izstrādes procesu automatizācijai.

Ja programmētājs izmanto tikai lokālo Git, nepublicē savu projektu GitHub un neizmanto GitHub Actions, konkrētais wfx-loot uzbrukuma mehānisms viņa lokālo projektu tieši neapdraud.

Šī nav ievainojamība pašā Git programmā, Visual Studio Code vai citā koda redaktorā. Uzbrukumā tiek izmantoti kompromitēti GitHub piekļuves dati un ļaunprātīgi modificētas CI/CD automatizācijas darbplūsmas.

Apdraudējuma novērtējums atkarībā no programmētāja darba vides

Kā pārbaudīt, vai projekts izmanto tikai lokālo Git?

Programmētājs var atvērt termināli sava projekta mapē, piemēram, Visual Studio Code vidē, un izpildīt komandu:

git remote -v

Ja komanda neatgriež nevienu adresi, lokālajam projektam pašlaik nav konfigurēts attālinātais Git repozitorijs.

Ja komandas izvadē parādās GitHub repozitorija adrese, jāpārbauda arī attiecīgais GitHub repozitorijs.

Programmētājiem, kuri pašlaik strādā tikai lokāli, bet agrāk ir publicējuši projektus GitHub, ieteicams pārbaudīt arī vecos repozitorijus un sava GitHub konta drošības žurnālu.

Vienlaikus jāņem vērā netiešais apdraudējums: kompromitētu programmatūras pakotņu, atkarību vai repozitoriju lejupielāde un ļaunprātīga koda izpilde var apdraudēt arī lokālos projektus.

Drošības pētnieki no Aikido ziņo par «wfx-loot» kampaņu

Drošības pētnieki no Aikido ziņo par «wfx-loot» kampaņu, kurā kopš 10. novembra izmantoti nozagti GitHub kontu piekļuves dati, lai pārbaudītu rakstīšanas tiesības 61 764 repozitorijos. Ar 4 837 kompromitētiem kontiem uzbrucējs atvēra pārbaudes pull request; tas nenozīmē, ka visos šajos repozitorijos tika izpildīts ļaunprātīgs kods. Aikido rīcībā esošie dati liecina, ka vismaz 1 835 repozitorijos kaitīgais kods izpildījās un piekļuves dati varēja nonākt uzbrucēja rokās. Šie skaitļi raksturo pētnieku konstatēto minimumu, nevis galīgu visu skarto projektu uzskaiti.

Uzbrukums sākās ar šķietami nekaitīgu pull request «docs: dependency audit notes» no zara «wfx-docs». Tas kalpoja tiesību pārbaudei, nevis pats par sevi bija galvenā datu zādzības daļa. Pēc tam uzbrucējs varēja iešūt aptuveni 1500 rindu skriptu esošā GitHub Actions darbplūsmā, pievienot atsevišķu darbplūsmu īslaicīgā zarā vai izveidot npm instalēšanas «postinstall» āķi. Pēc izpildes izmaiņas tika atsauktas un darbplūsmas palaišanas ieraksti ar žurnāliem dzēsti ne ilgāk kā minūtes laikā. Aikido novēroja, ka aptuveni 92% pārbaudes pull request palika atvērti.

BleepingComputer ziņo, ka starp kompromitēto kontu īpašniekiem ir cilvēki, kas saistīti ar Fortune 100 uzņēmumiem, ASV Vispārējo pakalpojumu pārvaldi (GSA), Francijas valdību, Nextcloud un WebdriverIO. Aikido ziņojumā šis konkrētais organizāciju uzskaitījums nav sniegts; BleepingComputer minējums nepierāda, ka katrā nosauktajā organizācijā notikusi datu noplūde. Aikido arī norāda, ka vismaz 50 kompromitētiem lietotājiem, šķiet, bija tiesības publicēt pakotnes npm, Go, Packagist, PyPI vai crates ekosistēmās. Konta kompromitēšana un iespēja publicēt pakotnes pati par sevi nenozīmē, ka visi šie reģistri tika izmantoti uzbrukuma izplatīšanai.

Skripts meklēja GitHub Actions noslēpumus, piekļuves pilnvaras, mākoņpakalpojumu AWS, Azure un Google Cloud akreditācijas datus, SSH atslēgas un arī AI rīku, tostarp OpenAI, Anthropic, Gemini un Cursor, piekļuves atslēgas. Tas spēja izmantot GitHub OIDC pilnvaras mākoņa sesiju iegūšanai un, ja tiesības to ļāva, radīt noturīgāku piekļuvi. Taču skripta iespējas nav tas pats, kas pierādījums par katras šādas darbības veikšanu katrā skartajā repozitorijā. Aikido norāda, ka šajā kampaņā datu nosūtīšanai izmantoti HTTP pieprasījumi uz uzbrucēja serveriem; atsevišķu artefaktu neesamība pati par sevi neizslēdz kompromitēšanu.

Repozitoriju uzturētājiem vērts pārbaudīt «wfx-docs» zaru, minēto pull request nosaukumu, aizdomīgus CI izmaiņu komitus un iztrūkstošus GitHub Actions palaišanas numurus. Ja kaitīgais kods darbplūsmā tiešām izpildījies, par kompromitētiem jāuzskata visi tai pieejamie noslēpumi un mākoņa lomas: akreditācijas dati jānomaina, jāpārskata OIDC uzticības konfigurācija un jāmeklē neatļautas izmaiņas mākoņa identitātēs. Tikai atvērts pārbaudes pull request vēl nepierāda, ka konkrētā projekta noslēpumi nozagti, taču tas ir pietiekams iemesls nekavējoties pārbaudīt repozitorija un konta piekļuves vēsturi.

Avots: avots: Aikido Security

Praktiska pārbaude: vai mans GitHub konts un repozitoriji ir skarti?

Programmētāji un repozitoriju uzturētāji var patstāvīgi pārbaudīt, vai viņu GitHub kontā nav konstatējamas wfx-loot uzbrukuma pazīmes. Sākotnējai pārbaudei nav nepieciešams instalēt papildu programmatūru.

1. Lokālā Git projekta pārbaude

Atveriet termināli sava projekta mapē un izpildiet komandu:

git remote -v

Ja komanda neatgriež nevienu adresi, projektam pašlaik nav konfigurēts attālinātais repozitorijs. Ja projekts nekad nav publicēts GitHub, konkrētais GitHub repozitoriju uzbrukuma mehānisms uz to tieši neattiecas.

2. Aizdomīgo Pull request pārbaude

Autorizējieties savā GitHub kontā un atveriet GitHub meklētāju.

Meklēšanas vaicājumi jāievada augšējā meklēšanas laukā ar lupas ikonu (Type / to search), nevis GitHub Copilot čatā.

Turpmākajos piemēros USERNAME jāaizstāj ar savu GitHub lietotājvārdu. Filtrs user:USERNAME ierobežo meklēšanu līdz konkrētajam lietotājam piederošajiem repozitorijiem.

Secīgi izpildiet šādus meklēšanas vaicājumus:

user:USERNAME is:pr head:wfx-docs

user:USERNAME is:pr "docs: dependency audit notes" in:title

author:USERNAME is:pr head:wfx-docs

author:USERNAME is:pr "docs: dependency audit notes" in:title

Kreisajā izvēlnē atlasiet Pull requests.

Pirmie divi vaicājumi pārbauda lietotājam piederošos repozitorijus, savukārt pēdējie divi palīdz atrast aizdomīgus pieprasījumus, kas izveidoti lietotāja vārdā arī citos repozitorijos.

3. Aizdomīgo komitu pārbaude

GitHub meklēšanas laukā secīgi ievadiet:

user:USERNAME "ci: refresh build cache"

user:USERNAME "chore: add ci helper"

user:USERNAME "chore: add dependency audit workflow"

user:USERNAME "ci: restore"

user:USERNAME "ci: cleanup"

Kreisajā izvēlnē atlasiet Commits.

Ja meklētājs parāda «0 results», attiecīgais komita nosaukums nav atrasts.

Svarīgi: GitHub kopējā komitu meklēšana pārbauda tikai repozitoriju galvenos zarus. Tā neaptver visu izdzēsto vai pārējos zaros esošo komitu vēsturi.

Organizācijām filtra user:USERNAME vietā jāizmanto org:ORGANIZATION, bet konkrēta repozitorija pārbaudei — repo:OWNER/REPOSITORY.

Jāpārbauda arī repozitoriji, kuros lietotājam ir rakstīšanas tiesības, bet kuri viņam nepieder.

4. Repozitoriju aktivitāšu pārbaude

Atveriet katru GitHub repozitoriju un izvēlieties sadaļu Code → Activity.

Aktivitāšu vēsture pieejama arī adresē:

https://github.com/OWNER/REPOSITORY/activity

Pārbaudiet darbības, sākot no 2026. gada 10. novembra.

Īpaša uzmanība jāpievērš:

• Nepazīstamiem komitiem un lietotājiem.
• Zara wfx-docs izveidošanai.
• Zariem ar nosaukumu chore/, kam seko astoņas nejaušas rakstzīmes.
• Zariem ar nosaukumu ci-check-, kam seko četri cipari.
• Komitu vēstures pārrakstīšanai (Force pushes).
• Neparedzētai zaru dzēšanai (Branch deletions).
• Īslaicīgām izmaiņām .github/workflows/ direktorijā.
• Aizdomīgiem .ci-*.sh skriptiem.
• Neparedzētiem postinstall ierakstiem failā package.json.

Pašreizējā failu satura pārbaude vien nav pietiekama, jo uzbrucējs pēc kaitīgā koda izpildes varēja atsaukt izmaiņas.

5. GitHub Actions pārbaude

Repozitorijā atveriet sadaļu Actions.

Tiešā adrese:

https://github.com/OWNER/REPOSITORY/actions

Pārbaudiet katras darbplūsmas palaišanas vēsturi un pievērsiet uzmanību iztrūkstošiem palaišanas numuriem.

Piemēram:

• CI #101 — veiksmīga izpilde.
• CI #102 — veiksmīga izpilde.
• CI #103 — ieraksts iztrūkst.
• CI #104 — veiksmīga izpilde.

Iztrūkstošs palaišanas numurs var liecināt par izdzēstu darbplūsmas izpildes ierakstu. Ja tas sakrīt ar aizdomīga komita laiku, nepieciešama padziļināta izmeklēšana.

Iztrūkstošs numurs pats par sevi vēl nepierāda uzbrukumu.

Ja organizācijai ir pieejams Audit log, tajā var meklēt darbplūsmu palaišanas dzēšanas notikumus:

action:workflows.delete_workflow_run

6. GitHub konta drošības pārbaude

Šīs pārbaudes jāveic vienreiz visam GitHub kontam, nevis katram repozitorijam atsevišķi.

GitHub drošības žurnālā var izmantot arī šādus meklēšanas filtrus:

created:>=2026-11-10

action:user.login

action:oauth_access.create

action:oauth_authorization.create

action:workflows.delete_workflow_run

Autorizētas lietotnes, piemēram, Visual Studio Code vai GitHub Copilot, pašas par sevi nav uzbrukuma pazīme, ja lietotājs tās atpazīst un ir autorizējis.

7. GitHub Actions noslēpumu pārbaude

Repozitorijā atveriet:

Settings → Secrets and variables → Actions

Pārbaudiet, vai repozitorijā, organizācijā vai izvietošanas vidēs (Environments) tiek izmantotas API atslēgas, paroles, piekļuves tokeni vai mākoņpakalpojumu akreditācijas dati.

Jāpārbauda arī mākoņpakalpojumu piekļuve ar OIDC, jo tā var darboties bez GitHub saglabātām pastāvīgām piekļuves atslēgām.

Ja kaitīgais kods ir izpildījies, jāuzskata, ka darbplūsmai pieejamie noslēpumi un mākoņa lomas var būt kompromitēti.

8. Kā interpretēt pārbaudes rezultātus?

9. Ko darīt, ja konstatētas uzbrukuma pazīmes?

• Saglabāt aizdomīgo komitu, Pull request un darbplūsmu saites izmeklēšanai.
• Apturēt skartās GitHub Actions darbplūsmas.
• Atsaukt kompromitētos tokenus un nepazīstamās autorizācijas.
• Pārtraukt nepazīstamās GitHub sesijas.
• Nomainīt kompromitētās paroles un API atslēgas attiecīgajos pakalpojumos.
• Pārbaudīt AWS, Azure un Google Cloud piekļuves tiesības un OIDC uzticības konfigurāciju.
• Novērst ļaunprātīgās koda izmaiņas pirms darbplūsmu atkārtotas palaišanas.
• Neizpildīt aizdomīgus skriptus un neinstalēt kompromitētas programmatūras pakotnes.

Negatīvs pārbaudes rezultāts nav absolūta drošības garantija. Uzbrucēji varēja izdzēst komitus, zarus un darbplūsmu izpildes ierakstus. Tomēr šīs pārbaudes palīdz identificēt zināmās wfx-loot kampaņas pazīmes.

Papildu informācija:

• Aikido Security — wfx-loot uzbrukuma analīze
• GitHub dokumentācija — komitu meklēšana
• GitHub dokumentācija — Pull request meklēšana
• GitHub dokumentācija — konta drošības žurnāls