اصلاح چندین آسیب پذیری در Jenkins

زمان مطالعه: 11 دقیقه

فرض کنید که قراره روی یه پروژه ی نرم افزاری، چندین برنامه نویس بصورت آنلاین و هماهنگ با هم کار کنن. اگه این برنامه نویس ها بصورت جداگانه روی این پروژه کار کنن، ایجاد این هماهنگی سخت میشه، همچنین پروژه ممکنه با کلی باگ روبرو بشه که برای اصلاح همین باگ ها ، کلی زمان نیاز باشه. در این شرایط هست که پای ابزارهایی مانند Jenkins میاد وسط.

Jenkins که در ابتدا باعنوان Hudson توسعه داده شده بود، یه سرور اتوماسیون متن بازه که با جاوا توسعه داده شده و برای ساخت ، استقرار و خودکارسازی پروژه های نرم افزاری استفاده میشه. این ابزار یکی از راهکارهای مورد استفاده در حوزه ی DevOps برای اجرای CI/CD هستش.

سهم 44 درصدی اون در سال 2023، نشون دهنده محبوبیت این ابزاره. با توجه به ماهیت و محبوبیت ابزار، وجود آسیب پذیری در اون، میتونه تاثیر بالقوه ای داشته باشه.

اخیرا جنکینز ، در بولتن امنیتیش، اعلام کرده که یسری آسیب پذیری رو در خود ابزار جنکنیز و پلاگین های اون اصلاح کرده که یه موردش بحرانی ، 6 موردش شدت بالا، 4 مورد شدت متوسط و یه مورد هم شدت پایین گزارش شده.

 

آسیب پذیری CVE-2024-23897 :

جنکینز دارای ویژگی CLI هستش که امکان دسترسی به جنکینز رو از طریق محیط Shell یا اسکریپت نویسی میده.

جنکینز هنگام پردازش دستورات CLI از کتابخونه ی args4j برای تجزیه ی آرگومانها و گزینه های خط فرمان روی Jenkins controller استفاده میکنه. این کتابخونه دارای یه ویژگی هستش که اگه یه آرگومانی دارای کاراکتر @ و بعدش یه مسیر فایل باشه، کتابخونه ، محتوای فایل رو جایگزین میکنه. مثلا اگه ما دستور زیر رو بهش بدیم :

 

 

و محتوای file.txt برابر myARG باشه، قبل از اجرا دستور بصورت زیر درمیاد :

 

 

کاربرد این روش زمانی هستش که شما بخوایید یسری از آرگومانها رو از طریق یه فایل به خط فرمان پاس بدید.

این ویژگی بصورت پیش فرض در نسخه های آسیب پذیر فعاله و در نتیجه مهاجم میتونه از اونا برای خوندن محتوای فایل های دلخواه مثلا etc/passwd/ سوء استفاده کنه.

آسیب پذیری شدت بحرانی داره . مهاجم احرازهویت شده که پرمیشن Overall/Read داره، میتونه کل محتوای یه فایل بخونه اما مهاجم راه دور و بدون احرازهویت، که پرمیشن Overall/Read رو نداره،  امکان خوندن چند خط اول یه فایل دلخواه روی سرور رو داره . تعداد خطوطی که مهاجم میتونه بخونه، بستگی به دستور CLI داره اما توسعه دهندگان جنکینز گفتن که تو یه نسخه ی پیش فرض و بدون هیچ پلاگینی، نهایتا تونستن سه خط اول یه فایل بخونن و پلاگینی هم پیدا نکردن که منجر به خوندن بیشتر این سه خط بشه.

خود آسیب پذیری بعنوان Arbitrary file read گزارش شده، اما در برخی شرایط امکان اجرای کد رو هم میده. جنکینز چند تا بردار حمله برای اجرای کد و سناریوهای دیگه منتشر کرده.

