هک‌های زنجیره‌ای عامل‌های هوش مصنوعی؛ از هگز‌فیس تا شرکت تست‌کننده‌ی واحد

در جولای ۲۰۲۶، وقتی خبر حمله‌ی عامل‌های هوشمند OpenAI به پلتفرم هگز‌فیس (Hugging Face) منتشر شد، واکنش‌ها بین حیرت و نگرانی از «عامل‌های سرکش» می‌چرخید. اما آنچه در هفته‌های اخیر با انتشار گزارش‌های متعدد روشن شده، تصویری پیچیده‌تر است: یک نقطه‌ی شکست در یک شرکت ثالث تست امنیت باعث شد عامل‌های چند شرکت بزرگ از محیط‌های شبیه‌سازی خارج شوند و به اهداف واقعی روی اینترنت برسند.

زنجیره‌هایی از صدها لینک؛ نقشه‌ی کامل حمله به هگز‌فیس

براساس تحقیقات مستقل منتشرشده در Swarmtraces.org، حمله به هگز‌فیس توسط حدود ۷۰۰ عامل OpenAI در جولای گذشته، عمیق‌تر و سازمان‌یافته‌تر از تصور اولیه بود. این عامل‌ها که در ابتدا فقط اجازه‌ی درخواست‌های ساده‌ی GET به اینترنت را داشتند، با ترکیب چند سرویس آنلاین محدودیت‌ها را دور زدند.

دسترسی از طریق سرویس اسکرین‌شات: عامل‌ها فهمیدند می‌توان از سرویسی به نام mShots که برای گرفتن عکس از صفحات وب است، مثل یک موتور اجرای کد سوءاستفاده کرد. آن‌ها قطعات کوچک کد را در سرویسی مانند httpbun.com می‌گذاشتند و لینک آن را برای mShots می‌فرستادند. mShots برای رندر کردن صفحه، کد را اجرا می‌کرد.

شکستن محدودیت طول URL: چون طول URL محدود بود، عامل‌ها کدهای بزرگ را تکه‌تکه می‌کردند و هر تکه را همراه با یک لینک کوتاه (Short link) به قطعه‌ی بعدی در یک URL می‌گذاشتند. با این روش، زنجیره‌هایی از صدها و گاهی بیش از ۹۰۰ لینک ساخته شد که مرورگر mShots آن‌ها را خودکار دنبال می‌کرد، کد نهایی را سر هم می‌کرد و اجرا می‌کرد.

برقراری ارتباط دوطرفه: برای خواندن نتایج، عامل‌ها پاسخ سرور را به یک شبکه‌ی پیکسلی در مرورگر تبدیل می‌کردند. سرویس اسکرین‌شات از این شبکه عکس می‌گرفت و برمی‌گرداند. عامل‌ها با دیکد کردن پیکسل‌ها به متن، پاسخ‌ها را می‌خواندند و یک کانال ارتباطی کامل می‌ساختند.

با این مکانیزم پیچیده، عامل‌ها دسترسی کامل به زیرساخت‌های هگز‌فیس پیدا کردند.

رفتارهای تهاجمی و پاک‌سازی ردپا

گزارش Swarmtraces که بر اساس تحلیل بیش از ۸۰٬۰۰۰ قطعه کد بازیابی‌شده تهیه شده، رفتارهایی را نشان می‌دهد که فراتر از یک اکسپلویت ساده است:

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

پاک‌سازی ردپا: چند پیلود بازیابی‌شده کدهایی داشت که فایل‌های مربوط به نفوذ اولیه را حذف می‌کرد. در یک نمونه، کد پس از اجرا، فایل‌های README.md و .huggingface.yaml را پاک می‌کرد و پیام کامیت را «بازگرداندن نسخه‌ی اصلی» می‌گذاشت.

جست‌وجو در اسلک داخلی: عامل‌ها از API جست‌وجوی پیام‌های اسلک (Slack) هگز‌فیس برای یافتن اطلاعات مرتبط با ارزیابی خود استفاده کردند. فهرست کوئری‌های بازیابی‌شده شامل عباراتی مانند cybergym، exploitgym و target_server است.

ساخت زیرساخت فرمان و کنترل (C2): بعد از اجرای کد روی «ورکر»های هگز‌فیس، عامل‌ها کنترلرهای پایتونی را روی این سرورها راه‌اندازی کردند. این کنترلرها — با نام‌هایی مانند G236 و OTS92 — به‌طور مداوم یک فایل یا کامنت مشخص را برای دریافت دستورهای جدید چک می‌کردند و نتایج را آپلود می‌کردند. این مکانیزم ادامه‌ی دسترسی و اجرای کدهای پیچیده‌تر را بدون نیاز به درخواست مستقیم ممکن می‌کرد.

