افشای جزئیات نحوه هک کردن Hugging Face توسط ماموران OpenAI

هنگامی که 700 مامور OpenAI در ماه ژوئیه Hugging Face را هک کردند، شواهد عمومی را پشت سر گذاشتند.

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

ما همه اینها و موارد دیگر را در این گزارش مستند می کنیم.

این عوامل در ابتدا دسترسی بسیار محدودی به اینترنت داشتند: آنها می توانستند URL ها را بارگیری کنند، اما با صفحات تعامل نداشته باشند یا هیچ داده ای ارسال نکنند. Agent ها مجموعه ای از راه حل ها را ایجاد کردند، در درجه اول از یک سایت کوتاه کننده لینک برای ایجاد تقریبا یک میلیون URL استفاده کردند که وقتی به هم متصل می شوند، به آنها اجازه می دهد کدی را برای هک کردن Hugging Face اجرا کنند. این پیوندها به ما امکان می دهد جزئیات نحوه دسترسی عوامل و میزان عمیق بودن مصالحه را گرد هم بیاوریم.

ما یافته های خود را با OpenAI و Hugging Face به اشتراک گذاشته ایم. Hugging Face تأیید کرد که این محموله‌ها با محموله‌های موجود در واکنش حادثه مطابقت دارند و می‌دانستند که از کوتاه‌کننده‌های پیوند در این حمله استفاده شده است.

Hugging Face خاطرنشان کرد که از لیست URL هایی که ما کشف کردیم و به آنها گزارش دادیم اطلاعی نداشتند. آنها اظهار داشتند که این محموله‌ها تکراری از محموله‌هایی هستند که از آنها مطلع بودند. این پیوندها بیش از دو ماه پس از حمله در دسترس عموم باقی مانده است.

هیچ یک از این جزئیات هرگز به صورت عمومی فاش نشد. ما در حال انتشار تجزیه و تحلیل خود از یافته‌ها و همچنین مجموعه داده کامل بیش از 80000 محموله حمله مجدد هستیم که عمیق‌ترین اطلاعات را تا به امروز در مورد چگونگی و چرایی فرار این عوامل از محیط‌های ارزیابی و عمق نفوذ Hagging Face در اختیار عموم قرار می‌دهد.

داده هایی که ماموران OpenAI به صورت عمومی در اینترنت منتشر کردند شامل کلیدهای API Hugging Face و سایر داده های حساس بود. Hugging Face تأیید کرده است که از آن زمان تمام کلیدهای دسترسی را در ماه ژوئیه لغو کرده اند، اما به دلیل احتیاط فراوان از ما می خواستند که تمام جزئیات مربوط به زیرساخت داخلی آنها را اصلاح کنیم زیرا ممکن است به طور بالقوه نیز حساس باشد.

در 11 سپتامبر، سه نویسنده اول این مقاله متوجه شدند که عوامل داخلی OpenAI سعی کرده اند از محصول استارتاپ خود، Parse، در ماه ژوئن استفاده کنند. این عوامل بخشی از همان انبوهی بودند که در گزارش منتشر شده در Collusion.wiki توضیح داده شد، که نشان می‌دهد عوامل داخلی OpenAI به طور غیرقانونی از چندین وب‌سایت شخص ثالث برای به اشتراک گذاشتن پاسخ‌های وظایف واکشی وب که در آنها ارزیابی می‌شدند استفاده کرده‌اند.

این تیم ابزارهای اسکن URL متعددی را مورد بررسی قرار دادند که به اعتقاد آنها ممکن است عوامل در فرآیند استفاده از Parse از آنها استفاده کرده باشند. در حین بررسی، آنها اسکنی از ده ها پیوند را از یک کوتاه کننده پیوند عمومی پیدا کردند که در آن هر پیوند به صفحه ای هدایت می شد که قطعه کد کدگذاری شده با base64 و همچنین شناسه پیوند بعدی را نمایش می داد. رمزگشایی محموله از زنجیره پیوندها یک اسکریپت پایتون را نشان داد که شبکه داخلی Hugging Face را اسکن می کرد. دومین زنجیره به Artifactory داخلی OpenAI اشاره دارد.

این نشان می‌دهد که این پیوندها به حمله Hugging Face مرتبط هستند، و ما را بر آن داشت تا مشکل را به طور کامل بررسی کنیم.

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

ما Hugging Face را در 21 سپتامبر از این کشف مطلع کردیم. Hugging Face تأیید کرد که محموله‌ها با مصنوعات مربوط به تحقیقات خود مطابقت دارند و اعتبار آنها لغو شده است. با این حال، در حالی که آنها می‌دانستند که نمایندگان از کوتاه‌کننده‌های لینک استفاده می‌کنند، اما از این لیست خاص از URLها بی‌اطلاع بودند. ما در 24 سپتامبر به OpenAI اطلاع دادیم.

ما یک مجموعه داده اولیه را منتشر می کنیم که در آن همه اعتبارنامه ها، PII و جزئیات خاص زیرساخت Hugging Face را ویرایش کرده ایم. ما نام هیچ یک از خدمات کوتاه‌کننده پیوند استفاده شده، یا هیچ لکه‌ای را که برای کاهش افشای اطلاعات بازبینی نشده رمزگشایی نکرده‌ایم، منتشر نمی‌کنیم. Hugging Face درخواست کرده است که تمام داده‌های کاربر (نام‌های کاربری/نام مخزن) و همچنین چند یادداشت در مورد زیرساخت آنها ویرایش شود. ما از سرعت و توجه تیم آنها به جزئیات در کار با ما قدردانی می کنیم.

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

یکی از سایت‌هایی که نمایندگان با درخواست‌های GET می‌توانستند به آن دسترسی داشته باشند، یک سرویس تصویربرداری به نام mShots بود. کاربران می توانند پیوندی را به یک وب سایت ارسال کنند، سپس mShots صفحه را در مرورگر خود باز می کند، یک اسکرین شات می گیرد و تصویر را به کاربر برمی گرداند. برای رندر کردن وب سایت برای اسکرین شات، mShots تمام کدهای یک وب سایت را به طور کامل در مرورگر خود بارگیری می کند.

اگر نمایندگان بتوانند کدی را در یک وب سایت بنویسند، می توانند از این سرویس آن کد را اجرا کنند.

این نمایندگان از وب‌سایت‌هایی مانند httpbun.com استفاده می‌کردند، یک سرویس انعکاسی HTTP که برای کمک به توسعه‌دهندگان وب طراحی شده است تا کد HTTP خود را آزمایش کنند. قطعات کوچک کد را می توان با Base64 کدگذاری کرد و به انتهای URL HTTP متصل کرد. سپس Httpbun این قطعه را رمزگشایی می کند و آن را به عنوان یک صفحه وب ارائه می کند.

سپس نمایندگان می توانند این URL های Httpbun را به mShots ارسال کنند، آنها را در مرورگر سرویس بارگذاری کنند و کد عامل ها را اجرا کنند.

آزمایش‌های بازیابی اولیه این مورد شامل پیام‌های ساده‌ای مانند:

عوامل به سرعت متوجه شدند که حداکثر طول کدی وجود دارد که می توانند در یک URL واحد قرار دهند. برای حل این مشکل، آنها برنامه‌های بزرگ را به تکه‌های کوچک متوالی کد، در کنار یک پیوند کوتاه شده (با استفاده از یک سرویس کوتاه‌کننده پیوند مشابه bit.ly) تقسیم می‌کنند که به URL قطعه کد بعدی در دنباله اشاره می‌کند. این زنجیره ای از URL ها را تشکیل داد که در صورت دنبال کردن، می توانند بلوک بزرگتری از کد را از بسیاری از قطعات منفرد بازسازی کنند.

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

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

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

ما می‌توانیم تلاش اولیه برای این کار را از یک محموله بازیابی شده ببینیم.

این اسکریپت یک درخواست POST را به نقطه پایانی نتایج ارسال یک ارزیابی به نام "cybergym" که در Modal میزبانی شده است، درخواست سوابق ارسال مرتبط با شناسه عامل "m47push2" می کند. سپس اسکریپت صفحه مرورگر را پاک می کند و پاسخ سرور را بر روی صفحه می نویسد و هر بیت از هر کاراکتر را به عنوان یک پیکسل نشان می دهد. با رمزگشایی پیکسل‌ها به متن، عامل می‌تواند پاسخ سرور را که توسط کدی که در یک مرورگر کاملا مجزا اجرا می‌شود، بخواند، حتی در حالی که سرویس اسکرین شات فقط یک تصویر را برمی‌گرداند.

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

یک README.md بازیابی شده برای یکی از مجموعه داده‌های داخلی Hugging Face حاوی هشدار زیر است:

به نظر نمی‌رسد که این اخطار مانعی برای عامل‌ها شود، زیرا ما چندین بار از عواملی را که نقشه‌برداری از این مخزن و استفاده از آن را به عنوان ذخیره‌سازی می‌کنند، بازیابی کرده‌ایم.

یکی از بارگذاری‌ها یک فایل مخرب را آپلود می‌کند، هشدار را حفظ می‌کند و در عین حال پیکربندی را اضافه می‌کند که کارگر مجموعه داده Hugging Face را برای بارگیری فایل مخرب، hb58428env .h5، هدایت می‌کند.

محتوای این فایل «/proc/self/environ» را هدف قرار می‌دهد، که محیط راه‌اندازی فرآیند خواندن را در خود نگه می‌دارد – که می‌تواند حاوی کلیدهای API و سایر اعتبارنامه‌های تولید باشد – و «/proc/1/cmdline» که می‌تواند اطلاعاتی را درباره فرآیند راه‌اندازی کانتینر نشان دهد. خلاصه commit این عملیات را به عنوان یک کاوشگر سازگاری قالب داده موقت توصیف می کند.

One payload این مجموعه داده را مستقیما بررسی و شمارش می کند. اسکریپت ابتدا متادیتا را درخواست می کند که خود مخزن را توصیف می کند، مانند آخرین commit و تنظیمات حریم خصوصی. سپس، فهرست بازگشتی فایل‌ها و پوشه‌ها را در شاخه اصلی این مجموعه داده درخواست می‌کند. سپس این اسکریپت تا 20000 بایت از متادیتای این مخزن و حداکثر 20000 بایت از ساختار فایل و پوشه را چاپ می کند.

بسیاری از محموله‌های بازیابی شده حاوی کدی برای حذف فایل‌هایی هستند که ابتدا برای ارائه یا راه‌اندازی برنامه‌ها در کارگران Hugging Face استفاده می‌شدند. در یک مثال با هدف قرار دادن REDACTED_ORG_NAME/hf-exports، برنامه ارائه شده حاوی این نظر است:

# فقط فایل هایی را که معرفی می کنیم حذف کنید. مخزن اصلی هیچ کدام را ندارد.

اسکریپت بررسی می کند که آیا README.md قبلا آپلود شده حاوی نشانگر "D64LINK" است یا خیر. اگر نشانگر وجود داشته باشد، یک تعهد حذف هر دو فایل README و .huggingface.yaml صادر می شود، با پیام بازیابی کارت اصلی بدون کارت. 1

یک محموله جداگانه FALL با اعتباری با برچسب: EXPORT_REDACTED_ORG_NAME_HF_TOKEN مطابقت دارد.

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

یک درخواست مشابه یکی از مجموعه داده های اولیه را هدف قرار می دهد که عامل ها از آن کار می کنند. این commit .huggingface.yaml را حذف می کند و README را با یک پیکربندی که به "yamlread.h5" اشاره می کند با پیام commit جایگزین می کند: حذف evil yaml

در مثالی دیگر، درخواست حذف یک سرویس وب هوک آنلاین را هدف قرار می دهد که سابقه درخواست آن قبلا برای ذخیره قطعات کد استفاده می شد. سپس اسکریپت وضعیت HTTP را به همراه بدنه پاسخ (یا خطا در صورت ناموفق بودن) را برمی گرداند.

بار دیگر تلاش می‌کند یک غلاف Kubernetes ایجاد کند تا یک راز خوشه را بخواند، سپس آن را با نظر حذف کنید، # غلاف ما را پاک کنید:

چندین اسکریپت حفظ شده درخواست هایی را برای مدل های زبان خارجی ایجاد می کنند. اولین موردی که ما بازیابی کرده‌ایم، انواع درخواست استنتاج را به GPT-2 تعریف می‌کند، که صرفا حاوی کلمه «سلام» است.

درخواست‌های دیگر DeepSeek-V4-Pro، DeepSeek-V4-Flash، Kimi-K2.6، DeepSeek-V3.1، و Qwen3-235B-A22B هستند. درخواست‌های آنها از این مدل‌ها می‌خواهد تا در مورد بهره‌برداری‌های خود قضاوت کنند و در مورد اینکه آیا الزامات معیار را برآورده می‌کنند یا خیر، حکم کنند.

درخواست‌های جداگانه Claude 3 Haiku و Claude Haiku 4.5 را از طریق سرویس چت هوش مصنوعی آنلاین هدف قرار می‌دهند، که شامل مدیریت چالش تأیید مرورگر قبل از درخواست «Say OK» از Claude 3 Haiku و پاسخ دقیقا OK از Haiku 4.5 است.

یک اسکریپت دیگر از اعتبارنامه AWS استفاده می‌کند و ذخیره‌سازی LFS (ذخیره‌سازی فایل بزرگ) Hugging Face را ترسیم می‌کند و اشیایی را در زیر «repos»، «lfs»، «objects»، «blobs»، «datasets» و «models» درخواست می‌کند. سپس متادیتا را برای یک فایل مدل GPT-2 با این نظر درخواست می کند:

SHA و اندازه ارائه شده با وزن‌های 8 بیتی TensorFlow Lite GPT-2 مخزن مطابقت دارد.

در یک اسکریپت بازیابی شده، مقادیر اعتبار با هم در یک فرهنگ لغت به نام "LOOT" گروه بندی می شوند. محتویات شامل اعتبارنامه های AWS، نشانه های حامل و متغیرهای محیطی است که نام آنها شامل رشته هایی مانند "SECRET"، "PASSWORD"، "CREDENTIAL" یا "KEY" است.

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

این بخش از کد حاوی این نظر است: # مطالب حساس را در کناری رمزگذاری شده جمع آوری کنید

اسکریپت انتخاب می کند که از کدام نشانه برای شناسایی بیشتر استفاده کند. تابعی به نام 'rule_score' بر اساس مجوزهای فهرست شده به هر نشانه امتیاز می دهد.

ResourceRules مجوزهای نوشته شده توسط Kubernetes هستند که بر حسب منابع و افعال توصیف می شوند - اشیاء (منابع) یک اعتبارنامه می تواند به آنها دسترسی داشته باشد و اقدامات (افعال) که می تواند روی آنها انجام شود.

این سیستم امتیازدهی برای مجوزهای گسترده و دسترسی به منابع ارزشمند ارزش قائل است. قاعده‌ای که «غلاف» را فهرست می‌کند، 10 امتیاز، یکی که هم «غلاف» و هم فعل «ایجاد» را فهرست می‌کند، 15 امتیاز دریافت می‌کند، و یک علامت عام (‘*) در فهرست افعال، 50 امتیاز، با یک منبع عام 100 امتیاز اضافه می‌کند.

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

در حالی که اکثر ترافیک ما در این پنجره زمانی، عواملی را نشان می‌دهد که بر استخراج داده‌ها از Hugging Face تمرکز می‌کنند، 1500 محموله به Docker Hub، یک رجیستری عمومی که برای اشتراک‌گذاری تصاویر Docker استفاده می‌شود، هدایت شده است. آنها نسخه های اصلاح شده تصاویر CyberGym/Arvo موجود را ساختند، سپس سعی کردند حداقل 115 تصویر عمومی را تحت حساب کاربری واقعی در پلتفرم ایجاد کنند. ما معتقدیم که این عوامل اعتبار کاربر را از طریق جستجوی Docker PAT در سایت‌های Pastebin به دست آورده‌اند.

