GitHub Token'larını Çalan Gheist Kampanyası 850'den Fazla Hesabı Ele Geçirdi

Bulut güvenlik şirketi Wiz'in analizine göre, Gheist adı verilen otomatik bir saldırı kampanyası, çalıntı GitHub token'larını kullanarak hedef depolardaki gizli anahtarları GitHub Actions loglarına yazdırıp bu logları indiriyor; ardından çalıştırma kayıtlarını siliyor. Saldırılar özellikle özel depolarda ve GitHub Enterprise ortamlarında başarıya ulaşıyor. Wiz, kampanyayı 15 Eylül'den bu yana izlediğini ve saldırganların araçlarının GitHub API isteklerine eklediği gheist kullanıcı ajanından yola çıkarak bu adı koyduğunu belirtiyor.

Saldırı Nasıl İşliyor?​

Saldırı zinciri, ele geçirilmiş bir token'ın erişebildiği her depo için ci-sync- önekiyle başlayan ve ardından altı rastgele karakterden oluşan yeni bir dal oluşturulmasıyla başlıyor. Bu dala yalnızca tek bir dosya ekleniyor: .github/workflows/sync-check.yml. Commit mesajı her seferinde aynı: ci: sync config. Commit imzasız olup token sahibinin adını içeriyor; dalın oluşturulmasıyla birlikte iş akışı otomatik olarak tetikleniyor.
İş akışı, ortam değişkenlerini ve işin okuyabildiği tüm gizli anahtarları base32 ile kodlayarak loga yazdırıyor. GitHub normalde logları gizli değerler açısından maskeler; ancak şirketin kendi belgelerine göre bu koruma, değerin kodlanmış ya da başka biçimde dönüştürülmüş olması durumunda garanti edilmiyor. Wiz, base32 çıktısının orijinal değerle artık birebir eşleşmediği için maskelemenin devreye girmediğini ve gizli anahtarların logda açık metin olarak göründüğünü aktarıyor. Araç daha sonra logu GitHub API'si üzerinden indiriyor ve çalıştırma kaydını birkaç saniye içinde siliyor. Gizli anahtarlar yalnızca GitHub'ın kendi altyapısı üzerinden dışarı çıktığından, engellenebilecek harici bir sunucu bağlantısı bulunmuyor.
Wiz'in incelediği tüm kamuya açık depolardaki Gheist çalıştırmalarının GitHub'ın şüpheli iş akışlarını onay bekletme mekanizmasıyla durdurulduğu görüldü. GitHub, bu önlemin yalnızca github.com üzerindeki genel depolar için geçerli olduğunu ve GitHub Enterprise Server'ı kapsamadığını belirtiyor. Özel depolarda ise GitHub denetim logları, ci-sync- dallarındaki çalıştırmaların tamamlandığını ve ardından gheist kullanıcı ajanı tarafından silindiğini gösteriyor.

Kurumsal Ortamlarda Genişleyen Tehdit​

Kurumsal yapılarda saldırı aracının dakikalar içinde birden fazla kullanıcı ve otomasyon hesabına ait token'ları sırayla denediği ve özel depoları klonladığı görüldü. Saatler sonra aynı kuruluşa ait bulut kimlik bilgileriyle AWS Secrets Manager üzerinde keşif işlemleri gerçekleştirildi; ancak Wiz'in analizi bu kimlik bilgilerinin nereden elde edildiğini ya da kimin kullandığını açıklamıyor.
AWS CloudTrail logları, kuruluşun kendi iş akışlarının da ci-sync- dallarında çalışarak AWS rollerini üstlendiğini ortaya koyuyor; bu durum, GitHub Actions'ın söz konusu dallarda onay alınmadan çalıştığına işaret ediyor. Aracın bir sürümü ayrıca depodaki her dağıtım ortamı için ayrı bir iş çalıştırıyor; bu ortamlara özgü gizli anahtarlar genellikle üretim kimlik bilgilerini içeriyor.
19 Ekim civarında aracın yeni bir sürümü, kendi barındırılan koşucuları (self-hosted runner) hedef alan ikinci bir iş ekledi. Bu iş, koşucu makinede özel anahtarlar, süreç ortamları, AWS örnek rolü kimlik bilgileri, koşucu kimlik bilgisi dosyaları ve Kubernetes servis hesabı token'ı dahil 31 farklı token türünü arıyor. Wiz bu işi hatalı olarak nitelendiriyor ve analizinde başarılı bir çalıştırma kaydedilmediğini belirtiyor.

Token Kaynakları ve Bağlantılı Kampanyalar​

