ما دسترسی مدیر به GitHub تولید Baseten را دریافت کردیم

قرار بود به Baseten به داده های خود و مشتریانمان اعتماد کنیم. بنابراین برای ایمن بودن، Strix را اجرا کردیم تا ابتدا مطمئن شویم که آنها ایمن هستند. حدود 25 دقیقه بعد، یک توکن GitHub زنده با حقوق مدیریت در سطح مخزن در مخازن داخلی Baseten داشت.

ما Strix را می سازیم، یک عامل هک مستقل، که البته به این معنی است که به استنتاج (ارزان و سریع) نیاز داریم. ما در حال بررسی گزینه های خود بودیم و Baseten یکی از گزینه های واضح است. این یک محصول عالی است، آنها 13 میلیارد دلار ارزش دارند و بسیاری از شرکت های جدی به آنها وابسته هستند.

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

بنابراین... ما Strix را به *.baseten.co اشاره کردیم و اجازه دادیم بدون اعتبار یا کد منبع اجرا شود.

با یک توکن دسترسی شخصی فعال GitHub برای basetenbot بازگشت. آن توکن دارای دسترسی سرپرست و فشاری به مخزن اصلی محصول Baseten، مخزن GitOps که کلاسترهای آن‌ها را هدایت می‌کند، و تپ Homebrew آن‌ها، به‌علاوه دسترسی خواندن/نوشتن به مخازن خصوصی دیگر از جمله مخازن خاص به ازای هر مشتری، داشت.

ساخت تصویر مربوط به مارس 2023 است، و زمانی که آن را در ژوئیه 2026 پیدا کردیم، توکن همچنان کار می کرد.

اما قبل از اینکه وارد جزئیات شویم، اجازه دهید از تیم امنیتی Baseten تشکر کنیم. آنها مشکل را به عنوان بحرانی تأیید کردند، پروژه رجیستری را قفل کردند و تا بعدازظهر بعد توکن را چرخاندند. آنها حرفه ای بودند و خیلی سریع با آن کنار آمدند (که اغلب در این مواقع صدق نمی کند).

Strix مانند هر پنتست خوب شروع می کند: recon. اغلب اوقات، شدیدترین آسیب‌پذیری در infra شما ممکن است در سرویسی در زیر دامنه‌ای باشد که فراموش کرده‌اید (به همین دلیل است که ما همیشه آزمایش جعبه سیاه را در کنار آزمایش با دسترسی به کد توصیه می‌کنیم)! بنابراین Strix میزبان ها را برشمرد، از طریق سیاهههای مربوط به گواهینامه ها نگاه کرد و سطح کامل را ترسیم کرد. در نهایت، یک رجیستری Harbor را در gcp-us-east4-zlw.registry.baseten.co پیدا کرد.

Harbor تصاویر کانتینر را ذخیره می کند و مخازن را در پروژه ها گروه بندی می کند. یکی از این پروژه ها عمومی بود. بدون هیچ توکن یا اعتباری، Strix می‌تواند مخازن را فهرست کند، توکن‌های کششی ناشناس را به دست آورد، و مانیفست‌ها و حباب‌های تصویر واقعی را دانلود کند. این شامل تصویری به نام baseten/baseten-app بود.

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

Strix تصمیم گرفت یک تصویر بکشد و ببیند چه چیزی داخل آن است. در اینجا آن قسمت از اجرا همانطور که در Strix ظاهر می شود (بله، نوشته خود عامل به دلایل واضح مانند هوش مصنوعی به نظر می رسد):

اگر قرار نیست پروژه‌های بندر عمومی باشند، این یک نوردهی واقعی است، نه نویز ابرداده. زنجیره آن چیزی است که اهمیت دارد: شمارش پروژه‌های عمومی، خواندن فراداده مصنوع، برش یک سرویس/توکن ناشناس در محدوده مخزن:baseten/baseten-app:pull، مانیفست را بکشید، سپس حباب را از طریق تغییر مسیر ذخیره‌سازی امضا شده واکشی کنید. این دسترسی ناشناس واقعی را ثابت می کند. راه جدی گرفتن تریاژ این است که یک چیز را از یک تصویر کشیده ثابت کنید: کد اختصاصی، باینری های داخلی، اعتبارنامه هاردکد یا نام میزبان داخلی.

