Çalınan GitHub Token’ları ile Sırlar Sızdırılıyor

Bulut güvenliği şirketi Wiz’in analizine göre, Gheist adı verilen otomatik bir saldırı kampanyası, çalınan GitHub tokenlerini kullanarak özel depoların ve GitHub Enterprise ortamlarının hassas verilerine ulaşıyor. Saldırganlar, hedef depolara otomatik iş akışları yerleştirerek havuzdaki tüm gizli anahtarları ve değişkenleri GitHub Actions loglarına yazdırıyor, ardından bu logları indirip iz bırakmadan işlemleri siliyor.

Gheist Kampanyası Nasıl Çalışıyor ve Sırlar Nasıl Sızdırılıyor?

Saldırganların kullandığı araç, erişim yetkisi olan her depo için ci-sync- önekiyle başlayan ve altı rastgele karakter içeren yeni bir dal oluşturuyor. Bu dal üzerine imzasız ve token sahibinin adını taşıyan bir dosya (.github/workflows/sync-check.yml) ekleniyor. İşlemin başlamasıyla birlikte GitHub Actions tetikleniyor ve ortam değişkenleri ile işlerin okuyabileceği tüm gizli anahtarlar loglara dökülüyor.

Normal şartlarda GitHub, hassas verileri log dosyalarında otomatik olarak maskeliyor. Ancak Gheist aracı, bu değerleri base32 formatında kodlayarak maskeleme mekanizmasını bypass ediyor ve verilerin tam halinin loglarda görünmesini sağlıyor. Araç, boş bir izin bloğu belirleyerek işin varsayılan GITHUB_TOKEN kullanımını sınırlandırıyor ancak bu durum, iş akışının depodaki gizli anahtarları okumasını engellemiyor. Bazı varyantlar ayrıca üretim kimlik bilgilerini barındıran dağıtım ortamları için de ek işler çalıştırıyor.

GitHub Koruma Mekanizmaları Neden Yetersiz Kalıyor?

GitHub, 28 Temmuz tarihinden bu yana potansiyel olarak kötü amaçlı gördüğü iş akışlarını yazma yetkisi olan bir işbirlikçi onaylayana kadar askıya alıyor. Wiz’in incelediği tüm halka açık Gheist çalıştırmaları bu güvenlik önlemine takılarak durdurulmuş ve hiçbir zaman payload çalıştırılamamıştır. Ancak bu koruma yalnızca public depolar için geçerli durumda.

GitHub Enterprise Server veya özel depolarda bu tarz bir durdurma filtresi bulunmuyor. Bu durum, kurumsal şirketlerin ve özel projelerin neden doğrudan hedef alındığını net bir şekilde açıklıyor. Denetim logları, eklenen dallardaki işlerin tamamlandığını ve ardından gheist kullanıcı ajanı tarafından silindiğini gösteriyor.

Saldırının Arkasındaki Kaynaklar ve Kapsam Ne Kadar Geniş?

Wiz, 15 Eylül’den bu yana takip ettiği bu faaliyet kapsamında 850’den fazla ele geçirilmiş hesaptan 13.500’den fazla dal kurtarmıştır. Çalınan tokenlerin kaynakları arasında bilgi hırsızı logları ve Mart ayındaki Trivy güvenlik tarayıcısı tedarik zinciri saldırısı gibi olaylarda sızdırılan kimlik bilgileri yer alıyor.

Saldırının arka planında yer alan teknik parametreler ve süreç detayları tabloda yer alıyor:

Ekim ayının ortalarına doğru araç, kendi kendine barındırılan çalıştırıcılara sahip makineleri hedef alan ikinci bir iş akışı da eklemiştir. Bu yeni iş akışı, makine içerisinde yer alan 31 farklı türdeki token, özel anahtar, AWS örnek rol kimlik bilgileri ve Kubernetes servis hesabı tokenlerini aramaya odaklanmıştır. Ancak Wiz’in analizine göre bu yeni modül hatalı kodlanmıştır ve başarılı bir çalıştırma rapor edilmemiştir.

Özel Ortamlar ve Self-Hosted Runner Hedefleri

Saldırı vektörünün evrimi, otomasyon sunucularının ve dahili geliştirme altyapılarının ne denli kırılgan olabileceğini gösteriyor. Kendi kendine barındırılan çalıştırıcılar üzerinde koşan iş akışları doğrudan ana makinenin kaynaklarına erişim sağlayabildiği için, bu makinelerin hedef alınması kurumsal ağlar içindeki yanal hareketleri kolaylaştırma potansiyeli taşıyor. Wiz’in raporuna göre self-hosted runner’ları hedefleyen kodlama henüz hatalı çalışsa da, bu durum saldırganların gelecekteki olası varyantlarında daha yıkıcı yetenekler kazanabileceğinin sinyallerini veriyor.

Yöneticiler ve Geliştiriciler Ne Yapmalı?

Bir deponun yazma erişimine sahip olan herhangi bir kullanıcı, o depoda yapılandırılmış tüm gizli anahtarları okuyabilir; çalınan bir token bu yetkiyi doğrudan sağlar. Dalın veya çalıştırılan işin silinmesi veri sızıntısını geri almamaktadır. Bu nedenle, organizasyonların alabileceği en somut önlem, deponun okuyabileceği her gizli anahtarın derhal yenilenmesi ve ilgili push işlemini gerçekleştiren tokenin iptal edilmesidir.