یک نقص امنیتی در مکانیزم توکن‌های ایمیل ورودی (Incoming Email Tokens) در GitLab کشف شده است که به مهاجمان اجازه می‌دهد با سوءاستفاده از این توکن‌ها، کدهای مخرب را به شاخه‌های اصلی (Main Branch) ارسال کرده و خط لوله‌های CI/CD را اجرا کنند.
جزئیات فنی مکانیزم حمله
در GitLab، ویژگی «Email work item» به کاربران اجازه می‌دهد تا از طریق ایمیل، Issue ایجاد کنند. این سیستم از یک توکن داخلی استفاده می‌کند که در آدرس ایمیل پروژه جاسازی شده است. محققان امنیتی شرکت Aikido دریافتند که این توکن‌ها برخلاف تصور، محدود به یک پروژه خاص نیستند، بلکه مانند یک Fine-grained Access Token برای کل حساب کاربری عمل می‌کنند و تاریخ انقضا ندارند.
اگر این توکن از طریق یک پروژه عمومی (Public)، فایل README یا مستندات لو رود، مهاجم می‌تواند از آن برای دسترسی به سایر پروژه‌های خصوصی (Private) که کاربر مذکور به آن‌ها دسترسی دارد، استفاده کند.
زنجیره حمله و دور زدن محدودیت‌ها
- تغییر مسیر درخواست: مهاجم با تغییر پسوند
-issueبه-merge-requestدر آدرس ایمیل، می‌تواند درخواست‌های Merge Request ارسال کند. - تزریق کد: با ارسال یک فایل Patch گیت در ایمیل، مهاجم می‌تواند کد را به یک Branch خاص ارسال کند. اگر کاربر هدف دسترسی Maintainer یا Owner داشته باشد، این کد مستقیماً وارد شاخه Main می‌شود.
- اجرای CI/CD: در صورتی که مهاجم بتواند فایل
.gitlab-ci.ymlرا تغییر دهد، می‌تواند Jobهای دلخواه خود را در محیط CI/CD اجرا کرده و به متغیرهای حساس (Secrets) یا توکن‌های محیطی دسترسی پیدا کند.
دور زدن محدودیت‌های IP
یکی از نقاط بحرانی این آسیب‌پذیری این است که ایمیل‌های ورودی به GitLab از کنترل‌های IP Restrictions مستثنی هستند. این بدان معناست که حتی اگر سازمان‌ها لیست سفید (Allowlist) برای IPها تعریف کرده باشند، مهاجم می‌تواند از طریق ایمیل این محدودیت‌ها را دور زده و تغییرات را در مخازن اعمال کند.
توصیه‌های امنیتی
سازمان‌ها باید آدرس‌های ایمیل ورودی GitLab را به عنوان اطلاعات حساس (Sensitive Information) در نظر بگیرند و از افشای آن‌ها در محیط‌های عمومی یا مستندات جلوگیری کنند. با توجه به اینکه این توکن‌ها منقضی نمی‌شوند، مدیریت دسترسی‌های کاربران و نظارت بر Merge Requestهای مشکوک ضروری است.