اولین موفقیت امیدوارکننده یک جفت کلید AWS در برنامه baseten/baseten-app بود. Strix یک تماس فقط خواندنی sts:GetCallerIdentity را امتحان کرد که به شما می‌گوید یک اعتبار متعلق به چه حسابی است. پاسخ InvalidClientTokenId بود.

لایه‌ها را کشید، TruffleHog را اجرا کرد (به دوستان امنیتی منبع باز ما فریاد بزنید!)، و پیکربندی تصویر را مستقیما بررسی کرد. و اینجا بود: یک نشانه دسترسی شخصی کلاسیک GitHub، که در history[].created_by .

من یک متخصص زمان اجرا Docker نیستم، اما خوشبختانه Strix این کار را انجام می دهد (به لطف داشتن تقریبا تمام دانش بشری در اختیارش). بنابراین می دانست که آن فیلد نحوه ایجاد مرحله ساخت را ثبت می کند. در این مورد، حاوی یک دستور RUN با مقدار GITHUB_TOKEN است که مستقیما در آن گسترش یافته است.

Strix از توکن برای یک درخواست GET /user فقط خواندنی به GitHub و… VOILÀ استفاده کرد. 200 با نام حساب basetenbot.

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

و این یکی هنوز هم بعد از بیش از سه سال کار کرد.

توکن زنده جالب است، اما بدیهی است که مجوزها مهم هستند. این نشانه می تواند 0 مجوز و در نتیجه 0 تاثیر داشته باشد. بنابراین Strix حساب و عضویت سازمان آن را بررسی کرد. GitHub X-OAuth-Scopes: repo را برگرداند و حساب متعلق به basetenlabs بود.

سپس با استفاده از درخواست‌های فقط خواندنی، مجوزهای مخزن فردی را بررسی کرد:

این مقدار دیوانه کننده دسترسی برای ترک در یک تصویر قابل دانلود عمومی است.

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

تاریخ ساخت دارای مهر زمانی بود. مرحله حاوی توکن در 3 مارس 2023 اجرا شد. این یک اعتبار ساخت قدیمی بود که وقتی آن را در جولای 2026 آزمایش کردیم، هنوز همه آن دسترسی را داشت.

اشتباه اساسی بسیار آشناست. یک ساخت برای واکشی وابستگی های خصوصی از GitHub لازم بود، بنابراین شخصی یک توکن را به عنوان آرگومان ساخت ارسال کرد. الگوی مربوطه به این شکل بود:

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

همچنین یک مشکل دوم با این الگو وجود دارد: git config --global URL تأیید شده را در فایل پیکربندی Git می‌نویسد. حتی اگر نحوه ورود توکن به بیلد را تغییر دهید، باز هم باید از ذخیره آن در تصویر خودداری کنید.

راه حل این است که از نصب مخفی BuildKit و احراز هویت موقت استفاده کنید که اعتبار را حفظ نمی کند. سپس لایه های تصویر و تاریخچه آن را بررسی کنید. و رمز قدیمی را لغو کنید! تغییر Dockerfile کاری در مورد تصویری که شخصی قبلا دانلود کرده است انجام نمی دهد.

Baseten یک تیم امنیتی پاسخگو دارد و در حال حاضر از ابزار امنیتی هوش مصنوعی استفاده می کند. با این حال، زمانی که ما آن را پیدا کردیم، این توکن از یک ساخت 2023 دسترسی سرپرست به مخزن محصول و استقرار آنها داشت.

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

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

ما به آن نگفته بودیم که به دنبال هاربر بگردد یا در مورد یک توکن به آن اشاره ای نکرده بودیم. در حدود 25 دقیقه تمام کار را به طور مستقل انجام داد.

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

آنها همچنین تعدادی تی شرت و گرمکن به عنوان تشکر از شما برای یافتن این اشکال مهم برای ما ارسال کردند.

اگر کانتینرها را اجرا می کنید و از GitHub استفاده می کنید، ارزش بررسی زیرساخت های خود را دارد:

و چیزی مانند Strix را علیه سیستم های خود اجرا کنید. کل این اسکن به این دلیل شروع شد که می‌خواستیم از یک ارائه‌دهنده استنتاج استفاده کنیم. ما به آن یک دامنه دادیم و یک آسیب پذیری حیاتی دریافت کردیم که Baseten می توانست صبح روز بعد روی آن عمل کند.

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