پوشش خبری مربوط به نفوذ ایجنت‌های خودکار OpenAI به پلتفرم هوش مصنوعی Hugging Face، بیشتر شبیه صحنه‌ای از فیلم Terminator است؛ آن هم ظاهراً یک پیش‌درآمد! با این حال، برای تیم‌های امنیتی سازمانی، حتی آن‌هایی که هوش مصنوعی توسعه نمی‌دهند یا از آن استفاده نمی‌کنند، گزارش دقیق این رخداد که توسط Hugging Face منتشر شده، یک نقشه راه عملیاتی بسیار مهم ارائه می‌دهد.

این رخداد باید بر اساس یک سؤال اساسی بررسی شود: «کدام ضعف‌های امنیتی سازمان، کنترل‌های ناکافی یا مفقود، پیکربندی‌ها یا فناوری‌ها باعث شدند این حمله موفق شود؟»

چه اتفاقی افتاد؟

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

مدل به این نتیجه رسیده بود که می‌تواند راه‌حل چالش‌های Benchmark را در این سیستم‌های خارجی پیدا کند.

تاکنون ده‌ها مقاله جزئیات این رخدادها را بررسی کرده‌اند؛ بنابراین نیازی به تکرار آن‌ها نیست. آنچه اهمیت بیشتری دارد، اتفاقاتی است که بین ۹ تا ۱۳ ژوئیه در سیستم‌های Hugging Face رخ داد؛ یعنی زمانی که ایجنت هوش مصنوعی بدون کنترل در زیرساخت این شرکت فعالیت می‌کرد.

گزارش رخداد Hugging Face شامل یک Timeline تعاملی از حمله است. مهم‌ترین مراحل حمله را می‌توان این‌گونه خلاصه کرد:

یک پیکربندی مخرب در Dataset بارگذاری‌شده توسط ایجنت، امکان استخراج اطلاعات ورود مربوط به یک Worker Pod و اجرای کد در آن را فراهم کرد. سپس ایجنت از Metadata محیط ابری سوءاستفاده کرد و با خارج شدن از Pod دارای سطح دسترسی بالا، به دسترسی در سطح Root روی Host رسید.

پس از آن، تعداد قابل‌توجهی Secret را از فضای ذخیره‌سازی استخراج کرد و با استفاده از یک کلید VPN سرقت‌شده و اطلاعات ورود مشترک مدیر Cluster، نفوذ خود را به بخش‌های عمیق‌تری از شبکه داخلی و Repository کد منبع گسترش داد. این روند تا زمانی ادامه داشت که تیم امنیتی Hugging Face دسترسی آن را مسدود کرد.

نسل جدید هوش مصنوعی چقدر در این حمله تأثیرگذار بود؟

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

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

با این حال، پژوهشگران امنیتی ماه‌هاست تأکید می‌کنند که حتی مدل‌های متن‌باز موجود در حال حاضر نیز می‌توانند برای تحقیقات تهاجمی و اجرای حملات واقعی مورد استفاده قرار بگیرند. نظارت انسانی هنوز لازم است، اما میزان آن می‌تواند بسیار محدود باشد.

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

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

سه ویژگی متمایز حملات مبتنی بر هوش مصنوعی

تکنیک‌هایی که در گزارش Hugging Face شرح داده شده‌اند جدید نیستند و ایجنت هیچ روش حمله تازه‌ای ابداع نکرده است. با این حال، سه عامل مرتبط با سرعت و مقیاس حمله، معادلات اقتصادی را هم برای مهاجمان و هم برای مدافعان به‌طور اساسی تغییر می‌دهند:

