GitLost: GitHub yapay zeka ajanı kandırılarak özel depolar sızdırıldı

 (noma.security)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Noma Labs, GitHub Agentic Workflows'ta dolaylı prompt injection açığı olan GitLost'u keşfetti; yalnızca herkese açık bir depo issue'su üzerinden aynı organizasyondaki özel depo verileri herkese açık yorumlarda ifşa edilebildi
  • Bu özellik, Markdown iş akışlarını YAML Actions dosyalarına derliyor; Claude veya GitHub Copilot tabanlı yapay zeka ajanı issue'ları okuyup araç çağırıyor ve organizasyon içindeki depolara erişiyor
  • Savunmasız iş akışı, issues.assigned etkinliğinde issue'nun Title ve Body alanlarını okuyup add-comment ile yanıt veriyordu ve hem herkese açık hem de özel depoları okuma iznine sahipti
  • Saldırganın kod, erişim izni veya kimlik bilgisine ihtiyacı yoktu; yalnızca herkese açık depoda inandırıcı bir issue açması yeterliydi. Testlerde poc ve testlocal içindeki README.md içerikleri herkese açık issue yorumuna gönderildi
  • GitHub'ın koruma mekanizmaları “Additionally” varyantında amaçlandığı gibi engelleyemedi; ajan tabanlı yapay zekada context window başlı başına bir saldırı yüzeyi olarak görülmeli ve kullanıcı kontrollü içerik güvenilir talimatlardan ayrılmalı

GitLost'un hedef aldığı güven sınırı

  • Noma Labs, GitHub'ın yeni Agentic Workflows özelliğinde GitLost adlı bir açık keşfetti
  • Kimliği doğrulanmamış bir saldırgan, aynı organizasyonun herkese açık deposuna manipüle edilmiş bir GitHub Issue gönderirse, ajan organizasyon içindeki özel depolardan veri çekmeye yönlendirilebiliyordu
  • Saldırı yöntemi, yapay zeka ajanının okuduğu içeriğe kötü niyetli talimatların gizlendiği dolaylı prompt injection kategorisine giriyor
  • İşletmecinin amaçladığı talimatlar yerine saldırganın gizlediği talimatlar önce işlenirse, özel veriler herkesin görebildiği herkese açık issue yorumlarına sızabiliyor

GitHub Agentic Workflows nasıl çalışıyor?

  • GitHub Agentic Workflows, ekiplerin depo otomasyonunu doğal dilde yazabilmesini sağlıyor
  • İş akışları Markdown .md dosyaları olarak yazılıyor ve YAML biçimindeki GitHub Actions .yml dosyalarına derleniyor
  • Çalıştırıldığında Claude veya GitHub Copilot tabanlı yapay zeka ajanı, tanımlanmış izinler dahilinde görev yapıyor
    • GitHub Issue okuma
    • Araç çağırma
    • Organizasyon içindeki diğer depolara erişme

Savunmasız iş akışı koşulları

  • Noma Labs'ın doğruladığı savunmasız yapılandırma, herkese açık issue'larla ajan izinleri birleştiğinde sorun yaratıyor
    • İş akışı, GitHub'ın issues.assigned etkinliğiyle tetikleniyor
    • Issue'nun Title ve Body alanlarını okuyor
    • add-comment aracıyla yorum gönderiyor
    • Organizasyon içindeki diğer depolar için okuma iznine sahip
      • Herkese açık depolar
      • Özel depolar
  • Saldırganın ayrıca kod yazmasına, erişim iznine veya kimlik bilgisine ihtiyacı yoktu
  • Gerekli tek koşul, GitHub Agentic Workflow kullanan organizasyonun herkese açık deposunda bir issue açabilmekti

Saldırı akışı

  • Araştırmacılar, müşteri toplantısından sonra VP Sales tarafından istenmiş gibi görünen inandırıcı bir GitHub Issue hazırladı
  • Issue atanınca iş akışı aksiyonu tetiklendi; testlerde aynı yöntemin başka GitHub workflow action'larında da çalıştığı görüldü
  • GitHub otomasyonu issue'yu atadıktan sonra, olayla çalışan iş akışı ajanı depo içeriğini getirmeye yönlendirdi
  • Ajan şu depolardaki README.md içeriğini getirmeye ikna edildi
    • poc herkese açık deposu
    • testlocal özel deposu
  • Ardından GitHub ajanı bu içerikleri herkese açık depodaki issue yorumuna gönderdi ve herkes tarafından okunabilir hale getirdi

