gitlab-critical-zero

آسیب‌پذیری بحرانی در GitLab؛ هکرها بدون احراز هویت به پروژه‌ها دسترسی دارند

یک آسیب‌پذیری امنیت سایبری با درجه بحرانی در GitLab CE/EE می‌تواند به مهاجمی از راه دور که هیچ حساب کاربری یا اطلاعات ورودی ندارد، اجازه دهد تا با بهره‌برداری از قابلیت GraphQL این پلتفرم، پروژه‌ها و داده‌های کاربران قابل‌دسترس عموم را دستکاری یا حذف کند.

این باگ که با شناسه CVE-۲۰۲۶-۱۹۴۷۸ ثبت شده است، یک نقص تزریق کد (Code Injection) است و یکی از دو آسیب‌پذیری است که این پروژه در این هفته افشا کرده است. GitLab از سازمان‌هایی که از نسخه‌های خودمدیریتی (Self-Managed) این پلتفرم توسعه نرم‌افزار و DevOps استفاده می‌کنند، خواسته است که فوراً به نسخه‌های جدید منتشرشده در روز دوشنبه ارتقا پیدا کنند، اما وصله‌گذاری به‌تنهایی خطر را برای شرکت‌ها و سایر کاربرانی که پروژه‌های خود را در این پلتفرم مدیریت می‌کنند، از بین نمی‌برد.


دو مشکل پیش از احراز هویت در GitLab

GitLab به این آسیب‌پذیری بحرانی امتیاز CVSS ۹.۴ از ۱۰ را اختصاص داده است، زیرا برای بهره‌برداری از آن نیازی به احراز هویت یا تعامل کاربر نیست و تأثیر بالایی بر یکپارچگی و در دسترس بودن داده‌ها دارد. این باگ تمام نسخه‌های GitLab Community Edition/Enterprise Edition (CE/EE) از نسخه ۱۸.۲ تا ۱۸.۱۱.۱۱، ۱۹.۰ تا ۱۹.۰.۸، ۱۹.۱ تا ۱۹.۱.۶ و ۱۹.۲ تا ۱۹.۲.۴ را تحت تأثیر قرار می‌دهد.

آسیب‌پذیری دیگر با شدت کمتر، با شناسه CVE-۲۰۲۶-۱۹۶۵۰، یک مشکل جعل درخواست بین‌سایتی (CSRF) در کنترل‌کننده پرس‌وجوی GraphQL چندگانه GitLab است. این مشکل می‌تواند به مهاجمی بدون احراز هویت اجازه دهد تا با استفاده از درخواست‌های GET ساخته‌شده، تغییرات غیرمجاز ایجاد کند. این باگ نسخه‌های مشابهی از GitLab CE/EE را تحت تأثیر قرار می‌دهد و امتیاز CVSS آن ۷.۱ است.

GitLabسازمان‌هایی که از سرویس‌های مدیریت‌شده GitLab مانند GitLab.com یا GitLab Dedicated استفاده می‌کنند، نیازی به اقدامی ندارند زیرا این محیط‌ها قبلاً وصله‌گذاری شده‌اند. اما کاربران نسخه‌های خودمدیریتی باید فوراً به نسخه‌های جدید ۱۹.۲.۴، ۱۹.۱.۶، ۱۹.۰.۸ و ۱۸.۱۱.۱۱ برای GitLab CE و EE ارتقا پیدا کنند.

به‌روزرسانی امنیتی خارج از نوبت GitLab جزئیات فنی آسیب‌پذیری‌ها را افشا نکرده است که این موضوع مطابق با سیاست این شرکت مبنی بر عدم انتشار چنین اطلاعاتی تا ۹۰ روز پس از انتشار وصله است و این می‌تواند برای تشخیص بهره‌برداری‌ها مشکل‌ساز باشد.


چالش‌های کاهش خطر بدون جزئیات فنی

اگرچه عدم شفافیت، تشخیص اینکه آیا محیط سازمان به خطر افتاده است را دشوارتر می‌کند، اما تیم‌های امنیت سایبری می‌توانند اقداماتی برای کاهش ریسک انجام دهند. جیکوب کرل، مدیر ارشد راه‌حل‌های هوش مصنوعی و امنیت سایبری در Suzu Labs، می‌گوید: «شما نمی‌توانید یک امضای تشخیصی قابل‌اعتماد برای مکانیسم‌های حمله‌ای که هنوز افشا نشده‌اند، بنویسید.»

او توصیه می‌کند که تیم‌ها باید بر حفظ لاگ‌های GraphQL، API، پروکسی معکوس و ممیزی GitLab تمرکز کنند و به دنبال درخواست‌های غیرعادی به /api/graphql باشند، به‌ویژه آنهایی که با حذف پروژه، تغییرات پیکربندی یا اصلاحات داده‌های کاربر همراه هستند.

