یک نقص امنیتی در نحوه مدیریت آدرس‌های ایمیل اختصاصی در GitLab کشف شده است که به مهاجمان اجازه می‌دهد با داشتن این آدرس، کدهایی را به نام کاربر ارسال کرده و عملیات CI/CD را اجرا کنند. این آدرس‌ها که برای ثبت Issueها از طریق ایمیل ایجاد می‌شوند، در واقع به عنوان یک Credential عمل می‌کنند.
مکانیسم حمله و توکن‌های دائمی
هر کاربر در GitLab آدرسی دارد که در بخش “Email work item to this project” نمایش داده می‌شود. در مرکز این آدرس، یک توکن (Token) قرار دارد که به حساب کاربر متصل است. طبق مستندات GitLab، این توکن‌ها تاریخ انقضا ندارند. نکته بحرانی این است که این توکن برای تمامی پروژه‌هایی که کاربر به آن‌ها دسترسی دارد (چه عمومی و چه خصوصی) یکسان است.
دور زدن مکانیزم‌های امنیتی
تحقیقات تیم Aikido Security نشان می‌دهد که GitLab هویت فرستنده ایمیل را بررسی نمی‌کند. هر کسی که این آدرس را در اختیار داشته باشد، می‌تواند از طریق قابلیت Merge Request via Email، کدهای مخرب را مستقیماً به شاخه‌های مورد نظر (از جمله Main) ارسال کند. این روش منجر به موارد زیر می‌شود:
- دور زدن 2FA: قابلیت‌های مربوط به ایمیل ورودی، حتی در نمونه‌هایی که احراز هویت دو مرحله‌ای (2FA) اجباری دارند، بدون نیاز به آن عمل می‌کنند.
- دور زدن محدودیت‌های IP: ایمیل‌های ورودی از محدودیت‌های IP Allowlist مستثنی هستند و مهاجم می‌تواند از هر کجا به پروژه دسترسی پیدا کند.
تاثیرات و سطح دسترسی
میزان آسیب‌پذیری به نقش (Role) کاربر بستگی دارد. اگر آدرس ایمیل یک کاربر با دسترسی Guest لو شود، تاثیر آن اندک است، اما در مورد کاربرانی با نقش Maintainer، مهاجم می‌تواند به شاخه‌های محافظت‌شده (Protected Branches) و اسرار CI/CD (Secrets) دسترسی پیدا کند.
پاسخ GitLab و وضعیت فعلی
GitLab در ابتدا این رفتار را به عنوان «عملکرد مورد انتظار» (Intended Behavior) تلقی کرده بود و استدلال می‌کرد که این آدرس مانند هر Credential دیگری است و افشای آن منجر به پیامدهای منفی می‌شود. با این حال، در حال حاضر بررسی‌هایی برای پذیرش ایمیل‌ها تنها از آدرس‌های تایید شده (Verified) در جریان است، اما هنوز هیچ راهکاری برای غیرفعال کردن این قابلیت توسط کاربر ارائه نشده است.