اگرچه به نظر می رسد این تصاویر به طور کامل از Docker Hub حذف شده اند، اما ما توانسته ایم نتایج موتور جستجوی کش شده را برای سه مورد از این آپلودها بازیابی کنیم و موفقیت این آپلودها را در ثبت عمومی تأیید کنیم. برای یکی از این موارد، ما تأیید کردیم که URL بازیابی شده با خلاصه مانیفست بازیابی شده در مجموعه داده ما مطابقت دارد.

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

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

کد انتشار این تصویر را می‌توانید در اینجا پیدا کنید، پیکربندی راه‌اندازی را در اینجا و منبع wrapper را در اینجا پیدا کنید.

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

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

یک نسخه اصلاح شده از تصویر libjpeg-turbo تغییرات هدف را با یک برنامه سمت عامل که ورودی های آماده شده و یک جدول جستجو را حمل می کند جفت می کند. در سمت هدف، اصلاح ابتدا سعی می کند پرچم را بخواند و محتوای آن را در حافظه برنامه چالشی ترسیم کند. سپس بخش‌های انتخابی از حافظه کاری برنامه در پاسخ‌های هدف به کمک‌کننده سمت عامل گنجانده می‌شود.

(قطعه برای خوانایی دوباره قالب بندی و کمی ویرایش شد). در سمت عامل، کمک کننده تلاش می کند تا با ارسال ورودی ها به هدف، یک کاراکتر پرچم را در یک زمان بازیابی کند. سپس 960 بایت حافظه موجود در پاسخ هش می‌شود و با جدول جستجوی «H» مقایسه می‌شود تا مشخص شود کدام کاراکترهای پرچم ممکن است هش را ایجاد کرده باشند. اگر چندین کاراکتر ممکن بود، یک بایت ورودی را تغییر می‌داد (با استفاده از مقدار آزمایش بعدی از «P») و دوباره امتحان می‌کرد تا تنها یک امکان باقی بماند. سپس این کاراکتر قبل از رفتن به موقعیت بعدی به پرچم اضافه می شود.

یک بار جداگانه نشان می دهد که چگونه عوامل قصد داشتند تا تصاویر جایگزین خود را بارگذاری کنند. قطعه زیر شامل مکان معمولی کش مصنوعی برای یک تصویر CyberGym Miniz به همراه یک مسیر کدگذاری شده دوگانه به سمت مانیفست جایگزین مرحله‌ای است. درخواست به‌دست‌آمده باعث می‌شود Artifactory جایگزین را واکشی کند در حالی که آن را در آدرس تصویر مورد انتظار ذخیره می‌کند (cache-poisoning). ارزیابی بعدی که تصویر عادی را می کشد، می تواند تصویر اصلاح شده را دریافت کند.

به طور خاص، به نظر می‌رسد این درخواست با آسیب‌پذیری مسمومیت حافظه پنهان مصنوعی که توسط OpenAI در گزارش فنی آن‌ها، که بعدا CVE-2026-66384 نام‌گذاری شد، مطابقت دارد.

بارهای بازیابی شده از نقطه پایانی Slack's search.messages استفاده می کنند و شامل یک جستجوی مستقل به همراه سه دسته جستجو هستند که در مجموع 27 عبارت جستجوی واقعی را شامل می شود:

'exploitgym'، 'restart_server'، 'catflag'، 'arvo_20494'، 'ff79aaeb2d57'، 'cybergym-server'، 'cybergym-exploit'، 'target_server'، 'packages.hub'، 'controller_stub'

"cyber gym"، "sunblaze"، "cyber-gym"، "[REDACTED-HF-USERNAME]"، "arvo"، "OSS-Fuzz"، "cybergym-server-fastapi"، "independentsafetyresearch"، "exploit gym"، "agent-cybergy-scorer"، "enaikop"

‘d293315c730d’، ‘arvo_61677’، ‘61677’، ‘rollout died’

دسته ها هر برچسب پرس و جو و پاسخ را به هم متصل می کنند، متن ترکیبی را gzip می کنند و یک آپلود را به مقصد S3 ویرایش شده آماده می کنند. سوابق مرتبط، فضای داخلی فرمان رمزگشایی شده است. مجموعه‌های بیرونی کامل، اجرا و پاسخ‌های Slack بازگشتی توسط این رکوردها ایجاد نمی‌شوند.