کرل توصیه می‌کند: «لاگ GraphQL در GitLab رشته‌های پرس‌وجو و متغیرها را ثبت می‌کند، بنابراین برای دستورالعمل‌ها یا فعالیت‌های جهش غیرعادی به آنجا نگاه کنید.» او اضافه می‌کند که تمرکز بر مهار (Containment) به‌جای تحقیق، تا زمانی که جزئیات فنی کامل در دسترس قرار گیرد، منطقی است.

کرل می‌گوید سازمان‌هایی که دارای نمونه‌های GitLab متصل به اینترنت یا نقاط پایانی GraphQL قابل‌دسترس از خارج هستند، باید در اولویت به نسخه‌های وصله‌شده نرم‌افزار ارتقا پیدا کنند. این واقعیت که GitLab تنها چند روز پس از انتشار وصله برنامه‌ریزی‌شده در ۱۲ آگوست، یک به‌روزرسانی خارج از نوبت منتشر کرده است، نشان‌دهنده جدیتی است که این شرکت برای تهدید ناشی از آسیب‌پذیری‌های جدید قائل است.

کرل می‌گوید: «وقتی یک فروشنده به‌سرعت یک به‌روزرسانی خارج از نوبت منتشر می‌کند، آن را به‌عنوان یک سیگنال شدت علاوه بر امتیاز CVSS در نظر بگیرید.» با این حال، سازمان‌هایی که روی نسخه‌های ۱۸.۲ تا ۱۸.۱۰ گیر کرده‌اند، ممکن است مسیر ارتقای دشوارتری داشته باشند، زیرا این شاخه‌ها وصله‌ای دریافت نکرده‌اند و باید به یک شاخه ثابت پشتیبانی‌شده منتقل شوند.


چالش‌های دفاعی در GraphQL

توصیه اضطراری GitLab همچنین بر GraphQL تأکید دارد؛ رابطی که از طریق آن یک مهاجم بدون احراز هویت می‌تواند از CVE-۲۰۲۶-۱۹۴۷۸ بهره‌برداری کند. GraphQL فناوری است که به برنامه‌های وب اجازه می‌دهد تا از طریق یک رابط منعطف، داده‌های ذخیره‌شده روی سرور را درخواست و اصلاح کنند.

نوئل موراتا، مدیر ارشد عملیات در XCape، می‌گوید: «نقاط قوت طراحی GraphQL دقیقاً همان چیزی است که دفاع از آن را دشوار می‌کند. همه چیز از طریق یک نقطه پایانی عبور می‌کند، بنابراین قوانین WAF مبتنی بر مسیر نمی‌توانند عملیات خطرناک را بدون غیرفعال کردن کل API ایزوله کنند.» از آنجا که بسیاری از عملیات‌ها از یک رابط مشترک استفاده می‌کنند، یک نقص امنیتی واحد می‌تواند به طور بالقوه بسیاری از عملکردها را تحت تأثیر قرار دهد. در عین حال، تشخیص فعالیت‌های قانونی از مخرب می‌تواند دشوار باشد، به‌ویژه زمانی که فروشنده دقیقاً مشخص نکرده که به دنبال چه چیزی بگردند.

سیمانت سگال، مدیرعامل و هم‌بنیانگذار BreachLock، می‌گوید: «بدون جزئیات فنی کامل از GitLab، مدافعان با اطلاعات ناقص کار می‌کنند که موقعیت ناراحت‌کننده‌ای است.» او توصیه می‌کند که سازمان‌ها باید به دنبال ناهنجاری‌ها در لاگ‌های API GraphQL باشند و به‌طور خاص به درخواست‌های بدون احراز هویت که به نقاط پایانی داده‌های پروژه یا کاربران به روش‌هایی که با الگوهای ترافیک عادی مطابقت ندارند، توجه کنند.

سگال می‌گوید: «تغییرات غیرمنتظره در تنظیمات پروژه، حذف‌ها یا تغییرات در سوابق کاربران بدون جلسه احراز هویت‌شده مربوطه، ارزش بررسی دارند. فعالیت عادی خود را اکنون Baseline کنید، زیرا مقایسه همان چیزی است که ناهنجاری‌ها را قابل‌مشاهده می‌کند.»

همچنین ببینید

SSDهای نسل جدید وارد بازار می‌شوند؛ سرعت ذخیره‌سازی به کجا می‌رسد؟

سال‌هاست سرعت SSDها با هر نسل جدید رابط PCIe افزایش پیدا می‌کند؛ اما در سال …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *