GitHub’da İç Repo Sızıntısı: Çalışan Cihazı Üzerinden 3.800’den Fazla Depo Dışarı Aktarıldı

Anasayfa » GitHub’da İç Repo Sızıntısı: Çalışan Cihazı Üzerinden 3.800’den Fazla Depo Dışarı Aktarıldı
GitHub’da İç Repo Sızıntısı: Çalışan Cihazı Üzerinden 3.800’den Fazla Depo Dışarı Aktarıldı

GitHub, bir çalışan cihazının ele geçirilmesiyle başlayan olayda şirketin yalnızca iç depolarını etkileyen bir veri sızıntısı yaşandığını doğruladı. İlk bulgulara göre saldırı, zehirlenmiş bir Visual Studio Code eklentisi üzerinden ilerledi ve etkilenen ortamdan yaklaşık 3.800 iç depo dışarı aktarıldı.

Olay, açık kaynak ekosistemini hedef alan tedarik zinciri saldırılarının hız kesmediği bir dönemde ortaya çıktı. Aynı süreçte, tehdit aktörleri GitHub kaynak kodunu satışa çıkarmaya çalıştı; buna paralel olarak başka bir kampanyada Microsoft’a ait Python paket ekosisteminde kötü amaçlı paket sürümleri tespit edildi. Bu tablo, geliştirici araçları, paket yöneticileri ve CI/CD hatlarının artık doğrudan saldırı yüzeyi olarak görüldüğünü bir kez daha gösteriyor.

Saldırının Genel Çerçevesi

GitHub’ın açıklamasına göre olay, bir çalışan cihazında tespit edilen uzlaşma ile başladı. Saldırganın, kötü niyetli hale getirilmiş bir VS Code uzantısı üzerinden erişim elde ettiği ve ardından iç depolara yönelik veri sızdırma faaliyeti yürüttüğü değerlendiriliyor. Şirket, kritik sırları döndürdüğünü, en yüksek etkiye sahip kimlik bilgilerine öncelik verdiğini ve ek altyapı hareketliliği için izleme yaptığını bildirdi.

Şu aşamada müşteri verilerinin, GitHub’ın iç repository alanı dışında etkilendiğine dair bir kanıt bulunmadığı belirtiliyor. Buna rağmen olay, kurumsal geliştirici cihazlarında EDR, IAM ve sıfır güven yaklaşımının neden kritik olduğunu açık biçimde ortaya koyuyor.

Teknik Saldırı Zinciri Nasıl İşledi?

İlk aşamada saldırganın, geliştirici iş istasyonunda kullanılan bir eklenti veya benzeri bir yazılım bileşeni üzerinden zararlı kod çalıştırdığı düşünülüyor. Bu tip saldırılar genellikle kimlik bilgisi hırsızlığı, oturum token’larının ele geçirilmesi ve ardından depo erişimlerinin genişletilmesiyle devam eder. Kurumsal ortamlarda bu zincir; GitHub token’ları, SSH anahtarları, npm/PyPI erişimleri, bulut erişim anahtarları ve CI/CD gizli değişkenleri üzerinden büyüyebilir.

Bu olayda da benzer şekilde, iç repository’lerden veri dışarı çıkarıldığı ve saldırganın iddia ettiği depo sayısının soruşturmayla büyük ölçüde örtüştüğü ifade edildi. Böyle senaryolarda SIEM tarafında olağandışı repo klonlama, beklenmeyen API çağrıları, kısa sürede çok sayıda secret erişimi ve yeni cihaz oturumları dikkatle incelenmelidir.

Açık Kaynak Tedarik Zincirinde Yeni Dalga

Aynı dönemde, TeamPCP olarak izlenen tehdit grubunun açık kaynak paketleri hedef alan kampanyasını genişlettiği görülüyor. Grup, bir Python paketi üzerinden kötü amaçlı sürümler yayımladı ve bu sürümlerin Linux sistemlerde otomatik çalışan bir bilgi hırsızı taşıdığı anlaşıldı. Paket ekosisteminde bu tür olaylar, yalnızca son kullanıcıyı değil; build sunucularını, container görüntülerini ve dağıtım hatlarını da etkileyebilir.

Analizlere göre kötü amaçlı paket, ikinci aşama bir yükü dış sunucudan çekip çalıştıran bir dropper içeriyor. Ardından devreye giren stealer bileşeni; bulut sağlayıcı kimlik bilgileri, parola yöneticileri, SSH anahtarları, Docker erişimleri, VPN yapılandırmaları ve shell geçmişi gibi verileri toplamaya çalışıyor. Bazı varyantların HashiCorp Vault sırlarını ve 1Password ile Bitwarden kasalarını hedef aldığı da bildirildi.

Yayılma Mekanizması ve Bulut Ortamları İçin Risk

