چرا یک اسکنر ساده منجر به افشای داده‌های ۲۵۰۰ سازمان شد؟

اگر امروز برای مدیریت مدل‌های هوش مصنوعی خود از درگاه‌های متمرکز استفاده می‌کنید، باید بدانید که یک نقطه شکست کوچک می‌تواند کل استراتژی داده‌ای شما را به خطر اندازد. نشت کلیدهای دسترسی به مدل‌های زبانی بزرگ (LLM) — که شبیه به کلید اصلی یک ساختمان است و به تمام اتاق‌های محرمانه دسترسی می‌دهد — اکنون بیش از ۲۵۰۰ سازمان جهانی را در معرض خطر قرار داده است.

به گزارش شرکت امنیتی CloudSEK در ۱۱ اوت ۲۰۲۶، یک حمله گسترده به زنجیره تأمین LiteLLM رخ داده است. این ابزار متن‌باز که برای مسیریابی درخواست‌ها بین مدل‌های مختلف هوش مصنوعی به کار می‌رود، به دلیل یک آسیب‌پذیری، باعث به خطر افتادن حدود ۴۳۴,۰۰۰ خط لوله CI/CD (سیستم‌های خودکار ساخت نرم‌افزار) شده است.

این حادثه یک آسیب‌پذیری حیاتی در نحوه ساخت زیرساخت‌های مدرن هوش مصنوعی را برجسته می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره این موضوع اشاره کردیم که محققان IIT Bombay و Adobe توانستند پرامپت‌ها را از خروجی مدل‌ها مهندسی معکوس کنند، این نفوذ یک تهدید مستقیم‌تر را نشان می‌دهد: سرقت کلیدهای واقعی که دسترسی به کل پشته (Stack) هوش مصنوعی را فراهم می‌کنند. برای اکثر کسب‌وکارها، درگاه هوش مصنوعی (AI Gateway) تنها نقطه شکست برای کل استراتژی LLM آن‌هاست. این نوع نفوذهای سیستمی یادآور حملات پیچیده به زیرساخت‌های Hugging Face است که در آن عوامل هوش مصنوعی توانستند در مراحل مختلف به محیط‌های عملیاتی نفوذ کنند.

زنجیره آلودگی

طبق مستندات منتشر شده، این حمله از خودِ LiteLLM شروع نشد. در ۲۴ مارس ۲۰۲۶، گروهی به نام TeamPCP از یک توکن اتوماسیون لو رفته در Trivy — یک اسکنر امنیتی متن‌باز محبوب — استفاده کردند. از آنجا که این توکن جایگزین شده بود اما به طور کامل ابطال (Revoke) نشده بود، مهاجمان یک پنجره زمانی حدود ۲۰ روزه داشتند تا کدهای مخرب را به صورت اجباری (Force-push) روی تگ‌های نسخه‌های منتشر شده Trivy جایگزین کنند.

از آنجا که خط لوله ساخت LiteLLM، ابزار Trivy را بدون تعیین نسخه دقیق (Unpinned) از مدیریت بسته سیستم نصب می‌کرد، این اسکنر مسموم مستقیماً وارد فرآیند ساخت شد. در نتیجه، نسخه‌های ۱.۸۲.۷ و ۱.۸۲.۸ از LiteLLM در مخزن پایتون (PyPI) منتشر شدند. این نسخه‌ها تنها ۴۰ دقیقه فعال بودند، اما همین زمان برای سیستم‌های خودکار CI/CD کافی بود تا کد مخرب را با سرعت ماشین و بدون بازبینی توسعه‌دهندگان به محیط‌های شرکتی منتقل کنند.

اجرای فنی و سرقت داده‌ها

بدافزار مورد استفاده برای دور زدن حفاظ‌های زمان نصب، از مکانیسم هوشمندانه‌ای بهره برد. نسخه ۱.۸۲.۸ یک فایل .pth در محیط پایتون ایجاد می‌کرد. این فایل هر بار که مفسر پایتون شروع به کار می‌کند اجرا می‌شود، فارغ از اینکه آیا کتابخانه LiteLLM واقعاً فراخوانی (Import) شده است یا خیر.

به نقل از CloudSEK، ابزار سرقت اعتبارنامه‌ای به نام SANDCLOCK پس از فعال شدن، اقدامات زیر را انجام داد:

• ارتقای سطح دسترسی به root در محیط‌های اجرای کد (Runners) آسیب‌دیده.
• استخراج کلیدهای SSH، فایل‌های محیطی (Environment files) و اسرار CI/CD از حافظه پردازش، با دور زدن ابزارهایی که به طور معمول این مقادیر را ماسک می‌کنند.
• سرقت اعتبارنامه‌های AWS، گوگل کلاود و Azure از طریق سرویس متادیتای نمونه (Instance Metadata Service) با استفاده از دسترسی‌های موجود در Runner.
• استخراج توکن‌های حساب‌های سرویس کوبرنتیز (Kubernetes service-account tokens)، کلیدهای API مدل‌های زبانی و پیکربندی‌های درگاه.

