تحقیقات اخیر پژوهشگران Aikido Security نشان می‌دهد که قابلیت «Email work item to this project» در GitLab می‌تواند به ابزاری برای به خطر انداختن مخازن (Repositories) تبدیل شود، به‌ویژه زمانی که آدرس خصوصی مربوط به این قابلیت فاش گردد.
مکانیزم حمله و تحلیل فنی
این آدرس حاوی یک توکن glimt-incoming-email با طول عمر زیاد است که طبق مستندات GitLab، منقضی نمی‌شود و باید محرمانه باقی بماند. هر کسی که به این توکن دسترسی داشته باشد، می‌تواند از طرف مالک توکن، Issueها و Merge Requestها ایجاد کند.
نکته بحرانی اینجاست که اگرچه رابط کاربری یک آدرس خاص برای هر پروژه نمایش می‌دهد، اما توکن‌های تولید شده برای پروژه‌های مختلف، در واقع یک توکن واحد در سطح حساب کاربری (Account-level token) هستند. یک مهاجم می‌تواند با تغییر پسوند -issue به -merge-request، یک Git patch را ضمیمه کرده و در موضوع ایمیل، شاخه (Branch) مبدأ را مشخص کند. در این حالت، GitLab پچ مذکور را با مجوزهای کاربر قربانی روی آن شاخه اعمال می‌کند.
پیامدهای امنیتی و دور زدن کنترل‌ها
- اجرای کد در CI/CD: با تغییر فایل
.gitlab-ci.yml، مهاجم می‌تواند کدهای تحت کنترل خود را در Pipeline پروژه اجرا کرده و به متغیرهای CI/CD، توکن‌های Job یا سایر اسرار (Secrets) دسترسی یابد. - تغییر در شاخه‌های محافظت‌شده: در صورتی که آدرس یک کاربر با سطح دسترسی Maintainer فاش شود، مهاجم می‌تواند مستقیماً روی شاخه‌های محافظت‌شده (مانند main) Commit ارسال کند.
- دور زدن محدودیت‌های IP: تحقیقات نشان می‌دهد که مسیرهای ایمیلی GitLab محدودیت‌های IP را نادیده می‌گیرند. حتی اگر یک پروژه خصوصی تنها برای یک IP خاص پیکربندی شده باشد، GitLab همچنان پچ‌های ارسالی از طریق ایمیل را می‌پذیرد.
پیش‌نیازهای بهره‌برداری
برای اجرای این حمله، مهاجم به آدرس خصوصی ایمیل و اطلاعات مسیریابی پروژه (مانند Project ID و Path) نیاز دارد. در مخازن عمومی این اطلاعات در دسترس هستند، اما برای پروژه‌های خصوصی، مهاجم باید ابتدا از طریق یک نشت اطلاعاتی دیگر به این جزئیات دست یابد. همچنین، به دلیل عدم نیاز به تایید ایمیل فرستنده، Spoofing ایمیل در این فرآیند لازم نیست.
توصیه‌های امنیتی برای مدیران SOC و مهندسان
با توجه به اینکه GitLab این رفتار را به عنوان «طراحی سیستم» (Designed behavior) تلقی کرده و تنها مستندات را به‌روزرسانی نموده است، تیم‌های امنیتی باید اقدامات زیر را انجام دهند:
- جستجوی فعال در لاگ‌ها، تیکت‌ها و مستندات برای یافتن آدرس‌های
glimt-. - در صورت مشاهده هرگونه نشت، توکن ایمیل ورودی را از بخش تنظیمات Personal Access Token بازنشانی (Reset) کنید.
- بازبینی دقیق مجوزهای کاربران، قوانین Protected Branch و متغیرهای Pipeline.
- در نظر گرفتن آدرس‌های ایمیلی پروژه به عنوان یک Credential حساس و نه یک آدرس تماس ساده.
