GhostAction kampanyası sahte GitHub Actions güvenlik workflow'leriyle CI gizli anahtarlarını çalıyor

Ne oldu

7 Ekim'den bu yana Socket'in GhostAction olarak takip ettiği bir kampanya, ele geçirilmiş maintainer hesapları aracılığıyla meşru repository'lere kötü niyetli GitHub Actions workflow dosyaları yerleştiriyor. Olayı aktarılan ve üç araştırma ekibine de atıfta bulunan bir dev.to yazısına göre GitGuardian, 772'den fazla ek repository'ye dokunan ikinci bir dalgayı saymış ve StepSecurity çalınan gizli anahtar sayısını 3.000'in üzerinde veriyor.\n Buradaki çerçeve önemli: Bu bir GitHub zero-day'i ya da bir yetki yükseltme değil. Saldırganlar, repository sahiplerinin zaten güvendiği otomasyonu istismar etti — CI'nın görebildiği her şeyi süpürürken sıradan görünen bir workflow dosyası.

Saldırı nasıl çalışıyor

Ele geçirilmiş bir maintainer hesabı, "Add security audit workflow" mesajıyla .github/workflows/security-audit.yml veya .github/workflows/github_actions_security.yml adlı bir dosya commit ediyor. Commit gerçek bir hesaptan geldiği için workflow, repository'nin kendi CI'ında, gizli anahtarları erişilebilir kapsamda çalışıyor.

Workflow, repository'yi fetch-depth: 0 ile checkout ediyor ve git log -p --all komutunu çalıştırıyor; bu da yıllar önce commit edilip silinen gizli anahtarların hâlâ okunabilir olduğu anlamına geliyor. Yazıya göre toplanan değerler arasında birkaç satır çevresel bağlam içeren AWS anahtarları; Anthropic, OpenAI ve OpenRouter anahtarları; GitHub, GitLab ve Google API token'ları ile Slack, SendGrid ve PyPI kimlik bilgileri yer alıyor. Her şey düz HTTP üzerinden açık metin olarak tek bir saldırgan IP'sine gönderiliyor; yazı bu IP'yi 193.32.204.199 olarak belirtiyor. Tek bir sabit adrese açık metin çıkışı, savunmacılar için kullanışlı bir tespit sinyali.

15 dakikalık öz denetim

Yazı kontrolleri şu şekilde sıralıyor:

1. Enjekte edilmiş workflow dosyalarını arayın. git log --diff-filter=A --name-only --format=%ci -- .github/workflows/security-audit.yml .github/workflows/github_actions_security.yml komutunu çalıştırın ve 7 Ekim veya sonrasında eklenmiş, hiçbir takım arkadaşının açıklayamadığı her dosyayı ele geçirilmiş kabul edin.
2. Actions çalışma geçmişinde takımınıza bağlanamayacağınız koşuları inceleyin ve herhangi bir şeyi silmeden önce logları arşivleyin, çünkü araştırma için ihtiyaç duyacağınız şeyler bu loglardır.
3. Kimlik bilgilerini döndürün: bulut anahtarları, kişisel erişim token'ları, PyPI ve npm token'ları, yapay zeka sağlayıcı anahtarları. Kritik nüans şu: bugünün gizli anahtarlarını döndürmek, geçmişten sızan değerler için hiçbir şey yapmaz; hiçbir zaman iptal edilmemiş her değer hâlâ iptal edilmeli.
4. Yalnızca mevcut checkout değil, tüm geçmişi gitleaks git . veya TruffleHog ile tarayın. Temiz bir çalışma ağacı, eski commit'ler hakkında hiçbir şey söylemez.
5. Ağ telemetrisinde sızıntı IP'sine geçmiş bağlantıları arayın, sonra engelleyin.

Yapısal ders

CI runner'ları repository'nin gizli anahtarlarına erişimle kuruludur; dolayısıyla pull_request ile tetiklenen bir workflow'un gizli anahtarlara shell erişimi aldığı veya maintainer commit'lerinin doğrudan varsayılan dalda landing yaptığı her repository, GhostAction'un istismar ettiği aynı açıkta demektir. Yazının önerdiği düzeltmeler ucuz: kurum genelinde write varsayılanları yerine workflow başına minimal izinler ayarlayın, commit'ler varsayılan dala ulaşmadan önce inceleme isteyin, gizli anahtarları fork ile tetiklenen koşulardan uzak tutun ve asla gizli anahtarları, pull-request kontrollü kodun bunları geri yazdırabileceği run: string'lerine yerleştirmeyin. Son nokta, aynı sorunun daha sessiz bir varyantı: gizli anahtarların bir kampanya tarafından dışarı sızdırılmasına gerek yoktur, eğer fork kodu bunları runner içerisinden yazdırabiliyorsa.

Neden önemli

GhostAction, hedefin güven modeli cömert olduğunda bir saldırganın ne kadar az şeye ihtiyaç duyduğunu gösteriyor: exploit yok, kötü amaçlı yazılım payload'ı yok, sadece gerçek bir hesaptan commit edilmiş sıkıcı görünümlü bir YAML dosyası. Sonuçlar halihazırda yapılandırılmış gizli anahtarların ötesine uzanıyor, çünkü geçmişi adımlayan aşama uzun zaman önce silinen kimlik bilgilerini de içine çekiyor. GitHub Actions çalıştıran herkes için denetim kısa ve sağlamlaştırma adımları — en az ayrıcalıklı workflow izinleri, dal koruması, daha dar gizli anahtar kapsamı — bu kampanyayı baştan körletecekti.