Megalodon GitHub Tedarik Zinciri Saldırısı: 5.500'den Fazla Depo 6 Saatte Nasıl Ele Geçirildi?

Operasyon, yaklaşık olarak 11:36 ile 17:48 UTC saatleri arasında gerçekleşti. Bu süre, bakımcıların değişiklikleri fark etmesine fırsat vermeden çok sayıda depoyu hızla tehlikeye atmak için tasarlanmış oldukça otomatize bir sisteme işaret ediyor.

Saldırganlar Binlerce Commit'i Nasıl Bu Kadar Hızlı Enjekte Etti?

Kampanya, kötü amaçlı commit'lerin normal CI bakım çalışmaları gibi görünmesini sağlamak için otomasyon ve sosyal kamuflaj tekniklerine dayanıyordu.

Sahte CI Botları ve Tek Kullanımlık Hesaplar

Saldırganlar, rastgele kullanıcı adlarına sahip tek kullanımlık GitHub hesapları oluşturdu ve aşağıdaki gibi otomasyon kimliklerini taklit etti:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Bu kimlikler, commit'lerin bir insan saldırgandan değil, rutin otomasyon sistemlerinden geliyormuş gibi görünmesini sağladı.

Sahte Commit Meta Verileri

Commit yazarlık verileri ve mesajları, genellikle rutin iş akışı güncellemeleri veya CI yapılandırma düzeltmelerine benzeyecek şekilde meşru görünmesi için özenle hazırlandı. Bu, commit'lerin normal geliştirme faaliyetleri arasında kaybolmasına ve şüphe uyandırmasının gecikmesine yardımcı oldu.

Zayıf Dal Korumasını Hedef Alma

Kampanya, dal koruma kurallarının zayıf veya hiç olmadığı depolara odaklandı. Zorunlu çekme isteği (pull request) incelemeleri veya iş akışlarını kimin değiştirebileceğine dair kısıtlamalar olmadan, saldırganlar iş akışı değişikliklerini doğrudan deponun varsayılan dalına (genellikle main veya master) itebildi.

Zehirli GitHub Actions İş Akışları

Her kötü amaçlı commit, Base64 ile kodlanmış bir Bash yükü içeren bir GitHub Actions iş akışı dosyası ekliyordu. CI hattı çalıştırıldığında, bu betik GitHub Actions çalıştırıcısı (runner) içinde çalışıyor ve kimlik bilgilerini toplamaya başlıyordu.

Bu tasarım, saldırının genellikle bir sonraki CI çalıştırması iş akışını tetikleyene kadar hareketsiz kalması anlamına geliyordu.

Yük Neyi Çalmaya Çalıştı?

İş akışlarına gömülü Base64 kodlu betik, CI ortamından hassas verileri toplamak ve bunları saldırganın kontrolündeki bir altyapıya göndermek üzere tasarlanmıştı.

Raporlanan hedefler şunları içeriyordu:

• CI/CD ortam değişkenleri
• Bulut sağlayıcı kimlik bilgileri (AWS, Google Cloud, Azure)
• SSH özel anahtarları
• API token'ları ve uygulama sırları
• GitHub Actions OIDC token'ları
• Çalıştırıcı ortamında açığa çıkan diğer yapılandırma sırları

Kötü amaçlı yazılım, ortam değişkenlerini, sistem bilgilerini ve CI çalıştırıcısının erişebildiği sırları topladıktan sonra bunları bir komuta ve kontrol (C2) sunucusuna sızdırıyordu.

CI hatları genellikle dağıtım kimlik bilgilerini içerdiğinden, bir derleme ortamının ele geçirilmesi, bulut altyapısına, paket kayıtlarına ve üretim dağıtımlarına giden yolları açabilir.

OIDC Token'larını Çalmak Neden Özellikle Tehlikeli?

Megalodon yükünün ana hedeflerinden biri GitHub Actions OIDC token'larıydı.

Modern CI/CD hatları, bulut sağlayıcılarına uzun ömürlü kimlik bilgileri depolamadan kimlik doğrulaması yapmak için sıklıkla OpenID Connect (OIDC) federasyonunu kullanır. Bunun yerine, bir iş akışı, bulut sağlayıcılarının geçici erişim kimlik bilgileriyle değiştirdiği kısa ömürlü bir kimlik token'ı talep eder.