• آزمون و خطا بسیار کم‌هزینه‌تر می‌شود. در حالی که یک هکر انسانی ممکن است پنج مسیر حمله را آزمایش کند، یک ایجنت می‌تواند ۵۰۰ مسیر را امتحان کند. سناریوهایی که تیم‌های امنیتی قبلاً آن‌ها را «از نظر تئوری ممکن، اما در عمل دشوار و بعید» می‌دانستند و بررسی‌شان را به آینده موکول می‌کردند، اکنون می‌توانند به تهدیداتی واقعی تبدیل شوند.
• زمان اجرای حمله و فرصت واکنش به رخداد کوتاه‌تر می‌شود. حملات پرسرعت موضوع جدیدی نیستند و حتی بدون هوش مصنوعی، برخی اپراتورهای باج‌افزار می‌توانند ظرف چند ساعت یک سیستم را به خطر بیندازند. با این حال، احتمالاً این سرعت بالا به استاندارد جدیدی در امنیت سایبری تبدیل خواهد شد؛ همان‌طور که ایجنت در حمله به Hugging Face توانست تنها طی ۱۳ ساعت به سطح دسترسی Administrator برسد.
• حجم بالای هشدارها و لاگ‌های ناشی از آزمون و خطای ایجنت می‌تواند هم به مهاجمان و هم به مدافعان کمک کند یا برای آن‌ها مشکل‌ساز شود. این حجم از رویدادها از یک سو می‌تواند شاخصی برای شناسایی تهدید باشد و از سوی دیگر، به‌عنوان پوششی برای پنهان کردن اقدامات مهم مهاجم عمل کند. همچنین زمانی که فرایندهای واکنش به رخداد کاملاً دستی باشند، این حجم اطلاعات خود به یک گلوگاه طبیعی تبدیل می‌شود.

چگونه از زیرساخت سازمانی محافظت کنیم؟

هشدارهای ایجادشده توسط کنترل‌های دفاعی را نادیده نگیرید. این اشتباه کلاسیک که کارشناسان Incident Response کسپرسکی بارها به آن اشاره کرده‌اند، در Hugging Face نیز رخ داد.

اجرای بدافزار، اسکن پورت‌ها، فعال شدن WAF، درخواست دسترسی به منابع خارج از Allowlist و تلاش‌های ناموفق برای احراز هویت از جمله رویدادهایی هستند که ممکن است به‌صورت خودکار مسدود شوند. با این حال، SIEM اغلب چنین رویدادهایی را صرفاً در دسته اطلاعاتی قرار می‌دهد و در نتیجه به‌طور معمول نادیده گرفته می‌شوند.

در رخداد Hugging Face، طی چند روز تعداد زیادی تلاش برای اجرای حملات Server-Side Request Forgery یا SSRF با موفقیت مسدود شد، اما این اتفاق توجه کسی را جلب نکرد. ایجنت هوش مصنوعی نیز درست مانند یک مهاجم انسانی پیگیر، بارها تلاش خود را تکرار کرد تا سرانجام موفق شد.

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

افزایش سریع تعداد خطاها را بررسی کنید. فعالیت‌های عادی به‌ندرت طی ۱۰ دقیقه صدها خطای احراز هویت را در چهار سیستم مختلف ایجاد می‌کنند.

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

مسیرهای Escalation را مشخص کرده و برای تیم امنیتی مانور برگزار کنید. موتور Correlation در Hugging Face حمله را با موفقیت شناسایی کرد، اما نتوانست توجه کارشناسان انسانی را به آن جلب کند.

در جریان مانورهای امنیتی، سازمان باید بررسی کند نیروهای کلیدی با چه سرعتی به رخدادهای بحرانی واکنش نشان می‌دهند؛ حتی زمانی که رخداد در ساعات غیرکاری، مانند شب یا آخر هفته اتفاق می‌افتد.

سرویس‌هایی را که ذاتاً ورودی‌های غیرقابل‌اعتماد پردازش می‌کنند، حتی اگر داخلی باشند، ایزوله کنید. آسیب‌پذیری اصلی در ابتدای این حمله مربوط به Nodeای بود که برای پردازش Datasetهای یادگیری ماشین پیکربندی شده بود؛ Datasetهایی که به‌خوبی مشخص است می‌توانند حاوی کد قابل‌اجرا باشند.

این Node که توانایی اجرای کد غیرقابل‌اعتماد را داشت، بدون Sandbox یا کنترل‌های ایزوله‌سازی کافی فعالیت می‌کرد.

این ریسک فقط به یادگیری ماشین محدود نمی‌شود. موتورهای تبدیل اسناد، Pipelineهای پردازش تصویر، Handlerهای آپلود فایل کاربران و هر فرایند سمت سرور دیگری که عملیات Deserialization یا Template Rendering انجام می‌دهد نیز می‌تواند با چنین خطری مواجه باشد.

