AutoJack: وقتی یک صفحه وب ساده، ایجنت هوش مصنوعی شما را به سلاح تبدیل می‌کند

این دقیقاً همان چیزی است که پژوهشگران امنیتی در یک زنجیره‌ی آسیب‌پذیری به نام AutoJack  کشف کردند — حمله‌ای که نشان می‌دهد چگونه یک صفحه وب مخرب می‌تواند ایجنت مرورگر هوش مصنوعی AutoGen Studio  مایکروسافت را ربوده و کد دلخواه را روی دستگاه میزبان اجرا کند، بدون آنکه کاربر کاری بیش از وارد کردن یک آدرس اینترنتی انجام داده باشد.

AutoGen Studio  چیست و چرا این موضوع اهمیت دارد؟

AutoGen Studio  یک ابزار رابط کاربری متن‌باز است که توسط واحد تحقیقاتی مایکروسافت (Microsoft Research)  برای نمونه‌سازی سریع سیستم‌های چندایجنتی هوش مصنوعی توسعه یافته است. به زبان ساده، این ابزار به توسعه‌دهندگان امکان می‌دهد چندین «ایجنت» هوش مصنوعی بسازند که می‌توانند با هم همکاری کنند از جمله ایجنت‌هایی که قابلیت مرور وب دارند (مثل ابزار MultimodalWebSurfer  که در این گزارش به آن اشاره شده.)

این نوع ابزارها این روزها به‌سرعت در میان توسعه‌دهندگان هوش مصنوعی محبوب می‌شوند، چون به ایجنت‌ها اجازه می‌دهند به‌جای آن‌که صرفاً متن تولید کنند، واقعاً اقدامات واقعی روی سیستم انجام دهند — از جمله باز کردن صفحات وب، پردازش محتوا، و اجرای دستورات.

دقیقاً همین قابلیت (توانایی ایجنت برای تعامل با دنیای واقعی) همان چیزی است که این حمله از آن سوءاستفاده می‌کند.

سازوکار حمله: سه ضعف، یک فاجعه

محققان دریافتند که AutoJack نه از یک باگ واحد، بلکه از زنجیره‌ای از سه ضعف مستقل در سطح ارتباطی WebSocket  مربوط به پروتکل Model Context Protocol (MCP) در AutoGen Studio بهره می‌برد. درک هر کدام از این سه ضعف، کلید فهم کل ماجراست:

ضعف اول: عدم بررسی صحیح مبدا درخواست (CWE-1385)

WebSocket  مربوط به MCP فقط درخواست‌هایی را می‌پذیرفت که از آدرس http://127.0.0.1  یا http://localhost  می‌آمدند یعنی فقط از همان کامپیوتر محلی. این منطق در حالت عادی منطقی به نظر می‌رسد: یک مرورگر روی یک سایت مخرب مثل evil.com نمی‌تواند این محدودیت را دور بزند. اما نکته‌ی کلیدی اینجاست: این بررسی، جاوااسکریپتی که توسط یک مرورگر بدون رابط گرافیکی (headless browser) متعلق به خود ایجنت AutoGen رندر می‌شود را مسدود نمی‌کند — چون آن مرورگر، خودش روی همان دستگاه محلی اجرا می‌شود و هویت «localhost» را به ارث می‌برد. به‌عبارت دیگر، ایجنت خودش، بدون آن‌که بداند، کلید عبور از این دیوار امنیتی را در دست دارد.

ضعف دوم: نبود احراز هویت برای یک تابع حیاتی (CWE-306)