Wiz'in izleyebildiği kadarıyla çalıntı token'ların kaynakları arasında bilgi hırsızı (infostealer) logları ve daha önce yaşanan tedarik zinciri saldırılarında açığa çıkan token'lar yer alıyor. Bu saldırılar arasında Mart ayındaki Trivy güvenlik açığı tarayıcısı ihlali de bulunuyor. Aynı hesapları başka saldırganlar da kullanıyor: 6 Ekim'de 391 hesap yaklaşık 1.461 depoyu kırık yazılım görünümüne büründürerek zararlı yazılım yaydı. Bu işlem, daha önce eklenmiş 610 dalı da sildi. Bazı kurbanların PolinRider adlı ve araştırmacıların Kuzey Kore ile ilişkilendirdiği zararlı yazılımla da enfekte olduğu görüldü. 19-20 Ekim'de üç hesap, Gheist commitlerini bir yükleyici eklenerek yeniden gönderdi.
Wiz ayrıca Gheist'i, Mayıs ayında binlerce GitHub deposunu etkileyen Megalodon kampanyasından ve farklı iş akışı dosyaları kullanan GhostAction'dan ayrı bir yapı olarak değerlendiriyor. 24 Ekim itibarıyla kampanya hâlâ aktifti ve değişmeye devam ediyordu. Hesapların yaklaşık üçte ikisi artık GitHub üzerinde mevcut değil; Wiz bu durumun büyük olasılıkla GitHub'ın müdahalesini yansıttığını belirtiyor.

Etkilenen Depolarda Alınması Gereken Önlemler​

Wiz, etkilenen depolarda şu adımların atılmasını öneriyor: Deponun kullanabildiği tüm depo, kuruluş ve ortam gizli anahtarlarının yenilenmesi; commit'leri ileten token'ların iptal edilmesi ve sahiplerinin cihazlarının bilgi hırsızı yazılımlara karşı incelenmesi. Bir ci-sync- dalı kendi barındırılan koşucu üzerinde çalıştıysa ilgili makinenin ve bulut örneği rolünün ele geçirilmiş kabul edilmesi gerekiyor. Beklemedeki sync-check çalıştırmalarının onaylanmaması ve ci-sync- dallarından kod çalıştırılmaması da kritik önlemler arasında sayılıyor.
Çalıntı token'ların etkisini azaltmak için Wiz şunları tavsiye ediyor: Üretim gizli anahtarlarını barındıran ortamlarda gözden geçiren zorunlu kılmak; OIDC güven politikalarını yalnızca korumalı dallar ya da ortamlarla sınırlamak; kişisel erişim token'ları yerine GitHub Apps veya kısa ömürlü ayrıntılı token'lar kullanmak; kendi barındırılan koşucuları Docker soket erişimi ya da bulut meta verilerine açık erişim olmaksızın kısa ömürlü makineler olarak çalıştırmak.

Sıkça Sorulan Sorular​

Gheist kampanyası ilk olarak ne zaman tespit edildi?​

Wiz, Gheist kampanyasını 15 Eylül'den itibaren takip ettiğini açıkladı. 24 Ekim itibarıyla kampanya hâlâ aktifti ve değişmeye devam ediyordu.

Gheist saldırıları kaç hesabı ve dalı etkiledi?​

Wiz'in verilerine göre kampanya, 850'den fazla ele geçirilmiş hesaba ait 13.500'ü aşkın dal oluşturdu. Etkilenen hesaplar kişisel projelerden kurumsal kuruluşların özel depolarına kadar geniş bir yelpazeyi kapsıyor.

GitHub'ın şüpheli iş akışlarını durdurma mekanizması neden tüm depoları koruyamıyor?​

GitHub, şüpheli iş akışlarını onay bekletme özelliğinin yalnızca github.com üzerindeki genel depolar için geçerli olduğunu belirtiyor. Özel depolar ve GitHub Enterprise Server bu koruma kapsamı dışında kalıyor; dolayısıyla Gheist bu ortamlarda engellenmeden çalışabiliyor.

Saldırganlar gizli anahtarları GitHub'ın maskeleme korumasını aşarak nasıl ele geçiriyor?​

İş akışı, gizli anahtarları base32 ile kodlayarak loga yazdırıyor. GitHub'ın maskeleme mekanizması, değerlerin kodlanmış ya da dönüştürülmüş olduğu durumlarda çalışmayı garanti etmiyor. Wiz, base32 çıktısının orijinal değerle eşleşmemesi nedeniyle maskelemenin devreye girmediğini ve anahtarların logda açık biçimde göründüğünü tespit etti.

Bir ci-sync- dalı bulunduğunda hangi adımlar atılmalı?​

Wiz, etkilenen depolarda tüm depo, kuruluş ve ortam gizli anahtarlarının yenilenmesini; commit'leri ileten token'ların iptal edilmesini ve cihazların bilgi hırsızı yazılımlara karşı incelenmesini öneriyor. Kendi barındırılan koşucularda çalıştırma gerçekleştiyse ilgili makinenin ve bulut rolünün ele geçirilmiş sayılması, beklemedeki çalıştırmaların ise kesinlikle onaylanmaması gerekiyor.