Kendi MCP Sunucumu Bilerek Bozunca: Otomatik Yetki Denetçisi Nasıl Oluşturuldu

Birkaç hafta önce Warden adlı bir projeyi yayınladım. Bu proje, MCP sunucularının önüne konumlanan ve kimlerin hangi verileri okuyabileceğini rol tabanlı olarak denetleyen bir yönetim katmanıydı. Örneğin, destek rolündeki kullanıcılar müşteri hesaplarını listeleyebilir ancak fatura derecesini göremezdi. Sistem, bu hassas verileri çıktıda gizliyordu. Fakat test ederken dikkatimi çeken bir sorun ortaya çıktı.

Destek rolündeki bir kullanıcı, query_resource("accounts", {"tier": "Enterprise"}) sorgusu yaptığında sistem altı şirket hesabı (Acme Corp, Initech, Umbrella, Hooli, Stark, Wayne) döndürdü. Destek rolünün çıktıda tier alanını görememesine rağmen, sorgunun filtreleme aşamasında bu alan kullanılmıştı. Yani veriler çıktıda gizlenmişti, ancak girişteki filtreleme süreci hassas bilgilerin varlığını açığa çıkarıyordu. Bu, veri gizliliğinin tamamen ihlal edildiği bir senaryoydu.

Statik Tarayıcıların Yetmediği An

Ardından, yaygın olarak kullanılan MCP güvenlik tarayıcılarını devreye aldım. Bu araçlar, sunucunun manifest dosyasını inceleyerek zararlı komutlar veya şüpheli meta veriler arıyordu. Tüm tarayıcılar temiz rapor verdi. Çünkü manifest dosyasında herhangi bir sorun yoktu. query_resource aracının açıklaması da masum görünüyordu. Hatta sorun, sunucu çalışırken ve gerçek bir rol gerçek bir çağrı yaptığında ortaya çıkıyordu. Metin taramasına dayanan statik araçlar, çalışma anındaki yetki denetimlerini yakalayamıyordu.

İşte tam da bu noktada, Siege adında yeni bir araç geliştirdim. Siege, çalışan bir MCP sunucusunu hedef alarak gerçek saldırgan gibi davranıyor. Manifest dosyasına bakmıyor; sunucunun çalışma anındaki davranışlarını test ediyor. Farklı roller adına bağlantı kuruyor ve her rolün gördüğü verileri karşılaştırıyor.

Çalışma Anındaki Yetki Denetimi

Siege’in temel prensibi, statik tarayıcıların yakalayamadığı çalışma anı yetki zafiyetlerini ortaya çıkarmak. Rol tabanlı erişim denetimi (RBAC) sistemlerinde sıkça verilen öneri, "yetki kapsamını kırmızı takım (red team) testleriyle doğrulayın" şeklindedir. Siege, bu öneriyi otomatik bir araç haline getiriyor.

En önemli kuralım, herhangi bir alanın veya rolün adını önceden kodlamamaktı. Eğer Siege sadece tier alanını arıyor olsaydı, Warden’daki sorunu yakalasa bile bu bir birim testi olurdu. Oysa Siege, farklı rollerin gördüğü veriler arasındaki farkları karşılaştırarak çalışıyor. Öncelikle, tüm verileri gören en yetkili rolün şemasını ve değerlerini öğreniyor. Ardından, daha kısıtlı rollerin gördüğü verileri bu baz çizgisiyle karşılaştırarak gizli veri sızıntılarını tespit ediyor.

Bu yaklaşım sonucunda dört farklı saldırı vektörü ortaya çıktı:

• Gizlenmiş Alan Filtre Sızıntısı: Warden’daki asıl sorunun genelleştirilmiş hali. Bir rolün çıktıda görmediği bir alanın filtre olarak kullanılması durumunda, sorgunun az sayıda satır döndürmesi gizli verilerin varlığını ortaya koyuyor.

• Kapsam Dışında Filtreleme: Bir rolün normalde sadece belirli bir coğrafi bölgedeki verileri görmesi gerekirken, başka bir bölge için filtre uyguladığında sistem tüm verileri döndürüyorsa, yetki denetimi çalışmıyordur.

• Kimlik Numarası Saydırma (IDOR): Bir rolün listeleme yoluyla erişemediği kayıtları, tekil kayıt getirme yoluyla (örneğin get_record) sorgulaması durumunda yetki kontrolü atlanabiliyor.