داده‌های سرقتی با یک کلید سخت‌افزاری (Hard-coded) رمزنگاری و به یک دامنه جعلی (Typosquatted) ارسال شدند. در مواردی که ارسال داده شکست می‌خورد، بدافزار مخازن عمومی در حساب گیت‌هاب خودِ قربانی می‌ساخت تا اسرار سرقتی را به عنوان دارایی‌های انتشار (Release assets) در معرض دید ذخیره کند. این متدولوژی نفوذ به محیط‌های ایزوله، شباهت زیادی به سوءاستفاده از حفره‌های امنیتی Sandbox دارد که در آن مهاجمان با دور زدن محدودیت‌های محیطی، به زیرساخت‌های تولید دسترسی پیدا کردند.

دامنه افشا

شرکت CloudSEK با اطمینان بالا ارتباط این نشت را با غول‌های جهانی متعددی تأیید کرده است، از جمله: NVIDIA، Samsung Electronics، Cisco Systems، Siemens، S&P Global، ServiceNow، Deloitte، Vodafone، X Corp، Zscaler، FedEx، Volkswagen، Thales و گروه بورس لندن (LSEG).

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

تحلیل: تداوم ریسک

این breach ثابت می‌کند که حذف یک بسته مخرب از مخزنی مثل PyPI، درمان قطعی نیست. هر اعتبارنامه‌ای که در آن بازه ۴۰ دقیقه‌ای سرقت شده، تا زمانی که به صورت دستی تغییر نکند (Rotate)، معتبر باقی می‌ماند. در ۲ ژوئیه ۲۰۲۶، FBI در یک هشدار فوری (FLASH advisory) اعلام کرد که TeamPCP احتمالاً مدت‌ها پس از نفوذ اولیه، از این داده‌ها برای حملات استفاده خواهد کرد.

هشدار FBI تأیید می‌کند که کمپین TeamPCP فراتر از LiteLLM بود. این گروه همچنین SDK پایتون Telnyx و اسکنر KICS شرکت Checkmarx را آلوده (Trojanized) کردند. این نفوذها با تاکتیک‌های باج‌گیری، از جمله انتشار نام قربانیان در یک سایت افشای عمومی و تهدید به انتشار داده‌های سرقتی همراه بود. این سطح از کنترل بر سیستم‌های هدف، ما را به یاد آزمون‌های امنیتی مدل‌های Claude آنتروپیک می‌اندازد که در آن مدل‌ها توانستند کنترل کامل سیستم‌های سه شرکت مختلف را به دست بگیرند.

برای مدیران کسب‌وکار، این یک زنگ خطر جدی درباره «جهنم وابستگی‌ها» (Dependency Hell) است. اینکه یک توکن ابطال‌نشده در سه مرحله قبل از زنجیره تأمین، می‌تواند کلیدهای هوش مصنوعی یک شرکت Fortune 500 را لو دهد، نشان‌دهنده نبود سیستماتیک سیاست «حداقل دسترسی» (Least-privilege) در خطوط تولید AI است.

توصیه‌های کاهش ریسک

برای مقابله با این آسیب‌پذیری‌ها، FBI و CloudSEK گام‌های زیر را توصیه می‌کنند:

• متصل کردن GitHub Actions به هش‌های تاییدشده (Commit Hashes) به جای تگ‌های نسخه‌ای شناور.
• تغییر (Rotate) تمام اسرار CI/CD و توکن‌های منتشرشده که در بازه زمانی افشای مارس در دسترس بوده‌اند.
• اعمال محدودیت‌های سخت‌گیرانه «حداقل دسترسی» بر توکن‌های مخزن و حساب‌های سرویس.
• جستجو در سازمان‌های گیت‌هاب برای یافتن مخازنی با نام‌های tpcp-docs یا docs-tpcp.

سازمان‌ها باید با هر اعتبارنامه‌ای که فرآیند آسیب‌دیده قادر به خواندن آن بوده است، به عنوان داده‌ای افشا شده برخورد کنند. این شامل بررسی لاگ‌های دسترسی در سیستم‌های ابری، کنترل منبع (Source-control)، مخازن و کلاسترها است. برای کسانی که نسخه‌های آسیب‌دیده را در ماه مارس اجرا کرده‌اند، ساعت تصمیم‌گیری برای تغییر کلیدها از پنج ماه پیش شروع شده است.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.