خواندن ۸ دقیقه·۷ ماه پیش

بررسی درب پشتی xz-utils در لینوکس

در این مقاله قصد دارم درباره درب پشتی (Backdoor) که در سرورهای لینوکسی چند روز پیش خبر کشف شدنش منتشر شده بود صحبت کنم و همچنین نظرات خودم را پیرامون این موضوع نیز مطرح کنم.

توضیح کلی درباره درب پشتی xz-utils:

یک خبری در 28 مارس 2024 منتشر شد که شوکه‌کننده بود و آن هم این خبر بود که سیستم های لینوکسی میزبان یک درب پشتی خطرناک بودند و شناسه CVE-2024-3094 را به خودش اختصاص داد که میتوانست وضعیت وخیمی را برای سرورهای لینوکسی دارای سرویس SSH در کل دنیا ایجاد کند. این خبر به قدری مهم بود که در زمان کوتاهی سر و صدای زیادی ایجاد کرد. یک مهندس نرم افزار در شرکت مایکروسافت بصورت اتفاقی متوجه یک اختلال در سطح شبکه سیستم عامل میشه و با بررسی هایی که در ادامه انجام میده متوجه میشه یک درب پشتی در کتابخانه liblzma که در پکیج xz-utils در نسخه های خاصی وجود دارد در نهایت میتواند منجر به دسترسی به سرویس SSH گردد. در ادامه به جزئیات بیشتر این موضوع خواهیم پرداخت.

آشنایی با کتابخانه liblzma:

این کتابخانه توسط بسیاری از ابزارها در لینوکس، از جمله OpenSSH، برای فشرده‌سازی داده‌ها استفاده می‌شود. OpenSSH ابزاری برای برقراری ارتباط امن از طریق شبکه است که در همه‌ی سرورهای لینوکس استفاده می‌شود.کتابخانه liblzma در اصل جزو بسته نرم افزاری xz-utils است که هنگام نصب این بسته نرم افزاری ، نصب میشود. درب پشتی در اصل داخل این کتابخانه جاسازی شده بود. این درب پشتی به شیوه ماهرانه‌ای در کتابخانه liblzma قرار داده شده بود و حدود یک ماه بدون اینکه شناسایی بشه ، وجود داشت که باعث آلودگی نسخه های جدید بعضی از توزیع های لینوکسی شده است و این مدت زمان برای شناسایی نشدن درب پشتی یک فاجعه است.

عملکرد این درب پشتی به چه صورت است؟

کد مخرب درب پشتی در دو نسخه آخر بسته نرم افزاری XZ Utils (نسخه‌های 5.6.0 و 5.6.1) تزریق شده بود. این کد مخرب در حین فرآیند ساخت کتابخانه liblzma، یک فایل آبجکت از پیش ساخته شده را از یک فایل تست مخفی استخراج می‌کند و سپس برای تغییر توابع خاص در کد liblzma استفاده می‌شود. کتابخانه liblzma آلوده می‌تواند توسط هر نرم‌افزاری که به آن لینک شده است و از این کتابخانه بهره میبرد، مورد استفاده قرار بگیرد. این کتابخانه می‌تواند تعاملات داده‌ای با این کتابخانه را رهگیری و تغییر دهد و همچنین مهاجم (شخصی که اقدام به ایجاد درب پشتی کرده است) از یک کلید RSA خصوصی برای ایجاد تعامل با درب پشتی استفاده میکند تا بتواند به اهداف مختلف متصل شود.

این درب پشتی چگونه شناسایی شده است؟

