یک کلیک ساده روی صفحه تأیید OAuth میتواند یک پلتفرم میلیارد دلاری را به زانو درآورد. اگر برای عاملهای (Agents) هوش مصنوعی دسترسی «Allow All» میدهید، در واقع درهای زیرزمین زیرساخت شرکتی خود را برای مهاجمان باز کردهاید.
در ۲۸ آوریل ۲۰۲۶، فاش شد که پلتفرم Vercel دچار یک نشت داده گسترده شده است که ریشه در دو لایه عمیق از زنجیره تأمین آن داشت. به نقل از گزارشی در dev.to، این حادثه زمانی آغاز شد که یکی از کارکنان شرکت Context.ai (یک پلتفرم عاملهای هوش مصنوعی سازمانی)، یک اسکریپت تقلب برای بازی Roblox را دانلود کرد که به بدافزار Lumma Stealer آلوده بود. این بدافزار که یک سرقتکننده اطلاعات (Infostealer) رایج است، توکنهای OAuth و کوکیهای نشست را جمعآوری کرد و به مهاجم اجازه داد تا با استفاده از این اعتبارنامهها، به حساب Google Workspace یکی از کارکنان Vercel نفوذ کند.
این رخنه امنیتی از طریق چهار لایه شکست متوالی پیش رفت:
- آلودگی نقطه پایانی: اجرای نرمافزار گیمینگ آلوده توسط کارمند Context.ai.
- دسترسیهای بیشازحد OAuth: یکی از کارکنان Vercel پیشتر دسترسیهای گسترده «Allow All» را به Context.ai داده بود که اجازه دسترسی دائمی به Gmail و Drive را میداد.
- حرکت عرضی: مهاجم از حساب Workspace مسروقه برای نفوذ به حساب ادمین Vercel از طریق بازیابی هویت مبتنی بر ایمیل استفاده کرد.
- افشای اسرار: مهاجم متغیرهای محیطی (Environment Variables) را که به عنوان «غیرحساس» علامتگذاری شده بودند، رمزگشایی کرد؛ تنظیماتی که به گزارش Vercel، حالت پیشفرض برای متغیرهای جدید است.
این زنجیره حوادث به گروه هکری ShinyHunters اجازه داد تا متغیرهای پروژههای مشتریان را سرقت کرده و آنها را با قیمت ۲ میلیون دلار در یک درایو هکری به فروش بگذارد.
در پوشش پیشین ما از امنیت مدلهای بازمتن، دیدیم که چگونه پیچیدگیهای لایهای میتوانند حفرههای امنیتی پیشبینیناپذیری ایجاد کنند. این حادثه دقیقاً همان شکاف امنیتی را نشان میدهد: در حالی که هوش مصنوعی زاینده (Generative AI) سرعت توسعه را افزایش میدهد، ریسکهای «سایهای» در لایههایی ایجاد میکند که توسعهگران بهندرت آنها را بازرسی میکنند. تناقض اینجاست که توسعهگرانی که هرگز رمز عبور خود را به یک بات نمیدهند، با خوشبینی کامل، دسترسی کامل OAuth خود را به یک «مجموعه اداری» هوش مصنوعی میسپارند.
Vercel به مشتریان خود توصیه کرده است که هر متغیر محیطی که صراحتاً به عنوان حساس علامتگذاری نشده، سریعاً تغییر دهند. این تنها آغاز ماجراست؛ اثر موجگونهی این تصمیم بر استانداردهای امنیتی OAuth را در گزارش بعدی بررسی خواهیم کرد.
گام بعدی شما
- تمام متغیرهای محیطی که به صورت حساس (Sensitive) علامتگذاری نشدهاند را سریعاً تغییر دهید (Rotate).
- دسترسیهای OAuth اپلیکیشنهای متصل به حسابهای سازمانی خود را بازبینی و دسترسیهای غیرضروری را حذف کنید.
- از ابزارهای مدیریت اسرار (Secret Management) برای جایگزینی متغیرهای ساده در محیطهای عملیاتی استفاده کنید.
گفتگو