زاپوکالیپس: زنجیرهای که میتونست Zapier رو تصاحب کنه
خلاصهٔ کاملتر
به گفته نویسنده، تیم Token Security دنبال پلتفرمی میگشت که هم AI-محور باشه، هم هایپراسکیلر نباشه (چون مهلت افشای AWS و گوگل ماههاست نه هفته)، هم خودش جایی برای اجرای کد مهاجم باز کرده باشه. سیگنالی که Zapier رو انتخاب کرد، چهار CVE فرار-از-سندباکس تو ابزار مشابه n8n طی یک سال بود؛ نویسنده میگه این یه مشکل دستهایه نه مشکل یه محصول خاص. Zapier هم با هزاران اینتگریشن و میلیونها کاربر، طعمه جذابی برای یه داستان supply-chain بود.
مرحله اول، فرار از سندباکسِ «Code by Zapier» بود که اجرای پایتون دلخواه رو به کاربر میده. معلوم شد کد کاربر داخل همون پراسسی exec میشه که لحظاتی قبل اعتبارنامههای AWS رو نگه داشته بوده. توسعهدهندهها فرض کرده بودن پاککردن متغیرهای محیطی با del os.environ[k] این کلیدها رو غیرقابلبازیابی میکنه و امنیت واقعی هم به عهده یه نقش IAM به اسم allow_nothing_roleه.
هر دو فرض غلط از آب دراومد. نویسنده توضیح میده که del تو پایتون متغیر رو از مپ حذف میکنه و unsetenv رو صدا میزنه، ولی بایتهای واقعی کلید رو تو heap صفر نمیکنه؛ پس اون بایتها همچنان تو حافظه پراسس باقی میمونن. چون کانتینرهای Lambda گرم استارت میشن و یه کانتینر به درخواستهای کاربرهای مختلف سرویس میده، حتی توکنهای اجراهای قبلی هم تو حافظه مونده بودن. مهاجم با خوندن /proc/self/mem و چندتا الگوی ساده تونست اعتبارنامههای STS زنده رو دوباره استخراج کنه.
مرحله بعد نشون داد allow_nothing_role اصلاً «هیچی» اجازه نمیداد نبود؛ مجوزهای read روی ECR (رجیستری کانتینر خصوصی Zapier با ۱۱۱۱ ریپازیتوری) لو رفته بود. مجوز ecr:GetAuthorizationToken رو نداشتن که docker pull لازمش داره، پس Docker رو کلاً دور زدن و با صدا زدن مستقیم APIهای ECR، لایهها رو خام دانلود و ایمیجها رو محلی بازسازی کردن. نویسنده تأکید میکنه هر مانیتورینگی که فقط دور Docker بسته شده باشه این کارو نمیبینه؛ درِ جلویی قفله ولی بارانداز بازه.
بین ایمیجها، یه بیلد خصوصی از LiteLLM یه توکن MCP کاربری (sk-ak-) رو هاردکد تو سورس داشت که به یه همبنیانگذار LiteLLM وصل بود و دسترسی به Gmail و اینتگریشنهای Zapier اون فرد رو میداد. این یه primitive فیشینگ متفاوته: ایمیلی که واقعاً از صندوق یه آدم واقعی فرستاده میشه و چکهای DMARC/DKIM رو پاس میکنه چون واقعاً حساب خودشه.
مرحله آخر، توکن NPM پر-دسترسیای بود که نه تو فایلسیستم، بلکه تو متادیتای بیلدِ ایمیج (فیلد history تو config blob) لو رفته بود و امکان انتشار نسخه دستکاریشده از پکیج design-system رو میداد. Zapier ظرف چند روز توکن رو باطل و نقش ECR رو سفت کرد و تا اوایل مارس وصله کامل رو تأیید کرد.
نکات کلیدی:
- زنجیره از پنج الگوی شناختهشده ساخته شده بود، نه یه روز-صفر؛ ترکیبشون خطرناک بود.
- del os.environ[k] پاککردن واقعی نیست؛ بایتهای کلید تو heap میمونن — راهحل، اجرای کد کاربر تو پراسسیه که اصلاً کلید رو نمیبینه.
- نقشی که اسمش allow_nothing بود، مجوز read روی ECR رو لو داده بود؛ اسم نقش، کنترل امنیتی نیست.
- محدودکردن GetAuthorizationToken جلوی pull رو نمیگیره، چون APIهای ECR رو میشه مستقیم صدا زد.
- توکنها میتونن تو متادیتای بیلد ایمیج لو برن، حتی وقتی تو فایلسیستم نیستن.
