Gheist, GitHub Actions’ı Kimlik Avı Platformuna Çeviriyor

Yazılım geliştirme süreçlerinin otomasyonunda merkezi bir rol oynayan GitHub Actions güvenlik mekanizmalarına yönelik yeni bir tehdit ortaya çıktı. “Gheist” olarak adlandırılan saldırı aktörleri, ele geçirilmiş GitHub hesaplarını birer kimlik bilgisi toplama platformuna dönüştürüyor. Saldırganlar, özel depolarda kötü niyetli GitHub Actions iş akışları yerleştirerek, depolama ve ortam sırlarını açığa çıkarıp, GitHub API’leri aracılığıyla bu verileri hızla ele geçiriyor ve ardından tüm kanıtları silerek izlerini kaybediyor.
Olayın Perde Arkası: Otomasyonu Suistimal
GitHub Actions, geliştiricilerin kod dağıtımından testlere kadar birçok süreci otomatikleştirmesine olanak tanıyan güçlü bir araç. Ancak bu esneklik, kötü niyetli aktörler için yeni bir saldırı vektörü sunuyor. Wiz Research tarafından 15 Eylül’den bu yana takip edilen Gheist kampanyası, kişisel projelerden büyük ölçekli kurumsal depolara kadar 850’den fazla tehlikeye atılmış hesapta 13.500’den fazla kötü amaçlı dal (branch) oluşturdu. Kampanyanın temelinde, daha önce ele geçirilmiş erişim belirteçleri (token) ve bilgi çalan yazılımlar (infostealer) aracılığıyla elde edilen kimlik bilgileri yatıyor. Bu durum, tedarik zinciri saldırılarının ve zayıf kimlik yönetimi uygulamalarının ne denli geniş bir yıkıma yol açabileceğini gözler önüne seriyor.
Saldırganlar, ele geçirdikleri erişimi kullanarak GitHub Actions’ın otomasyon yeteneklerini kendi lehlerine çeviriyor. Hedef alınan hesaplarda hızla yeni bir dal oluşturuluyor ve bu dala “sync-check” adında kötü niyetli bir iş akışı ekleniyor. Bu iş akışı, kritik bilgilerin yürütme günlüklerine yazılmasını hedefliyor. GitHub’ın kamuya açık depolarda potansiyel kötü niyetli iş akışlarını iş birliği yapanların onayına sunma şeklindeki kontrol mekanizması Gheist’in genel depolarda başarılı olmasını engelledi. Ancak bu koruma, özel depolara veya GitHub Enterprise Server ortamlarına uzanmıyor; araştırmacılar bu platformlarda saldırıların başarılı bir şekilde yürütüldüğünü ve sonrasında aktivite gözlemlediklerini belirtiyor.
Sızdırmanın Teknik Anatomisi: Gizleme Mekanizmasını Aşmak
Gheist aktörlerinin kullandığı en kritik teknik detaylardan biri, GitHub Actions’ın gizli veri maskeleme mekanizması ile iş akışlarının hassas değerlere erişim şekli arasındaki boşluktan faydalanmak. GitHub, gizli değerleri günlüklerde tam olarak göründükleri zaman maskeler. Ancak Gheist tarafından oluşturulan iş akışları, bu sırları günlüklerde görünmeden önce Base32 formatında kodluyor. Bu kodlama sayesinde orijinal değerlerle birebir eşleşmeyen veriler, maskeleme mekanizmasını atlatarak günlüklerde açıkça görünüyor. Bu durum, saldırganlara GitHub’ın kendi API’si üzerinden günlükleri çekme ve bu kodlanmış gizli verileri kolayca elde etme olanağı tanıyor. Elde edilen bu veriler daha sonra Base32’den çözülerek orijinal sırları ortaya çıkarıyor.
Saldırının diğer önemli bir özelliği ise, sızdırma sonrasında saldırganların iz bırakmamak adına hızla hareket etmesi. Kötü niyetli iş akışı çalıştırıldıktan ve günlükler GitHub API aracılığıyla çekildikten saniyeler sonra, saldırganlar ilgili iş akışı çalışmasını silerek kanıtları ortadan kaldırıyor. Bu hızlı silme işlemi, güvenlik ekiplerinin adli analiz yapmasını zorlaştırıyor ve saldırının tespitini geciktiriyor. Wiz araştırmacıları, “Sırlar GitHub’ın kendi API’si üzerinden ayrıldığı için engellenecek bir saldırgan alanı veya giden bağlantı yok” ifadesiyle, geleneksel ağ güvenliği önlemlerinin bu tür içsel platform saldırılarına karşı yetersiz kalabileceğine dikkat çekiyor.
Hedef: Üretim Sistemleri ve Bulut Kimlik Bilgileri
Gheist saldırıları, sadece depolama seviyesindeki sırları değil, aynı zamanda üretim ortamları gibi kritik dağıtım ortamlarında kullanılan hassas kimlik bilgilerini de hedef alıyor. Dağıtım ortamlarını kullanan depolarda Gheist, ortama özgü sırları hedeflemek için birden fazla iş akışı görevi oluşturuyor. Bu, potansiyel olarak depolama düzeyinde saklanan sırların yanı sıra, üretim sistemlerini çalıştırmak için kullanılan kritik kimlik bilgilerini de ifşa etme riski taşıyor. Örneğin, bir üretim ortamında kullanılan veritabanı şifreleri, API anahtarları veya bulut sağlayıcı kimlik bilgileri bu yolla ele geçirilebiliyor.
Gheist, zamanla evrilerek self-hosted GitHub Actions runner’ları (kendi barındırılan çalıştırıcılar) hedeflemeye başladı. Eklediği “sync-host” görevi, çalıştırıcı ana bilgisayarlarında API belirteçleri, özel anahtarlar, ortam dosyaları, bulut kimlik bilgileri ve diğer hassas verileri aramayı deniyor. Ayrıca Docker soketine, bulut örneği meta verilerine ve Kubernetes hizmet hesabı belirteçlerine erişim girişimlerinde bulunuyor. Bu evrilmiş varyantta bazı uygulama hataları olduğu belirtilse de, hedeflenen her kimlik bilgisinin başarılı bir şekilde ele geçirildiği varsayılmamalı, ancak tehdidin potansiyeli azımsanmamalı.
Güvenlik Ekipleri İçin Eylem Planı
Bu tür bir saldırının tespiti ve etkilerinin azaltılması, güvenlik ekiplerinin proaktif adımlar atmasını gerektiriyor. İlk olarak, sistem yöneticileri ve güvenlik analistleri, GitHub denetim günlüklerinde belirli desenleri aramalıdır. Özellikle “ci-sync-” ile başlayan ve ardından altı rastgele karakterin geldiği dalları (branch) incelemek, potansiyel Gheist aktivitesinin ilk işaretlerinden biri olabilir. Ayrıca, “ci: sync config” başlıklı commit’ler ve kısa süre içinde tamamlanıp silinen iş akışı çalıştırmaları da şüpheli davranışları işaret eder.
Bulut ortamlarında da dikkatli olunmalıdır. Saldırı ile ilişkilendirilen bulut rolü üstlenmelerini (cloud role assumptions) titizlikle araştırmak, ele geçirilen bulut kimlik bilgilerinin AWS Secrets Manager’ı numaralandırmak veya başka AWS rollerini üstlenmek için kullanılıp kullanılmadığını anlamak adına önemlidir. Tespit edilen herhangi bir ele geçirilmiş belirteç derhal iptal edilmeli ve erişimi olan tüm depolama, kuruluş ve ortam sırları rotate edilmelidir. Bu kapsamlı döndürme işlemi, saldırganların elde etmiş olabileceği tüm eski kimlik bilgilerini geçersiz kılacaktır.
Otomasyon Çağında Gizlilik Riskleri ve Büyük Resim
Gheist saldırısı, yazılım geliştirme ekosistemlerinin karmaşıklığının ve otomasyon araçlarının yaygınlaşmasının getirdiği güvenlik zorluklarını bir kez daha vurguluyor. Geleneksel çevre güvenliği önlemlerinin ötesine geçen bu tür saldırılar, platformların kendi iç mekanizmalarının kötüye kullanılabileceğini gösteriyor. GitHub gibi platformların sağladığı kolaylıklar, güvenlik kontrollerinin sürekli olarak gözden geçirilmesini ve geliştirilmesini zorunlu kılıyor.
Bu olay, sadece GitHub Actions’ın bir zafiyeti olmanın ötesinde, daha geniş bir bulut güvenliği sorununa işaret ediyor. Ele geçirilen kimlik bilgilerinin, AWS Secrets Manager gibi bulut hizmetlerinde kullanılmaya devam etmesi, tek bir platformdaki güvenlik ihlalinin domino etkisiyle tüm bulut altyapısına yayılma potansiyelini gösteriyor. Tedarik zinciri güvenliği, çok faktörlü kimlik doğrulama, düzenli güvenlik denetimleri ve şüpheli etkinliklerin sürekli izlenmesi, bu tür tehditlere karşı en etkili savunma hattını oluşturacaktır. Otomasyon ne kadar hız sağlarsa sağlasın, güvenlik her zaman öncelikli olmalıdır.
Sık Sorulan Sorular
İlgili Makaleler
- ›AI Ajan Ölçeklendirme: Protokoller Tek Başına Neden Yetersiz?
- ›Yapay Zeka Arka Kapı Tehdidi: Birkaç Nöronla LLM Manipülasyonu
- ›Microsoft AI'ı, Rust'ın Standart Kütüphanesinde On Yıllık Açığı Buldu
- ›Yapay Zeka Devleri Yazılım İş Akışını Nasıl Ele Geçiriyor?
- ›PuppyGraph: AI Şema ve MCP ile Kurumsal Veri Sorgulama Dönüşüyor
