GitHub hesablarının ələ keçirilməsi: wfx-loot kampaniyası

wfx-loot GitHub kampaniyası nədir?

wfx-loot hücumçunun oğurlanmış GitHub kimlik məlumatlarından istifadə edərək həmin hesabların yaza bildiyi repozitoriyalara zərərli workflow göndərdiyi və GitHub Actions sirlərini və bulud kimlik məlumatlarını oğurladığı kampaniyadır ^[1]. Bunu ilk bildirən Aikido Security ona hücumçunun zərərli proqram üçün özünün işlətdiyi ad (“wfx”) və oğurlanmış sirlər üçün istifadə etdiyi söz (“loot”) əsasında ad verib ^[1]. SafeDep də ilk hesabatı Aikido-ya aid edir ^[5].

StepSecurity eyni oğrunu “wfx” adlandırır və əsas məqamı vurğulayır: hücumçu GitHub Actions-dakı xətadan istifadə etmir ^[2]. Əvəzində real developer və bot hesabları üçün etibarlı tokenlərdən istifadə edir, developer kimi pull request-lər açır və commit-lər göndərir ^[2][4].

Aikido hesab edir ki, əsas məqsəd proqram paketləri vasitəsilə yayılmaq yox, CI sirləridir; baxmayaraq ki, payload avtomatik dərc tətikləyiciləri vasitəsilə ən azı bir Packagist və bir Go paketinə çatıb ^[1]. Aikido-nun təhlilinə əsaslanan BleepingComputer yazır ki, ələ keçirilmiş hesabların bəziləri böyük təşkilatlara məxsus olub ^[3].

wfx-loot hücumu nə qədər genişdir?

Aikido 61.764 repozitoriyada yoxlama pull request-ləri açmış 4.837 ələ keçirilmiş hesab sayır; oğru ən azı 1.806 repozitoriyada işləyib ^[1]. Tədqiqatçılar arasında rəqəmlər bir qədər fərqlənir, çünki hər biri kampaniya hələ aktiv ikən GitHub-da fərqli vaxtda axtarış edib.

• Aikido: 4.837 hesab, 61.764 repozitoriya; 10.431 pull request hesabın sahibi olmadığı repozitoriyalara göndərilib; 92%-i hələ də açıqdır; ən azı 50 ələ keçirilmiş istifadəçi npm, Go, Packagist, PyPI və ya crates-də paket dərc edir ^[1].
• Aikido (xülasə rəqəmi): ən azı 1.835 repozitoriya payload-u işlədib və kimlik məlumatları götürülüb; BleepingComputer bu rəqəmdən istifadə edir ^[1][3].
• StepSecurity: 12 noyabr saat 07:40 UTC-yə 63.000-dən çox yoxlama pull request-i, təxminən 90%-i hələ də açıq ^[2].
• SafeDep: 8.093 repozitoriya 10-12 noyabr arasında zərərli commit-lər alıb; SecurityWeek-in qeyd etdiyi kimi, bu rəqəm oğrunun icra olunduğunu mütləq göstərmir ^[5][4].

Aikido xəbərdarlıq edir ki, onun icra sayı təsiri az göstərə bilər, çünki təsirlənmiş repozitoriyalarda işləmə jurnalları silinib ^[1].

wfx-loot oğrusu necə işləyir?

Oğurlanmış tokenin yaza bildiyi hər repozitoriya üçün hücumçu yoxlayır, payload-u göndərir, sonra təxminən bir dəqiqə ərzində izləri təmizləyir ^[1].

1. Yoxlama: wfx-docs adlı budaqdan “docs: dependency audit notes” başlıqlı pull request kiçik qeyd faylı əlavə edir. StepSecurity deyir: “Pull request özü heç nə etmir”; o, yalnız tokenin yazma icazəsi olduğunu göstərir ^[2][4].
2. Payload: təxminən 1.500 sətirlik shell skripti üç yoldan biri ilə gəlir: mövcud workflow-a yeridilir (“ci: refresh build cache”), skript və npm postinstall hook kimi (“chore: add ci helper”) və ya birdəfəlik chore/ budağında yeni workflow kimi (“chore: add dependency audit workflow”) ^[1].
3. Təmizləmə: hücumçu dəyişikliyi geri qaytarır və workflow run-u və onun jurnallarını silir ^[1]. Çatışmayan run nömrəsi çox vaxt yeganə izdir ^[1].

