Red Hat، بیست و هشتم مارس ۲۰۲۴ یک هشدار امنیتی فوری را منتشر کرد و اعلام نمود که دو نسخه از یک کتابخانه فشرده سازی داده محبوب به نام XZ Utils (LZMA Utils سابق) حاوی کد مخرب جهت دسترسی غیرمجاز از راه دور طراحی شده است.
XZ Utils مجموعه‌ای است که به طور گسترده در سیستم های سازگار با POSIX مانند لینوکس و یونیکس برای پردازش فایل‌های xz. از جمله کامپوننت‌هایی مانند liblzma و xz استفاده می‌شود که در مخازن توزیع مانند Debian، Ubuntu و Centos ادغام شده‌اند.
امروز در این پست می‌خواهیم با استناد به مقاله securelist به مطالعه دقیق‌تر این آسیب پذیری بپردازیم.
خطر خاص کتابخانه بکدور شده در استفاده از آن توسط فرآیند سرور OpenSSH sshd نهفته است. OpenSSH در چندین توزیع مبتنی بر سیستم، از جمله لینوکس Ubuntu، Debian و RedHat/Fedora، برای استفاده از ویژگی‌های systemd وصله شده است و در نتیجه به این کتابخانه وابستگی دارد (توجه داشته باشید که Arch Linux و Gentoo تحت تأثیر قرار نگرفته‌اند). هدف نهایی مهاجمان به احتمال زیاد معرفی یک قابلیت اجرای کد از راه دور برای sshd می‌باشد که هیچ کس دیگری نمی توانست از آن استفاده کند.
برخلاف سایر حملات زنجیره تامین که در Node.js، PyPI، FDroid و کرنل لینوکس مشاهده شده است که عمدتاً شامل وصله‌های مخرب و بسته‌های جعلی بودند، این رویداد یک عملیات چند مرحله‌ای بود که تقریباً موفق شد سرورهای SSH را در مقیاس جهانی به خطر بیندازد.
بکدور در کتابخانه liblzma در دو سطح معرفی شد. کد منبع زیرساخت که بسته‌های نهایی را تولید می‌کند کمی تغییر یافت (با معرفی یک فایل اضافی build-to-host.m4) تا اسکریپت مرحله بعدی را که در یک فایل آزمایشی پنهان شده بود (bad-3-corrupt_lzma2.xz) استخراج کند.
این اسکریپت ها به نوبه خود یک کامپوننت باینری مخرب را از یک فایل آزمایشی دیگر (good-large_compressed.lzma) استخراج کردند که در طول فرآیند کامپایل با کتابخانه قانونی مرتبط شده بود تا به مخازن لینوکس ارسال شود. فروشندگان بزرگ به نوبه خود کامپوننت مخرب را در نسخه های بتا و آزمایشی ارسال کردند. حمله به زنجیره تامین نرم افزار که با شناسه CVE-2024-3094 دنبال می شود، دارای امتیاز CVSS 10.0 می‌باشد که نشان دهنده حداکثر شدت آسیب پذیری است. این بکدور XZ Utils نسخه 5.6.0 (منتشر شده در بیست و چهارم فوریه) و 5.6.1 (منتشر شده در نهم مارس) را تحت تأثیر قرار می دهد.
جدول زمانی رویدادها
۱۹/۰۱/۲۰۲۴ – وب سایت XZ توسط jiaT75 به صفحات GitHub منتقل گردید.
۱۵/۰۲/۲۰۲۴ – ” build-to-host.m4 ” به gitignore. اضافه شد.
۲۳/۰۲/۲۰۲۴ – دو «فایل آزمایشی» که حاوی مراحل اسکریپت مخرب بودند معرفی شدند.
۲۴/۰۲/۲۰۲۴ – XZ 5.6.0 منتشر گردید.
۲۶/۰۲/۲۰۲۴ – در CMakeLists.txt انجام می‌شود که ویژگی امنیتی Landlock را تخریب می‌کند.
۰۵/۰۳/۲۰۲۴ – بکدور منجر به مشکلاتی با Valgrind می‌شود.
۰۹/۰۳/۲۰۲۴ – دو «فایل آزمایشی» به روزرسانی و عملکردهای CRC اصلاح شدند، مشکل ” Valgrind ” نیز برطرف گردید.
۰۹/۰۳/۲۰۲۴ – XZ 5.6.1 منتشر شد.
۲۸/۰۳/۲۰۲۴ – باگ کشف گردید و Debian و RedHat مطلع شدند.
۲۸/۰۳/۲۰۲۴ – Debian، XZ 5.6.1 را به نسخه 5.4.5-0.2 بازگرداند.
۲۹/۰۳/۲۰۲۴ – یک ایمیل در لیست پستی OSS-security منتشر گردید.
۲۹/۰۳/۲۰۲۴ – RedHat تایید کرد که بکدور XZ در Fedora Rawhide و Fedora Linux 40 beta ارسال شده است.
۳۰/۰۳/۲۰۲۴ – Debian، build ها را خاموش کرده و فرآیند بازسازی آن را آغاز می‌کند.
۰۲/۰۴/۲۰۲۴ – توسعه دهنده اصلی XZ، بکدور را تشخیص داد.
توزیع‌های منبع بکدور
xz-5.6.0
MD5 | |
SHA1 | e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b |
SHA256 | 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875 |
xz-5.6.1
MD5 | |
SHA1 | 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7 |
SHA256 | 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8 |
تجزیه و تحلیل اولیه نفوذ
مخزن git متعلق به XZ ، شامل مجموعه‌ای از فایل‌های آزمایشی است که هنگام آزمایش کد کمپرسور/دیکمپرسور برای بررسی درستی کارکرد آن استفاده می‌شود. حساب کاربری به نام Jia Tan یا ” jiaT75″ دو فایل آزمایشی را متعهد شد که در ابتدا بی ضرر به نظر می‌رسیدند، اما به عنوان راه انداز برای استقرار بکدور عمل می‌کردند. فایل های مرتبط عبارت بودند از:
- bad-3-corrupt_lzma2.xz (86fc2c94f8fa3938e3261d0b9eb4836be289f8ae)
- good-large_compressed.lzma (50941ad9fd99db6fca5debc3c89b3e899a9527d7)
این فایل‌ها حاوی اسکریپت‌های shell و آبجکت باینری بکدور بودند. با این حال، آنها در داخل داده های نادرست پنهان بودند و مهاجم می‌دانست که چگونه آنها را در صورت نیاز به درستی استخراج کند.
مرحله 1 – اسکریپت build-to-host اصلاح شده
هنگامی که نسخه XZ آماده شد، مخزن رسمی Github، فایل‌های منبع پروژه را توزیع کرد. در ابتدا، این نسخه‌ها در مخزن، جدا از اینکه حاوی فایل‌های آزمایشی مخرب بودند، بی‌ضرر نیز بودند، چرا که فرصت اجرا نداشتند. با این حال، به نظر می‌رسد که مهاجم، تنها زمانی که نسخه‌ها از https://xz[.]tukaani.org که تحت کنترل Jia Tan بودند، منبع کدهای مخربی را که فرآیند نفوذ را راه‌اندازی می‌کند، اضافه کرده است.
این URL توسط اکثر توزیع‌ها استفاده می‌شود و هنگام دانلود، فایلی به نام build-to-host.m4 که حاوی کدهای مخرب است ارائه میدهد.
build-to-host.m4 (c86c8f8a69c07fbec8dd650c6604bf0c9876261f) در طول فرآیند build اجرا می‌شود و خطی از کد را اجرا می‌کند که اولین فایل اضافه شده به فولدر tests را اصلاح و از حالت فشرده خارج می‌کند:
این خط کد با استفاده از دستور tr، داده‌های «شکسته یا broken» از bad-3-corrupt_lzma2.xz را جایگزین می‌کند و خروجی را به دستور xz -d منتقل نموده که داده‌ها را از حالت فشرده خارج می‌کند. داده‌های فشرده شده حاوی یک اسکریپت shell است که بعداً با استفاده از /bin/bash اجرا می‌گردد که توسط آن، فایل m4. راه‌اندازی می‌شود.
مرحله ۲ – اسکریپت shell تزریق شده
اسکریپت مخرب تزریق شده توسط فایل مخرب m4. تأیید می‌کند که در یک ماشین لینوکس در حال اجرا است و همچنین در فرآیند build مورد نظر اجرا می‌شود.
اسکریپت مخرب برای اجرای مرحله بعدی، از good-large_compressed.lzma استفاده می‌کند که در واقع به درستی با XZ فشرده شده است، اما حاوی داده های ناخواسته در داخل داده‌های غیرفشرده است.
روش حذف داده‌های ناخواسته به این صورت است که head pipeline توسط تابع eval اجرا می‌شود و با هر فرمانِ head، 1024 بایت بعدی را نادیده می‌گیرد و یا 2048 یا 724 بایت بعدی را استخراج می‌کند.
در مجموع، این دستورات 33492 بایت (2048*16 + 724 بایت) استخراج می‌کنند؛ سپس دستور tail ، ۳۱،۲۶۵ بایت نهایی فایل را حفظ کرده و بقیه را نادیده می‌گیرد.
دستور tr پس از آن، یک جایگزین اساسی برای خروجی اعمال می‌کند تا آن را از حذف نماید. فرمان دوم XZ، بایت های تبدیل شده را به عنوان یک جریان خام lzma از حالت فشرده خارج می‌کند و پس از آن نتیجه به shell منتقل می‌شود.
مرحله ۳ – استخراج بکدور
آخرین مرحله اسکریپت shell، بررسی‌های زیادی را انجام میدهد تا از اجرای آن در محیط مورد انتظار اطمینان حاصل کند، مانند اینکه آیا پروژه برای استفاده از IFUNC پیکربندی شده است یا خیر (که در بخش های بعدی مورد بحث قرار خواهد گرفت).
بسیاری از بررسی‌های دیگر انجام شده توسط این مرحله شامل تعیین این است که آیا GCC برای کامپایل استفاده می‌شود یا اینکه پروژه حاوی فایل های خاصی است که بعداً توسط اسکریپت استفاده خواهد شد.
کد باینری در این مرحله، بکدور را استخراج می‌کند. یک فایل آبجکت که در حال حاضر در همان فایل good-large_compressed.lzma پنهان است، اما با یک آفست متفاوت. کد زیر این کار را انجام میدهد:
فرآیند استخراج از طریق دنباله‌ای از دستورات عمل می‌کند و نتیجه هر دستور به عنوان ورودی برای دستور بعدی می‌باشد. کد تک خطی فرمت شده در زیر نشان داده شده است:
فایل good-large_compressed.lzma در ابتدا با استفاده از خود ابزار XZ استخراج می‌شود. مراحل بعدی شامل فراخوانی زنجیره‌ای از فراخوانی‌های head با تابع ” eval $i” (همان مرحله 3 استخراج) است. سپس یک الگوریتم سفارشی مانند RC4 برای رمزگشایی داده‌های باینری استفاده می‌شود که حاوی فایل فشرده دیگری است. این فایل فشرده نیز با استفاده از ابزار XZ استخراج می‌گردد. سپس اسکریپت با استفاده از مقادیر از پیش تعریف شده، تعدادی بایت را از ابتدای داده های فشرده شده حذف می‌کند و نتیجه را به عنوان liblzma_la-crc64-fast.o در دیسک ذخیره خواهد کرد که فایل بکدور مورد استفاده در فرآیند پیوند داده شده است.
در نهایت، اسکریپت، تابع is_arch_extension_supported از فایل crc_x86_clmul.h در liblzma را تغییر میدهد تا فراخوانی تابع get_cpuid__ را با _get_cpuid جایگزین کند و یک کاراکتر زیر خط را حذف نماید.
این اصلاح به آن اجازه میدهد تا به کتابخانه، پیوند داده شود (در بخش بعدی در مورد جزئیات بیشتر بحث خواهیم کرد). کل زنجیره نفوذ build را می توان در طرح زیر خلاصه کرد:
تجزیه و تحلیل باینری بکدور
یک سناریوی بارگذاری مخفیانه
دو تابع ویژه در کد XZ اصلی، برای محاسبه CRC دیتاهای داده شده وجود دارد: lzma_crc32 و lzma_crc64. هر دوی این توابع در جدول symbol های ELF با نوع IFUNC ذخیره می‌شوند که یک ویژگی ارائه شده توسط کتابخانه GNU C (GLIBC) است. IFUNCبه توسعه دهندگان اجازه میدهد تا به صورت پویا عملکرد صحیح را برای استفاده انتخاب کنند. این انتخاب زمانی انجام می‌شود که پیوند دهنده پویا (dynamic linker)، کتابخانه مشترک را بارگیری کند.
دلیل اینکه XZ از این مورد استفاده می‌کند این است که اجازه میدهد تا تعیین کنیم که آیا یک نسخه بهینه از تابع lzma_crcX باید استفاده شود یا خیر. نسخه بهینه سازی شده به ویژگی‌های خاص پردازنده‌های مدرن (CLMUL، SSSE3، SSE4.1) نیاز دارد.
این ویژگی‌های خاص می‌بایست با صدور دستورالعمل cpuid تأیید شوند، که با استفاده ازget_cpuid wrapper/intrinsic__ ا رائه شده توسط GLIBC نامگذاری می‌شوند و در این مرحله است که بکدور برای بارگیری خود از مزیت مورد نظر استفاده می‌کند.
بکدور به عنوان یک فایل آبجکت ذخیره می‌شود و هدف اصلی آن، این است که در طول کامپایل به فایل اجرایی اصلی پیوند داده شود. فایل آبجکت حاوی symbolی به نام get_cpuid_ است، زیرا اسکریپت‌های shell تزریق شده یک علامت زیر خط را از کد منبع اصلی حذف می‌کنند، به این معنا که وقتی کد get_cpuid_ را فرا می‌خواند، در واقع نسخه بکدور آن را فراخوانی می‌کند.
تجزیه و تحلیل کد بکدور
کد بکدور اولیه دو بار فراخوانی می‌شود، زیرا هر دو lzma_crc32 و lzma_crc64 از یک تابع تغییر یافته استفاده می‌کنند (get_cpuid_). یک شمارنده ساده برای اطمینان از کنترل این مورد، ایجاد می‌شود تا تأیید کند که کد قبلاً اجرا شده است. فعالیت مخرب واقعی زمانی آغاز می‌شود که lzma_crc64 IFUNC، get_cpuid_ را فراخوانی می‌کند، مقدار شمارنده 1 را می‌بیند که نشان میدهد آن تابع قبلاً دسترسی داشته است، و یک مرحله نهایی را برای تغییر مسیر به نقطه ورودی واقعی این بدافزار آغاز خواهد کرد.
بکدور برای مقداردهی اولیه کد مخرب، ابتدا چند ساختار را که اطلاعات اصلی در مورد فرآیند در حال اجرا فعلی را نگه می‌دارند، مقداردهی می‌کند. بکدور در درجه اول، آدرس جدول آفست جهانی (GOT) را با استفاده از آفست های کدگذاری شده مشخص می کند و از این اطلاعات برای یافتن نشانگر cpuid در داخل آن استفاده می نماید.
GOT شامل افست symbol ها، از جمله پوشش cpuid است. بکدور سپس، پوینترها را به تابع بدافزار اصلی تغییر میدهد و آن را طوری فراخوانی می‌کند که انگار در حال فراخوانی cpuid است.
رفتار اصلی
هدف اصلی بکدور این است که توابع خاصی را با موفقیت هوک (hook) کند که به آن اجازه میدهد هر اتصال به دستگاه آلوده را نظارت نماید. توابع هدف عبارتند از:
تابع | شرح |
RSA_public_decrypt | توسط libcrypto برای رمزگشایی یک متن رمزنگاری و امضاء شده توسط یک کلید خصوصی استفاده می شود |
EVP_PKEY_set1_RSA | توسط libcrypto برای تنظیم کلید RSA یک محتوای خاص استفاده می شود |
RSA_get0_key | توسط libcrypto برای بازیابی یک کلید RSA استفاده می شود |
با این حال، هوک کردن تمام این توابع برای بکدور، کار ساده ای نیست. این شامل دسترسی به بسیاری از ساختارهای داخلی و دستکاری ساختارهای خاص فرآیند تا رسیدن به هدف است و همچنین باید تا حد امکان مخفی باشد، به این معنا که کد مخرب حاوی چندین بررسی است تا از تجزیه و تحلیل جلوگیری کند.
بررسی محیط اجرا
بکدور ابتدا ld-linux (پیوند دهنده پویا) را تجزیه (pars) می‌کند که در درجه اول مسئول resolve پویای آدرس‌های symbol در حافظه است. بکدور همچنین اطلاعات مختلفی را در خصوص محیط، استخراج و تأیید می‌کند تا تعیین کند که آیا فرآیند فعلی که بکدور در آن در حال اجرا است با معیارهای اجرای آن مطابقت دارد یا خیر. این بررسی ها عبارتند از:
- بررسی می‌کند که آیا فرآیند فعلی /usr/bin/sshd است یا خیر.
- بررسی می‌کند که آیا کلید kill وجود دارد یا خیر.
بکدور، نام فرآیند فعلی را از argv[0] استخراج می‌کند و همچنین تمام متغیرهای محیط فرآیند را تجزیه (pars) می‌کند تا ببیند آیا هر یک از آنها در جدول رشته داخلی آن وجود دارند یا خیر. اگر مطابقتی وجود داشته باشد، یا فرآیند sshd نباشد، بدافزار اجرای آن را متوقف خواهد کرد.
تنها متغیر داخل جدول yolAbejyiejuvnup=Evjtgvsh5okmkAvj است که در این زمینه به عنوان سوئیچ kill عمل می‌کند.
ساختار Trie
یکی از ویژگی های متمایز بکدور استفاده از یک ساختار Trie واحد برای عملیات رشته است. به جای مقایسه مستقیم رشته ها یا استفاده از هش رشته به منظور مطابقت با یک ثابت خاص (مثلاً نام یک تابع کتابخانه)، کد، یک جستجوی آزمایشی انجام میدهد و بررسی می‌کند که آیا نتیجه با یک عدد ثابت مشخص برابر است یا خیر.
به عنوان مثال، مقدار هدر ELF منجر به بازگشت 0x300 می‌شود و نام تابع system با مقدار بازگشتی 0x9F8 مطابقت داده خواهد شد. Trie فقط برای مقایسه استفاده نمی‌شود:
توابع خاصی که از اشاره گرها به رشته ها (به عنوان مثال ssh-2.0) استفاده می کنند، این رشته ها را در باینری میزبان با استفاده از Trie جستجو می‌کنند. بنابراین هیچ داده مشکوکی در بدنه بکدور وجود نخواهد داشت.
اجرای Trie از bitmaskهای 16 بایتی استفاده می‌نماید که هر نیمه مربوط به محدوده ورودی بایت 0x00-0x3F و 0x40-0x7F و nodeهای برگ دو بایتی است که 3 بیت آن، فلگ‌ها (جهت، پایان) هستند و مابقی برای مقداردهی (یا محل گره بعدی) رزرو شده‌اند.
Symbol resolver
حداقل سه روال مربوط به symbol resolver وجود دارد که توسط بکدور برای مکان یابی ساختار ELF Symbol مورد استفاده واقع می‌شود و اطلاعاتی مانند نام Symbol و آفست آن را در خود نگه می‌دارد. تمام توابع symbol resolver، کلیدی را دریافت می‌کنند تا در Trie جستجو شوند.
یکی از توابع بکدور در همه Symbol ها تکرار می‌شود و تأیید می‌کند که کدام یک، دارای کلید مورد نظر است. چنانچه کلید پیدا شد، ساختار Elf64_Sym را باز می‌گرداند که بعداً برای پر کردن ساختار داخلی بکدور که تمام پوینترهای تابع لازم را در خود نگه می‌دارد، استفاده می‌شود. این فرآیند شبیه به آن چیزی است که معمولا در تهدیدات ویندوز با روتین های هش API مشاهده می‌شود.
بکدور، بسیاری از توابع را از کتابخانه libcrypto (OpenSSL) جستجو می‌کند، زیرا اینها در روال‌های رمزگذاری بعدی مورد استفاده قرار خواهند گرفت؛ همچنین شمارِ توابعی را که قادر به یافتن و resolve آنها بوده است را نگهداری می‌کند. این تعداد، تعیین می کند که آیا روال به درستی اجرا می‌شود یا باید متوقف گردد.
یکی دیگر از symbol resolver های جالب از تابع lzma_alloc سوء استفاده می‌کند که بخشی از کتابخانه liblzma است. این تابع به عنوان کمکی برای توسعه دهندگان به منظور تخصیص کارآمد حافظه با استفاده از تخصیص دهنده پیش فرض (malloc) یا یک تخصیص دهنده سفارشی عمل می‌کند.
این تابع در مورد بکدور XZ، برای استفاده از یک تخصیص دهنده جعلی مورد سوء استفاده قرار می‌گیرد و در واقع، به عنوان یک symbol resolver دیگر عمل می‌کند. پارامتری که برای ” allocation size ” در نظر گرفته شده است، در اصل، کلید symbol داخل Trie است. این ترفند به منظور پیچیده‌تر ساختن تحلیل بکدور می‌باشد.
بکدور به صورت پویا، symbol های خود را در حین اجرا resolve می‌کند و لزوماً این کار را یکباره یا فقط زمانی که نیاز به استفاده از آنها دارد انجام نمی‌دهد. دامنه symbols/functions تحلیل شده از توابع قانونی OpenSSL تا توابعی مانند system که برای اجرای دستورات روی دستگاه استفاده می‌شوند، متغیر است.
هوک کردن Symbind
همانطور که قبلا ذکر شد، نخستین هدف از مقداردهی اولیه بکدور، هوک کردن موفقیت آمیز توابع است. بکدور برای انجام این کار، از rtdl-adit استفاده می‌کند، یکی از ویژگی‌های پیوندگر پویا (dynamic linker) آن است که کتابخانه‌های مشترک سفارشی را قادر می‌سازد تا زمانی که رویدادهای خاصی مانند symbol resolution در پیوند دهنده رخ می‌دهند، مطلع شوند.
در یک سناریوی معمولی، یک توسعه دهنده، یک کتابخانه مشترک را به دنبال کتابچه راهنمای rtdl-audit ایجاد می‌کند. با این حال، بکدور XZ انتخاب می‌کند تا یک runtime patch را بر روی اینترفیس های از قبل ثبت (پیش‌فرض) و بارگذاری شده در حافظه انجام دهد که در نتیجه روال symbol-resolving را ربوده است.
ساختار مخرب audit_iface، که در متغیر سراسری dl_audit در ناحیه حافظه پیوند دهنده پویا ذخیره می‌شود، حاوی آدرس callback symbind64 است که توسط پیوند دهنده پویا فراخوانی می‌شود و تمام اطلاعات symbol را به کنترل بکدور ارسال می‌کند، که سپس به منظور به دست آوردن یک آدرس مخرب برای توابع هدف مورد استفاده قرار می‌گیرد و در نتیجه به هوک کردن منجر می‌گردد.
آدرس‌های dl_audit و dl_naudit که تعداد واسط‌های audit موجود را در خود نگه می‌دارد، با جدا ساختن هر دو توابع dl_main و dl_audit_symbind_alt به دست می‌آیند. بکدور شامل یک جداساز (disassembler) داخلی مینیمالیستی است که برای رمزگشایی دستورالعمل استفاده می‌شود و همچنین از آن استفاده گسترده‌ای می‌کند، به خصوص زمانی که به دنبال مقادیر خاصی مانند آدرس‌های *audit است.
آدرس dl_naudit توسط یکی از دستورالعمل‌های mov در کد تابع dl_main که به آن دسترسی دارد، یافت می‌شود. بکدور با استفاده از این اطلاعات، یک آدرس حافظه را برای دسترسی جستجو کرده و آن را ذخیره می‌کند و همچنین بررسی می‌کند که آیا آدرس حافظه به دست آمده همان آدرسی است که تابع dl_audit_symbind_alt در یک آفست مشخص به آن دسترسی دارد یا خیر.
این آدرس به بکدور اجازه میدهد تا فرض کند که آدرس صحیح را یافته است و پس از اینکه آدرس dl_naudit را پیدا کرد، به راحتی می‌تواند مکان dl_audit را محاسبه کند، زیرا این دو در کنار یکدیگر در حافظه ذخیره می‌شوند.
نتیجه‌گیری
ما در این مقاله، کل فرآیند بکدور liblzma (XZ) را پوشش دادیم و به تجزیه و تحلیل دقیق کد باینری بکدور پرداختیم تا به هدف اصلی آن که هوک کردن (hooking) است، دست یابیم. بدیهی است که این بکدور بسیار پیچیده است و از روش های پیچیده‌ای برای فرار از تشخیص استفاده می‌کند. اینها شامل استقرار چند مرحله‌ای در مخزن XZ و همچنین کد پیچیده موجود در خود باینری هستند.
هنوز چیزهای بیشتری برای بررسی در مورد قسمت های داخلی بکدور وجود دارد، به همین دلیل است که ما تصمیم گرفتیم آن را به عنوان قسمت اول سری XZ بکور ارائه دهیم.
شاخص های نفوذ
قوانین Yara
rule liblzma_get_cpuid_function {
meta:
description = "Rule to find the malicious get_cpuid function CVE-2024-3094"
author = "Kaspersky Lab"
strings:
$a = { F3 0F 1E FA 55 48 89 F5 4C 89 CE 53 89 FB 81 E7 00 00 00 80 48 83 EC 28 48 89 54 24 18 48 89 4C 24 10 4C 89 44 24 08 E8 ?? ?? ?? ?? 85 C0 74 27 39 D8 72 23 4C 8B 44 24 08 48 8B 4C 24 10 45 31 C9 48 89 EE 48 8B 54 24 18 89 DF E8 ?? ?? ?? ?? B8 01 00 00 00 EB 02 31 C0 48 83 C4 28 5B 5D C3 }
condition:
$a
}
کتابخانه‌ها
Debian Sid liblzma.so.5.6.0
4f0cf1d2a2d44b75079b3ea5ed28fe54
72e8163734d586b6360b24167a3aff2a3c961efb
319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
Debian Sid liblzma.so.5.6.1
53d82bb511b71a5d4794cf2d8a2072c1
8a75968834fc11ba774d7bbdc566d272ff45476c
605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4
Related files
d302c6cb2fa1c03c710fa5285651530f, liblzma.so.5
4f0cf1d2a2d44b75079b3ea5ed28fe54, liblzma.so.5.6.0
153df9727a2729879a26c1995007ffbc, liblzma.so.5.6.0.patch
53d82bb511b71a5d4794cf2d8a2072c1, liblzma.so.5.6.1
212ffa0b24bb7d749532425a46764433, liblzma_la-crc64-fast.o
Analyzed artefacts
35028f4b5c6673d6f2e1a80f02944fb2, bad-3-corrupt_lzma2.xz
b4dd2661a7c69e85f19216a6dbbb1664, build-to-host.m4
540c665dfcd4e5cfba5b72b4787fec4f, good-large_compressed.lzma
