تحقیقات از حمله «آتش خودی» پرده برداشت: عوامل کدنویسی برتر هوش مصنوعی را می‌توان فریب داد تا کدهای مخرب را اجرا کنند

صنعت نرم‌افزار به طور فزاینده‌ای خسته‌کننده‌ترین کارهای امنیتی خود را به هوش مصنوعی واگذار می‌کند. توسعه‌دهندگان به طور معمول از عوامل کدنویسی خودکار می‌خواهند که کتابخانه‌های متن‌باز تازه دانلود شده را اسکن کنند تا قبل از ادغام کد در محیط عملیاتی، آسیب‌پذیری‌های پنهان را بیابند. اما تحقیقات جدید یک نقطه کور حیاتی را در این جریان کاری دفاعی آشکار می‌کند: ابزارهایی که برای شناسایی کدهای مخرب استخدام شده‌اند، خود می‌توانند فریب داده شوند تا همان کدها را اجرا کنند. یک حمله اثبات مفهوم با عنوان «آتش خودی» (Friendly Fire) نشان می‌دهد که وقتی از یک دستیار هوش مصنوعی خواسته می‌شود تا یک مخزن تله‌گذاری شده را بررسی کند، می‌توان آن را دستکاری کرد تا بار مخرب مهاجم را مستقیماً روی دستگاه توسعه‌دهنده اجرا کند.[1][2]

این آسیب‌پذیری که توسط محققان امنیتی بویان میلانوف و هایدی خلاف از مؤسسه AI Now افشا شده است، دستیاران کدنویسی سطح بالا، به ویژه Claude Code از Anthropic و Codex از OpenAI را هدف قرار می‌دهد. این حمله به بهره‌برداری‌های پیچیده نرم‌افزاری یا امتیازات سیستمی بالا متکی نیست. در عوض، از روش اساسی پردازش اطلاعات توسط مدل‌های زبان بزرگ سوءاستفاده می‌کند. محققان دریافتند که وقتی این عوامل در پیکربندی‌های رایج «حالت خودکار» (auto-mode) یا «بررسی خودکار» (auto-review) خود عمل می‌کنند – که به هوش مصنوعی اجازه می‌دهد دستورات خود را برای کاهش اصطکاک کاربر تأیید کند – در برابر تزریق‌های پرامپت که در دیدرس پنهان شده‌اند، آسیب‌پذیر می‌شوند.[1][3]

مکانیک حمله «آتش خودی» به طرز فریبنده‌ای ساده است. مهاجمان نیازی به به خطر انداختن منطق اصلی یک کتابخانه نرم‌افزاری محبوب ندارند؛ آنها فقط باید مستندات آن را تغییر داده و چند فایل مبدل اضافه کنند. در نمایش خود، محققان یک کپی از «geopy»، یک کتابخانه پرکاربرد کدگذاری جغرافیایی پایتون، را اصلاح کردند. آنها یک فایل README با ظاهر معمولی وارد کردند که به طور غیررسمی به کاربران دستور می‌داد تا یک اسکریپت به نام «security.sh» را به عنوان یک بررسی استاندارد قبل از نهایی کردن هرگونه تغییر کد اجرا کنند.[2][4]

هنگامی که یک توسعه‌دهنده به عامل هوش مصنوعی خود دستور می‌دهد تا «تست امنیتی» را روی مخزن دانلود شده انجام دهد، عامل با وظیفه‌شناسی مستندات را می‌خواند. هوش مصنوعی با برخورد به دستورالعمل موجود در README، فرض می‌کند که اسکریپت امنیتی بخشی مشروع از مجموعه تست بومی مخزن است. عامل اسکریپت را اجرا می‌کند، که به آرامی یک فایل باینری مخرب و پنهان را راه‌اندازی می‌کند. از آنجایی که عامل در حالت خودکار در حال اجرا است، اعلان تأیید انسان را دور می‌زند و در حالی که توسعه‌دهنده تصور می‌کند یک اسکن معمولی در حال انجام است، دستگاه میزبان را بی‌صدا به خطر می‌اندازد.[1][2]

برای اطمینان از اینکه طبقه‌بندی‌کننده‌های ایمنی داخلی هوش مصنوعی فایل باینری پنهان را مشکوک علامت‌گذاری نمی‌کنند، محققان از یک پوشش هوشمندانه استفاده کردند. آنها یک فایل فریبنده بی‌ضرر – که با زبان برنامه‌نویسی Go نوشته شده بود – را درست در کنار فایل باینری مخرب قرار دادند. آنها سپس فایل باینری را با ثابت‌های رشته‌ای که مستقیماً از فایل فریبنده برداشته شده بودند، پر کردند. هنگامی که طبقه‌بندی‌کننده ایمنی عامل هوش مصنوعی فایل باینری را بازرسی می‌کند، رشته‌ها مطابقت داده می‌شوند، نتیجه می‌گیرد که فایل باینری صرفاً نسخه کامپایل شده کد Go بی‌ضرر است و اجرای آن را تأیید می‌کند.[1][2]