Skript GitHub Actions sirlərini və tokenlərini, runner mühitinin tam məzmununu, AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH və digərləri üçün kimlik məlumatı fayllarını, shell tarixçələrini, AI provayderləri və developer alətləri üçün açarları toplayır ^[1][3]. O, hətta runner-də işləyən proseslərin yaddaşını da oxuyur ^[1][4]. Aikido müəyyən edib ki, təhlil etdiyi nüsxələr oğurlanmış məlumatı yalnız hücumçunun idarə etdiyi serverlərə HTTP POST ilə göndərirdi ^[1]. StepSecurity sonradan dəyişiklik gördü: 12 noyabr təxminən 05:30 UTC-dən yeni nüsxələr məlumatı yalnız Telegram vasitəsilə göndərirdi, ona görə dərc edilmiş server ünvanlarını bloklamaq tək başına artıq onları dayandırmır ^[2].

Sirləri dəyişdirmək niyə kifayət deyil?

Çünki oğru kimlik məlumatlarının dəyişdirilməsindən sağ çıxan arxa qapılar yerləşdirməyə çalışır ^[1][2]. Aikido üç davamlılıq üsulunu təsvir edir ^[1]:

• Saxta status yoxlamaları: Aikido bildirir ki, o, repozitoriyanın tələb olunan yoxlamalarının adlarından istifadə edərək saxta “uğur” yoxlamaları göndərir və bu, budaq qorunmasının birləşdirmə maneələrini aça bilər ^[1]. StepSecurity bu funksiyanın baxdığı bütün 101 nümunədə söndürülmüş olduğunu müəyyən edib ^[2].
• AWS etibar siyasətinin yenidən yazılması: o, rolun etibar siyasətini istənilən AWS hesabına icazə verəcək şəkildə təyin edə bilər ^[1].
• Azure federativ kimlik yeridilməsi: o, Azure AD tətbiqlərinə wfx-ci-… adlı federativ kimlik məlumatları əlavə edə bilər və bununla ələ keçirilmiş repozitoriyadakı workflow-lar saxlanılmış sirr olmadan autentifikasiya edə bilər ^[1].

O, həmçinin GitHub OIDC tokenləri yarada və onları AWS, Google Cloud və Azure sessiyaları ilə dəyişə, digər IAM rollarına zəncirlənə və uzunmüddətli AWS giriş açarları yarada bilər ^[1][3]. Məhz buna görə StepSecurity “davamlılığı silin, çünki yalnız dəyişdirmək onu silmir” deyir ^[2].

GitHub repozitoriyalarımın hədəf olub-olmadığını necə yoxlayım?

Noyabrın 10-dan bəri yoxlama pull request-ini və hücumçunun commit mesajlarını axtarın, sonra workflow run nömrələrindəki boşluqlara baxın ^[2][1].

1. Pull request-lərdə “docs: dependency audit notes”u və wfx-docs və ya chore/ ardınca səkkiz simvol olan budaqları axtarın ^[1][2].
2. 10 noyabrdan bəri commit-lərdə “ci: refresh build cache”, “ci: restore”, “ci: cleanup”, “chore: add ci helper” və “chore: add dependency audit workflow”u axtarın ^[2].
3. Hər tapıntı üçün Actions sekmesini açın və commit-dən dərhal sonra çatışmayan run nömrəsini axtarın; StepSecurity bunu oğrunun işlədiyinin ən etibarlı əlaməti adlandırır ^[2].
4. Commit-ləri hansı hesabın göndərdiyini qeyd edin: həmin hesabın tokenləri oğurlanıb ^[2]. Yoxlama pull request-i varsa, payload işləməsə belə hesab ələ keçirilib ^[1].

Çatışmayan artefaktlara arxalanmayın. Aikido bildirir ki, wfx-loot artefaktlarının, wfx- keş qeydlərinin və ya xüsusi addım xülasələrinin olmaması məlumatın götürülmədiyi demək deyil, çünki bu kanallar bu kampaniyada söndürülmüşdü ^[1]. Aikido həmçinin payload-un ictimai repozitoriyalarla yanaşı şəxsi repozitoriyalara da yerləşdirilə biləcəyini bildirir ^[1].

Oğru işləyibsə nə etməliyəm?

Təsirlənmiş workflow-un əlçatan olduğu hər sirrin və bulud rolunun ələ keçirildiyini fərz edin, onları dəyişdirin və sonra davamlılığı axtarın ^[1][2].