“Additionally” ile koruma mekanizmasını aşmak

  • GitHub'da bu senaryoyu engellemek için sınırlı koruma mekanizmaları vardı
  • Noma Labs, bir saldırgan gibi birden fazla varyasyonu tekrar tekrar test etti
  • “Additionally” anahtar kelimesi eklendiğinde modelin reddetmek yerine çıktıyı yeniden yapılandırdığı, amaçlanmamış bir davranış ortaya çıktı
  • Bu atlatma yöntemiyle GitHub'ın koruma mekanizmaları amaçlandığı gibi çalışmadı ve veri sızıntısını önleyemedi

PoC ve açığa çıkan veriler

Ajan tabanlı yapay zekada değişen güvenlik varsayımları

  • Ajanın context window'u hem çalışma alanı hem de saldırı yüzeyi haline geliyor
  • Ajanın okuduğu her içerik silah haline getirilebilir
    • Issue'lar
    • Pull Request'ler
    • Yorumlar
    • Dosyalar
  • Geleneksel güvenlik modelleri çoğu zaman güven sınırlarının kod tarafından zorlandığını varsayar
  • Ajan tabanlı sistemlerde güven sınırının bir kısmı modelin davranışı tarafından uygulanır
  • Model doğası gereği talimatları takip ettiği için, prompt injection ajan tabanlı yapay zekada web uygulamalarındaki SQL injection ile aynı türden kategorik bir zafiyete dönüşür
  • Bu açık türü için sistematik stratejiler ve savunmalar gerekir