Bu kampanyayı özellikle tehlikeli yapan unsur, zararlının kendini çoğaltabilmesi. AWS ortamlarında SSM üzerinden diğer EC2 örneklerine sıçrayabildiği, Kubernetes kümelerinde ise kubectl exec benzeri yollarla yayılabildiği belirtiliyor. Bu, tek bir geliştirici makinesinde başlayan olayın kısa sürede daha geniş bir bulut ayağına taşınabileceği anlamına geliyor.

Güvenlik ekipleri için burada kritik nokta, yalnızca uç nokta koruması değil; bulut güvenliği, ağ segmentasyonu ve kimlik temelli denetimlerin birlikte çalışmasıdır. Özellikle IAM politikaları, kısa ömürlü token kullanımı, secret scanning, container runtime izleme ve anormal SSM komutları gibi log kaynakları öncelikli olarak gözden geçirilmelidir.

Kurumsal Ekipler İçin Pratik Kontrol Listesi

1) Geliştirici iş istasyonlarında tüm IDE eklentilerini ve paket kaynaklarını envantere alın, imzasız veya doğrulanmamış bileşenleri engelleyin.

2) GitHub, GitLab, PyPI, npm ve benzeri platformlara ait token’ları düzenli döndürün; uzun ömürlü erişim anahtarlarını kaldırın.

3) EDR üzerinde repo klonlama, tar.gz/paket açma, curl-wget ile ikinci aşama indirme ve şüpheli child process zincirleri için kural yazın.

4) SIEM’de olağandışı GitHub API kullanımı, yeni cihaz oturumları, toplu secret erişimi ve beklenmeyen dış bağlantılar için alarm üretin.

5) AWS SSM, kubectl exec ve benzeri yönetim kanallarında ayrıcalık yükseltme ve yatay hareket göstergelerini izleyin.

6) CI/CD boru hatlarında secret scanning, dependency pinning ve bağımlılık doğrulamasını zorunlu hale getirin.

7) Docker, SSH ve VPN yapılandırmalarını merkezi olarak yönetin; yerel dosyalardan sızabilecek kimlik bilgilerini minimize edin.

8) Olay müdahale planında depo sızıntısı, token iptali, zorunlu parola sıfırlama ve anahtar rotasyonu adımlarını önceden tanımlayın.

Benzer Olaylar İçin Ne İzlenmeli?

Bu tip saldırılarda ilk işaretler çoğu zaman sessiz olur. Ancak güvenlik ekipleri; beklenmeyen paket sürümü yüklemeleri, yeni yayınlanan bağımlılıklar, kısa sürede artan outbound trafik, bilinmeyen alan adlarına DNS sorguları ve geliştirici araçlarından çıkan olağandışı süreç zincirlerini izleyerek erken tespit şansını artırabilir. Özellikle e-posta güvenliği, kimlik avı ile başlayan ilk erişim senaryoları açısından hâlâ önemli bir savunma katmanı olmaya devam ediyor.

Kurumsal ortamlar için bir diğer önemli nokta da erişim kapsamının dar tutulmasıdır. Bir geliştiricinin yalnızca ihtiyacı olan depolara erişmesi, üretim sırlarının ayrı kasalarda tutulması ve kritik işlemlerin çok faktörlü kimlik doğrulama ile korunması, sızıntının etkisini ciddi biçimde azaltabilir. Bu yaklaşım, fidye yazılımı ve tedarik zinciri saldırılarında da yaygın olarak önerilen en iyi uygulamalarla örtüşür.

Teknik Özet

İlk erişim: Zehirlenmiş bir VS Code eklentisi veya benzeri geliştirici aracı üzerinden çalışan cihazın ele geçirilmesi.

Etkilenen varlıklar: İç GitHub depoları, geliştirici sırları, paket yayınlama token’ları ve potansiyel olarak bulut erişim bilgileri.

Yük davranışı: İkinci aşama payload indirme, Linux üzerinde çalışan bilgi hırsızı, kimlik bilgisi toplama ve yatay yayılma.

Yayılma kanalları: AWS SSM, Kubernetes komut yürütme, token tabanlı paket yayılımı.

Savunma öncelikleri: Secret rotasyonu, token iptali, EDR avcılığı, SIEM korelasyonu, ağ segmentasyonu ve bağımlılık doğrulaması.

Olayın tam etkisi netleşmiş değil, ancak mevcut göstergeler geliştirici ekosisteminin yalnızca kod üretim alanı değil, aynı zamanda yüksek değerli bir saldırı yüzeyi olduğunu bir kez daha kanıtlıyor. Özellikle bulut tabanlı yazılım geliştirme yapan kurumlar için bu tür vakalar, kimlik ve erişim yönetimi ile olay müdahale süreçlerinin yeniden gözden geçirilmesi gerektiğini gösteriyor.