شکست ۷۵ درصدی سرورهای رسمی MCP در آزمون‌های نفوذ رفتاری

اگر امروز از سرورهای مرجع MCP برای اتصال عامل‌های هوش مصنوعی خود به پایگاه‌داده‌ها استفاده می‌کنید، احتمالاً درهای پشتی سیستم خود را برای مهاجمان باز گذاشته‌اید. طبق تحلیل فنی منتشر شده در ۱۰ سپتامبر ۲۰۲۶، ۷۵ درصد از سرورهای مرجع پروتکل زمینه مدل (Model Context Protocol - MCP) در برابر اعتبارسنجی‌های خصمانه شکست خوردند. این ممیزی ثابت می‌کند که اسکنرهای استاتیک، که بر تطبیق الگوها (Pattern-matching) متکی هستند، قادر به شناسایی آسیب‌پذیری‌های رفتاری نیستند؛ آسیب‌پذیری‌هایی که تنها در زمان اجرای واقعی (Runtime) ظاهر می‌شوند.

این شکست در حالی رخ می‌دهد که عامل‌ها (Agents) به‌طور فزاینده‌ای برای تعامل با فایل‌های محلی و دیتابیس‌ها به MCP متکی شده‌اند. برای توسعه‌دهندگان، این یک ریسک سیستمیک است؛ زیرا دقیقاً همان پیاده‌سازی‌های مرجعی که در آموزش‌های رسمی توصیه شده‌اند، حفره‌های امنیتی را به ابزارهای عامل تزریق می‌کنند. تفاوت این وضعیت با امنیت ادعایی، شبیه تفاوت میان دری است که در ظاهر قفل است (تحلیل استاتیک) و دری که با یک فشار ساده باز می‌شود (اجرای خصمانه). این چالش با شکست عامل‌های کدنویس در آزمون‌های سخت‌افزاری همسو است که نشان می‌دهد حتی پیشرفته‌ترین ابزارها در مواجهه با محیط‌های خصمانه لغزش می‌کنند.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به کدهای مرجع می‌تواند کل زنجیره امنیت را متلاشی کند.

متدولوژی اعتبارسنجی

به نقل از گزارش وب‌سایت dev.to، فرآیند اعتبارسنجی از مجموعه‌ای از عملیات‌های تصادفی و جابه‌جا شده با بذرهای (Seeds) مختلف برای تست «ناورداهای رفتاری» استفاده کرده است. این ناورداها گزاره‌های عینی، ابطال‌پذیر و پیش‌ثبت‌شده‌ای هستند که برای هر مهارت تعریف شده‌اند؛ مثلاً «سرور باید درخواست‌های محدوده خصوصی را رد کند» یا «پرس‌وجوی خواندن فقط باید دستور SELECT را اجرا کند».