Önerilen savunmalar ve açıklama süreci

  • Kullanıcı kontrollü içerik, yapay zeka ajanının güvenilir talimat girdisi olarak ele alınmamalı
  • Ajan izinleri gerekli olan en dar kapsamla sınırlandırılmalı
    • Birden fazla depoya erişebilen ajanlar özellikle yüksek değerli saldırı hedeflerine dönüşür
  • Issue içeriğine yanıt verme gibi durumlarda, ajanın herkese açık şekilde paylaşabileceği içerik sınırlandırılmalı
  • Kullanıcı girdisi modele iletilmeden önce talimat bağlamından arıtılmalı veya yalıtılmalı
  • GitLost, GitHub'a sorumlu biçimde bildirildi ve açığın ayrıntıları GitHub'ın bilgisi dahilinde paylaşıldı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Prompt injection'ın, ajan tipi yapay zekada SQL injection'ın web uygulamalarındaki konumuna denk olduğu benzetmesi tuhaf. Prompt injection bana LLM'ler için SQL injection'dan çok daha ölümcülmüş gibi geliyor
    SQL injection, kullanıcı girdisi SQL motoruna gönderilen komut dizgesinin bir parçası olduğunda ortaya çıktı; kötü niyetli girdi mevcut komutu SQL sözdizimi belirteçleriyle sonlandırıp kendi SQL komutunu eklediğinde motor ikisini de çalıştırıyordu. Çözüm, prepared statement gibi sabit, statik, önceden derlenmiş komut dizgeleri kullanmak ve rastgele kullanıcı girdisini yalnızca veri olarak uygulamaktı
    Ajanlardaki benzer bir hafifletme, “repo 1 oku”, “repo 2 oku” gibi sabit eylemler tanımlayıp kullanıcı girdisini yalnızca hangi eylemin çalıştırılacağını seçen veri olarak kullanmak olurdu; buna zaten menü denen teknik deniyor. LLM'nin değeri özünde menünün ötesinde olmasında, SQL'in değerinin ise “rastgele verilere uygulanan önceden tanımlı mantık”ın ötesine geçmek zorunda olmamasında yatıyor

    • Doğru. SQL injection, kullanıcı girdisine saf veri değil komutun bir parçası muamelesi yapıldığı için ortaya çıktı ve ikisi ayrılınca çözüldü. Prompt injection ise kullanıcı girdisinin kendisi komut olarak amaçlandığı için kaçınılması zor
    • “Çözüm prepared statement'tır” demektense, asıl nokta parametre bağlama. Parametreleri SQL ifadesinden ayrı göndererek kod ile kullanıcı verisini ayırıyorsun
      Ajanlara yalnızca sınırlı eylemler izin vermek bazı özel sorunları ancak kısmen ele alır; ayrıca kod ile kullanıcı verisini de ayırmaz, dolayısıyla aynı problem değildir. Yalnızca sınırlı eylemler bırakmak, daha sıkı veritabanı izinleri kullanmaya daha çok benzer. Kullanıcının zaten çalıştırabileceği SQL'e izin veriliyorsa SQL injection da büyük ölçüde anlamını yitirir
    • SQL injection ile aynı türden bir problem ama çözüm zorluğu aynı değil. Çok daha incelikli sorunlar çıkabilir, ancak açıklama amaçlı bir benzetme olarak fena değil
      Menüden seçtirmek bir yöntem ama mümkün eylem aralığı daha geniş tasarlanabilir. Bir e-posta aracı verirsen müşterilere spam gönderebilir; yalnızca yanıt vermeye kilitlersen hasar alanını azaltırsın. Görüntü render etme yoluyla verinin sızması gibi açıklar misali, veri sızıntısı da kısıtlanmalı
    • Prompt injection ölümcül değil; aslında gerçek bir problemden çok alttaki güvenlik mimarisi sorununu görünür kılıyor. İnsanlara yönelik sosyal mühendislik saldırılarına benziyor
      Çözüm de aynı. En az ayrıcalıkla rol tabanlı erişim kontrolü uygular, kritik eylemler için yönetici onayı istersin. O zaman LLM'nin tek başına yapabileceği en kötü şey uygunsuz kelimeler üretmek olur
    • Bunun herkesin düşündüğü kadar derin bir sorun olduğundan emin değilim. SQL injection da aynı derecede tehlikeli. Çünkü sorguyu çalıştıran kullanıcının yapabildiği tüm veritabanı işlemlerine sınırsız erişim açıyor
      Hafifletmelerden biri prepared statement, ama bir diğeri de hiçbir kullanıcıya tüm veritabanına tam erişim vermemek. Salt okunur bir kullanıcı, SQL injection olsa da olmasa da DROP TABLE çalıştıramamalı
      Bu ajan sınırsız okuma erişimine sahip ve yanıttaki “alıcı” kavramı yok. Alıcının yetkilerini dahil edersen okuma erişiminin otomatik reddedilmesini sağlamak oldukça basit olur. Tek çözüm bu değil ama bu yönde çözümler düşünmek zor değil
      “Menü” örneği de aslında hiçbir şeyin değişmediği anlamına geliyor. İster LLM ister insan çalışan olsun, izin verilen şeyler kontrollü ve sabit bir eylem kümesiyle sınırlı. Serbestlik çoğunlukla ifadede, yetkilendirme ise sabit kümede. Neden menünün ötesine geçmesi gerektiğini bilmiyorum

  • Bunun neden bir GitHub güvenlik açığı olduğunu anlamıyorum. Araştırmacılar ajana özel depoya erişim izni verip herkese açık depoda soruları yanıtlatmış; dolayısıyla özel bilgilerin çıkarılması elbette mümkün.
    Bu, gizli değerlere erişebilen sıradan bir CI işini oluşturup bunu herkese açık bir PR'da çalıştırmakla aynı şey. GitHub'ı, herkese açık kodun ya da LLM talimatlarının hassas verilere erişebilen bir bağlamda çalışmasına izin verecek şekilde yapılandırırsanız sızıntı olur. Bu GitHub'ın hatası değil, o şekilde yapılandıranın hatasıdır.

    • Sanırım izinlerin yalnızca o anda soru sorulan depoyla sınırlı olduğunu, özel depoları kapsamadığını varsaymışlar. İki tarafın mantığını da anlıyorum.
    • GitHub, ajan erişimini güvenli şekilde yapılandırmayı kolaylaştırmıyor. Genel erişim token'ları ve uygulama kimlik bilgileri, özel depolara doğrudan erişim vermek için yeterince ince taneli denetim sunmuyor.
      Token kapsamını çok sıkı tutsanız bile herkese açık depo erişimi her zaman açık kalıyor; örneğin herkese açık depo issue'ları üzerinden sızdırma yolu kalıyor. Güvenli olması için, GitHub'ın sunduğundan daha katı denetimler uygulayan bir MITM proxy ile tamamlamak gerekir.
      GitHub Agentic workflows muhtemelen bu sorun için resmî birincil çözüm olacak, ancak gerek güvenlik modeli gerek güvenli kullanılabilirlik açısından hâlâ yapılacak işler var gibi görünüyor.
      Ayrıntılar: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • Bu tür prompt injection saldırılarının özünde, ajan izin kapsamının düzgün kısıtlanamaması var. Bu durumda ajanın gerçekten yapması gereken işe göre depo başına ayrı workflow ajanları kullanabilir ya da daha geniş depo erişimi olan bir ajan tanımlayıp bunu yalnızca izin verilenler listesindeki kullanıcıların tetiklemesine izin verebilirsiniz.
      Bu, açık geliştirmeyle de uyumlu olabilir; dışarıdan kişilerin herkese açık issue açmasına izin verirken her kullanıcı için farklı güven seviyelerini yansıtabilirsiniz. Doğru şekilde düşünülürse seçenekler daha da fazla olacaktır.
      Bunun için hem ince kapsam belirleme hem de izinlerin teknik olarak desteklenmesi gerekir; ayrıca ajanla ne başarmak istediğinizi ve bunun için gereken en düşük izin ve yetenekleri zaman ayırıp değerlendirmeniz gerekir.
      İlkinin geleceğini düşünüyorum. Ajan kullanımı hâlâ vahşi batı döneminde. İnsanların ajan tasarlarken kapsam ve izinleri bulup tanımlamasındaki sürtünmeyi azaltacak soyutlamaların, ayrıca ajan yeteneklerini kısıtlarken ayrıntı düzeyi ile kullanılabilirlik arasında denge kuran arayüzlerin ne olacağını görmek ilginç olacak.
      İkincisi ise yüksek kaliteli yazılım üretmenin önündeki temel engeldi ve hâlâ öyle. Doğru düşünmeye ve doğru uygulamaya zaman ayırmak, ajanları “hızlı hareket et ve kır” anlayışıyla rastgele her yere atma yaklaşımıyla doğrudan çelişiyor.
    • Ajanik workflow'lara göre erişimi bölüp birinin hassas verilere, diğerinin yalnızca herkese açık verilere erişmesini sağlamanın bir yolu var mı? Varsayılan olarak kapsam yalnızca mevcut depoyla mı sınırlı? GitHub, özel depo verilerine erişim ile ajanik workflow'ların birleşmesinin risklerini yeterince açık şekilde anlatıyor mu?
      Bu sorulardan birinin bile cevabı “hayır” ise ortada bir sorun vardır. Klasik GitHub Workflows'ta da PR tetiklemeli workflow'lar üzerinden bir sürü ayrıcalık yükseltme sorunu var, ama bu ayrı bir konu.
    • İzinler açısından bakarsanız LLM sadece aptal bir terminaldir. İstenen şey, prompt'a göre anlık bileşik izinler üretiyormuş gibi görünmek; bu da “hazır cümle” çözümünden çok “kullanıcının SQL sorgusunu regex ile güvenli hâle getireceğim” demeye benziyor. Bunun sonunun nereye vardığını zaten biliyoruz.
      Gerçek çözüm, prompt bazlı izin kontrolü UI'ını iyileştirmektir. “Web'de ara” seçeneğini açıp kapatır gibi “özel depolarımı da dahil et” seçeneğini de kolayca açıp kapatabilmek gerekir.

  • Araştırmacıların “Additionally” gibi tek bir kelimeyle GitHub'ın övündüğü guardrail'leri aşabilmesi komik. Bu, LLM bağlam penceresinin içinde güçlü bir güvenlik sınırı oluşturmaya çalışma girişimlerinin başarısız olmaya mahkûm olduğunu gösteriyor.
    Model özünde talimat izlemek üzere yapıldığından, sistem kurallarıyla kullanıcı girdisini karıştırırsanız daha yeni ya da daha ısrarcı talimat kazanacaktır.

  • “Sorumlu açıklama” bölümünde bunun ne zaman düzeltildiği ya da GitHub'ın bunu kabul edip etmediği neden yok? GitLost'un GitHub'a sorumlu şekilde bildirildiği ve ayrıntıların GitHub'ın bilgisi dâhilinde paylaşıldığı yazıyor; peki bu hâlâ düzeltilmedi mi?

    • Bu tipik bir yazılım hatası değil ve sıradan bir destek çalışanının kandırılmasını “düzeltemediğiniz” gibi bunu da aynı şekilde düzeltemezsiniz. Çözüm, LLM'nin aynı anda hem güvenilmeyen girdilere hem hassas verilere erişmesine izin vermemektir.
    • Asıl yazıyı yazanın aşağıdaki ayarı açıkken mi deneme yaptığını merak ediyorum. Bunu engelleyen kelimenin tam anlamıyla bir ayar var. Bunun bu rapor yüzünden ortaya çıkan bir ayar mı olduğunu, yoksa raporu yazanın bunu yorumlarda belirtmemesinin bir dikkatsizlik mi olduğunu öğrenmek isterim.
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • Burada tam olarak neyin düzeltileceği söyleniyor? LLM'ye sadece özel verilere erişim ile herkese açık yorumları okuma yeteneği birlikte verilmiş. Bu düpedüz yanlış yapılandırma.

  • Microsoft gibi büyük şirketler, yatırımcı baskısı nedeniyle artık AI şirketi olduklarını iddia edebilmek için her ürüne AI ekliyor. Bu biraz Adobe'nin yaptığını andırıyor.
    Tüketiciler bu yarım yamalak AI entegrasyonlarından bıkmaya başladı ve yakında bir sınır noktasına ulaşılacak gibi görünüyor.

    • Ben bıraktım. Forgejo'ya geçtim. Harika ve her şey daha iyi çalışıyor.
      Cidden, orada burada tıkladığımda her şey anında tepki veriyor ve runner eklenmiş CI da şahane çalışıyor. Runner kurulumu belgeleri biraz daha net olabilirdi ama onun dışında her şey inanılmaz derecede pürüzsüzdü.
    • Microsoft halka açık bir şirket. Tam olarak hangi yatırımcılar, istenmeyen AI özellikleriyle GitHub'ı bozması için baskı yapıyor? Bu hangi toplantıda oluyor?
    • Katılıyorum ama kurumsal AI ürünlerinin oldukça etkileyici olduğunu düşünüyorum. Yatırımcılar ve tüketiciler pek farkında değil, çalışanlar da pazarlık yapamıyor.
      Gelir gerçekten var ve etkileyici; tüketici ve koltuk bazlı gelirin yerini alıyor. Piyasa hâlâ SaaS çarpanlarını aşağı çekiyor ama bunun doğru bir değerlendirme olduğunu düşünüyorum. Çeyrek raporlarında geliri ayırdığınızda, gerçek verimlilikten gelen büyük bir büyüme hikâyesi görüyorsunuz.

  • Herkese açık depo bağlamında çalışan action’ların neden özel depo erişim yetkisine sahip olduğunu anlamıyorum. Workflow’ya bakınca genelde özel depo izni vermeyen github token kullanıyor gibi görünüyor
    Yoksa ajanın kendisi somehow daha yüksek yetkilere mi sahipti? Öyleyse ajan yanlış yapılandırılmış demektir. Ajanın bir şeyi zorunlu kıldığına güvenmemek gerektiğini zaten biliyoruz

  • Bu yazı Noma pazarlaması gibi okunuyor. Sevimli bir isim, logo, clickbait başlık ve teknik olmayan okurları hedefliyormuş gibi duran dramatik bir ton var
    Gerçek açık şu: LLM’e özel veri verir ve herkesin onunla etkileşime girmesine izin verirseniz, veriler sızabilir. Fazlasıyla bariz

  • Bu tip insanlar LLM’e tüm diske yazma izni verip yıkıcı işler yaptığında da şikayet eder
    Bir AI ajanının özel depoyu okuyamamasını istiyorsanız, ona özel depo erişim izni vermeyin. Bu bir yetki atlatma sorunu değil, prompt injection sorunu ve ajan katmanında güvenilir biçimde çözülemez

  • Bu ya zaten çözülmüş bir sorun, ya da GitHub hâlâ çözemedi ve bu arada kötü niyetli aktörler depolarda açığı denemeye devam edecek
    Depo sayısı çok fazla olduğu için sıfır olmayan bir olasılıkla sızıntılar yaşanabilir. Ama dolandırıcılık mağduriyetlerinde olduğu gibi, neredeyse hiç kimse veri sızdığını kabul etmeyecek