Bu yaklaşım, statik API anahtarlarını veya hizmet hesabı kimlik bilgilerini ortadan kaldırarak güvenliği artırır. Ancak, yeni bir risk de ortaya çıkarır: eğer bir saldırgan, hat yürütme sırasında bu token'ı çalabilirse, CI işinin kimliğine geçici olarak bürünebilir.

Bu token'lar bulut kimlik sistemleri tarafından güvenilir olduğu için, çalınan bir token potansiyel olarak dağıtım hattına verilen aynı izinlerle geçici bulut erişimi elde etmek için kullanılabilir.

Bu, tehlikeye atılmış bir CI iş akışının şunlara yol açabileceği anlamına gelir:

• bulut altyapısına erişim
• dağıtım hattının ele geçirilmesi
• bulut hizmetlerinden sırların çalınması

OIDC token'ları hızlı bir şekilde süresi dolsa da, kendilerine bağlı izinler, kısa süreli erişimi saldırganlar için oldukça değerli kılabilir.

Saldırı Neden Önemliydi?

Megalodon kampanyası, tedarik zinciri saldırılarının uygulama kodunu değiştirmekten ziyade otomasyon altyapısını tehlikeye atmaya doğru bir kayma yaşadığını gösteriyor.

CI iş akışlarını kaynak kodu yerine hedef alarak, saldırganlar şunları yapabilir:

• hatlar çalıştığında otomatik olarak kimlik bilgilerini çalmak
• dağıtım sistemlerine ve bulut ortamlarına erişmek
• rutin otomasyon değişikliklerinin içinde gizli kalmak

Binlerce depo, güçlü kimlik bilgilerine sahip CI hatlarına güvendiğinden, tek bir iş akışı değişikliği birçok alt sistemdeki sırları açığa çıkarabilir.

Megalodon, GitHub VS Code Eklentisi İhlaliyle Bağlantılı mıydı?

Aynı dönemde GitHub, bir çalışan cihazına yüklenen zehirli bir Visual Studio Code eklentisini içeren ayrı bir güvenlik olayını açıkladı. Kötü amaçlı eklenti, saldırganların olay kontrol altına alınmadan önce yaklaşık 3.800 dahili GitHub deposuna erişmesini sağladı.

Bu ihlal, tehlikeye atılmış bir geliştirici ortamına kadar izlendi ve VS Code pazarı üzerinden dağıtılan truva atı benzeri bir eklenti aracılığıyla kimlik bilgisi toplamayı içeriyordu.

Bazı güvenlik raporları, bu olayın zamanlaması ve taktikleri ile geliştirici araçlarını hedef alan diğer tedarik zinciri saldırıları arasında benzerliklere dikkat çekiyor. Ancak, kamuya açık kanıtlar, GitHub'daki dahili ihlalin doğrudan Megalodon kampanyasını mümkün kıldığını henüz doğrulamamıştır.

Şimdilik, bu iki olayı geliştirici ekosistemini etkileyen ayrı ancak eşzamanlı tedarik zinciri güvenlik olayları olarak anlamak en doğrusu.

CI/CD Güvenliği İçin Genel Ders

Megalodon, otomasyonun bir tedarik zinciri saldırısını binlerce depoya ne kadar hızlı bir şekilde yayabileceğini gösteriyor. Taklit edilmiş botları, otomatik commit'leri ve zehirli CI iş akışlarını birleştiren saldırganlar, rutin derleme altyapısını bir kimlik bilgisi toplama sistemine dönüştürdü.

Bu olay, yazılım ekipleri için birkaç savunma önceliğini bir kez daha vurguladı:

• katı dal koruma kuralları
• iş akışı değişiklikleri için zorunlu incelemeler
• CI işleri için minimum izinler
• otomasyon hesaplarının ve iş akışı güncellemelerinin dikkatli bir şekilde izlenmesi

Geliştirme hatları, bulut dağıtımlarını ve üretim altyapısını giderek daha fazla kontrol ettiğinden, CI/CD iş akışlarının güvenliği, yazılım tedarik zinciri savunmasının kritik bir parçası haline gelmiştir.