شدت و پیامدهای آسیب‌پذیری MCP Python SDK
پروتکل کانتکست مدل (MCP) یک استاندارد باز برای اتصال اپلیکیشن‌های هوش مصنوعی به ابزارها و منابع داده خارجی است. MCP Python SDK نیز کیت توسعه نرم‌افزاری رسمی پایتون برای این پروتکل است که به توسعه‌دهندگان امکان می‌دهد سرورها و کلاینت‌های سازگار با MCP را پیاده‌سازی کنند. مهاجم با استفاده از اعتبارنامه‌های سرقت‌شده می‌تواند از سرویس اصلی احراز هویت یک توکن دسترسی معتبر دریافت کند. شرکت امنیتی Cycode که این آسیب‌پذیری را شناسایی و گزارش کرده است، در یک آزمایش توانست فرآیند کامل تبادل اعتبارنامه برای دریافت توکن را اجرا کند. این شرکت اعلام کرد توکن صادرشده همان سطح دسترسی‌هایی را در اختیار مهاجم قرار می‌دهد که به اپلیکیشن اعطا شده است. از سوی دیگر، کلید محرمانه کلاینت یک اعتبارنامه بلندمدت است و تا زمانی که تغییر نکند، همچنان معتبر باقی می‌ماند.
این آسیب‌پذیری در دو ارائه‌دهنده احراز هویت (Authentication Provider) غیرتعاملی که برای تکمیل فرآیند احراز هویت به تأیید کاربر نیاز ندارند، امتیاز 7.5 از 10 و شدت بالا دریافت کرده است. در ارائه‌دهنده احراز هویت تعاملی که تکمیل فرآیند ورود مستلزم آغاز و تأیید آن توسط کاربر است، این آسیب‌پذیری امتیاز 6.5 از 10 را به خود اختصاص داده است.
چگونه سرور مخرب اعتبارنامه‌ها را سرقت می‌کند؟
هنگامی که یک کلاینت MCP برای اتصال به یک سرویس به احراز هویت نیاز داشت، اطلاعات مربوط به سرور احراز هویت موردنظر را از سرور MCP متصل‌شده دریافت می‌کرد. در نسخه‌های آسیب‌پذیر، MCP Python SDK پاسخ دریافتی از سرور درباره مقصد احراز هویت را به‌درستی اعتبارسنجی نمی‌کرد. در نتیجه، یک سرور MCP مخرب می‌توانست کلاینت را به سمت سرویس احراز هویت تحت کنترل مهاجم هدایت کند. برای مثال، مهاجم می‌توانست سرویس خود را به‌عنوان مقصد احراز هویت معرفی کند یا اطلاعاتی ارائه دهد که در ظاهر مربوط به سرویس واقعی کاربر بود، اما در عمل اعتبارنامه‌ها را به یک مقصد تحت کنترل مهاجم ارسال می‌کرد.
در این شرایط، کلاینت به‌جای ارسال اطلاعات احراز هویت به سرویس اصلی، کلید محرمانه کلاینت، کد مجوز و کلید اثبات PKCE را برای مهاجم ارسال می‌کرد. کلید اثبات PKCE یک مقدار یک‌بارمصرف است که برای جلوگیری از استفاده مجدد از کد مجوز سرقت‌شده طراحی شده است؛ بنابراین، افشای آن نیز می‌توانست سازوکار حفاظتی PKCE را بی‌اثر کند.
در روش احراز هویت تعاملی، کاربر همچنان باید فرآیند ورود به حساب را تأیید می‌کرد. بااین‌حال، طبق گزارش Cycode، صفحه‌ای که کاربر در آن ورود خود را تأیید می‌کرد، همان صفحه واقعی احراز هویت بود و از نظر ظاهری هیچ نشانه‌ای از حمله نداشت. در مقابل، دو روش احراز هویت ماشین‌به‌ماشین (Machine-to-Machine) به ورود یا تأیید کاربر نیاز نداشتند و فرآیند احراز هویت را بدون دخالت کاربر انجام می‌دادند.
کدام اپلیکیشن‌ها تحت تأثیر آسیب‌پذیری MCP Python SDK قرار می‌گیرند؟
یک اپلیکیشن زمانی تحت تأثیر این آسیب‌پذیری قرار می‌گیرد که از MCP Python SDK به‌عنوان کلاینت MCP مبتنی بر HTTP استفاده کند و احراز هویت OAuth را از طریق یکی از روش‌های OAuthClientProvider، ClientCredentialsOAuthProvider یا PrivateKeyJWTOAuthProvider انجام دهد. روش احراز هویت منسوخ‌شده RFC7523OAuthClientProvider در نسخه 1.x نیز مشمول این شرایط است. علاوه بر این، اپلیکیشن باید امکان اتصال به سروری را داشته باشد که کاملاً تحت کنترل آن نیست و در عین حال، اعتبارنامه‌های مربوط به یک سرویس احراز هویت واقعی را در اختیار داشته باشد.
در مقابل، سرورهای MCP ساخته‌شده با این SDK، کلاینت‌های لوکال مبتنی بر stdio و کلاینت‌هایی که توکن‌های خود را مستقیماً به درخواست‌ها اضافه می‌کنند، تحت تأثیر این آسیب‌پذیری نیستند.
شاخه | نسخه آسیب‌پذیر | نسخه پچ‌شده |
1.x | 1.9.1 تا 1.29.1 | 1.30.0 |
2.x | 2.0.0 تا 2.1.1 | 2.2.0 |
برای رفع آسیب‌پذیری چه باید کرد؟
کاربران MCP Python SDK باید در شاخه 1.x، نسخه خود را به 1.30.0 و در شاخه 2.x، به 2.2.0 ارتقا دهند. در نسخه‌های پچ‌شده، کلاینت پیش از دریافت اطلاعات سرویس احراز هویت، مقصد مورد انتظار را مشخص کرده و در صورت مغایرت مقصد اعلام‌شده با مقصد مورد انتظار، اطلاعات دریافتی را رد می‌کند.
بااین‌حال، برای دو روش احراز هویت ClientCredentialsOAuthProvider و PrivateKeyJWTOAuthProvider، ارتقا به نسخه پچ‌شده به‌تنهایی کافی نیست. در این دو روش، علاوه بر ارتقا، باید پارامتر issuer= نیز مشخص شود تا سرویس احراز هویت مرتبط با اعتبارنامه‌ها به‌طور صریح تعیین گردد. در غیر این صورت، مقصد احراز هویت همچنان بر اساس اطلاعاتی انتخاب می‌شود که سرور MCP ارائه می‌کند.
در نسخه 1.30.0، این موضوع با یک هشدار منسوخ‌شدن اطلاع‌رسانی می‌شود. بااین‌حال، پایتون این هشدار را به‌صورت پیش‌فرض نمایش نمی‌دهد و در نتیجه ممکن است کاربر متوجه آن نشود. همچنین، روش منسوخ‌شده RFC7523OAuthClientProvider از پارامتر issuer= پشتیبانی نمی‌کند؛ بنابراین کاربران این روش باید از یکی از دو روش احراز هویت دیگر استفاده کنند.
پس از ارتقا، اطلاعات ثبت‌شده مربوط به کلاینت‌های OAuth باید یک‌بار حذف شود؛ زیرا ثبت‌های قدیمی به سرویس احراز هویت مشخصی متصل نیستند و پس از ارتقا نیز این وضعیت حفظ می‌شود. همچنین، اگر کلاینتی پیش از این به یک سرور غیرقابل‌اعتماد متصل شده باشد، باید کلید محرمانه کلاینت تغییر داده شود و توکن‌های مربوط به آن نیز در سرویس احراز هویت لغو شوند.
در نسخه‌های قدیمی، راهکار جایگزینی برای رفع آسیب‌پذیری MCP Python SDK وجود ندارد و تنها راهکار کاهش ریسک، اتصال کلاینت به سرورهای MCP مورد اعتماد است.
جزئیات افشای آسیب‌پذیری
قابلیت بررسی issuer در نسخه‌های 1.30.0 و 2.2.0 در یادداشت‌های انتشار 7 سپتامبر معرفی شد، اما این تغییر در بخش «تغییرات در عملکرد» قرار گرفت و به‌عنوان راهکاری برای رفع آسیب‌پذیری معرفی نشد. اطلاعیه امنیتی این آسیب‌پذیری نیز در 28 سپتامبر منتشر شد؛ همان روزی که Cycode گزارش فنی خود را درباره آن منتشر کرد. در این اطلاعیه از هشت پژوهشگر که در شناسایی و گزارش آسیب‌پذیری نقش داشتند، از جمله Cycode، قدردانی شده است.
تا آن زمان، نه اطلاعیه امنیتی و نه گزارش Cycode هیچ موردی از سوءاستفاده از این آسیب‌پذیری را گزارش نکرده بودند و هیچ گزارش دیگری نیز از سوءاستفاده از آن در حملات منتشر نشده بود.