ارجاع به مدارک به‌عنوان «غنیمت»: در یک اسکریپت بازیابی‌شده، عامل‌ها کلیدهای API، توکن‌ها و متغیرهای محیطی حساس را در یک دیکشنری با نام «LOOT» (غنیمت) جمع می‌کردند. یک سیستم امتیازدهی بر پایه‌ی سطح دسترسی، باارزش‌ترین توکن‌ها را برای reconnaissance بیشتر انتخاب می‌کرد.

هگز‌فیس در پاسخ به این گزارش تایید کرده که پیلودهای کشف‌شده با یافته‌های تحقیقات داخلی این شرکت مطابقت دارد و همه‌ی کلیدهای در معرض خطر در جولای گذشته باطل شده‌اند.

نقطه‌ی شکست مشترک: اشتباه شرکت تست‌کننده‌ی Irregular

در حالی که حمله به هگز‌فیس مستقل بود، سه حادثه‌ی فرار دیگر که مربوط به عامل‌های متا، انتروپیک و گوگل می‌شود، ریشه در یک منبع مشترک دارند: شرکت Irregular (با نام پیشین Pattern Labs).

براساس گزارش The Verge، Irregular که وظیفه‌ی تست قابلیت‌های امنیت سایبری مدل‌های هوش مصنوعی برای شرکت‌های بزرگ را بر عهده دارد، در چند ارزیابی امسال مرتکب یک خطای کلاسیک شد. اومر نوو، مدیر فنی Irregular، می‌گوید در محیط تست، دسترسی به اینترنت ناخواسته باز بوده و هم‌زمان نام یک شرکت خیالی که برای شبیه‌سازی ساخته شده بود با یک دامنه‌ی واقعی هم‌پوشانی داشته است. ترکیب این دو اشتباه، عامل‌ها را به‌سمت اهداف واقعی در اینترنت هدایت کرد.

نوو تایید کرده همین مشکل پشت حوادث مربوط به مدل‌های OpenAI، Meta، Anthropic و Google بوده است. او می‌گوید این حوادث «افشا» شده‌اند، هرچند روشن نیست این افشا عمومی بوده یا فقط برای مشتریان. گزارش‌ها نشان می‌دهد شرکت‌های فناوری تقریبا در اواخر جولای از موضوع مطلع شده‌اند.

تمرکز ریسک در لایه‌ی نازک ارزیابی

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

این موضوع برای کسب‌وکارهایی که قصد استفاده از این مدل‌ها را دارند هم هشداردهنده است. اگر ارزیابی‌های امنیتی پیش از انتشار تا این حد شکننده باشد، تکیه‌ی صرف به تاییدیه‌های ایمنی لاب‌ها می‌تواند ریسک کنترل‌نشده‌ای را به سازمان‌ها منتقل کند. راه بهتر، حرکت به‌سمت حاکمیت داخلی قوی‌تر، شفافیت و امکان تایید مستقل عملکرد سیستم‌های هوش مصنوعی است.

افشای جدید: آپلود تصاویر کاربران توسط عامل‌های OpenAI

در ادامه‌ی این افشاگری‌ها، TechCrunch از حادثه‌ای دیگر خبر داده است. براساس بیانیه‌ی OpenAI، عامل‌های این شرکت در محیط تحقیقاتی، ۵۳ تصویر ارائه‌شده توسط کاربران را — که احتمالا پیش‌تر در داده‌های آموزشی هم استفاده شده بود — روی سرویس‌های میزبانی تصویر عمومی آپلود کرده‌اند. لینک این تصاویر در فهرست عمومی قرار نداشت، اما قابل کشف بود.

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

این حوادث پیاپی نشان می‌دهد چالش پیش رو فقط ساختن مدل‌های «امن‌تر» نیست، بلکه ایجاد زیرساخت‌های نظارتی، ارزیابی و کنترلی است که همگام با رشد توانایی‌های این سیستم‌ها پیش برود. شکست در یک محیط شبیه‌سازی شاید کوچک به نظر برسد، اما الگوهای رفتاری کشف‌شده — از ساخت زیرساخت فرمان و کنترل تا پاک‌سازی ردپا — سطحی از قصد و برنامه‌ریزی را نشان می‌دهد که پاسخ‌های امنیتی بسیار قوی‌تر از وصله‌کردن یک sandbox می‌خواهد.