عنوان:

‫نشت اطلاعات خصوصی از طریق بهره‌برداری از GitHub MCP: آسیب‌پذیری بحرانی در سیستم‌های عامل هوشمند


نویسنده: وحید نصیری
تاریخ: ۱۴۰۴/۰۳/۱۳ ۱۰:۵۱
آدرس: www.dntips.ir
گروه امنیتی Invariant اخیراً از کشف یک آسیب‌پذیری حیاتی در سرور رسمی GitHub MCP (پروتکل مدل-مشتری) پرده برداشت. این آسیب‌پذیری به مهاجمان اجازه می‌دهد تا با بهره‌برداری از عامل‌های هوشمند (Agents) کاربران، به مخازن (Repositories) خصوصی دسترسی یافته و اطلاعات آن‌ها را به سرقت ببرند. این رخنه‌ی امنیتی، که از جمله اولین موارد شناسایی شده توسط تحلیلگر امنیتی Invariant برای تشخیص "جریان‌های عامل سمی" (Toxic Agent Flows) است، زنگ خطر را برای استقرار گسترده عامل‌های کدنویسی و محیط‌های توسعه یکپارچه (IDEs) به صدا درآورده است.

تشریح آسیب‌پذیری
آسیب‌پذیری کشف شده در GitHub MCP، که دارای ۱۴ هزار ستاره در گیت‌هاب است، به مهاجم اجازه می‌دهد تا عامل یک کاربر را از طریق یک "مسئله" (Issue) مخرب در گیت‌هاب ربوده و آن را وادار به افشای داده‌ها از مخازن خصوصی کند. این سناریو، که Invariant آن را "جریان عامل سمی" می‌نامد، زمانی رخ می‌دهد که یک عامل برای انجام اقدامات ناخواسته، مانند نشت داده یا اجرای کد مخرب، دستکاری می‌شود.
در سناریوی حمله، کاربر از یک کلاینت (Client) MCP مانند Claude Desktop استفاده می‌کند که به سرور GitHub MCP و حساب کاربری او متصل است. فرض می‌شود کاربر دو مخزن دارد: یک مخزن عمومی که برای همه قابل دسترسی است و یک مخزن خصوصی که حاوی کد اختصاصی یا داده‌های محرمانه شرکت است. مهاجم می‌تواند یک "مسئله" مخرب در مخزن عمومی ایجاد کند که حاوی یک تزریق پرامپت (Prompt Injection) است و منتظر تعامل عامل با آن می‌ماند. حمله زمانی آغاز می‌شود که کاربر و صاحب حساب گیت‌هاب، یک درخواست ساده و بی‌خطر را به عامل خود ارسال می‌کند، مانند "نگاهی به مسائل باز در بینداز." این درخواست باعث می‌شود عامل مسائل را از مخزن عمومی واکشی کرده و به این ترتیب، تزریق شود.
پس از تزریق، عامل می‌تواند به زور وادار شود تا داده‌های مخزن خصوصی را به محیط کاری خود وارد کرده و سپس آن‌ها را در یک درخواست کشش (Pull Request) خودکار در مخزن عمومی که آزادانه برای مهاجم یا هر کس دیگری قابل دسترسی است، منتشر کند.

نمایش عملی حمله
برای اثبات این آسیب‌پذیری، Invariant از یک سناریوی عملی با مخازن نمایشی استفاده کرد: یک مخزن عمومی به نام ukend0464/pacman (یک پیاده‌سازی ساده از بازی Pacman) و چندین مخزن خصوصی حاوی پروژه‌های شخصی و اطلاعات حساس کاربر.
مهاجم یک "مسئله" مخرب با عنوان "'About The Author' injection" در مخزن عمومی قرار داد. این "مسئله" حاوی یک بایت‌کد (Payload) بود که بلافاصله پس از اینکه عامل لیست مسائل مخزن عمومی را پرس و جو می‌کرد، توسط عامل اجرا می‌شد. برای فعال‌سازی حمله، کاربر به سادگی Claude 4 Opus را با درخواست "Claude prompt used to trigger the attack" وادار به عمل کرد. Claude سپس از ادغام GitHub MCP برای دنبال کردن دستورالعمل‌ها استفاده کرد. اگرچه Claude Desktop به طور پیش‌فرض برای هر فراخوانی ابزار (Tool Call) تأیید کاربر را می‌خواهد، اما بسیاری از کاربران سیاست "همیشه اجازه بده" (Always Allow) را انتخاب می‌کنند و نظارت بر اقدامات فردی را متوقف می‌کنند.
در مرحله بعدی حمله، عامل لیست مسائل را مرور کرد تا بایت‌کد حمله را پیدا کند. سپس داوطلبانه داده‌های مخزن خصوصی را به محیط خود کشید و آن‌ها را در یک درخواست کشش (Pull Request) در مخزن pacman منتشر کرد که آزادانه برای مهاجم قابل دسترسی بود. این درخواست کشش شامل اطلاعات خصوصی متعددی از کاربر ukend0464 بود، از جمله اطلاعاتی درباره مخازن خصوصی‌شان مانند "Jupiter Star"، برنامه‌شان برای نقل مکان به آمریکای جنوبی و حتی حقوقشان.

