GitHub MCP İstismarı: MCP Üzerinden Özel Depolara Erişim

• GitHub hesabına bağlı bir MCP ajanı, yalnızca herkese açık bir Issue’yu okuyarak özel depo verilerinin sızdırılmasına giden bir yol açabilir
• Saldırı, herkese açık bir depo Issue’suna yerleştirilen dolaylı prompt injection ile başlar; bu, ajanın araç kullanım akışını değiştirir
• Demoda, ukend0464/pacman içindeki kötü amaçlı bir Issue, Claude 4 Opus ve GitHub MCP entegrasyonu üzerinden özel depo bilgilerini herkese açık bir PR’ye aktarır
• Sorunun özü, GitHub MCP server kodundaki bir hatadan çok, güvenilen araçların güvenilmeyen dış içerikle birlikte kullanıldığı yapıda yatıyor
• Depo bazında en az yetki, oturum düzeyinde erişim kısıtları ve MCP-scan gibi çalışma zamanı güvenlik izleme mekanizmaları ajan sistemlerinde gerekli

---

Kötü Amaçlı Bir Issue ile Başlayan GitHub MCP Saldırısı

• Invariant, yaygın olarak kullanılan GitHub MCP integration içinde saldırganların kullanıcının ajanını ele geçirip özel depo verilerini sızdırmasına olanak tanıyan bir zafiyet keşfetti
  • Söz konusu GitHub MCP server, GitHub’da 14k stars almış bir proje
  • Bu zafiyet, Invariant’ın güvenlik analiz aracının tespit ettiği ilk Toxic Agent Flows örneklerinden biri
• Toxic Agent Flow, dolaylı prompt injection nedeniyle ajanın amaçlanmayan bir araç kullanım sırasını izlemesine yol açan bir akış
  • Bu durum veri sızıntısı veya kötü amaçlı kod çalıştırma gibi sonuçlara yol açabilir
• Kodlama ajanları ve IDE’ler hızla yaygınlaşırken, benzer saldırılar temel yazılım geliştirme araçlarını kullanan kullanıcıları da etkileyebilir

Saldırının Yapısı

• Kullanıcı, Claude Desktop gibi bir MCP istemcisi kullanıyor ve GitHub MCP server’ı kendi GitHub hesabına bağlamış durumda
• Saldırı senaryosu iki tür depo varsayıyor
  • <user>/public-repo: Herkesin Issue ve hata raporu oluşturabildiği herkese açık depo
  • <user>/private-repo: Tescilli kod veya şirket içi veri içeren özel depo
• Saldırgan, GitHub’ın normal yetki kuralları gereği herkese açık depoda kötü amaçlı bir Issue oluşturabilir
• Kullanıcı ajanına Have a look at the open issues in <user>/public-repo gibi normal bir istek gönderdiğinde, ajan herkese açık depo Issue’larını alır ve prompt injection’a maruz kalır
• Ardından ajan, özel depo verilerini bağlama alabilir ve verileri herkese açık depoda otomatik oluşturduğu bir PR üzerinden sızdırabilir

Demoda Doğrulanan Sızıntı Akışı

• Demo, herkese açık ukend0464/pacman deposunu ve birden fazla özel depoyu kullanıyor
  • ukend0464/pacman: Basit bir Pacman oyunu uygulaması içeren herkese açık bir depo ve GitHub’da görülebilir
  • Özel depolarda kullanıcının kişisel projeleri ve hassas bilgileri bulunuyor
• Saldırgan, herkese açık depoya kötü amaçlı bir Issue yerleştiriyor
  • Bu Issue, ajanın herkese açık depo Issue listesini sorguladığı anda çalışacak bir payload içeriyor
• Kullanıcı, saldırıyı tetiklemek için Claude 4 Opus’a bir istek gönderiyor
  • Claude Desktop varsayılan olarak her bir araç çağrısı için kullanıcı onayı istiyor
  • Ancak birçok kullanıcı ajanları kullanırken “Always Allow” onay politikasını seçiyor ve tekil eylemleri izlemeyi bırakıyor
• Ajan, Issue listesini dolaşırken saldırı payload’unu buluyor, özel depo verilerini bağlama alıyor ve bunları pacman deposundaki pull request üzerinden sızdırıyor
• Herkese açık PR, ukend0464 kullanıcısına ait özel bilgileri içeriyor
  • Jupiter Star gibi özel depo bilgileri
  • Güney Amerika’ya taşınma planı
  • Maaş bilgisi
• Ajanın tüm akıl yürütme ve araç kullanım sırası, Invariant Explorer’daki tam trace içinde görülebilir

Güvenilen Araçlarda da Ortaya Çıkan Toxic Agent Flow

