سلفهاست کردن GitLab: درس حمله Alpine و باگ Ruby برای تیمهای فنی
نویسنده: آرش لطیفی — موسس The DevArt
حمله اخیر به GitLab Alpine نشون داد اپدیت کردن خود ابزار کافی نیست. اگه GitLab یا سرویس مشابهی رو خودتون میزبانی میکنید، این چکلیست رو جدی بگیرید.
TL;DR — Alpine Linux همین هفته تونست جلوی یه حمله جدی به GitLabش رو بگیره، ولی مجبور شد کل سرور رو از صفر بازسازی کنه؛ درس اصلی: وقتی ابزار سلفهاست دارید، اپدیت خودِ ابزار همیشه کافی نیست.
چی شد؟
Alpine Linux روز ۲۸ اکتبر ۲۰۲۶ اعلام کرد یه مهاجم در روزهای ۲۰ و ۲۱ اکتبر سعی کرده از یه باگ بحرانی GitLab (کد CVE-2026-97229) سوءاستفاده کنه. این باگ اجازه میداد یه کاربر بدون لاگین با یه regex دستکاریشده توی کانفیگ CI، کد دلخواه روی سرور اجرا کنه — امتیاز CVSSش ۱۰ از ۱۰.
جزئیات جالب ماجرا:
- مهاجم با یه اکانت تازهساخت، کانفیگهای CI دستکاریشده فرستاد و ۸ بار پروسههای GitLab رو کرش کرد؛ ۴ بار تا وسط مسیر اکسپلویت رفته بود و شکست خورد.
- حتی ایمیج کانتینر GitLab Alpine رو دانلود کرده بود — یعنی داره اکسپلویت رو دقیقاً برای همون بیلد تنظیم میکرد.
- Alpine هیچ مدرکی از موفقیت حمله پیدا نکرد، ولی «ردش نکرد» و محتاطانه کل اینستنس رو از صفر بازسازی کرد: همه پسوردها ریست شد، کلیدهای مخفی سرور عوض شد.
نکته تلخ: اپدیت کردن GitLab اکسپلویت رو بست نبود
این قسمتش برای خیلی از تیمها غافلگیرکنندهست. Alpine روز ۲۲ اکتبر به GitLab 19.3.6 آپگرید کرد — و باگ هنوز بود!
چرا؟ چون فیکس داخل کد GitLab نبود؛ فیکس یه پچ روی موتور regex خود زبان Ruby (پروژه Onigmo) بود که GitLab فقط توی پکیجها و ایمیجهای رسمی خودش اعمال میکنه. فیکس واقعی Ruby روز ۲۳ اکتبر اومد: نسخههای 3.3.13، 3.4.12 و 4.0.9.
یعنی اگه شما GitLab رو با Ruby خودتون (از سورس یا ایمیج کانتینر شخصی) اجرا میکنید، آپگرید GitLab بهتنهایی هیچ کاری نمیکنه — باید Ruby رو هم جدا آپدیت کنید. تیم Alpine ایمیج alpinelinux/gitlab:19.3.6ای که قبل از ۲۷ اکتبر pull شده بود رو هم vulnerabel اعلام کرد.
چرا این به درد کسبوکار شما میخوره؟
خیلی از فروشگاهها و تیمهای کوچیک، GitLab یا Git سرور خودشون رو سلفهاست کردن — چون ارزونتره و دیتا پیش خودتونه. ولی هزینه پنهانش اینه:
| مسئولیت | ابزار رسمی (SaaS) | سلفهاست خودتون | |---|---|---| | اعمال فیکسهای زیربنایی (مثل پچ Ruby) | خود vendor | خودتون | | شناسایی «فیکس دو لایهای» | خود vendor | کسی بهش فکر نمیکنه | | بازسازی بعد از احتمال نفوذ | تیم vendor | شبانه و با استرس | | مدیریت پسوردها و کلیدها بعد از incident | خود vendor | خودتون |
مهاجم Alpine یه هفته بعد از انتشار فیکس حمله کرد — یعنی پنجرهی بین «فیکس منتشر شده» و «من آپدیت کردم» الان عملاً روزهاست، نه ماهها. و این حمله خودکار و اسکریپتی بود، نه یه هدفگذاری اختصاصی.
چکلیست برای سرور GitLab خودتون
- [ ] نسخه GitLab سرور رو چک کنید؛ اگه قبل از ۱۹.۲.۸ / ۱۹.۳.۵ / ۱۹.۴.۲ هستید، فوراً آپگرید کنید.
- [ ] بفهمید Ruby از کجا میاد: پکیج رسمی GitLab؟ ایمیج رسمی؟ یا بیلد/ایمیج خودتون؟ اگه Ruby خودتونه، حداقل
3.3.13/3.4.12/4.0.9لازمه. - [ ] اگه ایمیج
alpinelinux/gitlab:19.3.6دارید که قبل از ۲۷ اکتبر pull شده، دوباره pull کنید. - [ ] دسترسی به GitLab داخلی رو پشت VPN یا allowlist بذارید؛ حمله Alpine از یه اکانت تازهمسجل اومد.
- [ ] یه صفحه incident ساده داشته باشید: «اگه مشکوک شدیم، چی رو ریست کنیم؟» (پسوردها، secret keys، توکنهای CI).
FAQ
Q: ما GitLab استفاده نمیکنیم، ربطی به ما داره؟
آره، از دو جهت. اول اینکه باگ توی موتور regex خود Ruby بود، نه GitLab — هر برنامه Rubyای که regex رو از ورودی کاربر کامپایل میکنه در معرضه. دوم اینکه الگوی «فیکس در لایه زیرین، نه خود ابزار» توی اکوسیستم سلفهاست تکرار میشه؛ همون الگو رو توی حملههای Node و PHP هم دیدیم.
Q: پس بهتره بریم سراغ SaaS؟
بستگی داره. SaaS یعنی کسانی که شغلشون پچ کردن این باگهاست، مسئولیتش رو دارن. ولی یعنی دیتای CI و سورسکدتون روی سرور شخص ثالثه. برای تیمهای کوچیک بدون نفر DevOps اختصاصی، معمولاً SaaS انتخاب درستتری از یه GitLab نیمهرهاشدهست.
Q: از کجا بفهمم سرور من اصلاً در معرض بوده؟
Alpine هم نتوست مطمئن بشه — لاگها نشون دادن حمله تلاش شده ولی موفقیت قابل اثبات نبود. معیار عملی: نسخه GitLab و Rubyتون رو چک کنید؛ اگه در بازه آسیبپذیر بودید و سرور عمومی بود، فرض کنید تلاش شده و حداقل پسوردها و secretها رو بچرخونید.