• اجرای کد از طریق Resource Root URL (نمونه اول)
  • عملکرد Resource Root URL فعال باشه.
  • نقطه پایانی CLI WebSocket در دسترس باشه. این زمانی رخ میده که جنکینز روی Jetty اجرا بشه تا از WebSockets پشتیبانی کنه. این گزینه هم زمانی رخ میده که جنکینز از طریق نصب کننده های بومی ، پکیجها یا کانتینرهای داکر و یا دستور java -jar jenkins.war اجرا بشه.
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم بتونه به نام کاربری که پرمیشن Overall/Read داره دسترسی داشته باشه یا اونو حدس بزنه.

 

• اجرای کد از طریق Resource Root URL (نمونه دوم)
  • عملکرد Resource Root URL فعال باشه.
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم به API token یه اکانت کاربری دسترسی داشته باشه، مهم نیست این کاربر پرمیشن Overall/Read داره یا نه، فقط باید ناشناس نباشه (non-anonymous) .

 

• اجرای کد از طریق کوکی های Remember me :
• مهاجم میتونه با جعل کوکی Remember me با استفاده از یه مرورگر وارد جنکینز بشه و اگه این کوکی برای ادمین باشه، میتونه به Script Console دسترسی داشته باشه. برای اکسپلویت از این طریق ، همه ی شرایط زیر باید برقرار باشه:
  • ویژگی Remember me فعال باشه که البته بصورت پیش فرض فعاله.
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم باید پرمیشن Overall/Read داشته باشه تا بتونه همه ی فایل رو بخونه.

 

• اجرای کد از طریق XSS ذخیره شده در Build logها :
• مهاجم از طریق حملات XSS و تزریق جاوااسکریپت و HTML به Build logها ، امکان اجرای کد داره. آسیب پذیری یه جورایی آسیب پذیری CVE-2017-2607 رو دور میزنه. برای این منظور باید همه ی شرایط زیر برقرار باشه :
  • مهاجم به Build logها دسترسی داشته باشه مثلا از طریق pull requests
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.

 

• اجرای کد از طریق دور زدن محافظ های CSRF :
• مهاجم از طریق ارسال درخواست POST با یه توکن جعلی CSRF (crumbs) ، از طریق حملات CSRF میتونه کد دلخواه اجرا کنه. برای این روش هم شرایط زیر نیاز هست :
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • web session ID قسمتی از CSRF crumbs نیست. البته بطور پیش فرض نیازه مگه اینکه :
    • جنکینز از default crumb issuer استفاده کنه و مقدار hudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID روی True تنظیم شده باشه.
    • جنکینز از پلاگین Strict Crumb Issuer برای تولید crumbs  استفاده کنه و گزینه ی Check the session ID تیک نداشته باشه.

 

• رمزگشایی اطلاعات حساس ذخیره شده در جنکینز:
• جنکینز برای اینکه بتونه به ارائه دهندگان ابری ، SCM و … دسترسی داشته باشه، از یسری اطلاعات حساس ذخیره شده ، استفاده میکنه. برای اینکه مهاجم به این اطلاعات دسترسی داشته باشه، باید موارد زیر برقرار باشه:
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم بتونه به این اطلاعات حساس رمز شده ، دسترسی داشته باشه. برای اینکار نیاز به پرمیشن Overall/Read داره تا بتونه همه ی فایل رو بخونه. البته به غیر از اینا، منابع احتمالی دیگه هم هست که هکر میتونه بهش دسترسی پیدا کنه از جمله : بکآپ های JENKINS_HOME یا پیکربندی در قالب فایل YAML

 

• حذف هر چیزی در جنکینز :
• برای استفاده از آسیب پذیری برای حذف هر مورد در جنکینز باید شرایط زیر برقرار باشه:
  • قابلیت Resource Root URL فعال باشه.
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم بتونه نام کاربری که دارای پرمیشن Overall/Read هست، دسترسی داشته باشه، یا اونو حدس بزنه.

 

• دانلود یه دامپ Java heap از پروسس Jenkins controller یا هر پروسس agent دیگه :
  • قابلیت Resource Root URL فعال باشه.
  • مهاجم بتونه فایلهای باینری با اطلاعات حساس رو بازیابی کنه.
  • مهاجم بتونه نام کاربری که دارای پرمیشن Overall/Read هست، دسترسی داشته باشه، یا اونو حدس بزنه.
  • پروسس agent و Jenkins controller که روی Java runtime اجرا میشن، امکان ایجاد فایلهای heap dump رو بدون پسوند hprof. میدن. اما با توجه به JENKINS-72579 بصورت پیش فرض روی نسخه های اخیر OpenJDK/HotSpot مبتنی بر JVM کار نمیکنن.

 

