GitHub Hesapları Ele Geçirildi: wfx-loot Sırları Çalıyor

wfx-loot GitHub kampanyası nedir?

wfx-loot, bir saldırganın çalıntı GitHub kimlik bilgileriyle, bu hesapların yazabildiği depolara kötü amaçlı bir iş akışı gönderdiği, GitHub Actions gizli bilgilerini ve bulut kimlik bilgilerini çaldığı bir kampanyadır ^[1]. İlk bildiren Aikido Security, kampanyaya saldırganın kötü amaçlı yazılım için kullandığı kendi adı ("wfx") ve çalınan gizli bilgiler için kullandığı sözcükten ("loot") yola çıkarak ad verdi ^[1]. SafeDep de ilk raporu Aikido'ya atfediyor ^[5].

StepSecurity aynı hırsıza "wfx" diyor ve önemli bir noktayı vurguluyor: saldırgan GitHub Actions'taki bir hatayı istismar etmiyor ^[2]. Bunun yerine gerçek geliştirici ve bot hesaplarına ait geçerli belirteçleri kullanarak, bir geliştiricinin yapacağı gibi çekme istekleri açıyor ve işlemeler gönderiyor ^[2][4].

Aikido, ana hedefin yazılım paketleri üzerinden yayılmak değil CI gizli bilgileri olduğuna inanıyor; ancak yük en az bir Packagist ve bir Go paketine otomatik yayımlama tetikleyicileri aracılığıyla ulaştı ^[1]. BleepingComputer, Aikido'nun analizine dayanarak ele geçirilen hesaplardan bazılarının büyük kuruluşlara ait olduğunu bildiriyor ^[3].

wfx-loot saldırısı ne kadar büyük?

Aikido, 61.764 depoda yoklama çekme istekleri açan 4.837 ele geçirilmiş hesap sayıyor; hırsız en az 1.806 depoda çalıştı ^[1]. Rakamlar araştırmacılar arasında hafifçe farklılaşıyor; çünkü her biri kampanya hâlâ etkinken GitHub'ı farklı bir zamanda taradı.

• Aikido: 4.837 hesap, 61.764 depo; 10.431 çekme isteği hesabın sahibi olmadığı depolara gitti; %92'si hâlâ açık; ele geçirilen kullanıcılardan en az 50'si npm, Go, Packagist, PyPI veya crates'te paket yayımlıyor ^[1].
• Aikido (özet rakam): en az 1.835 depo yükü çalıştırdı ve kimlik bilgileri alındı; BleepingComputer bu rakamı kullanıyor ^[1][3].
• StepSecurity: 12 Kasım'da 07:40 UTC itibarıyla 63.000'den fazla yoklama çekme isteği, yaklaşık %90'ı hâlâ açık ^[2].
• SafeDep: 10-12 Kasım arasında 8.093 depo kötü amaçlı işlemeler aldı; SecurityWeek'in belirttiği gibi bu rakam hırsızın çalıştığı anlamına gelmek zorunda değil ^[5][4].

Aikido, etkilenen depolarda çalıştırma günlükleri silindiği için çalıştırma sayısının etkiyi olduğundan düşük gösterebileceği uyarısında bulunuyor ^[1].

wfx-loot hırsızı nasıl çalışıyor?

Çalıntı bir belirtecin yazabildiği her depo için saldırgan yoklar, yükü gönderir, sonra yaklaşık bir dakika içinde izleri temizler ^[1].

1. Yoklama: wfx-docs adlı bir daldan gelen, "docs: dependency audit notes" başlıklı bir çekme isteği küçük bir not dosyası ekler. StepSecurity, "Çekme isteği kendi başına hiçbir şey yapmaz" diyor; yalnızca belirtecin yazma erişimi olduğunu gösterir ^[2][4].
2. Yük: yaklaşık 1.500 satırlık bir kabuk betiği üç yoldan biriyle gelir: mevcut bir iş akışına enjekte edilerek ("ci: refresh build cache"), bir betik artı npm postinstall kancası olarak ("chore: add ci helper") veya geçici bir chore/ dalında yeni bir iş akışı olarak ("chore: add dependency audit workflow") ^[1].
3. Temizlik: saldırgan değişikliği geri alır ve iş akışı çalıştırmasını ve günlüklerini siler ^[1]. Eksik bir çalıştırma numarası çoğu zaman tek izdir ^[1].