این فریب یک ضعف ساختاری را در معماری‌های فعلی هوش مصنوعی مولد برجسته می‌کند: ناتوانی در جداسازی مطمئن دستورالعمل‌های مورد اعتماد از داده‌های نامعتبر. همانطور که الجان محمدلی، رئیس بخش منشأ هوش مصنوعی در Polygraf AI، اشاره کرد، یک مدل زبان هر چیزی را در پنجره متنی خود به عنوان یک جریان واحد از توکن‌ها پردازش می‌کند. دستور اولیه اپراتور برای «بررسی این کد» و دستور پنهان مخزن شخص ثالث برای «اجرای این اسکریپت» با همان اعتبار وارد می‌شوند. هنگامی که دستور مخرب وارد پنجره متنی می‌شود، عامل مکانیسم قابل اعتمادی برای تشخیص خصمانه بودن آن ندارد.[4]

اتکا به طبقه‌بندی‌کننده‌های هوش مصنوعی برای کنترل مرزهای ایمنی به طور فزاینده‌ای ناکافی است. توسعه‌دهندگان ابزار، حالت‌های خودکار را به عنوان یک راه میانی بین اجرای کاملاً نامحدود و اصطکاک خسته‌کننده درخواست از کاربر برای هر اقدام معرفی کردند. Anthropic قبلاً اشاره کرده بود که حالت خودکار Claude Code شاهد تأیید ۹۳ درصد از درخواست‌های مجوز توسط کاربران است، که طبقه‌بندی‌کننده را به یک راحتی خوشایند تبدیل می‌کند. با این حال، تحقیق Friendly Fire ثابت می‌کند که این اکتشافات را می‌توان با تطبیق فایل‌های منبع واقعی با فایل‌های باینری مخرب جعل کرد و یک ویژگی راحتی را به یک آسیب‌پذیری حیاتی تبدیل نمود.[2]

پیامدهای این آسیب‌پذیری بسیار فراتر از ایستگاه‌های کاری توسعه‌دهندگان فردی است. توسعه نرم‌افزار مدرن به شدت به خطوط لوله یکپارچه‌سازی مداوم و استقرار مداوم (CI/CD) متکی است، که به طور خودکار به‌روزرسانی‌های کد را واکشی، آزمایش و مستقر می‌کنند. اگر تیم‌های مهندسی شروع به واگذاری اسکن خودکار آسیب‌پذیری به‌روزرسانی‌های بسته ورودی به عوامل هوش مصنوعی خودکار کنند، این تکنیک تزریق می‌تواند بی‌صدا در محیط‌های سازمانی فعال شود. یک به‌روزرسانی وابسته به خطر افتاده می‌تواند بار خود را بدون اینکه انسانی هرگز تغییر را بررسی کند، اجرا کند و به طور مؤثری یک حمله زنجیره تأمین را خودکار سازد.[2][3]

خوشبختانه، حمله Friendly Fire همچنان یک اثبات مفهوم آزمایشگاهی باقی مانده است. مؤسسه AI Now هیچ بهره‌برداری از این تکنیک خاص را در دنیای واقعی مشاهده نکرده است و کد تحقیقاتی عمومی بدون بار مخرب واقعی منتشر شد. این حمله همچنین در اولین اجرا متوقف می‌شود و محققان هیچ تلاشی برای نشان دادن افزایش امتیاز یا حرکت جانبی در شبکه نکردند. این افشاگری به عنوان یک هشدار پیشگیرانه عمل می‌کند تا یک واکنش فعال به حادثه، و به صنعت زمان می‌دهد تا شیوه‌های خود را تنظیم کند.[1][3]

کاهش این تهدید نیازمند تغییر در نحوه استقرار ابزارهای هوش مصنوعی توسط توسعه‌دهندگان است، نه انتظار برای یک وصله نرم‌افزاری. از آنجایی که آسیب‌پذیری در طراحی اساسی مدل‌های زبان ریشه دارد، هیچ به‌روزرسانی نسخه ساده‌ای وجود ندارد که خطر را از بین ببرد. مؤثرترین و فوری‌ترین دفاع، غیرفعال کردن حالت‌های اجرای خودکار هر زمان است که یک عامل هوش مصنوعی با کد نامعتبر شخص ثالث تعامل دارد. با مجبور کردن عامل به درخواست تأیید صریح انسانی قبل از اجرای هر فایل یا اسکریپت قابل اجرا، توسعه‌دهندگان می‌توانند قبل از انفجار بار، زنجیره حمله را بشکنند.[1][5]