در حالیکه فایلهای دارای محتوای باینری قابل خوندنه، مولفه ی آسیب پذیر تلاش میکنه تا از طریق انکدینگ پیش فرض پروسس کنترلر، اونارو بصورت رشته بخونه . این کار باعث میشه که برخی از بایتها بدرستی خونده نشه و بجاش مقدار placeholder (کاراکترهای ناخوانا) قرار بگیره. اینکه حالا کدوم بایتها خونده میشن یا نمیشن، بستگی به انکدینگ کارکترها داره. مثلا اگه از UTF-8 استفاده بشه، تقریبا نیمی از داده های باینری با مقدار placeholder جایگزین میشن. برای باینری های 32 بیتی که در جنکینز برای HMAC-SHA256 استفاده میشن، مهاجم باید بطور میانگین 16 بایت رو حدس بزنه که این کار تقریبا غیرممکنه. در انکدینگ Windows-1252 فقط 5 کاراکتر از 256 کاراکتر با placeholder جایگزین میشه.

براساس تله متری که جنکیز داره، نسخه های 2.467 به بعد ، حدود 90 درصدش از UTF-8 استفاده میکنن. تقریبا همه ی نمونه هایی که روی لینوکس و مک استفاده میکنن از UTF-8 استفاده میکنن . اما مواردی که روی ویندوز نصب شدن، غالبا از انکدینگی استفاده میکنن که کار اکسپلویت رو ساده تر میکنن مثلا از Windows-1252 استفاده میکنن.

برای اینکه بدونید از کدوم انکدینگ استفاده می کنید، در قسمت Manage Jenkins > System Information مقدار file.encoding رو بررسی کنید.

البته خود جنکینز توصیه کرده که بی خیال اینا بشید و جنکینز رو بروزرسانی کنید.

اگه نمیتونید به هر دلیلی جنکینز رو بروزرسانی کنید، میتونید یسری راه حل های کاهشی طبق این راهنما انجام بدید.

نسخه های تحت تاثیر :

• Jenkins weekly up to and including 2.441
• Jenkins LTS up to and including 2.426.2

نسخه های اصلاح شده :

• Jenkins weekly  2.442
• Jenkins LTS  2.426.3

 

 

آسیب پذیری CVE-2024-23898 :

از نسخه ی Jenkins 2.217 و LTS 2.222.1 یکی از راههای ارتباط با CLI از طریق نقطه پایانی WebSocket هست. این نقطه پایانی به احرازهویت پیش فرض درخواستهای جنکینز مانند احرازهویت HTTP Basic از طریق API Token یا کوکی های جلسه ، متکی هست. این نقطه پایانی وقتی که جنکینز روی Jetty اجرا بشه تا از WebSockets پشتیبانی کنه، فعال میشه. این هم زمانی رخ میده که جنکینز از طریق نصب کننده های بومی ، پکیجها یا کانتینرهای داکر و یا دستور java -jar jenkins.war اجرا بشه.

نسخه های آسیب پذیر ، مبدا (origin) درخواستها از نقطه پایانی CLI WebSocket رو اعتبارسنجی نمیکنن، در نتیجه منجر به رخ دادن آسیب پذیری cross-site WebSocket hijacking (CSWSH) میشن. همچنین جنکینز ویژگی SameSite رو برای کوکی ها تنظیم نمیکنه. این باعث میشه که درخواستهای بین سایتی ، از کوکی های جلسه استفاده کنن، یعنی این درخواستها، با احرازهویت کاربری که لاگین کرده، ارسال میشن.