Betik; GitHub Actions gizli bilgilerini ve belirteçlerini, çalıştırıcının (runner) tüm ortamını, AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH ve daha fazlası için kimlik bilgisi dosyalarını, kabuk geçmişlerini ve yapay zekâ sağlayıcıları ile geliştirici araçlarının anahtarlarını topluyor ^[1][3]. Hatta çalıştırıcıda çalışan süreçlerin belleğini bile okuyor ^[1][4]. Aikido, incelediği kopyaların çalınan verileri yalnızca saldırganın denetimindeki sunuculara HTTP POST ile gönderdiğini buldu ^[1]. StepSecurity daha sonra bir değişiklik gördü: 12 Kasım'da yaklaşık 05:30 UTC'den itibaren yeni kopyalar verileri yalnızca Telegram üzerinden gönderiyor; bu yüzden yayımlanan sunucu adreslerini engellemek tek başına artık onları durdurmuyor ^[2].

Gizli bilgileri yenilemek neden yetmiyor?

Çünkü hırsız, kimlik bilgisi yenilemesinden sonra da kalan arka kapılar yerleştirmeye çalışıyor ^[1][2]. Aikido üç kalıcılık hilesi anlatıyor ^[1]:

• Sahte durum denetimleri: Aikido, bir deponun zorunlu denetimlerinin adlarını kullanarak sahte "başarılı" denetimler gönderdiğini söylüyor; bu, dal koruması birleştirme kapılarını geçebilir ^[1]. StepSecurity bu özelliğin incelediği 101 örneğin hepsinde kapalı olduğunu buldu ^[2].
• AWS güven politikası yeniden yazımı: bir rolün güven politikasını herhangi bir AWS hesabına izin verecek şekilde ayarlayabilir ^[1].
• Azure federasyon kimliği enjeksiyonu: Azure AD uygulamalarına wfx-ci-… adlı federasyon kimlik bilgileri ekleyebilir; bu, ele geçirilen depodaki iş akışlarının saklanan bir gizli bilgi olmadan kimlik doğrulamasına izin verir ^[1].

Ayrıca GitHub OIDC belirteçleri üretip bunları AWS, Google Cloud ve Azure oturumlarıyla değiştirebilir, diğer IAM rollerine zincirleme geçebilir ve uzun ömürlü AWS erişim anahtarları oluşturabilir ^[1][3]. StepSecurity'nin "kalıcılığı kaldırın, çünkü yenileme tek başına kaldırmaz" demesinin nedeni bu ^[2].

GitHub depolarımın vurulup vurulmadığını nasıl kontrol ederim?

10 Kasım'dan itibaren yoklama çekme isteğini ve saldırganın işleme mesajlarını arayın, ardından iş akışı çalıştırma numaralarındaki boşluklara bakın ^[2][1].

1. Çekme isteklerinde "docs: dependency audit notes" ifadesini ve wfx-docs ya da chore/ ardından sekiz karakter şeklinde adlandırılmış dalları arayın ^[1][2].
2. 10 Kasım'dan beri işlemelerde "ci: refresh build cache", "ci: restore", "ci: cleanup", "chore: add ci helper" ve "chore: add dependency audit workflow" ifadelerini arayın ^[2].
3. Her eşleşme için Actions sekmesini açın ve işlemenin hemen ardından eksik bir çalıştırma numarası arayın; StepSecurity bunu hırsızın çalıştığının en güvenilir işareti olarak nitelendiriyor ^[2].
4. İşlemeleri hangi hesabın gönderdiğine dikkat edin: o hesabın belirteçleri çalınmıştır ^[2]. Bir yoklama çekme isteği varsa, hiçbir yük çalışmamış olsa bile hesap ele geçirilmiştir ^[1].

Eksik izlere güvenmeyin. Aikido, wfx-loot yapıtlarının, wfx- önbellek girdilerinin veya özel adım özetlerinin bulunmamasının verinin alınmadığı anlamına gelmediğini söylüyor; çünkü bu kanallar bu kampanyada kapatılmıştı ^[1]. Aikido ayrıca yükün herkese açık depoların yanı sıra özel depolara da yerleştirilmiş olabileceğini belirtiyor ^[1].

Hırsız çalıştıysa ne yapmalıyım?

Etkilenen iş akışının kullanabildiği her gizli bilginin ve bulut rolünün ele geçirildiğini varsayın, bunları yenileyin, sonra kalıcılık izlerini arayın ^[1][2].