کارشناسان امنیتی همچنین سازمان‌ها را ترغیب می‌کنند که محیط‌های زمان اجرای این عوامل را بازنگری کنند. کنترل پایدار باید در زیرساخت اطراف مدل قرار گیرد، نه در خود مدل. این بدان معناست که دستیاران کدنویسی هوش مصنوعی باید در فضاهای کاری یکبار مصرف یا محیط‌های ایزوله سخت‌گیرانه (sandboxes) اجرا شوند که دسترسی به اعتبارنامه‌های تولید، فایل‌های میزبان حساس یا خروج شبکه خارجی را ندارند. اگر عاملی فریب داده شود تا یک اسکریپت مخرب را اجرا کند، شعاع آسیب محدود به یک کانتینر موقت و ایزوله باقی می‌ماند که می‌توان آن را با خیال راحت از بین برد.[3][4]

افشای Friendly Fire در بحبوحه موج گسترده‌تری از تحقیقاتی رخ می‌دهد که مرزهای امنیتی شکننده هوش مصنوعی عاملیت‌محور را آشکار می‌کند. تنها چند روز قبل، محققان در Wiz، آسیب‌پذیری «GhostApproval» را افشا کردند که شش دستیار کدنویسی محبوب هوش مصنوعی را تحت تأثیر قرار می‌داد. آن حمله از پیوندهای نمادین (symbolic links) برای فریب عوامل استفاده می‌کرد تا فایل‌های سیستمی حساس را خارج از فضای کاری تعیین شده خود تغییر دهند. به طور مشابه، تکنیکی به نام «HalluSquatting» نشان داد که مهاجمان می‌توانند نام بسته‌های جعلی را که عوامل هوش مصنوعی احتمالاً توهم می‌زنند، پیش‌بینی کنند، آن نام‌ها را در مخازن عمومی ثبت کنند و منتظر بمانند تا عوامل به طور خودکار بدافزار را به نمایندگی از کاربر دانلود کنند.[5][6]

در مجموع، این یافته‌ها واقعیت دشواری را برای بازار ابزارهای هوش مصنوعی که به سرعت در حال گسترش است، تأکید می‌کنند. فشار برای اعطای استقلال بیشتر به عوامل هوش مصنوعی – که به آنها اجازه می‌دهد مخازن را کلون کنند، وابستگی‌ها را نصب کنند و دستورات راه‌اندازی را به طور مستقل اجرا کنند – همزمان سطح حمله را گسترش می‌دهد. هر فایلی که یک عامل می‌خواند و هر ابزاری که می‌تواند به آن دسترسی داشته باشد، یک بردار بالقوه برای دستکاری است. در حالی که دولت‌ها و شرکت‌ها برای پذیرش هوش مصنوعی برای کارهای دفاعی امنیت سایبری عجله دارند، این فرض که یک مدل توانمندتر ذاتاً ایمن‌تر است، به شدت در حال آزمایش است.[1][4]

با وجود این آسیب‌پذیری‌ها، محققان امنیتی خواستار پایان دفاع مبتنی بر هوش مصنوعی نیستند. توانایی مدل‌های زبان بزرگ برای تجزیه و تحلیل سریع پایگاه‌های کد عظیم، همچنان یک دارایی بسیار ارزشمند برای شناسایی آسیب‌پذیری‌های واقعی است. درس اصلی تحقیق Friendly Fire این نیست که هوش مصنوعی برای کار امنیتی نامناسب است، بلکه این است که هنگام مدیریت داده‌های خارجی باید با آن به عنوان یک جزء نامعتبر رفتار شود. مجوز اجرای کد باید از عاملی که کد را می‌خواند، جدا شود.[3][4]

در حالی که صنعت این یافته‌ها را هضم می‌کند، تمرکز به سمت ایجاد حفاظ‌های قوی و قابل تأیید در اطراف محیط‌های اجرای هوش مصنوعی در حال تغییر است. فروشندگان در حال بررسی راه‌هایی برای اتصال رمزنگاری تأییدیه‌های فراخوانی ابزار به هویت‌های تأیید شده کاربر هستند، تا اطمینان حاصل شود که یک عامل نمی‌تواند به طور یکجانبه اقدامات خود را بر اساس محتوای تزریق شده تأیید کند. تا زمانی که این تغییرات معماری به بلوغ برسند، توسعه‌دهندگان باید به یاد داشته باشند که دستیاران هوش مصنوعی آنها فقط تقویت‌کننده‌های بهره‌وری غیرفعال نیستند – آنها شرکت‌کنندگان فعال در چرخه عمر توسعه هستند و به همان مرزهای اعتماد سخت‌گیرانه‌ای نیاز دارند که هر پیمانکار انسانی دارد.[3][5]