• Dəyişdirin: job-un çata biləcəyi hər repozitoriya, mühit və təşkilat sirrini, yalnız workflow-un adlandırdıqlarını yox; npm, PyPI və digər dərc tokenlərini; və sirr kimi saxlanılan bulud açarlarını ^[2].
• Paketləri yoxlayın: zərərli commit-dən sonra dərc olunmuş paket versiyalarını axtarın ^[2].
• AWS: istənilən AWS principal-ına icazə verən etibar siyasətlərini, 10 noyabrdan bəri yaradılmış IAM giriş açarlarını və wfx- ilə başlayan CloudTrail sessiyalarını axtarın ^[2].
• Azure: tətbiq qeydiyyatlarında wfx-ci-* adlı federativ kimlik məlumatlarını silin ^[2].
• Google Cloud, Vault, Kubernetes: GitHub Actions giriş tokenləri ilə edilmiş token yaradılmasını və girişləri nəzərdən keçirin ^[2].
• GitHub: qalan budaqları silin, yoxlama pull request-lərini bağlayın, saxta yoxlama üzərindən heç nəyin birləşdirilmədiyini yoxlayın və hesabın tokenlərini, OAuth icazələrini və SSH açarlarını ləğv edin ^[2].
• Tokenlər, GitHub sənədlərinə görə: Settings, Developer settings altında şəxsi giriş tokenlərinizi nəzərdən keçirin və tanımadığınız və ya ehtiyac duymadığınız tokenləri silin; GitHub dəqiq təyin olunmuş (fine-grained) tokenləri, yalnız zəruri minimum icazələri və bitmə tarixini tövsiyə edir, çünki klassik token sizin çata bildiyiniz hər repozitoriyaya çata bilər ^[6].

npm hook developer maşınlarında da işləyir: qısa pəncərə ərzində npm install işlədən hər kəs oğrunu lokal olaraq işlədib və öz kimlik məlumatlarını da dəyişməlidir ^[2]. SecurityWeek bir neçə təhlükəsizlik şirkətinin məsləhətini ümumiləşdirir: ələ keçirilmiş tokenləri ləğv edin, açıq qalmış sirləri dəyişdirin və icazəsiz bulud dəyişikliklərini yoxlayın ^[4]. Bot hesabları üçün StepSecurity həmçinin onların budaq qorunmasını keçmək üçün ümumiyyətlə icazəyə ehtiyacı olub-olmadığını nəzərdən keçirməyi təklif edir ^[2]. Güclü giriş qoruması oğurlanmış hesab kampaniyalarını çətinləşdirir; bax: İki faktorlu autentifikasiya izah olunur: hansı 2FA üsulu ən təhlükəsizdir?.

Hansı paketlər təsirlənib?

Aikido avtomatik dərc vasitəsilə payload götürmüş bir Packagist paketini və bir Go modulunu sadalayır ^[1].

• Packagist: digitalelvis/neuronai-studio versiya 3.14.3; Aikido deyir ki, onu quraşdıran və ya açan hər maşını ələ keçirilmiş hesab edin ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 və v1.0.280; payload yalnız GitHub Actions workflow faylındadır, Go mənbə kodu və binar fayllar dəyişməyib və Go build-ləri heç vaxt workflow fayllarını işlətmir, lakin Aikido yenə də bu versiyaların silinməsini tövsiyə edir ^[1].

Say fərqlidir: SafeDep Packagist-də və Go module proxy-də üç paketin payload daşıdığını bildirir, SecurityWeek isə iki Go modulunun versiyalarını qeyd edir ^[5][4]. SafeDep əlavə edir ki, bu paketləri composer require və ya go get ilə quraşdıran tipik istifadəçilər üçün payload işləməyib ^[5]. Hər birinə arxalanmazdan əvvəl hər tədqiqatçının cari siyahısını yoxlayın.

wfx-loot-un arxasında kim dayanır və tokenləri necə əldə ediblər?

Burada adı çəkilən hesabatların heç biri hücumçunu müəyyən etmir və StepSecurity tokenlərin necə əldə olunduğunu müəyyən etmədiyini bildirir ^[2][4].

StepSecurity Fly.io GitHub App-a verilmiş tokenlər vasitəsilə 19 hesabdan edilmiş 173 yoxlama pull request-i tapıb; onların necə əldə olunduğunu müəyyən edə bilmədiyini və Fly.io infrastrukturunun pozulduğuna dair sübutu olmadığını bildirib ^[2][4].

Aikido oktyabrdakı GhostAction dalğasından təsirlənmiş hesablarla üst-üstə düşmə tapıb və wfx-loot-un 100-dən çox repozitoriyada GhostAction workflow fayllarına yeridildiyini görüb, lakin ikisini, oğurlanmış kimlik məlumatları tez-tez bir neçə qrupun əlinə keçdiyi üçün, ehtimal ki, müxtəlif aktorlar tərəfindən idarə olunan ayrı kampaniyalar kimi qiymətləndirib ^[1]. O, həmçinin zərərli proqramın bəzi yeni versiyalarında indoneziyadilli şərhlər fərq edib ^[1]. Tokenlərin diqqətlə saxlanması burada vacibdir; əsasları Parol menecerləri izah olunur: necə işləyir və təhlükəsizdirmi əhatə edir.