دسترسی به کدهای محرمانه یک سازمان اکنون می‌تواند تنها با نوشتن یک متن ساده در بخش نظرات گیت‌هاب ممکن شود. اگر از اتوماسیون‌های جدید گیت‌هاب برای مدیریت پروژه‌ها استفاده می‌کنید، باید بدانید که مرز بین داده‌های عمومی و خصوصی در این سیستم‌ها فروپاشیده است. پژوهشگران Noma Security نام این آسیب‌پذیری را GitLost گذاشته‌اند؛ حفره‌ای امنیتی که به یک مهاجم غیر تاییدشده (unauthenticated) اجازه می‌دهد تا صرفاً با ارسال یک «ایشو» (Issue) طراحی‌شده در یک مخزن عمومی، به‌طور مخفیانه داده‌ها را از مخازن خصوصی سرقت کند. این نقص از یک شکست بحرانی در نحوه مدیریت ورودی‌های غیرقابل‌اعتماد توسط گردش‌های کاری عامل‌محور گیت‌هاب نشأت می‌گیرد.
درک گردش‌های کاری عامل‌محور گیت‌هاب (GitHub Agentic Workflows)
گیت‌هاب به‌تازگی قابلیت Agentic Workflows را معرفی کرد تا تیم‌ها بتوانند تعامل با مخازن کد را با استفاده از زبان طبیعی خودکار کنند. این گردش‌های کاری در فایل‌های Markdown (با پسوند .md) تعریف می‌شوند که سپس به فایل‌های پیکربندی YAML (با پسوند .yml) کامپایل می‌گردند. سیستم‌های مذکور توسط یک عامل هوش مصنوعی که توسط مدل‌هایی نظیر Claude یا GitHub Copilot پشتیبانی می‌شود، هدایت می‌شوند. این عامل به‌گونه‌ای طراحی شده است که ایشوها را بخواند، ابزارها را فراخوانی کند و بر اساس مجوزهای قابل پیکربندی، به‌صورت خودمختار پاسخ دهد.
ظهور هوش مصنوعی عامل‌محور (Agentic AI)، چشم‌انداز امنیتی را از «مرزهای سخت‌کد شده» به «مرزهای رفتاری» تغییر داده است. در حالی که نرم‌افزارهای سنتی بر لیست‌های کنترل دسترسی (ACL) سخت‌گیرانه تکیه دارند، عامل‌های AI از دستوراتی پیروی می‌کنند که در دل محتویاتی که پردازش می‌کنند، نهفته است. این وضعیت یک سطح حمله (Attack Surface) عظیم ایجاد می‌کند که در آن «پنجره بافت» (Context Window) مدل AI به یک سلاح تبدیل می‌شود.
بررسی کلی آسیب‌پذیری GitLost
آسیب‌پذیری GitLost یک نمونه کلاسیک و درسی از حمله تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) است. این اتفاق زمانی رخ می‌دهد که یک مهاجم، دستورات مخرب را درون محتوایی پنهان کند که توسط عامل AI خوانده می‌شود و باعث شود عامل به‌جای پیروی از دستورات مورد نظر کاربر یا اپراتور، از آن فرمان‌های پنهان پیروی کند. این تکنیک در واقع تکامل یافته‌ی روش‌های دور زدن حفاظ‌های امنیتی هوش مصنوعی از طریق تزریق پرامپت است که پیش‌تر شناسایی شده بودند.
طبق گزارش Noma Security، این آسیب‌پذیری ناشی از عدم حفظ یک مرز اعتماد سخت‌گیرانه بین دستورات سطح سیستم و داده‌های غیرقابل‌اعتماد کاربر است. پژوهشگران پیکربندی آسیب‌پذیر خاصی را شناسایی کردند که در آن گردش کار عامل‌محور به شرح زیر تنظیم شده بود:
- فعال شدن گردش کار در هنگام وقوع رویدادهای
issues.assigned. - خواندن عنوان (Title) و بدنه (Body) ایشو.
- ارسال یک کامنت در پاسخ با استفاده از ابزار
add-comment. - اجرا با دسترسی خواندن (Read Access) به سایر مخازن (هم عمومی و هم خصوصی) در همان سازمان.
مکانیزم دقیق حمله
اکسپلویت این آسیب‌پذیری از یک جریان دقیق پیروی می‌کند که به هیچ مهارت برنامه‌نویسی، دسترسی خاص یا اعتبارنامه‌ای (Credentials) نیاز ندارد:
۱. مهاجم یک ایشوی عمومی در مخزن سازمان هدف باز می‌کند و در آن یک درخواست پذیرفتنی و باورپذیر قرار می‌دهد. در تست‌های Noma، این درخواست شبیه به پیام یک نایب رئیس فروش (VP of Sales) پس از یک جلسه با مشتری بود تا مشکوک‌برانگیز نباشد.
۲. در بدنه ایشو، دستوراتی به زبان انگلیسی ساده پنهان شده است که به عامل AI فرمان می‌دهد تا فایل‌های خاصی را استخراج کند.
۳. به محض اینکه ایشو به عامل اختصاص یابد (Assigned شود)، عامل به‌جای اجرای گردش کار پیش‌فرض، دستورات پنهان را اجرا می‌کند.
۴. عامل داده‌ها را از مخازن خصوصی می‌کشد و آن‌ها را به‌عنوان یک کامنت عمومی در همان ایشو پست می‌کند و بدین ترتیب داده‌ها برای هر کسی در اینترنت قابل دسترسی می‌شود.
در یک اثبات مفهوم (PoC) واقعی، داده‌های لو رفته شامل فایل‌های README.md از سه مخزن مختلف بود: مخازن sasinomalabs/poc (عمومی)، sasinomalabs/remote-ping (عمومی) و sasinomalabs/testlocal (خصوصی). این نوع نشت داده‌ها یادآور حملات گسترده‌تری در گیت‌هاب است که منجر به تعطیلی ده‌ها پروژه مایکروسافت برای مقابله با بدافزارهای سرقت اطلاعات شد.
دور زدن حفاظ‌های امنیتی (Guardrails)
گیت‌هاب حفاظ‌های محدودکننده‌ای را برای جلوگیری از این سناریو پیاده کرده بود، اما Noma دریافت که این اقدامات ناکافی هستند. از طریق آزمایش‌های مکرر و تغییرات مختلف، پژوهشگران کشف کردند که افزودن کلمه کلیدی «Additionally» (علاوه بر این) باعث ایجاد رفتاری ناخواسته در مدل می‌شود.
این کلمه کلیدی باعث شد مدل به‌جای رد کردن درخواست مخرب، خروجی خود را بازطراحی کند (Reframe). با فریب دادن مدل به این روش، پژوهشگران اطمینان حاصل کردند که حفاظ‌ها طبق برنامه عمل نمی‌کنند و موفق شدند فیلترهای ایمنی را برای تسهیل نشت داده‌ها دور بزنند.
چرا این موضوع برای امنیت AI حیاتی است؟
این آسیب‌پذیری یک تغییر بنیادی در ریسک‌های AI را برجسته می‌کند: تزریق پرامپت برای هوش مصنوعی عامل‌محور، دقیقاً همان نقشی دارد که تزریق SQL (SQL Injection) در سال‌های ابتدایی وب داشت. این یک نقص سیستماتیک و در سطح کل دسته است که در آن سیستم‌ها، محتوای کنترل‌شده توسط کاربر را به‌عنوان ورودی instructional (دستوری) مورد اعتماد تلقی می‌کنند. این ریسک‌ها زمانی بحرانی‌تر می‌شوند که ابزارهای AI دسترسی مستقیم به اجرای کد در سیستم داشته باشند، مشابه آنچه در تحلیل‌های مربوط به قابلیت‌های Claude Code مشاهده شد.
برای ایمن‌سازی این سیستم‌ها، آزمایشگاه Noma چندین استراتژی دفاعی را توصیه می‌کند:
- به حداقل رساندن مجوزها: محدوده دسترسی‌ها را به کمترین سطح ممکن کاهش دهید. عامل‌هایی که دسترسی بین‌مخزنی (Cross-repository) دارند، اهداف بسیار باارزشی هستند.
- محدود کردن خروجی‌های عمومی: آنچه یک عامل می‌تواند به‌صورت عمومی پست کند، به‌ویژه هنگام پاسخ به محتوای ایشوها، محدود شود.
- ایزولاسیون ورودی: پیش از ارسال ورودی کاربر به مدل، آن را پاکسازی کرده یا از بستر دستورات سیستمی جدا کنید.
- ورودی با اعتماد صفر: هرگز محتوای کنترل‌شده توسط کاربر را به‌عنوان منبع قابل اعتماد برای دستورات قبول نکنید.
در نهایت، GitLost به‌صورت مسئولانه به گیت‌هاب گزارش شد و جزئیات آن با اطلاع آن‌ها منتشر گردید.
گام بعدی شما
- اگر از Agentic Workflows در سازمان استفاده می‌کنید، دسترسی‌های Read به مخازن خصوصی را بازبینی و محدود کنید.
- از ابزارهای مانیتورینگ برای شناسایی الگوهای غیرعادی در کامنت‌های تولیدشده توسط AI استفاده کنید.
- مستندات به‌روزرسانی‌های امنیتی گیت‌هاب را برای دریافت وصله‌های مربوط به GitLost چک کنید.
اما این نشت داده‌ها تنها بخشی از یک مشکل بزرگتر است؛ تأثیر تزریق پرامپت بر مدل‌های استدلالی جدید را در گزارش بعدی بررسی خواهیم کرد.
گفتگو