جالب است این درب پشتی پس از یک ماه فعالیت خود ، بصورت اتفاقی شناسایی شده است. یک مهندس نرم افزار در مایکروسافت در حال کار برروی نسخه ناپایدار و ادج توزیع دبیان بوده است که به اصطلاح به این نسخه‌ها ، نسخه های Testing میگویند. این مهندس نرم افزار بصورت اتفاقی متوجه میشود که هنگام برقراری اتصال به سرویس SSH تغییراتی در میزان لود CPU و تاخیر زمانی 500 میلی ثانیه اتفاق میفتد.این تغییرات اونقدر کوچک هستند که کمتر کسی میتواند به این موضوع مشکوک شود و تقریبا همه افراد اینچنین موضوعات را به پای اختلالات اینترنتی و شبکه و ... میگذارند اما این مهندس نرم افزار شرکت مایکروسافت موضوع را پیگیری کرده و متوجه میشود یک درب پشتی در کتابخانه liblzma بسته نرم افزاری xz-utils وجود دارد. این مهندس نرم افزار باتوجه به احتمالاتی که میدهد اقدام به بررسی اجزای مختلف تشکیل دهنده سرویس SSH میکند و همچنین توزیع دبیان Testing را نیز مورد بررسی قرار میدهد چرا که این مشکل میتوانست از منشا خوده توزیع دبیان و یا کرنل لینوکس قرار گرفته برروی آن باشد.در نهایت با مقایسه بسته های نرم افزاری اجزای تشکیل دهنده سرویس SSH در نسخه Testing و Stable دبیان متوجه میشوند که کتابخانه liblzma در بسته نرم افزاری xz-utils دارای درب پشتی است. همچنین قابل ذکر است نسخه های جدید بسته نرم افزاری xz-utils که در واقع نسخه های 5.6.0 و 5.6.1 هستند این مشکل را دارند و بدلیل اینکه این نسخه ها هنوز وارد مخازن نسخه های Stable دبیان نشده بودند خوشبختانه فقط نسخه های Testing آلوده شده بودند. همچنین میتوان نتیجه گرفت این مشکل به توزیع دبیان مربوط نمیشود بلکه تمامی توزیع های لینوکسی که از بسته نرم افزاری xz-utils نسخه های 5.6.0 و 5.6.1 استفاده میکردند دارای این درب پشتی هستند که لیست آن توزیع ها را میتوانید مشاهده کنید:

اجزای تشکیل دهنده OpenSSH چه چیزهایی است؟

علاوه بر ux-utils که به آن اشاره کردیم و گفتیم که یکی از اجزای تشکیل دهنده سرویس OpenSSH است ، اجزای دیگر آن عبارتند از آیتم sshd که در واقع daemon برای سرویس SSH است که به اتصالات ورودی گوش میدهد و آنها را مدیریت میکند. آیتم ssh-keygen که برای ایجاد و مدیریت کلیدهای SSH استفاده می‌شود. آیتم ssh-copy-id که برای کپی کردن کلیدهای SSH به سرورهای دیگر استفاده می‌شود. آیتم openssl که برای رمزنگاری برای رمزنگاری ترافیک SSH استفاده می‌شود. آیتم PAM که برای احراز هویت کاربران SSH استفاده می‌شود.

هویت شخصی که درب پشتی را ایجاد کرده بود:

همه از سراسر دنیا حتی با وجود هرنوع وابستگی و عدم وابستگی به سرویس‌های جاسوسی دولت‌ها میتوانند در پروژه‌های متن باز (Open Source) نظیر لینوکس مشارکت داشته باشند و نقطه ضعف شدیدی که اینجا وجود دارد اینست که این افراد نیاز به وریفای و تایید هویت ندارند. شخص یا اشخاصی که این درب پشتی را در بسته نرم افزاری xz-utils قرار داده بودند مدت زمان 2 سال در کامیونیتی متن باز فعالیت داشتند و افراد جدیدی نبودند که امروز اکانت ایجاد کنند و فردا درب پشتی را وارد مخازن کنند. بنابراین این شخص یا اشخاص در حال حاضر مشخص نیست چه کسانی هستند چرا که تنها چیزی که از آن/آنها در دست است یک نام و یک آدرس ایمیل و یک کلید هستش که هیچکدوم از این موارد هویت یک شخص را مشخص نمیکنند. اما با توجه به پیچیدگی سناریوی بارگذاری درب پشتی و زمانی که برای جلب اعتماد کامیونیتی صرف شده است، افراد مختلفی معتقدن که اینکار میتواند توسط یک دولت انجام شده باشد که البته دور از منطق هم نیست و میتواند استنباط درستی باشد.

نکات امنیتی:

بعد از اینکه با عملکرد درب پشتی فوق آشنا شدیم میخوام در این قسمت پایانی یکسری مواردی رو مطرح کنم که میتوان از نتایج اینچنین تحقیقات امنیتی برداشت کرد و همچنین نظرات متخصصین امنیت و مدیران سیستم نیز بوده است که جا داره بیشتر به این موارد دقت شود. این موارد رو بصورت عناوین کوتاه در ادامه مطرح میکنم که درک آنها نیز ساده‌تر باشد:

