‏توکن ادمین گیت‌هاب Baseten تو تاریخچهٔ یه ایمیج Docker مونده بود

تیم Strix، سازندهٔ یه ایجنت هک خودکار، می‌خواست از Baseten (یه سرویس inference با ارزش 13 میلیارد دلار) استفاده کنه. طبق روال همیشگیشون، قبلش Strix رو بدون هیچ credential یا دسترسی به کد روی *.baseten.co اجرا کردن. بعد از حدود 25 دقیقه، ایجنت یه personal access token فعال گیت‌هاب برای اکانت basetenbot پیدا کرد. این توکن روی مخزن اصلی محصول، مخزن GitOps کلاسترها و Homebrew tap شرکت دسترسی admin و push داشت.

به گفتهٔ نویسنده، Strix اول مثل هر pentest دیگه‌ای سراغ recon (یعنی شناسایی سطح حمله) رفت: زیردامنه‌ها رو پیدا کرد و certificate logها رو گشت. تهش به یه رجیستری Harbor (سرور نگهداری ایمیج‌های کانتینر) رسید که یکی از projectهاش عمومی بود. یعنی بدون لاگین می‌شد ایمیج‌ها، از جمله baseten/baseten-app، رو دانلود کرد. اولین یافته یه جفت کلید AWS بود که با یه درخواست read-only معلوم شد باطل شده.

بعد ایجنت لایه‌ها رو با TruffleHog گشت و config خود ایمیج رو هم بررسی کرد. توکن گیت‌هاب تو فیلد history[].created_by بود؛ این فیلد ثبت می‌کنه هر مرحلهٔ build با چه دستوری ساخته شده. اینجا یه دستور RUN بود که مقدار GITHUB_TOKEN مستقیم داخلش جایگذاری شده بود. config همراه ایمیج دانلود می‌شه، پس پاک کردن فایل credential از لایه‌ها کافی نیست. این build مال 3 مارس 2023 بود و توکن تا جولای 2026 هنوز کار می‌کرد.

ریشهٔ ماجرا یه الگوی آشناست. build باید dependencyهای خصوصی رو از گیت‌هاب می‌گرفت، پس توکن به‌صورت build argument (همون ARG تو Dockerfile) پاس داده شده بود. Docker ممکنه مقدار build argumentها رو تو metadata و history ایمیج ثبت کنه و خودش هم دربارهٔ این موضوع هشدار داده. مشکل دوم این بود که با git config --global آدرس احرازهویت‌شده، همراه توکن، تو فایل تنظیمات گیت داخل ایمیج نوشته می‌شد.

نویسنده می‌گه راه درست استفاده از BuildKit secret mount و احراز هویت موقتیه که credential رو هیچ‌جا ذخیره نکنه. بعدش باید هم لایه‌ها و هم history ایمیج رو مثلاً با docker history --no-trunc چک کرد. مهم‌تر از همه، توکن قدیمی رو باید revoke کرد، چون عوض کردن Dockerfile روی ایمیجی که قبلاً دانلود شده اثری نداره. توکن‌های build هم باید حداقل دسترسی و تاریخ انقضا داشته باشن.

تیم امنیت Baseten سریع وارد عمل شد: گزارش شب 13 جولای رسید، صبح فردا project رجیستری خصوصی شد و تا بعدازظهر همون روز توکن rotate شد و مشکل critical اعلام شد. Strix هم فقط درخواست read-only زده بود و نه چیزی clone کرد، نه push. نویسنده معتقده ایجنت‌های مهاجم هم می‌تونن همین مسیر رو برن، پس بهتره خودتون زودتر سیستم‌هاتون رو اسکن کنین.

نکات کلیدی:

• توکن basetenbot روی مخزن اصلی محصول، مخزن GitOps و Homebrew tap شرکت Baseten دسترسی admin داشت
• توکن تو فیلد history[].created_by در config ایمیج بود، نه تو لایه‌های فایل
• این توکن از build سوم مارس 2023 مونده بود و تا جولای 2026 فعال بود
• Strix بدون credential و بدون هیچ راهنمایی، تو حدود 25 دقیقه به این یافته رسید
• راه‌حل: BuildKit secret mount، بررسی history ایمیج، revoke کردن توکن و محدود کردن دسترسی توکن‌های build
• Baseten تو کمتر از 24 ساعت رجیستری رو خصوصی کرد و توکن رو rotate کرد