• Yetkisiz Kaynak Erişimi: Bir rolün belirli bir kaynağa bile erişimi yokken, tekil kayıt getirme yöntemiyle bu kayda ulaşabiliyorsa, yetki denetimi eksik demektir.

Son üç saldırı vektörü, ilkini genelleştirirken ortaya çıktı. Yani bir saldırı tespit etmek için geliştirilen sistem, diğer zafiyetleri de otomatik olarak buluyor.

Gerçek Dünya Testi: Warden Örneği

Warden’ın hem savunmasız hem de düzeltildiği iki farklı versiyonunu test ettim. Siege, her iki versiyonu da aynı koşullarda çalıştırdı.

Savunmasız Warden (4938bdf) için sonuçlar:

• YÜKSEK: tier alanı, accounts kaynağında filtre olarak kullanıldığında gizli veri sızıntısı meydana geliyor.
• Rol: destek
• Yeniden üretilebilir saldırı: query_resource({"resource_type":"accounts","filters":{"tier":"Enterprise"}})
• Baz çizgisi satır sayısı: 8
• Filtrelenmiş satır sayısı: 6
• Kaçak kayıtlar: Acme Corp, Initech, Umbrella Co, Hooli, Stark Industries, Wayne Enterprises

Düzeltildiği Warden (7188eed) için sonuçlar:

• Hiçbir bulgu yok. Tüm saldırı vektörleri başarısız oldu.
• VERDİKT: BAŞARILI — Siege hem sorunu yakaladı hem de düzeltmenin doğruluğunu onayladı.

Her saldırı tespiti, yeniden üretilebilir bir saldırı senaryosuyla birlikte geliyor. Bu senaryoları kendi MCP istemcinizde çalıştırarak gizli veri sızıntısını doğrulayabilirsiniz. Ayrıca, projenin deposunda kasıtlı olarak savunmasız bir sunucu da bulunuyor. Siege, bu sunucuda tüm dört saldırı vektörünü test ediyor, hatta yetkisiz kaynak erişimi saldırısını da yakalıyor. Merak edenler için bu testi çalıştırabilir.

Ajanların Tehdit Edilmesi: Gerçek Hayat Senaryosu

MCP güvenlik tartışmalarında sıkça bahsedilen saldırı vektörü, aracın açıklamasına veya çıktısına gizlenmiş bir komut enjekte etmektir. Statik tarayıcılar, bir açıklamanın ne kadar tehditkar olduğunu metin analiziyle değerlendirir. Fakat Siege farklı bir soruya odaklanıyor: Acaba ajan, saldırganın komutunu yerine getiriyor mu?

Siege, gerçek bir ajan döngüsü çalıştırıyor. Zararsız bir okuma aracının yanı sıra, verileri dışarıya aktaran bir export_record araç da bulunuyor. Kullanıcı, yalnızca belirli bir kaydı özetlemekle görevlendiriliyor. Ardından Siege, hem açıklama hem de çıktı kanalı üzerinden beş farklı saldırı yükünü enjekte ediyor ve ajan tarafından saldırganın hedefine veri aktarılıp aktarılmadığını gözlemliyor. Saldırganın hedef URL’sine veri aktarımı gerçekleştiyse, bu bir başarılı saldırı olarak kaydediliyor. Tüm saldırı yüklerinin engellendiği durumlar da raporlanarak, model versiyonları güncellendiğinde ortaya çıkabilecek regresyonları önlemek için bir kontrol mekanizması oluşturuluyor.

Geleceğe Yönelik Planlar

Siege şu anda yalnızca MCP sunucularını destekliyor. OpenAI fonksiyon çağırma sistemleri için uyarlanması planlanıyor. Ayrıca, şu an sadece stdio üzerinden iletişim kuran araç, gelecekte HTTP protokolünü de destekleyecek. Raporda çalıştırılan testler detaylı olarak listeleniyor ve hangi testlerin atlandığı da açıkça belirtiliyor.

Unutmayın: Statik güvenlik tarayıcıları yetmez. Çalışma anındaki yetki denetimlerini otomatik olarak test eden araçlar, modern sistemlerin güvenliği için vazgeçilmez hale geliyor.