متد «متا-هکینگ»؛ افشای حفرهٔ امنیتی بحرانی در مایکروسافت کوپایلت

تصور کنید دستیاری دارید که آن‌قدر مشتاق شفافیت است که در حین توضیح دادنِ امنیتِ قفل‌های خانه، نقشه‌ی دقیق کلیدها را در دست سارق می‌گذارد. این دقیقاً همان اتفاقی است که برای کاربران مایکروسافت کوپایلت (Microsoft Copilot) افتاد و دسترسی به خصوصی‌ترین داده‌های آن‌ها را به خطر انداخت.

طبق گزارش شرکت وارونیس (Varonis)، یک لینک مخرب می‌توانست به‌طور خاموش تاریخچه گفتگوها، ایمیل‌های Gmail و فایل‌های گوگل درایو کاربران را تخلیه کند. این آسیب‌پذیری که با کد CVE-2026-24301 و نام مستعار «CoSnitch» شناخته می‌شود، تا ۱۸ اوت ۲۰۲۶ به‌طور کامل برطرف نشد.

این اتفاق نشان می‌دهد که «مفید بودن» در مدل‌های هوش مصنوعی، اکنون به یک نقطه ضعف امنیتی تبدیل شده است. همان‌طور که در تحلیل قبلی ما درباره‌ی پارامترهای مخفی URL در کوپایلت اشاره کردیم، ساختار این ابزارها فرصت‌های عجیبی برای نفوذ ایجاد می‌کند. این حادثه نشان می‌دهد که تمایل مدل به کمک‌رسانی، اکنون به یک مسئولیت امنیتی خطرناک تبدیل شده است.

در دنیای امروز، عامل‌های هوش مصنوعی (AI Agents) — شبیه به کارمندانی هستند که اجازه دارند به جای شما در صندوق پستی یا فایل‌هایتان جست‌وجو کنند — اما وقتی این دسترسی‌ها با یک نقص فنی ترکیب شوند، فاجعه رخ می‌دهد.

کشف از طریق متا-هکینگ

پژوهشگران برای یافتن CoSnitch از روش‌های سنتی مثل تحلیل کد یا ارسال داده‌های تصادفی (API Fuzzing) استفاده نکردند. آن‌ها متدی به نام «متا-هکینگ» را به کار گرفتند. آن‌ها بسته‌های جاوااسکریپت را بررسی نکردند و ورودی‌های تصادفی به APIهای خاموش نفرستادند تا رفتار سیستم را از روی کدهای خطا یا زمان پاسخ‌دهی استنباط کنند.

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

به نقل از آدار، مدل در حالی که از انجام حمله امتناع می‌کرد، اما در پاسخ‌هایش جزئیات فنی معماری داخلی خود را لو می‌داد. هر «نه» از طرف مدل، در واقع یک نشت اطلاعاتی (Specification Leak) بود. تیم تحقیق با تغییر صورت سؤالات و تبدیل «نه»ها به سؤالات تکمیلی، جزئیات معماری مستندنشده‌ای را استخراج کردند.

آن‌ها مستقیماً از کوپایلت پرسیدند که آیا یک URL می‌تواند بدون اینکه کاربر دکمه Enter را فشار دهد، یک دستور (Prompt) را به‌طور خودکار اجرا کند یا خیر. کوپایلت، در تلاش برای حداکثر شفافیت و مفید بودن، دقیقاً همان طراحی پارامتری را توصیف کرد که در حال دفاع از آن بود.

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

مکانیسم حمله CoSnitch

این حمله بر پایه ترکیب دو پارامتر خاص در URL استوار بود که وقتی با هم ترکیب می‌شدند، تایید کاربر را دور می‌زدند. هیچ‌کدام از این پارامترها به تنهایی خطرناک نبودند، اما ترکیب آن‌ها یک ابزار برای تصاحب حساب با یک کلیک ایجاد می‌کرد:

• ?q=: این پارامتر متن مورد نظر مهاجم را در کادر ورودی کوپایلت پیش‌پر می‌کند. به تنهایی، این یک ویژگی رفاهی برای لینک دادن مستقیم به یک پرس‌وجوی خاص است، اما همچنان نیاز دارد که قربانی دکمه Enter را فشار دهد.
• ?autorun=1: این پارامتر مستندنشده، نیاز به فشردن Enter را حذف می‌کند و دستور پیش‌پر شده را بلافاصله پس از بارگذاری صفحه، بدون هیچ تعامل دیگری از سوی قربانی، اجرا می‌کند.