هرگونه اجرای کد سمت سرور از این نوع باید با حداکثر سطح ایزوله‌سازی ممکن انجام شود. دسترسی آن به Hostهای خارجی یا داخلی شبکه نیز باید به حداقل مطلق محدود شود و در حالت ایده‌آل، کل فرایند داخل یک Sandbox اجرا شود.

ترافیک خروجی یا Egress را محدود کنید. بیشتر سرورهای سازمانی نیازی به ارتباط نامحدود با Hostهای خارجی ندارند.

اگر اجرای سیاست سخت‌گیرانه Default-Deny برای Egress از نظر فنی دشوار است، می‌توان از رویکرد ساده‌تری استفاده کرد: تمام درخواست‌های DNS فقط از طریق DNS Server سازمان پردازش شوند و دسترسی به سرویس‌های عمومی شناخته‌شده‌ای که معمولاً به‌عنوان زیرساخت Command-and-Control یا کانال استخراج اطلاعات مورد سوءاستفاده قرار می‌گیرند، مانند Pastebin یا OneDrive، مسدود شود.

محدودیت‌های مشابه برای ترافیک خروجی را می‌توان از طریق NGFW نیز اعمال کرد.

از صدور تعداد زیادی Secret یا ذخیره همه آن‌ها در یک Object خودداری کنید. حتی در صورت استفاده از Secret Manager، اگر یک حساب به سطح دسترسی بیش از حدی دسترسی داشته باشد، مهاجم با به خطر انداختن آن می‌تواند به طیف گسترده‌ای از منابع دست پیدا کند.

در نفوذ به Hugging Face، تنها یک Kubernetes Secret Object شامل ۱۳۶ کلید بود. هرچه تعداد Secretهای صادرشده کمتر باشد، تأثیر یک نفوذ نیز محدودتر خواهد بود و فرایند Key Rotation آسان‌تر انجام می‌شود.

از Secretهای با طول عمر بالا استفاده نکنید و آن‌ها را در Environment Variableهایی که تمام Child Processها به ارث می‌برند، ذخیره نکنید.

برنامه‌ها را از Metadata Serverها ایزوله کنید. بیشتر محیط‌های ابری سرویس‌هایی مانند EC2 Instance Metadata Service دارند که در صورت دریافت درخواست، اطلاعات ورود و جزئیات سیستم را ارائه می‌کنند.

ایزوله کردن این سرویس‌ها از برنامه‌های مختلف، از طریق قوانین Firewall یا با الزام به استفاده از IMDSv2، مستقیم‌ترین مسیر تبدیل یک نفوذ محدود به یک برنامه به تصاحب کامل حساب را از بین می‌برد.

هویت‌های مربوط به سرورها و برنامه‌ها را ممیزی کنید. Service Accountهایی با سطح دسترسی گسترده، OAuth Tokenها، کلیدهای مشترک میان محیط‌های مختلف و سایر مواردی که دسترسی بیش از حد ایجاد می‌کنند، معمولاً بیشتر در هویت‌های مربوط به سرورها و برنامه‌ها دیده می‌شوند تا حساب‌های کاربران انسانی.

استفاده از اطلاعات ورود از نقاط ورودی غیرعادی را کنترل کنید. در حمله به Hugging Face، اطلاعات ورود اختصاص‌یافته به یک Host داخلی از یک Host خارجی مورد استفاده قرار گرفت.

پیاده‌سازی قوانین شناسایی برای تشخیص چنین ناهنجاری‌هایی نسبتاً ساده است و می‌تواند سیگنال‌هایی دقیق و با نویز کم درباره حمله‌ای ارائه دهد که از مراحل اولیه خود عبور کرده است.

هنگام Provision کردن دستگاه‌ها و سرویس‌های جدید، از کلیدهای کوتاه‌عمر و یک‌بارمصرف استفاده کنید. در جریان این رخداد، از یک کلید واحد برای ثبت ۱۸۱ دستگاه مختلف استفاده شد، بدون اینکه حتی یک هشدار ایجاد شود.