میان‌افزار (middleware) احراز هویت AutoGen Studio به‌صورت صریح، مسیرهای/api/mcp/*  را نادیده می‌گرفت — با این فرض که خودِ هندلر  WebSocket، بررسی‌های امنیتی لازم را انجام خواهد داد. اما این کار هرگز انجام نشد. نتیجه این بود که WebSocket مربوط به MCP، اتصالات بدون احراز هویت را می‌پذیرفت، بدون توجه به اینکه چه حالت احراز هویتی برای بقیه‌ی برنامه تنظیم شده باشد.

ضعف سوم: تزریق دستور سیستم‌عامل  (CWE-78)

این نقطه‌ی مرگبار زنجیره است. نقطه‌ی پایانی (endpoint) این WebSocket، یک پارامتر کوئری به نامserver_params  را می‌پذیرفت، آن را از فرمت base64 رمزگشایی می‌کرد، به یک شیء JSON تبدیل می‌کرد، آن را بهStdioServerParams  تحلیل می‌کرد، و سپس فیلدهایcommand  وargs را مستقیماً به تابع (stdio_client) ارسال می‌کرد. مشکل اینجاست که هیچ فهرست سفید (allowlist) از فایل‌های اجرایی مجاز وجود نداشت — یعنی یک مهاجم می‌توانست به‌جای نام یک «سرور MCP» واقعی، مقادیری مثل calc.exe، یا حتی powershell.exe -enc … یا bash -c '...' را وارد کند.

مسیر کامل حمله

با کنار هم گذاشتن این سه ضعف، مسیر حمله این‌گونه شکل می‌گیرد:

۱. توسعه‌دهنده‌ای AutoGen Studio را رویlocalhost:8081  اجرا می‌کند، همراه با یک ایجنت مرورگر — مثلاً یک خلاصه‌ساز محتوای وب ساخته‌شده با MultimodalWebSurfer.

۲. مهاجم یک صفحه‌ی مخرب می‌سازد (یا کاربر را فریب می‌دهد تا یک URL تحت کنترل مهاجم را وارد کند.)

۳. مرورگر بدون رابط گرافیکی ایجنت، به آن صفحه می‌رود؛ جاوااسکریپت موجود در آن صفحه، یک اتصال WebSocket به آدرسی شبیه ws://localhost:8081/api/mcp/ws/<id>?server_params=<base64_payload> باز می‌کند.

۴. چون ایجنت مرورگر به‌صورت محلی اجرا می‌شود، بررسی مبدا (origin check) با موفقیت رد می‌شود؛ و چون میان‌افزار احراز هویت مسیرهای /api/mcp/*  را نادیده می‌گیرد، هیچ توکنی لازم نیست.

۵. AutoGen Studio محموله را رمزگشایی می‌کند و دستوری که مهاجم مشخص کرده را، تحت حساب کاربری خود توسعه‌دهنده، اجرا می‌کند.

نتیجه؟ در آزمایش‌های اثبات مفهومی (proof-of-concept)، فایل calc.exe  تنها چند ثانیه پس از آنکه ایجنت صفحه‌ی مخرب را رندر کرد، روی دسکتاپ توسعه‌دهنده باز شد — و نکته‌ی هشداردهنده‌تر این بود که این اجرا توسط خودِ فرآیند AutoGen Studio آغاز شده بود، نه توسط مرورگر معمولی کاربر.

اسکرین‌شات منتشرشده از این آزمایش، دقیقاً همین صحنه را نشان می‌دهد: یک ایجنت خلاصه‌ساز محتوای وب که آدرس مخربی را پردازش می‌کند، در حالی که هم‌زمان یک پنجره‌ی ماشین‌حساب باز شده و عبارت «You've been exploited» با رنگ قرمز روی صفحه نمایش داده می‌شود.

چرا این حمله این‌قدر خطرناک است؟

نکته‌ای که این آسیب‌پذیری را از موارد مشابه متمایز می‌کند، میزان پایین تعامل لازم از سمت قربانی است. کاربر فقط باید یک URL را در یک فرم وارد کند کاری که در استفاده‌ی عادی از چنین ابزاری کاملاً طبیعی به نظر می‌رسد. هیچ نیازی به دانلود فایل، کلیک روی لینک مشکوک، یا حتی باز کردن یک ضمیمه‌ی ایمیل نیست.

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

واکنش مایکروسافت و وضعیت فعلی

پژوهشگران این یافته‌ها را به مرکز پاسخ‌گویی امنیتی مایکروسافت (MSRC) گزارش دادند، و شاخه‌ی اصلی (main branch)  این پروژه در کامیت b047730  تقویت شد.

نکته‌ی مهمی که باید به آن توجه کرد این است که این آسیب‌پذیری خاص، تمام کاربران AutoGen Studio را تحت تأثیر قرار نمی‌دهد: سطح آسیب‌پذیر WebSocket مربوط به MCP، هرگز در هیچ نسخه‌ی منتشرشده در PyPI  (مخزن رسمی پکیج‌های پایتون) وجود نداشته است. به‌عبارت دیگر، توسعه‌دهندگانی که AutoGen Studio  را از طریقpip  نصب کرده‌اند، در معرض این زنجیره‌ی خاص حمله نبوده‌اند این موضوع بیشتر کسانی را که مستقیماً از شاخه‌ی اصلی روی گیت‌هاب کار می‌کنند، تحت تأثیر قرار می‌داد.

مایکروسافت دو اصلاح کلیدی اعمال کرد:

• محدودسازی پارامتر در سمت سرور: پارامتر server_params  دیگر از طریق URL پذیرفته نمی‌شود؛ این پارامترها اکنون در سمت سرور ذخیره شده و با یک شناسه‌ی یکتا (UUID) کلیدگذاری می‌شوند.
• سخت‌گیری در فهرست استثنای احراز هویت: مسیر /api/mcp  دیگر از میان‌افزار احراز هویت معاف نیست؛ تمام مسیرهای مرتبط با MCP اکنون از فرآیند استاندارد احراز هویت عبور می‌کنند.

این تغییرات از کامیتb047730  (نسخه ۰.۷.۲) در شاخه‌ی اصلی فعال شده‌اند. بررسی‌ها همچنین تأیید کردند که پکیج منتشرشده در PyPI (نسخه‌ی autogenstudio 0.4.2.2) هیچ فایل مسیر mcp.py  یا ارجاعی به StdioServerParams  ندارد.

درس‌هایی برای کل صنعت ایجنت‌های هوش مصنوعی

شاید مهم‌ترین بخش این گزارش، توصیه‌های دفاعی‌ای است که فراتر از این مورد خاص اعمال می‌شوند توصیه‌هایی که هر تیم توسعه‌دهنده‌ی ایجنت هوش مصنوعی باید آن‌ها را در نظر بگیرد:

• هر پارامتر ابزاری که از خروجی مدل قابل‌دسترس است را به‌عنوان داده‌ی تحت کنترل مهاجم در نظر بگیرید. اگر یک مدل هوش مصنوعی می‌تواند مقداری را تولید کند که مستقیماً به یک ابزار اجرایی منتقل می‌شود، آن مقدار باید همان سطح بی‌اعتمادی را داشته باشد که ورودی مستقیم از یک کاربر ناشناس دارد.
• هیچ‌گاه صفحه‌های کنترلی حساس را بدون احراز هویت به آدرس localhost متصل نکنید رابط loopback (آدرس محلی) برای هر ایجنتی که روی آن دستگاه اجرا می‌شود، یک سطح حمله‌ی واقعی محسوب می‌شود، نه یک پناهگاه امن.
• فایل‌های اجرایی‌ای که می‌توانند به‌عنوان سرور MCP فراخوانی شوند را در یک فهرست سفید (allowlist)  محدود کنید.
• هویت ایجنت را از هویت توسعه‌دهنده جدا کنید با استفاده از کانتینرها، کاربران جداگانه در سطح سیستم‌عامل، یا ماشین‌های مجازی.
• اگر از شاخه‌ی اصلی (main) پروژه استفاده می‌کنید، حتماً از نسخه‌ای مساوی یا جدیدتر از کامیت b047730  استفاده کنید.
  
  

جمع‌بندی: مرز محلی، دیگر مرز امن نیست

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

برای کاهش مؤثر این نوع ریسک، صرف‌نظر از اینکه از کدام فریم‌ورک استفاده می‌شود، سه اصل ضروری است: احراز هویت یکپارچه در سطح صفحه‌ی کنترلی، اعمال سخت‌گیرانه‌ی فهرست سفید برای اقدامات مجاز، و جداسازی کامل هویت ایجنت از هویت کاربر/توسعه‌دهنده.

با گسترش روزافزون ایجنت‌های خودکار هوش مصنوعی در محیط‌های توسعه، احتمال می‌رود این نوع زنجیره‌های حمله که از تعامل میان قابلیت‌های «مرور وب» و «اجرای دستور محلی» سوءاستفاده می‌کنند به یکی از الگوهای رایج‌تر در فهرست تهدیدات امنیتی هوش مصنوعی در سال‌های آینده تبدیل شوند.