• Bu zafiyet, MCP aracının kendisinin bozulmasını gerektiren geleneksel araç kirlenmesi saldırılarından farklı
• GitHub gibi dış platformlara bağlı bir ajan güvenilmeyen bilgiye maruz kaldığında, araç tamamen güvenilir olsa bile sorun ortaya çıkabiliyor
• Ajan sistemlerinde bu tür akışları anlamak, analiz etmek ve azaltmak büyük ölçekte elle yapılması zor bir iş
• Invariant, kuruluşların kötü niyetli aktörler tarafından istismar edilmeden önce potansiyel tehditleri belirleyip modelleyebilmesi için Toxic Agent Flow tespitini otomatikleştiren yöntemler geliştiriyor

Etki Alanı ve Azaltma Önlemleri

• Deney Claude Desktop’a odaklansa da zafiyet belirli bir ajan veya MCP istemcisiyle sınırlı değil
• GitHub MCP server kullanan tüm ajanlar, temel model veya uygulamadan bağımsız olarak etkilenebilir
• Buradaki kritik nokta, bunun GitHub MCP server kodunun kendisindeki bir hata olmaması
  • Bu, GitHub’ın yalnızca sunucu tarafı bir yama ile tek başına çözebileceği bir zafiyet değil
  • Ajan sistemi düzeyinde ele alınması gereken yapısal bir sorun

• Ayrıntılı Yetki Kontrolü

  • GitHub gibi MCP entegrasyonları kullanılırken ajanın erişim yetkileri gerekli depolarla sınırlandırılmalı
  • Geleneksel token tabanlı yetkiler bir miktar koruma sağlasa da, ajan işlevlerini kısıtlayan katı sınırlamalar oluşturabilir
  • Invariant, ajan sistemlerine uygun dinamik bir çalışma zamanı güvenlik katmanı öneriyor
  • Invariant Guardrails, ajan iş akışına uyum sağlayan bağlam farkındalıklı erişim kontrolü sunuyor
  • Örnek politika, aynı oturumda yalnızca tek bir depoya erişime izin vererek depolar arası bilgi sızıntısını önlüyor
  • Farklı repo veya owner için depo ile ilgili araç çağrıları art arda gelirse bu bir ihlal olarak değerlendiriliyor
  • Politikanın tamamı github_policy.txt içinde görülebilir
  • Uygulama yöntemi MCP-scan documentation içinde yer alıyor
  • Guardrails Playground üzerinden dağıtımdan önce politikalar test edilebilir

• Sürekli Güvenlik İzleme

  • Önleyici tedbirlerin yanında gerçek zamanlı tehdit tespiti ve müdahale için izleme de gerekli
  • Invariant, ajanlar ile MCP sistemleri arasındaki etkileşimleri sürekli denetlemek için MCP-scan gibi özel güvenlik tarayıcılarının kullanılmasını öneriyor
  • MCP-scan’in proxy mode özelliği, mevcut ajan altyapısını değiştirmeden MCP bağlantılarının gerçek zamanlı taranmasını sağlıyor
  • MCP trafiği bir proxy üzerinden yönlendirilirse görünürlük ve gerçek zamanlı güvenlik ihlali taraması elde edilebilir
  • Kapsamlı izleme, denetim izi oluşturarak potansiyel zafiyetlerin, istismar girişimlerinin ve yeni saldırılara karşı koruma durumunun doğrulanmasına yardımcı olur

Yalnızca Model Hizalaması Yeterli Değil

• Deneyde, en güncel hizalama ve güvenlik eğitimi uygulanmış Claude 4 Opus kullanıldı
• Güçlü güvenlik eğitimine rağmen ajan, görece basit bir prompt injection ile manipüle edilebildi
• Mevcut birçok prompt injection tespit savunması da bu saldırıyı yakalayamadı
• Ajan sistemi güvenliği bağlama ve ortama bağlıdır
  • Genel model hizalama eğitimi, her dağıtım senaryosunu veya kuruma özgü güvenlik gereksinimini öngöremez
  • Sistem düzeyindeki güvenlik önlemleri, model düzeyindeki korumaları tamamlamalıdır

Ajan Güvenliğinde Kalan Zorluklar

• GitHub MCP server kullanan ajanlar, kötü amaçlı GitHub Issue’ları üzerinden manipüle edilerek özel depo verilerini herkese açık depolara sızdırabilir
• Bu zafiyet GitHub MCP’ye özgü olsa da, benzer saldırılar başka ortamlarda da ortaya çıkmaya devam ediyor
  • Legit Security kısa süre önce GitLab Duo içindeki uzaktan prompt injection zafiyetini raporladı
• Büyük ölçekte sorumlu dağıtım için MCP entegrasyonları ve ajan sistemlerinde MCP-scan ve Guardrails gibi özel güvenlik tarayıcıları ile politika kontrolleri gerekli

[crawler]

Kulağa büyük geliyor ama aslında sadece prompt injection + MCP’nin kullanabildiği yetkilerin fazla olmasından kaynaklanan bir sorun.
Bu yüzden, sanki MCP yetkilerini dışarıdan kontrol edebilen bir aracı tanıtıyormuş gibi bir his veriyor.
Dışarıdan girilen prompt’larla yalnızca içeriden girilen prompt’ların kullanabildiği MCP yetkileri farklı olursa iyi olur.