آسیب پذیری Cross-site WebSocket hijacking که با عنوان cross-origin WebSocket hijacking هم شناخته میشه، یه آسیب پذیری CSRF هست که روی WebSocket handshake رخ میده. آسیب پذیری زمانی رخ میده که درخواست WebSocket handshake ، برای مدیریت جلسه ، صرفا از کوکی های HTTP استفاده میکنه ، بدون استفاده از توکن های CSRF یا مقادیری که قابل حدس زدن نباشن. تفاوتش با CSRF معمولی اینه که مهاجم تعامل دو طرف با برنامه آسیب پذیر داره. مهاجم با این نوع آسیب پذیری میتونه دو تا کار انجام بده :

• میتونه کارهای غیرمجاز رو بعنوان قربانی انجام بده.
• میتونه اطلاعات حساسی که کاربر بهش دسترسی داره رو بدست بیاره.

در مرورگرهای Google Chrome و Microsoft Edge اگه ویژگی SameSite تنظیم نشده باشه، این مرورگرها بصورت پیش فرض اونو بصورت Lax در نظر میگیرن. این باعث میشه که هیچ کوکی جلسه ای با درخواستهای بین سایتی به نقطه پایانی WebSocket ارسال نشه و در نتیجه منجر به این میشه که از CLI بعنوان یه کاربر ناشناس بشه استفاده کرد (امن میشه) . فایرفاکس چنین گزینه ای رو داره، اما بصورت پیش فرض غیرفعاله.

در کل با این آسیب پذیری ، مهاجم میتونه دستورات CLI رو ، روی کنترلر جنکینز اجرا کنه. تاثیر این حمله بستگی به پرمیشنی که مهاجم داره و/یا مرورگر مورد استفاده ی، قربانی حملات CSWSH داره:

• اگه کاربر ناشناس، هیچ پرمیشنی نداشته باشه و مرورگر قربانی از ویژگی SameSite Lax بصورت پیش فرض استفاده کنه :
  • در این صورت مهاجم فقط میتونه دستور who-am-i رو اجرا کنه و یسری اطلاعات در خصوص کاربر ناشناس بدست بیاره. این آسیب پذیری رو میشه با آسیب پذیری قبلی ، CVE-2024-23897 ، زنجیر کرد و چند خط اول فایلها رو خوند.

 

• کاربر ناشناس دارای پرمیشن هست :
  • این حالت زمانی رخ میده که تیک Anyone can do anything زده بشه یا ادمین یسری پرمیشن برای این کاربر تعریف کنه. در این صورت مهاجم بسته به پرمیشنی که برای این کاربر تعرف شده میتونه کارهای مختلفی انجام بده. حداکثر کاری هم که میتونه انجام بده، اینه که میتونه به قابلیت برنامه نویسی Groovy دسترسی داشته باشه و ازش برای اجرای کد دلخواه استفاده کنه. این آسیب پذیری رو میشه با آسیب پذیری قبلی ، CVE-2024-23897 ، زنجیر کرد و محتوای همه ی فایلها رو خوند.

 

• کاربرای جنکینز از مرورگرهایی استفاده میکنن که ویژگی SameSite Lax بصورت پیش فرض تعریف نشده:
  • کوکی Remember me و/یا جلسه از طریق درخواستهای بین سایتی ارسال میشه و کاربر میتونه احرازهویت کنه.  مهاجم میتونه دستورات CLI رو بسته به پرمیشن های قربانی اجرا کنه. حداکثر کاری هم که میتونه انجام بده، اینه که میتونه به قابلیت برنامه نویسی Groovy دسترسی داشته باشه و ازش برای اجرای کد دلخواه استفاده کنه.

 

اگه نمیتونید به هر دلیلی ، جنکینز رو بروزرسانی کنید، میتونید از طریق این راهنما ، یسری اقدامات موقت انجام بدید.

نسخه های تحت تاثیر :

• Jenkins weekly up to and including 2.441
• Jenkins LTS up to and including 2.426.2

نسخه های اصلاح شده :

• Jenkins weekly  2.442
• Jenkins LTS  2.426.3

 

آسیب پذیری CVE-2024-23899 :