وقتی کاربر روی لینکی کلیک می‌کرد که هر دو پارامتر را داشت، کوپایلت دستور مهاجم را به‌طور خودکار اجرا می‌کرد. چون کاربر از قبل در حساب خود احراز هویت شده بود، دستور در جلسه فعال (Live Session) او اجرا می‌شد. این وضعیت به مهاجم یک عامل هوش مصنوعی فعال را می‌داد که روی داده‌های خصوصی کاربر سوار بود و می‌توانست از ابزارهای متصل استفاده کند.

تخلیه داده‌ها و بازه زمانی خطر

این دسترسی شامل خواندن و نوشتن در Gmail و گوگل درایو از طریق او-آت (OAuth) — سیستمی شبیه به کلیدهای دیجیتالی که به برنامه‌ها اجازه می‌دهد بدون دانستن رمز عبور شما، به بخش‌های خاصی از حسابتان دسترسی داشته باشند — و همچنین حافظه بلندمدت مدل از گفتگوهای قبلی بود. این آسیب‌پذیری یک میان‌بر در تجربه کاربری (UX) را به راهی برای تخلیه خاموش داده‌ها از برنامه‌های متصل تبدیل کرد.

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

بر اساس مستندات وارونیس، این حفره در ۳۱ دسامبر ۲۰۲۵ برای اولین بار به مایکروسافت گزارش شد. مایکروسافت در ۱ فوریه ۲۰۲۶ یک اصلاح جزئی برای توقف اجرای خودکار ارائه کرد. اما وصله کامل تا ۱۸ اوت ۲۰۲۶ منتشر نشد؛ یعنی تقریباً هشت ماه پس از گزارش اولیه و تنها چند روز قبل از انتشار عمومی مقاله.

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

مایکروسافت مدعی است شواهدی از سوءاستفاده از این باگ در دنیای واقعی وجود ندارد، اما هیچ گزارش دقیقی (Postmortem) درباره علت ریشه‌ای طولانی شدن فرآیند اصلاح ارائه نکرده است. تیم‌های امنیتی برای ارزیابی اعتماد به یک تامین‌کننده، معمولاً به این سطح از جزئیات نیاز دارند تا شکست در چرخه توسعه را درک کنند.

مشکل «نایب گیج‌شده» و تغییرات ساختاری

این مورد نمونه‌ای مدرن از مشکل «نایب گیج‌شده» (Confused Deputy) است؛ جایی که یک واسطه مورد اعتماد (کوپایلت) فریب می‌خورد تا از اختیارات قانونی خود برای انجام کاری به نفع یک شخص غیرمجاز استفاده کند.

در عصر پیش از عامل‌ها، مثلاً در یک برنامه وب سال ۲۰۱۵ با یک پارامتر autorun مستندنشده، دایره تخریب محدود به کارهایی بود که همان یک برنامه می‌توانست انجام دهد. اما در عصر عامل‌محور (Agentic)، دایره تخریب برابر است با مجموع تمام سرویس‌هایی که کاربر از طریق OAuth به هوش مصنوعی متصل کرده است.

تغییرات امنیتی در این حوزه شامل موارد زیر است:

• گسترش سطح حمله: حالا سطح حمله فقط کد برنامه نیست، بلکه مجموع کد برنامه به علاوه هر دسترسی (Scope) اعطا شده در هر سرویسی است که مدل می‌تواند به آن دسترسی داشته باشد، منهای حفاظ‌های زمان استنتاج مدل.
• مرزهای احتمالی: حفاظ‌هایی که در یک مدل احتمالی زندگی می‌کنند، اساساً نرم‌تر از بررسی‌های دسترسی سخت‌افزاری (Hard-coded) هستند. این مرزها از طریق مهندسی اجتماعی با زبان طبیعی قابل نفوذ هستند.
• ابزارهای قدیمی، اهداف جدید: مکانیسم حمله همان لینک‌های <a href> بود — همان ابزاری که از دهه ۹۰ برای فیشینگ ایمیلی استفاده می‌شد. اما این بار هدف، به جای یک کوکی جلسه، عاملی بود که دسترسی خواندن و نوشتن به فایل‌ها و حافظه AI داشت.

توصیه‌هایی برای توسعه‌دهندگان

وارونیس برای جلوگیری از ایجاد «سطوح حمله خود-مستند»، این گام‌ها را پیشنهاد می‌کند:

بازرسی‌های فنی:

