آدرس ایمیل خصوصیای که GitLab برای ثبت Issue از طریق ایمیل در اختیار شما قرار میدهد، در عمل یک اعتبارنامه (Credential) محسوب میشود. هر کسی که به این آدرس دسترسی پیدا کند، میتواند یک Patch را از طریق ایمیل ارسال کند و GitLab آن را با نام شما، روی هر Branchای که شما مجوز Push کردن به آن را دارید ــ حتی main ــ Commit کند. همچنین، در شرایطی میتواند Jobهای CI/CD را با سطح دسترسی شما اجرا کند.
گیتلب این آدرس را برای هر کاربر پشت دکمهای با عنوان «Email work item to this project» نمایش میدهد. ایمیلی که به این آدرس ارسال شود، در پروژه مربوطه یک Issue ایجاد میکند و نویسنده آن نیز شما خواهید بود.
رشتهای که در بخش میانی این آدرس قرار دارد، یک Token وابسته به حساب کاربری است و طبق مستندات GitLab، منقضی نمیشود.
ممکن است این آدرس در ظاهر متعلق به یک پروژه خاص به نظر برسد، اما در واقع چنین نیست. شرکت Aikido Security که این رفتار را گزارش کرده، متوجه شده است آدرسهایی که GitLab برای پروژههای مختلف یک کاربر ایجاد میکند، همگی یک Token یکسان دارند. این Token برای تمام پروژههایی که آن حساب میتواند به آنها دسترسی داشته باشد ــ چه عمومی و چه خصوصی ــ معتبر است.
GitLab بررسی نمیکند که ایمیل را چه کسی ارسال کرده است. هر صندوق ایمیلی میتواند به این آدرس پیام بفرستد و GitLab با آن پیام طوری رفتار میکند که گویی از طرف خود شما ارسال شده است. بنابراین، هر کسی که این آدرس را در اختیار داشته باشد، میتواند بدون دسترسی به صندوق ایمیل شما، عملا با استفاده از مجوزهای شما اقداماتی انجام دهد.
این آدرس فقط برای ثبت Bug نیست
آیکیدو نشان داده است که میتوان از همین آدرس برای Commit کردن کد نیز استفاده کرد؛ آن هم با بهرهگیری از قابلیت داخلی GitLab برای ایجاد Merge Request از طریق ایمیل:
- پسوند آدرس را از
-issueبه-merge-requestتغییر دهید. در این حالت GitLab بهجای Issue، یک Merge Request ایجاد میکند. - یک Patch آماده کنید و نام Branch مقصد را در خط Subject ایمیل قرار دهید.
- Patch را به ایمیل پیوست کرده و ارسال کنید. GitLab Patch را روی Branch موردنظر اعمال میکند و اگر آن Branch از قبل وجود نداشته باشد، آن را ایجاد میکند.
- تغییرات بهصورت یک Commit روی آن Branch ثبت میشوند و نویسنده Commit، شما خواهید بود. اگر آن Branch قابل Push شدن توسط شما باشد، این موضوع شامل
mainنیز میشود. - اگر Patch فایل
.gitlab-ci.ymlپروژه را تغییر دهد و نقش کاربری شما اجازه اجرای چنین کاری را بدهد، گیتلب Job مهاجم را با سطح دسترسی شما اجرا میکند.
خود Merge Request را نمیتوان به یک کپی از پروژه که مهاجم مالک آن است هدایت کرد؛ به همین دلیل، در این روش کد مخرب داخل Patch پیوست شده قرار میگیرد، نه داخل Merge Request.
چه چیزهایی شدت حمله را محدود میکند؟
دو عامل باعث میشوند دامنه این مشکل محدودتر باشد.
نخست اینکه Token فقط مجوزهای خود کاربر را در اختیار مهاجم قرار میدهد. بنابراین میزان دسترسی مهاجم به نقش کاربر بستگی دارد. برای مثال، یک آدرس لو رفته متعلق به حسابی با نقش Guest تقریبا کاربرد چندانی ندارد، در حالی که آدرس مربوط به یک Maintainer میتواند امکان دسترسی به Branchهای محافظتشده و Secretهای CI/CD را فراهم کند.
دوم اینکه برای دسترسی به یک پروژه، داشتن خود آدرس ایمیل کافی نیست. GitLab مقصد را با استفاده از مسیر پروژه (Project Path) و شناسه عددی پروژه (Project ID) مشخص میکند. بنابراین مهاجمی که بخواهد یک پروژه خاص را هدف قرار دهد، علاوه بر Token به Path و ID آن پروژه نیز نیاز دارد.
در پروژههای عمومی، هر دو مورد قابل رویت هستند. در مورد پروژههای خصوصی، مهاجم به یک اطلاعات جداگانه نیاز دارد که مشخص کند پروژه موردنظر کدام است؛ هرچند Project IDهای GitLab بهراحتی قابل حدس زدن هستند.
دور زدن محدودیت IP
یکی دیگر از مشکلات این است که ایمیلهای ورودی از محدودیتهای IP مستثنا هستند. در نتیجه حمله میتواند از خارج از IP Allowlist انجام شود. مستندات GitLab نیز تصریح میکند که ایمیلهای ورودی مشمول محدودیتهای IP نیستند.
Aikido یک پروژه خصوصی را طوری پیکربندی کرد که فقط یک IP مشخص ــ که متعلق به خود Aikido نبود ــ اجازه دسترسی داشته باشد. GitLab دسترسی مرورگر را مسدود کرد و اجازه git clone نداد، اما ایمیل حاوی Merge Request را پذیرفت و در نهایت Commit روی برنچ main قرار گرفت.
دور زدن احراز هویت دومرحلهای (2FA)
همین مسیر همچنین میتواند احراز هویت دومرحلهای را دور بزند.
طبق مستندات GitLab، قابلیتهای مربوط به ایمیلهای ورودی حتی در شرایطی که 2FA اجباری باشد، بدون نیاز به 2FA کار میکنند.
بنابراین فعال بودن 2FA بهتنهایی مانع سواستفاده از این Token ایمیلی نمیشود.
چه حسابهایی تحت تأثیر هستند؟
هر حساب GitLab.com یک Token از این نوع دارد. همینطور هر نمونه Self-Managed GitLab که قابلیت ایمیل ورودی در آن فعال باشد، چنین Tokenی دارد؛ این قابلیت در GitLab.com بهصورت پیشفرض فعال است.
به نظر نمیرسد GitLab Dedicated تحت تاثیر قرار گرفته باشد، زیرا GitLab این قابلیت را به GitLab.com و نسخههای Self-Managed محدود کرده است. البته Aikido گفته است که نتوانسته مستقیما GitLab Dedicated را آزمایش کند.
چه کار باید کرد؟
نمیتوانید این قابلیت را بهطور کلی از دیگران بگیرید، اما اگر آدرس شما افشا شده باشد، میتوانید آن را باطل و Token مربوطه را بازنشانی کنید.
- از صفحه Personal Access Tokens در پروفایل خود، Incoming Email Token را Reset کنید. با Reset کردن، آدرس مربوط به تمام پروژهها بهطور همزمان تغییر میکند. بنابراین اگر در حال حاضر از یکی از این آدرسها استفاده میکنید، آدرس قبلی از کار میافتد و باید آدرس جدید را در اختیار کاربران قرار دهید.
- در READMEها، راهنمای مشارکت (Contributing Guide) و صفحات پشتیبانی خود جستوجو کنید تا ببینید آیا این آدرس ایمیل جایی منتشر شده است یا نه. Aikido گفته است حدود ۱۲ آدرس فعال را از همین طریق پیدا کرده؛ بیشتر آنها عمدا برای دریافت گزارش Bug منتشر شده بودند و تعدادی نیز در پروژههای متنباز پرکاربرد قرار داشتند.
- در یک نمونه Self-Managed، مدیر سیستم میتواند قابلیت Incoming Email را برای کل Instance غیرفعال کند. با این حال، تنظیمی وجود ندارد که یک کاربر بتواند بهصورت شخصی، ایجاد Issue یا Merge Request از طریق ایمیل را برای حساب خودش غیرفعال کند.
GitLab چه تغییری داده است؟
GitLab پس از گزارش Aikido، متن توضیحات مربوط به Token را تغییر داد.
اکنون توضیحات میگویند این آدرس میتواند Issue و Merge Request ایجاد کند؛ در حالی که قبلا فقط به ایجاد Work Item اشاره میشد. GitLab همچنین جملهای را حذف کرده که میگفت این Token نمیتواند برای دسترسی به دادههای دیگر مورد استفاده قرار گیرد.
اما رفتار فنی سیستم تغییری نکرده است.
Token همچنان منقضی نمیشود، GitLab همچنان فرستنده ایمیل را بررسی نمیکند و همچنان هیچ گزینهای وجود ندارد که یک کاربر بتواند این قابلیت را فقط برای حساب خودش خاموش کند.
GitLab همچنین یک Issue برای بررسی این موضوع باز کرده است که آیا میتوان ایمیلهای ورودی را فقط از آدرسی که روی حساب مالک تایید شده است پذیرفت یا نه. اما این راهکار هنوز در دست بررسی است و اجرا نشده است.
Aikido گفته است که نخستین بار در ماه مه ۲۰۲۶ این رفتار را از طریق HackerOne گزارش کرد، اما گزارش بهعنوان رفتار مورد انتظار سیستم بسته شد. سپس در ژوئن، یک گزارش محرمانه برای GitLab ارسال کرد.
بر اساس توضیح Aikido از موضع GitLab، این Token نیز مانند هر Credential دیگری در نظر گرفته میشود و اگر یک Credential افشا شود، پیامدهای ناشی از آن افشا اجتنابناپذیر خواهد بود.
منبع: https://thehackernews.com/۲۰۲۶/۰۹/a-leaked-gitlab-issue-email-address.html
