FireAI Güvenlik Blogu

Yazan FireAI Security & Research Team · Yayınlandı

Uç Nokta Tespiti Neden Sahtekar Bir Yapay Zeka Aracısıyla Mücadele Ediyor?

Uç Nokta Tespiti Neden Sahtekar Bir Yapay Zeka Aracısıyla Mücadele Ediyor?

Uç Nokta Tespiti ve Yanıtı yirmi yılını bir soruyu iyi yanıtlamak için harcadı: Bu süreç, kötü amaçlı kodun yapabileceği bir şey mi yapıyor? İmzaları kontrol eder, anormal davranışları izler ve yetkisiz ayrıcalık artışını işaretler. Araç erişimine sahip bir yapay zeka aracısı, kötü amaçlı kod olması nedeniyle değil, kendi, tamamen meşru erişimini kötüye kullanması konusunda ikna edilebilecek güvenilir bir program olması nedeniyle bu sorunun öncülünü bozar.

Bu sorunun yapay zeka öncesi sürümünün zaten bir adı var

Kötü amaçlı bir şey yapmak için meşru, imzalı bir program kullanmak yeni bir şey değil. MITRE ATT&CK bunu Sistem İkili Proxy Yürütme (T1218) olarak katalogluyor: "Güvenilir dijital sertifikalarla imzalanan ikili dosyalar genellikle dijital imza doğrulaması ile korunan Windows sistemlerinde yürütülebilir", bu da tam olarak bu nedenle güvenilir ikili dosyanın kendisi harekete geçtiğinde izin verilenler listesine ekleme ve imza kontrollerinin zorluk yaşamasına neden olur. Bir yapay zeka aracısı, aynı zayıflığı, kötü amaçlı kodla önceden yüklenmesi gerekmeyen bir programa kadar genişletir: çalışma zamanında okuduğu metinle yeniden yönlendirilebilir.

Kaçırılan bir ajan kafası karışmış bir milletvekilidir

Burada geçerli terim karışık milletvekili sorunu'dir: “başka bir program (daha az ayrıcalığa veya daha az haklara sahip) tarafından yetkisini kötüye kullanmak üzere kandırılan bir bilgisayar programı.” Bir temsilciye gerçek araçlar verin, ardından incelemediğiniz içeriği okumasına izin verin ve bu içerikten talimat alabilir. Bu tam olarak OWASP'ın İstemi Enjeksiyon girişi'ın tanımladığı modeldir ve sadece teorik olarak değil, zaten kanıtlanmıştır: Invariant Labs'tan 26 Mayıs 2025 raporu, bir kodlama aracısının, halka açık bir depodaki sıradan görünümlü bir GitHub sayısını okuduğunu, özel depo verilerini açığa çıkarmak için içindeki gizli talimatları, meşru olarak verilen araçları kullanarak izlediğini gösterdi. Araştırmacıların vardığı sonuç: "Bu, GitHub MCP sunucu kodunun kendisindeki bir kusur değil, aracı sistem düzeyinde ele alınması gereken temel bir mimari sorundur."

Açıklayıcı: EDR günlük girişi her iki durumda da nasıl görünüyor?
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling

# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.

Gerçek kör nokta budur: herhangi bir üründe bir boşluk değil, ancak "temsilcinin normal işini yaptığı" ve "temsilcinin normal işini kötüye kullanması için kaçırıldığı" günlük girişinin süreç düzeyinde aynı olabileceği gerçeği. İkiliyle ilgili hiçbir şey değişmedi. Sistem çağrısı düzeniyle ilgili hiçbir şey yeni değil. Yalnızca isteğin arkasındaki amaç değişti ve amaç, işlem günlüğündeki bir alan değil.

Aslında bunu azaltan ve azaltan şey nedir?

Bu modele adını veren kişinin gerçekte ne tavsiye ettiği konusunda kesin olmakta fayda var. “ölümcül üçlü” özel veri erişimi, güvenilmeyen içeriğe maruz kalma ve dış iletişimin tek bir temsilcide bir arada olduğunu anlatan Simon Willison, bu kombinasyondan kaçınmanın ek bir korkuluk değil gerçek çözüm olduğunu açıkça belirtiyor: "Orada güvende kalmanın tek yolu, bu ölümcül üçlü kombinasyondan tamamen kaçınmaktır." Kendisi, enjekte edilen talimatları güvenilir bir şekilde yakaladığını iddia eden ürünlere açıkça şüpheyle yaklaşıyor ve "bunun gerçekleşmesini yüzde 100 güvenilir bir şekilde nasıl önleyeceğimizi hala bilmediğimizi" ve yüzde 95'lik bir yakalama oranının bir güvenlik kontrolü için "oldukça başarısız bir derece" olduğunu belirtiyor.

  • Önce tasarlayın: Bir aracıya görevin ihtiyaç duyduğu en dar araçları ve veri erişimini verin, böylece başarılı bir enjeksiyonun kötüye kullanılması daha az olur (hem Willison hem de Invariant Labs'ın işaret ettiği mimari düzeltme).
  • Temsilcinin okuduğu, sizin yazmadığınız veya incelemediğiniz içeriği, sorunları, getirilen sayfaları, indirilen dosyaları prensip olarak her zaman güvenilmeyen girdi olarak değerlendirin.
  • Tasarım ve incelemenin yeterli olmadığı durumlarda, veri hırsızlığı girişiminin atlayamayacağı tek adım ağ bağlantısını kesmektir. Bunu süreç başına izlemek veya kısıtlamak, bir aracının kandırılmasını engellemez, ancak ilk etapta enjekte edilen talimatın tanınmasına bağlı olmayan gerçek, bağımsız bir katmandır.

FireAI ve HisnLabs burada nereye oturuyor

No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.

FireAI, HisnLabs’in kendi ürünüdür: doğrudan Mac’inizde çalışan, yapay zekâ destekli bir güvenlik duvarı. Uygulamalarınızın kurduğu her bağlantıyı sade bir dille gösterir ve Mac’inizden neyin çıkacağına sizin karar vermenizi sağlar — yapay zekâsı yerel olarak çalışır, yani trafiğiniz asla bize ya da başka birine gönderilmez. HisnLabs güvenlik araştırma ekibi bu kararların isabetli kalmasını sağlayan ekiptir: hangi alan adlarının sıradan telemetri, hangilerinin gerçek bir hizmet olduğunu kataloglar, bir bağlantının ardındaki ülkeyi ve ağı izler ve cihaz üzerindeki modeli (Autopilot özelliği) gerçek trafik örüntüleriyle eğitir — üstelik bunların hiçbiri Mac’inizden dışarı çıkmadan.

Arkasındaki teknik kararları okuyabilir ya da FireAI’yi 17 gün boyunca deneyebilirsiniz: HisnLabs’ten FireAI.

Kaynaklar