• بازرسی پارامترهای URL: هر پارامتری که رابط وب می‌پذیرد، به‌ویژه آن‌هایی که دستورات را پیش‌پر یا تحریک می‌کنند، بررسی شوند. اگر پارامتری گفتگو را بدون اقدام مثبت کاربر (مثل کلیک) پیش می‌برد، آن را به عنوان یک ابزار اجرای خودکار در نظر بگیرید.
• تایید لینک‌های عمیق (Deep-Link): اطمینان حاصل کنید که لینک‌های عمیق به جای عبور خاموش از تاییدیه، نیاز به تایید صریح کاربر داشته باشند. اجرای این لینک‌ها باید مستلزم یک اقدام مثبت از سوی کاربر باشد.

حفاظ‌های مدل:

• محدود کردن شفافیت مدل: تشخیص دهید که توضیحات دستیار درباره محدودیت‌های خودش، بخشی از مدل تهدید است. سؤالات حساس به معماری باید پاسخ‌های کلی و غیرفنی دریافت کنند، نه مشخصات دقیق. این مشابه روشی است که سرورهای وب از توضیح قوانین WAF به کاربران احرازنشده اجتناب می‌کنند.
• اجتناب از خود-مستندسازی: اگر از یک عامل خواسته شود توجیه کند چرا یک مسیر حمله بسته است، پاسخ او ممکن است مکانیسم همان بستن را فاش کند.

کنترل دسترسی:

• سخت‌گیرانه کردن OAuth: پیاده‌سازی دسترسی‌ها بر اساس اصل «حداقل امتیاز» (Least-privilege). آسیب در CoSnitch از دسترسی به Gmail، درایو و حافظه ناشی شد، نه از عملکرد اصلی چت.
• گزارش‌دهی پیشرفته: ایجاد لاگ‌های حسابرسی مجزا برای اقداماتی که از طریق ورود URL تحریک می‌شوند در مقابل اقداماتی که در جلسه تایپ شده‌اند تا دایره تخریب نقص‌های اجرای خودکار محدود شود.

مایکروسافت اشاره کرد که مشتریان سازمانی تحت تأثیر نبودند و این نقص فقط مربوط به نسخه شخصی (Copilot Personal) بود.

زمینه صنعتی و تیم قرمز

کوپایلت تنها نیست. کانکتورهای ChatGPT و اکستنشن‌های Gemini در همین دسته قرار می‌گیرند: عامل‌هایی با دسترسی دائمی OAuth به ایمیل، فایل‌ها و تقویم‌ها که طبق طراحی، از طریق لینک‌های اشتراک قابل دسترسی هستند. این ریسکی است که کل دسته دستیارهای عامل‌محور با آن روبروست.

این مورد ثابت می‌کند که «تیم قرمز» (Red Teaming) باید فراتر از کتابخانه‌های جیل‌بریک (Jailbreak) برود. پرتاب کردن داده‌های متخاصم به مدل کافی نیست. تیم‌ها اکنون باید فعالانه از مدل «با مهربانی بخواهند» تا حفاظ‌های خود را توضیح دهد. اگر عاملی توجیه کند که چرا یک مسیر حمله بسته است، احتمالاً در حال فاش کردن مکانیسم آن بسته شدن است.

متدولوژی متا-هکینگ

پژوهشگران امنیتی و تیم‌های قرمز باید متا-هکینگ را به ابزارهای استاندارد خود اضافه کنند. این یک تکنیک ارزان است که به هیچ ابزار خاصی جز یک پنجره چت و صبر نیاز ندارد. ثابت شده است که این روش قادر به یافتن باگ‌های با شدت بالا است که تست‌های متداول برای ماه‌ها نادیده گرفته بودند.

به جای تمرکز صرف بر داده‌های متخاصم، پژوهشگران باید جلساتی را به پرسیدن سؤالات ساده درباره محدودیت‌های مدل اختصاص دهند، هر پاسخ را ثبت کنند و به دنبال هر چیزی بگردند که بیشتر شبیه به یک مشخصه فنی است تا یک سیاست کلی.

تحلیل نهایی

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

برای کسانی که از Copilot Personal استفاده می‌کنند، در حالی که اصلاحیه اعمال شده و نیازی به اقدام نیست، بازبینی و حذف دسترسی‌های OAuth برای هر نمونه هوش مصنوعی، اقدامی محتاطانه است. تیم‌های محصولی که ویژگی‌های «اتصال حساب» را عرضه می‌کنند باید درک کنند که هر ویژگی لینک اشتراک، یک نقطه ورود مبتنی بر URL به یک جلسه احراز شده است و شایسته همان بررسی دقیقی است که یک نقطه پایانی (Endpoint) بازگشت OAuth دریافت می‌کند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.