آسیب پذیری در پلاگین Git server و از نوع Arbitrary file read و دارای شدت بالاست. این پلاگین هم از کتابخونه ی args4j برای تجزیه ی آرگومانها و گزینه های دستورات Git که از طریق SSH به کنترلر جنکینز ارسال میشه، استفاده میکنه. مهاجمی که دارای پرمیشن Overall/Read هست، امکان خوندن دو خط اول فایل دلخواه رو با استفاده از انکدینگ کاراکتر پیش فرص کنترلر جنکینز داره. برای جزییات بیشتر میتونید آسیب پذیری CVE-2024-23897 رو بررسی کنید.

اگه نمیتونید به هر دلیلی جنکینز رو بروزرسانی کنید، یکی از راهکارهای موقت اینه که از طریق Manage Jenkins > Security مطمئن بشید که تنظیمات SSHD Port در قسمت SSH Server ، غیرفعاله. با این کار دسترسی به مخازن Git که توسط جنکینز و Jenkins CLI میزبانی میشن، از طریق SSH غیرفعال میشه.

نسخه تحت تاثیر:

• Git server Plugin up to and including 99.va_0826a_b_cdfa_d

نسخه اصلاح شده:

• Git server Plugin 99.101.v720e86326c09

 

آسیب پذیری CVE-2024-23900 :

آسیب پذیری در پلاگین Matrix Project و از نوع Path traversal و دارای شدت متوسط هست. آسیب پذیری بدلیل عدم پاکسازی نام محورهای تعریف شده توسط کاربر در پروژه های multi-configuration که از طریق config.xml REST API ارسال میشن، رخ میده.

مهاجمی که دارای پرمیشن Item/Configure باشه، میتونه هر فایل config.xml رو در سیستم فایل کنترلر جنکینز با محتوایی که توسط مهاجمان قابل کنترل نیست، ایجاد یا جایگزین کنه.

نسخه های تحت تاثیر:

Matrix Project Plugin up to and including 822.v01b_8c85d16d2

نسخه های اصلاح شده :

Matrix Project Plugin 822.824.v14451b_c0fd42

 

آسیب پذیری CVE-2024-23901 :

آسیب پذیری در پلاگین GitLab Branch Source هست و شدت متوسط داره. GitLab امکان اشتراک پروژه با گروه های دیگه رو میده. نسخه ی آسیب پذیر این پلاگین، امکان مشاهده پروژه هایی که با owner group پیکربندی شده به اشتراک گذاشته میشن رو میده.

مهاجم میتونه یه پروژه رو ایجاد و به اشتراک بزاره، در نتیجه میتونه یه Pipeline مخرب بعد از اسکن پروژه های گروه ،توسط جنکینز ساخته بشه.

نسخه های تحت تاثیر:

GitLab Branch Source Plugin up to and including 684.vea_fa_7c1e2fe3

نسخه های اصلاح شده:

GitLab Branch Source Plugin 688.v5fa_356ee8520

 

آسیب پذیری CVE-2024-23902 :

آسیب پذیری در پلاگین GitLab Branch Source و از نوع CSRF و دارای شدت متوسط هست. نسخه های آسیب پذیر این پلاگین، به درخواست های POST به یه نقطه پایانی، اعتبارسنجی فرم رو انجام نمیده ، که منجر به آسیب پذیری CSRF میشه.

مهاجم میتونه از این آسیب پذیری ، برای اتصال به یه URL که توسط مهاجم مشخص شده، استفاده کنه.

نسخه های تحت تاثیر:

GitLab Branch Source Plugin up to and including 684.vea_fa_7c1e2fe3

نسخه های اصلاح شده:

GitLab Branch Source Plugin 688.v5fa_356ee8520

 

آسیب پذیری CVE-2024-23903 :

آسیب پذیری در پلاگین GitLab Branch Source و دارای شدت پایین هست. نسخه های آسیب پذیر این پلاگین از یه تابع مقایسه constant-time برای بررسی اینکه آیا توکن های webhook ارائه شده و مورد انتظار برابر هستن، استفاده نمیکنن، در نتیجه مهاجم میتونه ، توکن های webhook معتبر بدست بیاره.

نسخه های تحت تاثیر:

GitLab Branch Source Plugin up to and including 684.vea_fa_7c1e2fe3