اولین پارامتر در تامین امنیت و امن نگهداشتن یک سیستم اینست که تا حد امکان بصورت Minimal استفاده شود.هرچقدر سیستم سبک‌تر باشد دامنه آسیب پذیری های آن نیز کمتر است و بازدهی سیستم نیز بالاتر است.
این تفکر اشتباه است که چون پروژه های متن باز در دسترس عموم هستند بنابراین باگ هاش سریع‌تر برطرف میشوند و امنیت بالاتری دارند. اینکه باگ هاش سریع تر برطرف میشوند تفکر درستی است اما پروژه های متن باز الزاما دارای امنیت بالایی نیستند و این موضوع در ابعاد مختلف میتواند بررسی شود. همانطور که رفع شدن باگ های پروژه های متن باز میتواند سریع‌تر اتفاق بیفتد در مقابل نیز آلوده کردن آنها توسط طیف گسترده‌ای از افراد نیز میتواند با زحمت نه چندان زیادی انجام شود. پس راه چاره چیست؟
بروز بودن سیستم عامل و بسته های نرم افزاری در دنیای لینوکس نباید با عجله و شور و ذوق همراه باشد. درب پشتی زیر میتواند نمونه واضح برای مثال این موضوع باشد که پایداری و امن نگهداشتن بسته های نرم افزاری اهمیت بالاتری نسبت به بروز بودن آنها دارد بخصوص در محیط‌های پروداکشن.
سرویس های مهم یک سرور ترجیحا نباید در معرض عموم باشند (هرچند دارای مکانیزم های احرازهویت باشند). بازهم درب پشتی فوق میتواند مثال خوبی برای این موضوع باشد چرا که اگر سرویس SSH سرور شما پشت یک فایروال باشد و یا دسترسی محدودی برای یکسری شبکه های خاص داشته باشد مهاجم قادر به برقراری ارتباط با سرور آلوده شده نخواهد بود.
بحث های مربوط به هاردنینگ و امن سازی در سیستم‌ها و سامانه های لینوکسی بسیار بسیار دارای اهمیت بالایی هستند چرا که این سیستم ها ذاتا امنیت کافی ندارند. امن سازی این سیستم ها نباید بصورت یک مرحله و یکباره اتفاق بیفتد و بعدش رها شود. این سیستمها نیاز بیشتری دارند تا مانیتورینگ امنیتی شوند و امن نگهداشته شوند. هرکدام از این موضوعات بحث های طولانی و جداگانه دارد.
و کلی نکات دیگری که بایستی هنگام استقرار یک سیستم و بکارگیری آن در محیط پروداکشن بایستی مورد توجه واقع شوند.

تشخیص سیستم آلوده به این درب پشتی:

برای اینکه مطمئن بشیم سرور و یا سیستم ما به این درب پشتی آلوده نشده است خوشبختانه به راحتی میتوان این بررسی را انجام داد و فقط کافیست با کانسپت کلی عملکرد این درب پشتی آشنایی داشته باشیم. برای نمونه میتوان از اسکریپت Bash زیر استفاده کرد:

#! /bin/bash
set -eu
# find path to liblzma used by sshd
path=&quot$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')&quot
# does it even exist?
if [ &quot$path&quot == &quot&quot ]
then
       echo probably not vulnerable
exit
fi
# check for function signature
if hexdump -ve '1/1 &quot%.2x&quot' &quot$path&quot | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
then
       echo probably vulnerable
else
        echo probably not vulnerable
fi
exit

این اسکریپت ابتدا میاد مسیر کتابخانه liblzma را که توسط سرویس ssh استفاده میشود را پیدا میکند و سپس با استفاده از hexdump برای نمایش محتوای hexadecimal فایل liblzma استفاده میکند و به دنبال یک hexadecimal خاص مرتبط با این درب پشتی میگردد و در نهایت بر اساس نتایج موجود میتواند اعلام کند که سیستم و یا سرور ما به این درب پشتی آلوده شده است یا خیر.

منابع:

NVD - CVE-2024-3094 (nist.gov)

Threat Brief: XZ Utils Vulnerability (CVE-2024-3094) (paloaltonetworks.com)

CVE-2024-3094: malicious code in Linux distributions | Kaspersky official blog

CVE-2024-3094 (debian.org)

CVE-2024-3094 | Ubuntu

access.redhat.com/security/cve/CVE-2024-3094

Disclosed backdoor in xz releases - FreeBSD not affected

xz utils liblzma بک‌دور بکدور ssh xz backdoor

کیوان

مهندس امنیت شبکه

شاید از این پست‌ها خوشتان بیاید