• Yenileyin: işin erişebildiği her depo, ortam ve kuruluş gizli bilgisini, yalnızca iş akışının adını andıklarını değil; npm, PyPI ve diğer yayımlama belirteçlerini; ve gizli bilgi olarak saklanan bulut anahtarlarını ^[2].
• Paketleri kontrol edin: kötü amaçlı işlemeden sonra yayımlanan paket sürümlerini arayın ^[2].
• AWS: herhangi bir AWS sorumlusuna izin veren güven politikalarını, 10 Kasım'dan beri oluşturulan IAM erişim anahtarlarını ve wfx- ile başlayan CloudTrail oturumlarını arayın ^[2].
• Azure: uygulama kayıtlarında wfx-ci-* adlı federasyon kimlik bilgilerini silin ^[2].
• Google Cloud, Vault, Kubernetes: GitHub Actions oturum açma belirteçleriyle yapılan belirteç üretimini ve oturum açmaları gözden geçirin ^[2].
• GitHub: kalan dalları silin, yoklama çekme isteklerini kapatın, sahte bir denetim üzerinden hiçbir şeyin birleştirilmediğini kontrol edin ve hesabın belirteçlerini, OAuth izinlerini ve SSH anahtarlarını iptal edin ^[2].
• Belirteçler, GitHub'ın belgelerine göre: kişisel erişim belirteçlerinizi Settings, Developer settings altında gözden geçirin ve tanımadığınız ya da ihtiyaç duymadığınız her birini silin; GitHub, ayrıntılı (fine-grained) belirteçleri, yalnızca gereken en düşük izinleri ve bir son kullanma tarihini öneriyor, çünkü klasik bir belirteç erişebildiğiniz her depoya erişebilir ^[6].

npm kancası geliştirici makinelerinde de çalışır: kısa süre içinde npm install çalıştıran herkes hırsızı yerelde çalıştırmıştır ve kendi kimlik bilgilerini de yenilemelidir ^[2]. SecurityWeek birkaç güvenlik firmasının tavsiyesini özetliyor: ele geçirilen belirteçleri iptal edin, açığa çıkan gizli bilgileri yenileyin ve yetkisiz bulut değişikliklerini kontrol edin ^[4]. Bot hesapları için StepSecurity, dal korumasını atlama iznine hiç ihtiyaç duyup duymadıklarının gözden geçirilmesini de öneriyor ^[2]. Güçlü oturum açma koruması, çalıntı hesap kampanyalarını zorlaştırır; bkz. Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

Hangi paketler etkilendi?

Aikido, yükü otomatik yayımlama yoluyla alan bir Packagist paketini ve bir Go modülünü listeliyor ^[1].

• Packagist: digitalelvis/neuronai-studio sürüm 3.14.3; Aikido, onu kuran ya da açan her makinenin ele geçirilmiş sayılması gerektiğini söylüyor ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 ve v1.0.280; yük yalnızca bir GitHub Actions iş akışı dosyasında, Go kaynağı ve ikili dosyalar değişmedi ve Go derlemeleri iş akışı dosyalarını hiç çalıştırmaz; ancak Aikido yine de bu sürümlerin kaldırılmasını öneriyor ^[1].

Sayılar farklılaşıyor: SafeDep, Packagist'teki ve Go modül proxy'sindeki üç paketin yükü taşıdığını söylüyor, SecurityWeek ise iki Go modülünün sürümlerinden söz ediyor ^[5][4]. SafeDep, bu paketleri composer require veya go get ile kuran tipik kullanıcılar için yükün çalışmadığını da ekliyor ^[5]. Herhangi birine güvenmeden önce her araştırmacının güncel listesini kontrol edin.

wfx-loot'un arkasında kim var ve belirteçleri nasıl ele geçirdi?

Burada anılan raporların hiçbiri saldırganı tanımlamıyor ve StepSecurity belirteçlerin nasıl elde edildiğini belirleyemediğini söylüyor ^[2][4].

StepSecurity, Fly.io GitHub Uygulaması'na verilen belirteçlerle yapılmış, 19 hesaptan 173 yoklama çekme isteği buldu; bunların nasıl elde edildiğini belirleyemediğini ve Fly.io altyapısının ihlal edildiğine dair kanıtı bulunmadığını söyledi ^[2][4].

Aikido, Ekim'deki GhostAction dalgasından etkilenen hesaplarla örtüşme buldu ve 100'den fazla depoda GhostAction iş akışı dosyalarına wfx-loot'un enjekte edildiğini gördü; ancak çalıntı kimlik bilgileri çoğu zaman birkaç gruba ulaştığı için ikisini muhtemelen farklı aktörlerin yürüttüğü ayrı kampanyalar olarak değerlendirdi ^[1]. Ayrıca bazı yeni kötü amaçlı yazılım sürümlerinde Endonezce yorumlar fark etti ^[1]. Belirteçleri dikkatle saklamak burada önemlidir; Password Managers Explained: How They Work and Whether They Are Safe temel bilgileri ele alıyor.