Resmi MCP Python SDK'da tespit edilen bir güvenlik açığının, kötü niyetli bir MCP sunucusunun uygulamayı kandırarak gerçek bir servise giriş için kullanılan OAuth kimlik bilgilerini ele geçirmesine olanak tanıdığı açıklandı. SDK bakımcılarının güvenlik danışma metnine göre etkilenen sürümler, istemci gizli anahtarını, yetkilendirme kodunu ve PKCE kanıt anahtarını saldırganın kontrolündeki bir token uç noktasına gönderiyor. Sorun 1.x kolunda 1.30.0 ve 2.x kolunda 2.2.0 sürümlerinde düzeltildi. Model Context Protocol (MCP), yapay zeka uygulamalarını dış araçlara ve verilere bağlamak için kullanılan açık bir standart ve bu paket, MCP sunucuları ve istemcileri oluşturmak için resmi Python SDK'sı olarak sunuluyor.
Çalınan kimlik bilgileriyle saldırganın gerçek giriş servisinden geçerli bir erişim belirteci talep edebildiği belirtildi. Açığı bildiren güvenlik firması Cycode, bu tam değişimi bir test ortamında gösterdi ve ortaya çıkan belirtecin uygulamaya verilmiş olan tüm izinleri taşıdığını ifade etti. İstemci gizli anahtarının uzun ömürlü olması nedeniyle değiştirilene kadar geçerliliğini koruduğu vurgulandı. Açık, insan olmadan çalışan iki sağlayıcı için yüksek seviye olarak 7,5 puanla derecelendirildi. Bir kişinin oturum açma işlemini başlatmasının gerektiği etkileşimli sağlayıcı için puan 6,5 olarak kaydedildi. 29 Eylül itibarıyla açığa bir CVE atanmadığı bildirildi.
Yönlendirmenin iki şekilde yapılabildiği anlatıldı. Saldırgan sunucu, doğrudan kendi sunucusunu işaret edebiliyor ya da kullanıcının gerçek servisini isim olarak gösteren giriş detayları sunarken kimlik bilgilerini başka bir yere gönderecek şekilde yapılandırma yapabiliyor. İstemci bu durumda gizli anahtarını, yetkilendirme kodunu ve PKCE kanıt anahtarını gerçek servis yerine saldırgana gönderiyor.
PKCE kanıt anahtarının, çalınan bir yetkilendirme kodunun yeniden kullanılmasını engellemek için tasarlanmış tek seferlik bir değer olduğu hatırlatıldı. Bu anahtarın da ele geçirilmesiyle söz konusu korumanın etkisiz hale geldiği kaydedildi. Etkileşimli sağlayıcıda kişinin yine de bir oturum açma işlemini onaylaması gerektiği, ancak Cycode'a göre onaylanan sayfanın gerçek giriş sayfası olması nedeniyle kullanıcı açısından şüpheli bir durum görünmediği belirtildi. Makineden makineye çalışan iki sağlayıcıda ise hiçbir oturum açma ve hiçbir insan etkileşimi gerekmediği vurgulandı.
SDK ile oluşturulmuş MCP sunucularının, yerel (stdio) istemcilerin ve kendi belirteçlerini ekleyen istemcilerin etkilenmediği açıklandı. Etkilenen ve düzeltilen sürümler ise şöyle sıralandı:
Yükseltmenin iki sağlayıcı için tek başına yeterli olmadığı vurgulandı. ClientCredentialsOAuthProvider veya PrivateKeyJWTOAuthProvider kullananların, danışma metnine göre kimlik bilgilerinin ait olduğu giriş servisini belirtmek için ayrıca issuer= parametresini geçmesi gerekiyor. Bu parametre olmadan istemcinin, MCP sunucusunun işaret ettiği sunucuyu takip etmeye devam ettiği kaydedildi. 1.30.0 sürümünde bu konudaki uyarının standart bir deprecation uyarısı olarak verildiği ve Python'da varsayılan olarak gizlendiği için kolayca gözden kaçabileceği uyarısı yapıldı.
Desteği sonlandırılmış RFC7523OAuthClientProvider için hiçbir issuer= seçeneği bulunmadığı, bu nedenle diğer iki sağlayıcıdan birine geçiş yapılması gerektiği bildirildi. Yükseltme sonrasında, daha önce saklanan OAuth istemci kayıtlarının bir kez temizlenmesi istendi; çünkü eski kayıtların bir giriş servisine bağlı olmadığı ve bu şekilde kalmaya devam ettiği belirtildi.
Daha önce güvenilmeyen bir sunucuya bağlanmış olabilecek istemciler için, giriş servisinde istemci gizli anahtarının döndürülmesi ve belirteçlerin iptal edilmesi önerildi. Eski sürümlerde, yalnızca güvendiğiniz MCP sunucularına bağlanmak dışında bir geçici çözüm bulunmadığı ifade edildi.
Danışma metninde, Cycode araştırmacısı da dahil olmak üzere sekiz raportöre teşekkür edildiği bildirildi. Ne danışma metninde ne de Cycode'un raporunda açığı kullanan herhangi bir saldırıdan söz edilmediği, başka bir yerde de bu açığı kullanan bir saldırının raporlanmadığı kaydedildi.
Çalınan kimlik bilgileriyle saldırganın gerçek giriş servisinden geçerli bir erişim belirteci talep edebildiği belirtildi. Açığı bildiren güvenlik firması Cycode, bu tam değişimi bir test ortamında gösterdi ve ortaya çıkan belirtecin uygulamaya verilmiş olan tüm izinleri taşıdığını ifade etti. İstemci gizli anahtarının uzun ömürlü olması nedeniyle değiştirilene kadar geçerliliğini koruduğu vurgulandı. Açık, insan olmadan çalışan iki sağlayıcı için yüksek seviye olarak 7,5 puanla derecelendirildi. Bir kişinin oturum açma işlemini başlatmasının gerektiği etkileşimli sağlayıcı için puan 6,5 olarak kaydedildi. 29 Eylül itibarıyla açığa bir CVE atanmadığı bildirildi.
Açık Nasıl Çalışıyor?
MCP istemcisinin oturum açması gerektiğinde, bağlandığı sunucuya giriş servisinin yani yetkilendirme sunucusunun nerede bulunabileceğini sorduğu aktarıldı. Etkilenen sürümlerde SDK'nın bu yanıtı her zaman doğrulamadığı belirtildi. Bu durumun, kötü niyetli bir sunucunun istemciyi saldırganın seçtiği bir giriş servisine yönlendirmesine imkan verdiği ifade edildi.Yönlendirmenin iki şekilde yapılabildiği anlatıldı. Saldırgan sunucu, doğrudan kendi sunucusunu işaret edebiliyor ya da kullanıcının gerçek servisini isim olarak gösteren giriş detayları sunarken kimlik bilgilerini başka bir yere gönderecek şekilde yapılandırma yapabiliyor. İstemci bu durumda gizli anahtarını, yetkilendirme kodunu ve PKCE kanıt anahtarını gerçek servis yerine saldırgana gönderiyor.
PKCE kanıt anahtarının, çalınan bir yetkilendirme kodunun yeniden kullanılmasını engellemek için tasarlanmış tek seferlik bir değer olduğu hatırlatıldı. Bu anahtarın da ele geçirilmesiyle söz konusu korumanın etkisiz hale geldiği kaydedildi. Etkileşimli sağlayıcıda kişinin yine de bir oturum açma işlemini onaylaması gerektiği, ancak Cycode'a göre onaylanan sayfanın gerçek giriş sayfası olması nedeniyle kullanıcı açısından şüpheli bir durum görünmediği belirtildi. Makineden makineye çalışan iki sağlayıcıda ise hiçbir oturum açma ve hiçbir insan etkileşimi gerekmediği vurgulandı.
Kimler Etkileniyor ve Hangi Sürümler Risk Altında?
Bir uygulamanın etkilenmesi için belirli koşulların bir arada bulunması gerektiği bildirildi. Buna göre SDK'yı HTTP üzerinden MCP istemcisi olarak kullanan, OAuth sağlayıcılarından OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider veya desteği sonlandırılmış 1.x sürümündeki RFC7523OAuthClientProvider'dan birini barındıran ve tam olarak kontrol etmediği bir sunucuya bağlanabilen, aynı zamanda gerçek bir giriş servisi için kimlik bilgilerini tutan uygulamalar risk altında bulunuyor.SDK ile oluşturulmuş MCP sunucularının, yerel (stdio) istemcilerin ve kendi belirteçlerini ekleyen istemcilerin etkilenmediği açıklandı. Etkilenen ve düzeltilen sürümler ise şöyle sıralandı:
- 1.x kolu: 1.9.1 ile 1.29.1 arasındaki sürümler etkilendi, düzeltme 1.30.0 sürümünde yayımlandı.
- 2.x kolu: 2.0.0 ile 2.1.1 arasındaki sürümler etkilendi, düzeltme 2.2.0 sürümünde yayımlandı.
Nasıl Güncelleme Yapılmalı ve Ek Önlemler Neler?
Danışma metninde ilk adım olarak 1.x kolunu kullananların 1.30.0 sürümüne, 2.x kolunu kullananların ise 2.2.0 sürümüne yükseltme yapması istendi. Düzeltilen sürümlerde istemcinin, herhangi bir detayı almadan önce hangi giriş servisini beklediğini belirlediği ve farklı bir servisi işaret eden yanıtları reddettiği belirtildi.Yükseltmenin iki sağlayıcı için tek başına yeterli olmadığı vurgulandı. ClientCredentialsOAuthProvider veya PrivateKeyJWTOAuthProvider kullananların, danışma metnine göre kimlik bilgilerinin ait olduğu giriş servisini belirtmek için ayrıca issuer= parametresini geçmesi gerekiyor. Bu parametre olmadan istemcinin, MCP sunucusunun işaret ettiği sunucuyu takip etmeye devam ettiği kaydedildi. 1.30.0 sürümünde bu konudaki uyarının standart bir deprecation uyarısı olarak verildiği ve Python'da varsayılan olarak gizlendiği için kolayca gözden kaçabileceği uyarısı yapıldı.
Desteği sonlandırılmış RFC7523OAuthClientProvider için hiçbir issuer= seçeneği bulunmadığı, bu nedenle diğer iki sağlayıcıdan birine geçiş yapılması gerektiği bildirildi. Yükseltme sonrasında, daha önce saklanan OAuth istemci kayıtlarının bir kez temizlenmesi istendi; çünkü eski kayıtların bir giriş servisine bağlı olmadığı ve bu şekilde kalmaya devam ettiği belirtildi.
Daha önce güvenilmeyen bir sunucuya bağlanmış olabilecek istemciler için, giriş servisinde istemci gizli anahtarının döndürülmesi ve belirteçlerin iptal edilmesi önerildi. Eski sürümlerde, yalnızca güvendiğiniz MCP sunucularına bağlanmak dışında bir geçici çözüm bulunmadığı ifade edildi.
Açığın Keşfi ve Duyuru Süreci
Düzeltmeye ilişkin issuer kontrollerinin 7 Eylül'de yayımlanan 1.30.0 ve 2.2.0 sürüm notlarında yer aldığı, ancak burada bir güvenlik düzeltmesi olarak değil davranış değişiklikleri başlığı altında listelendiği aktarıldı. Güvenlik danışma metninin ise 28 Eylül'de yayımlandığı ve aynı gün Cycode'un kendi yazısını paylaştığı belirtildi.Danışma metninde, Cycode araştırmacısı da dahil olmak üzere sekiz raportöre teşekkür edildiği bildirildi. Ne danışma metninde ne de Cycode'un raporunda açığı kullanan herhangi bir saldırıdan söz edilmediği, başka bir yerde de bu açığı kullanan bir saldırının raporlanmadığı kaydedildi.
Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yorumlar (0)
Yorum yapmak için giriş yapmalısınız.