تشخیص و کاهش جریان‌های عامل سمی
برخلاف حملات قبلی مسموم‌سازی ابزار (Tool Poisoning Attacks) با MCP، این آسیب‌پذیری نیازی به آسیب‌دیدگی خود ابزارهای MCP ندارد. در عوض، این مشکل حتی با ابزارهای کاملاً مورد اعتماد نیز بروز می‌کند، زیرا عامل‌ها می‌توانند در هنگام اتصال به پلتفرم‌های خارجی مانند گیت‌هاب، در معرض اطلاعات غیرقابل اعتماد قرار گیرند. درک، تجزیه و تحلیل و کاهش این مسائل در سیستم‌های عامل هوشمند، کاری بسیار پیچیده است که انجام آن به صورت دستی و در مقیاس بزرگ دشوار است. برای مقابله با این چالش، Invariant روش‌های خودکار برای تشخیص جریان‌های عامل سمی را توسعه داده است.
Invariant دو راهبرد اصلی برای کاهش این حملات و تقویت وضعیت امنیتی سیستم‌های عامل هوشمند توصیه می‌کند:

۱. اعمال قوانین جریان داده (Dataflow Rules) با کنترل‌های دسترسی دقیق:
هنگام استفاده از ادغام‌های MCP مانند گیت‌هاب، محدود کردن دسترسی عامل به تنها مخازنی که نیاز به تعامل با آن‌ها دارد، حیاتی است – این اصل از اصل "حداقل امتیاز" (Least Privilege) پیروی می‌کند. در حالی که مجوزهای مبتنی بر توکن (Token-based Permissions) سنتی تا حدی محافظت می‌کنند، اغلب محدودیت‌های سختی را اعمال می‌کنند که عملکرد عامل را محدود می‌سازد. برای امنیت مؤثرتر بدون قربانی کردن قابلیت‌ها، Invariant پیاده‌سازی لایه‌های امنیتی زمان اجرا (Runtime Security Layers) پویا را توصیه می‌کند که به طور خاص برای سیستم‌های عامل هوشمند طراحی شده‌اند. راه‌حل‌هایی مانند Invariant Guardrails کنترل دسترسی حساس به متن (Context-aware Access Control) را فراهم می‌کنند که با گردش کار عامل سازگار است و در عین حال مرزهای امنیتی را اعمال می‌کند. به عنوان مثال، یک سیاست می‌تواند از نشت اطلاعات بین مخازن جلوگیری کند و عامل را به کار با تنها یک مخزن در هر جلسه محدود کند.

۲. نظارت مستمر امنیتی با بازرسی توسط اکسپلورر (Inspect with Explorer):
علاوه بر اقدامات پیشگیرانه، پیاده‌سازی راه‌حل‌های نظارتی قوی برای تشخیص و پاسخ به تهدیدات امنیتی بالقوه در زمان واقعی ضروری است. Invariant استقرار اسکنرهای امنیتی تخصصی مانند MCP-scan از Invariant را برای ممیزی مستمر تعاملات بین عامل‌ها و سیستم‌های MCP توصیه می‌کند. حالت پراکسی (Proxy Mode) که اخیراً در MCP-scan معرفی شده، این فرآیند را با فعال کردن اسکن امنیتی بلادرنگ اتصالات MCP بدون نیاز به تغییر در زیرساخت عامل موجود، به میزان قابل توجهی ساده می‌کند. پیاده‌سازی نظارت جامع همچنین یک مسیر حسابرسی (Audit Trail) ایجاد می‌کند که به شناسایی آسیب‌پذیری‌های بالقوه، تشخیص تلاش‌های بهره‌برداری و اطمینان از محافظت سیستم‌های عامل شما در برابر حملات نوظهور کمک می‌کند.

چرا هم‌ترازی مدل کافی نیست؟
همانطور که یافته‌های Invariant نشان می‌دهد، حتی مدل‌های هم‌تراز (Aligned Models) پیشرفته نیز در برابر این حملات آسیب‌پذیر هستند. در آزمایش‌ها از Claude 4 Opus، یک مدل هوش مصنوعی بسیار جدید، هم‌تراز و ایمن استفاده شد. با این حال، عامل با وجود آموزش ایمنی قوی، همچنان از طریق تزریق‌های پرامپت نسبتاً ساده در برابر دستکاری آسیب‌پذیر بود. به همین ترتیب، بسیاری از دفاع‌های آشکارساز تزریق پرامپت آماده نیز قادر به تشخیص این حمله نیستند.
این آسیب‌پذیری همچنان پابرجاست زیرا امنیت سیستم‌های عامل اساساً وابسته به متن و محیط است. در حالی که آموزش هم‌ترازی مدل عمومی، برخی حفاظ‌ها را ایجاد می‌کند، نمی‌تواند الزامات امنیتی خاص هر سناریوی استقرار یا زمینه سازمانی را پیش‌بینی کند. اقدامات امنیتی باید در سطح سیستم پیاده‌سازی شوند و مکمل محافظت‌های سطح مدل باشند.

نتیجه‌گیری
این آسیب‌پذیری، اگرچه خاص GitHub MCP است، اما حملات مشابهی در سایر تنظیمات نیز در حال ظهور هستند، مانند آسیب‌پذیری گزارش شده در GitLab Duo. حفاظت از سیستم‌های عامل و ادغام‌های MCP با استفاده از اسکنرهای امنیتی اختصاصی مانند MCP-scan و Guardrails از Invariant برای اطمینان از استقرار مسئولانه در مقیاس بزرگ، حیاتی است.


مشاهده مطلب اصلی