برای اطمینان از اینکه نتایج پوچ یا توخالی نیستند، یک «دروازه ضد-پوچی» (anti-vacuity gate) تعبیه شده بود. این مکانیزم باعث می‌شد که اگر هیچ عملیاتی در واقعیت اجرا نمی‌شد، کل مجموعه تست شکست بخورد. در این مدل، هر مورد خصمانه باید به یک حکم مشاهده‌شده (Observed Verdict) منجر می‌شد، سرور باید در طول فرآیند زنده می‌ماند و موارد صادقانه (Honest cases) باید با موفقیت اجرا می‌شدند. هر یافته سپس از یک مرحله «رد-اول» (debunk-first) می‌گذشت تا مشخص شود آیا مشکل یک ویژگی واقعی از آن مهارت است یا صرفاً باگی در ابزار تست (Harness) است. در اولین مرحله اعتبارسنجی (#01)، چهار پرچم خطا به عنوان باگ ابزار شناسایی، اصلاح و پیش از انتشار نهایی دوباره اجرا شدند.

خروجی نهایی یک «مانیفست اعتماد» (Trust Manifest) در قالب JSON است که امضا شده است. این مانیفست هویت مهارت را به یک هش کد (Code Hash) متصل کرده و شامل ناورداها به همراه تعداد عملیات‌ها، هش ابزار تست، یافته‌ها و یک امضای دیجیتال Ed25519 است. به دلیل اینکه محموله شامل حداقل‌های اجرایی است، امکان صدور مانیفست برای قابلیتی که هرگز اجرا نشده، وجود ندارد.

جزئیات شکست‌ها

در حالی که سرور رسمی سیستم فایل (که ۲۲۸ عملیات، شامل ۱۷۴ حمله را پشت سر گذاشت) تمام پنج ناورداهای رفتاری را پاس کرد، سه سرور حیاتی دیگر شکست خوردند:

• mcp-server-fetch (v0.6.3): این سرور به دلیل آسیب‌پذیری جعل درخواست سمت سرور (Server-Side Request Forgery - SSRF) شکست خورد. در تست‌هایی با ۶۳ عملیات در ۳ بذر مختلف، سرور یک ریدایرکت ۳۰۲ محلی را از یک ریدایرکتور در 127.0.0.1:8899 به loopback دنبال کرد که توسط یک شنودکننده کاناری (Canary listener) ثبت شد. اگرچه این سرور به فایل robots.txt و محدودیت‌های طرح (Scheme confinement) برای file:// احترام می‌گذاشت، اما فاقد محافظ SSRF بود. همچنین این سرور نتوانست IP متادیتای محلی-لینک 169.254.169.254 را رد کند، هرچند محیط شبکه باعث شد این IP از نظر TCP غیرقابل دسترس باشد.

• @modelcontextprotocol/server-postgres (v0.6.2): این سرور که با عنوان «اجرای پرس‌وجوی SQL فقط-خواندنی» تبلیغ شده بود، در ۹۶ عملیات و ۳ بذر شکست خورد. سرور دستور BEGIN TRANSACTION READ ONLY را باز می‌کند اما SQL ارسالی کاربر را عیناً به client.query(sql) می‌فرستد. از آنجایی که node-postgres برای رشته‌های چند-دستوری از پروتکل پرس‌وجوی ساده استفاده می‌کند، مهاجمان می‌توانستند از دستورات انباشته (Stacked Statements) استفاده کنند؛ مثلاً دستور SELECT 1; COMMIT; INSERT INTO items(name) VALUES('escape6b') را ارسال کنند تا تراکنش فقط-خواندنی را پایان داده و از طریق autocommit داده‌ها را در دیتابیس ثبت کنند.

• mcp-server-sqlite (v0.6.2): این سرور در ۸۱ عملیات و ۳ بذر، به عنوان یک ابزار نوشتن فایل بدون محدودیت عمل کرد. ابزار write-query تنها پرس‌وجوهایی را رد می‌کرد که با SELECT شروع می‌شدند. این نقص اجازه می‌داد دستوراتی مانند DROP TABLE ،ALTER TABLE و PRAGMA journal_mode=DELETE با موفقیت اجرا شوند. بحرانی‌ترین مورد، دستور VACUUM INTO '/tmp/...' بود که فایل‌هایی را روی دیسک ایجاد می‌کرد و به هر عاملی که دسترسی write-query داشت اجازه می‌داد یک کپی کامل از دیتابیس را در هر مسیری که پردازش سرور به آن دسترسی داشت، بنویسد.

اصلاح خودکار و شفافیت

بازرس در گزارش خود به لحظه حیاتی از «اصلاح خودکار» در طول فرآیند اشاره کرد. در طول اعتبارسنجی دوم (#02)، مجموعه تست به درستی شکست‌ها را پیدا کرد، اما درایور حکم نهایی را تنها بر اساس تخلفات هر عملیات محاسبه کرد و وضعیت کلی ناوردا را نادیده گرفت. چون هیچ تخلف تک-عملیاتی وجود نداشت، مانیفست برای یکی از موارد شکست، در ابتدا با وضعیت «pass_with_notes» صادر شد، در حالی که ناوردا در وضعیت not_held (عدم رعایت) بود.

تیم بازرسی این مورد را در مرحله بازبینی شناسایی کرد، درایور را اصلاح نمود تا قانون مجموعه (Corpus rule) مطلق شود (هر ناوردای not_held برابر است با FAIL) و سپس مجموعه ۶۳ عملیاتی را دوباره روی همان کامیتِ پین‌شده‌ی سرور اجرا کرد. پس از آن، مانیفست به عنوان FAIL صادر شد. این باگ، اصلاحیه و امضای جایگزین شده، همگی در فایل RESULTS.md مخزن مستند شده‌اند.

این شفافیت، استدلالی قدرتمند علیه اتکای فعلی صنعت به اسکنرهای استاتیک است. گزارش استدلال می‌کند شرکتی که حاضر است حکم خود را علناً به «شکست» تغییر دهد، بسیار قابل‌اعتمادتر از فروشنده‌ای است که صرفاً بر اساس الگوهای کد، یک نمره باینری «پاک» (Clean) ارائه می‌دهد. این رویکرد یادآور تجربه Traceguard 1.6.0 است که در آن تست‌های سبز (Pass) نتوانستند حفره‌های امنیتی بحرانی را شناسایی کنند.

برای جامعه فنی، این اتفاق معیار ایمنی ابزارهای هوش مصنوعی را از «بازبینی کد» به «اثبات رفتاری» تغییر می‌دهد. این نشان می‌دهد مرز اعتماد بین یک مدل زبانی بزرگ (LLM) و یک پایگاه‌داده، اگر پیاده‌سازی سرور قابلیت‌های ادعایی را در سطح اجرا به طور سخت‌گیرانه اعمال نکند، صرفاً یک توهم است. این موضوع شباهت زیادی به شکست‌های خاموش در تله‌متری AI دارد، جایی که تست‌های خودکار در شناسایی نقص‌های امنیتی ناتوان بودند.

اگر در حال استقرار مهارت‌های عامل در محیط عملیاتی (Production) هستید، نتیجه روشن است: به برچسب امنیتی یک پیاده‌سازی مرجع اعتماد نکنید. شما باید ابزار تست خصمانه (Adversarial harness) خود را اجرا کنید تا تأیید کنید قابلیت‌های واقعی ابزار با مرزهای ادعایی آن مطابقت دارد.

توسعه‌دهندگان اکنون می‌توانند مخزن عمومی github.com/roblambert9/skillproof-verifications را کلون کنند تا مجموعه تست‌ها را دوباره اجرا نمایند، فایل setup-and-run.sh را اجرا کنند و امضاهای Ed25519 مانیفست‌های اعتماد را شخصاً تأیید کنند.

گام بعدی شما

• اگر از MCP استفاده می‌کنید، هرگز به برچسب امنیتی پیاده‌سازی‌های مرجع اعتماد نکنید.
• برای هر ابزاری که به عامل خود می‌دهید، یک محیط ایزوله (Sandbox) ایجاد کنید تا دسترسی‌های فایل و شبکه محدود شود.
• مخزن عمومی github.com/roblambert9/skillproof-verifications را کلون کرده و تست‌های رفتاری را روی سرورهای خود اجرا کنید.

اما تأمین امنیت در لایه سخت‌افزاری حتی پیچیده‌تر است؛ برای درک چگونگی ایزوله‌سازی در سطح تراشه، تحلیل ما درباره محیط‌های TEE را بخوانید.