نسخه های اصلاح شده:

GitLab Branch Source Plugin 688.v5fa_356ee8520

 

آسیب پذیری CVE-2023-6148 :

آسیب پذیری در پلاگین Qualys Policy Compliance Scanning Connector و از نوع Stored XSS و شدت بالا داره. نسخه های آسیب پذیر این پلاگین، پاسخ های Qualys API که در صفحه ی پیکربندی کار نمایش داده میشن رو بدرستی مدیریت نمیکنن، در نتیجه مهاجمی که بتونه کارها رو پیکربندی کنه، میتونه حمله ی Stored XSS انجام بده.

نسخه های تحت تاثیر:

Qualys Policy Compliance Scanning Connector Plugin up to and including 1.0.5

نسخه های اصلاح شده:

Qualys Policy Compliance Scanning Connector Plugin  1.0.6

 

آسیب پذیری CVE-2023-6147 :

آسیب پذیری در پلاگین Qualys Policy Compliance Scanning Connector و از نوع XXE هست و شدت بالا داره.

نسخه های تحت تاثیر:

Qualys Policy Compliance Scanning Connector Plugin up to and including 1.0.5

نسخه اصلاح شده:

Qualys Policy Compliance Scanning Connector Plugin 1.0.6

 

آسیب پذیری SECURITY-3007 :

آسیب پذیری در زمان نگارش این پست ، CVE نگرفته، اما آسیب پذیری در پلاگین Qualys Policy Compliance Scanning Connector و از نوع Incorrect permission هست و شدت متوسط داره. نسخه های آسیب پذیر این پلاگین، در چندین نقطه پایانی HTTP ، پرمیشن ها رو بدرستی بررسی نمیکنن. در نتیجه مهاجمی که دارای پرمیشن Item/Configure هست، میتونه با اعتبارنامه هایی که از روش های دیگه بدست آورده، به یه URL که توسط مهاجم مشخص میشه، متصل بشه و اعتبارنامه های ذخیره شده در جنکینز رو بدست بیاره.

نسخه های تحت تاثیر:

Qualys Policy Compliance Scanning Connector Plugin up to and including 1.0.5

نسخه اصلاح شده:

Qualys Policy Compliance Scanning Connector Plugin 1.0.6

 

آسیب پذیری CVE-2024-23905 :

آسیب پذیری در پلاگین Red Hat Dependency Analytics هست و شدت بالا داره. جنکینز هدر Content-Security-Policy رو روی یسری فایل ثابت که توسط جنکینز ارائه میشن، مثلا workspaces ، userContent یا موارد ذخیره شده، تنظیم میکنه، مگه اینکه Resource Root URL مشخص شده باشه. نسخه های آسیب پذیر این پلاگین، این هدر رو برای فایلهای ثابت که در فرایند نصب Invoke Red Hat Dependency Analytics (RHDA) توسط جنکینز اجرا میشن، غیر فعال میکنه. در نتیجه کاربری که امکان مدیریت فایل در workspaces  و … داره، میتونه حملات XSS انجام بده.

اگه Resource Root URL پیکربندی شده باشه، تحت تاثیر حمله نیست.

نسخه های تحت تاثیر:

Red Hat Dependency Analytics Plugin up to and including 0.7.1

نسخه اصلاح شده:

Red Hat Dependency Analytics Plugin 0.9.0

 

آسیب پذیری CVE-2024-23904 :

آسیب پذیری در پلاگین Log Command و از نوع Arbitrary file read هست و شدت بالا داره. این پلاگین هم چون از کتابخونه ی args4j برای تجزیه آرگومانها و گزینه های خط فرمان که از پلتفرمهای پیامرسانی مانند IRC  و Jabber میاد، استفاده میکنه، تحت تاثیر آسیب پذیری هست. مهاجم بدون احرازهویت، امکان خوندن خط اول هر فایل دلخواه رو داره.

نسخه های تحت تاثیر:

Log Command Plugin up to and including 1.0.2

نسخه اصلاح شده:

در زمان نگارش این پست، اصلاحیه ای برای این آسیب پذیری منتشر نشده.

 

منبع