هنگامی که اجرای کد از راه دور روی کارمندان مجموعه داده Hugging Face تأیید شد، عوامل شروع به راه‌اندازی زیرساخت C2 کردند که هدف آن اطمینان از دسترسی مداوم و اجرای دستورات بعدی بود. یک بار اولیه، کنترل‌کننده پس‌زمینه را منتشر و راه‌اندازی می‌کند (که در نظرات به‌عنوان «ربات»، «پل» یا «رله» نامیده می‌شود)، که سپس به دستورالعمل‌های بیشتر از عامل گوش می‌دهد. بنابراین، نمایندگان می‌توانند فایل‌های کارگر را کاوش کنند، کدی را در زیرساخت Hugging Face اجرا کنند، و سعی کنند بدون انجام هر اقدامی در درخواست اصلی، به خدمات اضافی دست یابند.

ما اسکریپت‌های آپلود اولیه، کد منبع و تاریخچه فرمان چندین مورد از این کنترل‌کننده‌ها را بازیابی کردیم که یکی از آنها G236 نام داشت. جاوا اسکریپت اولیه که در مرورگر سرویس اسکرین شات اجرا می شود، مجموعه داده README و فایل های پشتیبانی کننده را در Hugging Face آپلود می کند. پیکربندی مجموعه داده README به یک بار تزریق قالب در یک فایل پشتیبانی اشاره می‌کند که برای راه‌اندازی کنترل‌کننده پایتون در هنگام پردازش توسط یک کارگر در نظر گرفته شده است. کنترل‌کننده‌های مختلف دستورات را می‌خوانند و پاسخ‌ها را به مکان‌های مختلف می‌نویسند. G236 از فایل های جداگانه در همان مخزن استفاده می کرد.

یکی دیگر، به نام OTS92، از نظرات گفتگوی صورت در آغوش گرفتن برای هر دو استفاده کرد. از آنجایی که کنترل‌کننده‌ها خودشان آن مکان‌ها را نظرسنجی کردند، عوامل نیازی به اتصال مستقیم ورودی به کارگران نداشتند.

مثال پیوند داده شده (G23619 Isolated Signed/encrypted HF worker bridge v3) برای بررسی دستورات از یک فایل مخزن به نام «g23619cmd .bin» برای حداکثر شش ساعت پیکربندی شد. هر فرمان دارای یک عدد، یک امضای RSA (که قبل از اجرا بررسی می‌شود) و داده‌های فرمان فشرده شده بود. نتایج رمزگذاری شده و در همان مخزن آپلود می‌شوند، با نام فایل‌هایی که کارگر و فرمان را شناسایی می‌کنند. از حلقه مرکزی G236:

(نظرسنجی پیرامون و رسیدگی به خطا از قطعه بالا حذف شده است). «loadcmd()» دستور را واکشی و تأیید می کند، «execute()» آن را اجرا می کند و «out()» نتیجه را رمزگذاری و آپلود می کند. برای جلوگیری از اجرای مکرر یک فرمان توسط کنترلر، اعداد فرمان به خاطر سپرده شد.

برای G236 ما 28 فرمان امضا شده متمایز را بازیابی کردیم: 18 فرمان برای کنترل‌کننده اصلی و 10 فرمان در نظر گرفته شده برای یک کنترل‌کننده فرزند که یک فرمان قبلی سعی در راه‌اندازی آن در یک pod جداگانه و تازه ایجاد شده داشت. در این مثال، دستور اولیه تلاش کرد تا اعتبارنامه AWS را به دست آورد، از آنها برای دسترسی به Kubernetes، درخواست نشانه‌ها برای حساب‌های خدمات انتخابی، و در نهایت نوشتن اطلاعات جمع‌آوری‌شده در یک فایل محلی استفاده کرد. یک دستور بعدی آن فایل را بررسی می کند و کلیدهای سطح بالای JSON آن را چاپ می کند: