نفوذ به SSH با در پشتی
یک نگهدارندهی بدخواه یا آسیبپذیر، رفتار مخربی را در کتابخانهای به نام ... وارد کرده است. لیبلزما، بخشی از ابزارها و کتابخانههای فشردهسازی xz، که منجر به یک درِ پشتی در SSH میشود. این یک حمله زنجیره تأمین نرمافزار پیشرفته است زیرا کتابخانه عمداً برای درِ پشتی اصلاح شده است، با تکنیکهای مبهمسازی و پنهانکاری برای پنهان کردن بار داده حمله از بررسیکنندگان.
این آسیبپذیری اخیراً (در ۲۹ مارس گذشته) کشف و افشا شد و مدیریت حمله همچنان ادامه دارد. با این حال، به سرعت مهار شد زیرا به نظر میرسد فقط نسخههای پیشانتشار از مجموعهای محدود از محیطها (بستههای DEB و RPM، برای معماری x86_64 و ساخته شده با GCC) را تحت تأثیر قرار میدهد. به هر حال، CVE داده شد امتیاز پایه CVSS از ۱۰، که برای مهمترین آسیبپذیریهای امنیت سایبری در نظر گرفته شده است. اگر وارد توزیعهای پایدار شود، تأثیر آن بسیار زیاد خواهد بود.
تحلیل فنی حمله، شامل توضیح عمیق درب پشتی xzدر جای دیگری مورد تجزیه و تحلیل قرار گرفته است. این پست بر جدول زمانی حمله، نحوه شناسایی آن، نحوه مدیریت حادثه تا به امروز و درسهایی که میتوان از این حمله استخراج کرد، تمرکز خواهد کرد.
دنباله طولانی این درِ پشتی پس از وصله اولیه نیز ادامه داشته است. در آگوست 2025، بیش از یک سال پس از افشای CVE-2024-3094، محققان امنیتی در Binarly دریافتند که این درِ پشتی هنوز در دوازده تصویر Debian Docker منتشر شده در Docker Hub وجود دارد، در حالی که تیم Debian از حذف آنها خودداری کرده و آنها را به عنوان مصنوعات توسعه تاریخی به جای خطر فعال در نظر گرفته است. به طور جداگانه، OpenSSF و OpenJS اندکی پس از حادثه XZ هشدار مشترکی صادر کرد مبنی بر اینکه تلاشهای مشابه برای تصاحب پروژههای جاوا اسکریپت با مهندسی اجتماعی، پیش از این نیز انجام شده است، که نشان میدهد الگوی حمله نگهدارنده-اعتماد که در اینجا استفاده شده است، در جاهای دیگر نیز مورد استفاده مجدد قرار میگیرد.
نحوه تزریق درب پشتی XZ
توجه: مخزن git در git.tukaani.orgاست. با این حال، همچنین وجود داشت مخزن میزبانی شده توسط گیتهاب (در حال حاضر مسدود شده) که در آن حساب GitHub تغییراتی را که بعداً در مخزن Git ادغام شدند، ارسال میکرد.
به نظر میرسد بخشی از این درِ پشتی فقط در فایلهای فشرده توزیعشده برای نسخههای ۵.۶.۰ و ۵.۶.۱ وجود دارد، نه در مخازن گیت و به ... متکی است. یک خط در فایل build-to-host.m4 فایل ماکرو مورد استفاده توسط autoconf. بخش دیگر در دو فایل آزمایشی فرضی بود bad-3-corrupt_lzma2.xz و good-large_compressed.lzma
آن بود commitپخش کردن توسط حساب کاربری گیتهاب «جیا تان» (JiaT75) در مخزن xz در ۲۳ فوریه. این یک تغییر بیضرر بود که فایلهای آزمایشی (ظاهراً بلوکهای فشرده .lzma و .xz) را اضافه میکرد. جالب اینجاست که فایلهای آزمایشی توسط آزمایشکنندگان استفاده نشدند! خط موجود در فایل .m4 یک اسکریپت مبهمسازی شده (موجود در tarball) را تزریق میکند تا در صورت مطابقت برخی شرایط، در انتهای configure اجرا شود. این خط Makefile را برای لیبلزما کتابخانهای که شامل کدی است که دادهها را از فایل .xz استخراج میکند، که پس از پایان مبهمسازی، این کار را انجام میدهد. در این اسکریپت، در پایان configure فراخوانی میشود. این دستور تصمیم میگیرد که آیا فرآیند ساخت را برای تزریق کد تغییر دهد یا خیر: فقط تحت GCC و لینکر GCC، تحت Debian یا rpm، و فقط برای لینوکس x86_64. در صورت تطابق، کد تزریق شده با جایگزینی دو مورد، اجرا را متوقف میکند. ایفونک بنابراین فراخوانیهای خاصی جایگزین میشوند. این باعث میشود جداول نماد در حافظه تجزیه شوند (این کار زمان میبرد، که منجر به تشخیص شد، همانطور که بعداً توضیح داده خواهد شد).
سپس اوضاع جالب میشود: درِ پشتی یک قلاب حسابرسی را در پیونددهنده پویا نصب میکند و منتظر میماند تا نماد تابع RSA_public_decrypt از راه برسد، که به نقطهای در کد درِ پشتی هدایت میشود، که به نوبه خود فراخوانی میشود. libcrypto، احتمالاً برای انجام احراز هویت عادی. و اگر برنامه در حال اجرا نام فرآیند را داشته باشد، payload فعال میشود. /usr/sbin/sshdواضح بود که سرورهای SSH هدف بودند. به طور سنتی، ssh سرورهایی مانند OpenSSH با آنها مرتبط نبودند لیبلزما، اما sshd است اغلب وصله شده برای پشتیبانی از systemd-notify تا سایر سرویسها بتوانند هنگام اجرای sshd شروع به کار کنند. و سپس liblzma به طور غیرمستقیم توسط آن بارگذاری میشود. systemd، بستن دایره.
این درِ پشتی هنوز به طور کامل تجزیه و تحلیل نشده است، اما به نظر میرسد که ... امکان اجرای دستورات از راه دور (RCE) با امتیازات سرویس sshd، در یک زمینه پیش از احراز هویت اجرا میشود. اطلاعات گواهی از راه دور، هنگامی که با درب پشتی مطابقت داشته باشد، با ChaCha20 رمزگشایی میشود و هنگامی که با موفقیت رمزگشایی شد، به ... منتقل میشود. سیستم()بنابراین این اساساً یک RCE دروازهدار است، بسیار بدتر از یک دور زدن کلید عمومی صرف.
یک tarball نسخه ۵.۶.۱ بعدی تلاشهای بیشتری را برای پنهان کردن ردپاها نشان داد، ابهام بیشتری را برای نام نمادها اضافه کرد و سعی در رفع خطاهای مشاهده شده داشت. مکانیسم گسترش جایی که فایلهای آزمایشی اضافی برای یافتن امضاهای خاص جهت افزودن به درب پشتی جستجو میشدند، نیز ایجاد شد.
این حمله نسبتاً پیچیده میتواند تا زمان رسیدن به توزیعهای پایدار لینوکس، مورد توجه قرار نگیرد. خوشبختانه، برخی افراد دوست دارند بررسی کنند که چرا اتفاقات غیرعادی رخ میدهد.
کشف حملهی درب پشتی XZ
بسیاری از اوقات رفتار مخرب تزریقشده بهطور اتفاقی یا تصادفی کشف میشود. یک مثال خوب این بود هشدار استهلاک («چه کسی به هشدارها اهمیت میدهد؟») که منجر به کشف ... شد. حمله جریان رویداد در اکتبر ۲۰۱۸. یکی دیگر از کاربرانی است که هشدار داده است Codecov در آوریل ۲۰۲۱ اعلام شد که اسکریپت آپلودکنندهی bash آنها از چکسام عبور نکرده است («چه کسی صحت مصنوعات را با چکسامها تأیید میکند»؟) ناهنجاریها و علائم عجیب و غریب با ssh loginها (login(مصرف زیاد CPU و افزایش زمان سپری شده، خطاهای valgrind) کنجکاوی را برانگیخت. آندرس فروند، یک توسعهدهنده هوشیار PostgreSQL اما نه یک تحلیلگر امنیتی (همانطور که خودش اظهار داشت)). پس از کمی بررسی با OpenSSH روی دبیان سید، او به این نتیجه رسید که مشکل زمان پاسخ به یک کتابخانه متکی است، لیبلزما، بخشی از XZ-UTILS کتابخانه فشردهسازی. دلیل: «مخزن بالادستی xz و فایلهای فشرده xz دچار در پشتی شدهانداین تشخیص خیلی دقیق بود! در ۲۹ مارس ۲۰۲۴، آندرس اولین تحلیل خود را در Openwall منتشر کرد: «یک درِ پشتی در سرور xz/liblzma که منجر به نفوذ به سرور ssh میشود.واقعیت: فایلهای فشرده XZ Utils نسخههای ۵.۶.۰ و ۵.۶.۱ حاوی یک در پشتی هستند. این فایلهای فشرده توسط حساب کاربری Jia Tan که قبلاً به آن اشاره شد، ایجاد و امضا شدهاند. He منتشر شده در ماستودون بعداً در همان روز، با تشخیص اینکه این کشف تصادفی بوده و نیاز به اتفاقات زیادی داشته است. نظرات سایر کاربران ارزش خواندن دارد. کاربر GitHub سامسام (معروف به سم جیمز) یک Gist خوب منتشر کرد سوالات متداول در مورد در پشتی xz-utils جایی که حمله خلاصه شده بود و به موارد بیشتری پیوند میخورد تحلیلهای عمیق از محموله حمله. این تحلیلها از نظر فنی بسیار مفید بودند و به ما کمک کردند تا تزریق را که بسیار مفصل بود، بهتر درک کنیم:- xz/liblzma: توضیح مبهمسازی در سطح Bashتحلیل خوبی در مورد رفع ابهام توسط اسکریپت تزریق، در چهار «مرحله».
- رشته آبی فیلیپو والسوردا تحلیل خودِ درِ پشتی در RSA_public_decrypt، که ماهیت آن را نشان میدهد: یک RCE، نه دور زدن احراز هویت، و دروازهدار (کلید خصوصی نویسنده را میپذیرد و در غیر این صورت، به رفتار عادی برمیگردد) / غیرقابل بازپرداخت. نویسنده قصد داشته برای جلوگیری از شناسایی، کمتر مورد توجه قرار گیرد!
- تحلیل در پشتی XZ توسط @smx-smx (در حال انجام) – تحلیل تکمیلی درب پشتی (تقریباً از همان ابتدا گم شدم 😀)
- ویکی مستندات درب پشتی xz، تحلیل دیگری از اسکریپت تزریق ۵.۶.۱.
نحوه رسیدگی به حادثه
افشاگری آندریاس فروند محتاطانه بود زیرا به قول خودش:«با توجه به دخالت آشکار در بالادست، من هیچ اشکالی در بالادست گزارش نکردهام. از آنجایی که در ابتدا فکر میکردم این یک مشکل خاص دبیان است، گزارش اولیهتری را به security@...ian.org ارسال کردم. متعاقباً، مشکل را به distros@ گزارش دادم.» CISالف از طریق توزیع مطلع شد.
چه کسی زیر حمله است؟
یا حساب کاربری GitHub JiaT75 مورد نفوذ قرار گرفته است (به یاد داشته باشید که GitHub اخیراً احراز هویت دو مرحلهای را اجباری کرده است) یا کاربر فیزیکیِ صاحب حساب کاربری به دام افتاده است. اما دلایل قانعکنندهای وجود دارد که به دلیل پیچیدگی فنی حمله، احتمال وجود یک تهدید پیشرفتهی مداوم (APT)، شاید تحت حمایت دولت، را در نظر بگیریم. تحقیقات بیشتر توسط سازمانهای امنیت سایبری و مجریان قانون نشان خواهد داد... این مدخل در اخبار هکرهای YCombinator درباره جیا تان کمی در مورد «چه کسی» و فعالیت او توضیح میدهد. توصیه میشود! این اطلاعات زیادی در مورد چگونگی تلاش افراد شرور برای فریب سایر کاربران با استفاده از مهندسی اجتماعی ارائه میدهد.«بسیار آزاردهنده است - نویسندهی ظاهراً این درِ پشتی چندین هفته با من (rwmj) در ارتباط بود و سعی میکرد xz 5.6.x را به دلیل «ویژگیهای جدید عالی» آن به فدورا ۴۰ و ۴۱ اضافه کند. ما حتی با او برای رفع مشکل valgrind (که اکنون مشخص شده است که ناشی از درِ پشتیای بوده که او اضافه کرده بود) همکاری کردیم. دیشب مجبور شدیم برای رفع مشکل پس از نقض ناخواستهی تحریم، با هم رقابت کنیم. او به مدت ۲ سال بخشی از پروژهی xz بوده و انواع فایلهای آزمایشی باینری را اضافه کرده است و صادقانه بگویم با این سطح از پیچیدگی، من حتی به نسخههای قدیمیتر xz هم مشکوک خواهم بود، مگر اینکه خلافش ثابت شود.»
جیا تان اقداماتی را برای جلوگیری از ردیابی انجام داد: به نظر میرسد از VPN (vpn.singapore.witopia.net) برای اتصال استفاده کرده است - که فی نفسه اشکالی ندارد. و به نظر میرسد بسیاری از تغییرات توسط ایمیلهای موقت و یکبار مصرف (در این مورد از ProtonMail) پشتیبانی میشوند که خواستار ادغام تغییرات هستند.
این عامل ممکن است قصد داشته باشد حتی عمیقتر عمل کند و به هسته لینوکس برسد، به عنوان مشارکتکننده در ... جاسازیشده در xy پروژه. تا به امروز، تجزیه و تحلیل اولیه هیچ مدرکی دال بر سقط جنین پیدا نکرده است.
نکته: یکی دیگر «هانس جانسن»، همکار کمسروصدای XZ (کاربر گیتهاب "hansjans162") است. تحت نظارتحساب کاربری آن در دبیان اکنون ... است. مسدود شدهاو بهروزرسانیهای زیادی برای بازیهای دبیان انجام داد تا نسخهی مورد نظرش را روی debian/xz-utils پنهان کند، و بهروزرسانیای برای نسخهٔ بالاتر ۵.۶.۱ انجام داد تا توزیع درِ پشتی را تسریع کند. دبیان/ناپایدار.
فعلاً تنها چیزی که میتوانیم بگوییم این است که این یک APT (هنوز شناسایی نشده) است که از حسابهای کاربری مختلف استفاده میکند، حداقل دو سال است که روی این کمپین کار میکند و با صبر و حوصله در تلاش است تا یک RCE را در SSH پیادهسازی کند.
تا زمان نگارش این مطلب، هویت پشت «جیا تان» هنوز تأیید نشده است. هیچ انتساب معتبری به فرد، سازمان یا بازیگر دولتی خاصی به طور عمومی تأیید نشده است، که این امر نشان میدهد نظم عملیاتی این شخصیت چقدر مؤثر بوده است.
آیا حملهی درب پشتی XZ قابل پیشگیری بود؟
نسبتاً دشوار.
اولاً، بخشی از درِ پشتیِ تزریقشده وارد فایلهای آزمایشی فشردهای شد که توسط آزمایشها استفاده نشده بودند. با نگاهی به گذشته، این میتواند برخی هشدارها (پر سر و صدا) را برانگیزد، اما چه کسی به بررسی این موضوع اهمیت میدهد که آیا همه فایلهای آزمایشی توسط آزمایشهای واقعی در دنیای واقعی استفاده میشوند؟ ثانیاً، بخشی از درِ پشتیِ تزریقشده در فایلهای ماکرو وارد تاربالهای انتشار شد و بررسی دستی تفاوتها با تاربالهای مورد انتظار دشوار است. اتوماسیون نیز پیچیده است، زیرا مدلسازی نتیجه مورد انتظار از خودِ ساخت (برای هر کسی که میداند automake/autoconf چگونه کار میکند) برای تجزیه و تحلیل اینکه آیا تاربال واقعی با انتظارات مطابقت دارد یا خیر، دشوار است. بعضیها آن را مطرح کردند as «عدم تطابق tarballها از درخت گیت یک ویژگی است، نه یک اشکال»منشأ فایلهای فشردهی باینری از کد منبع آن، یک مشکل حل نشده است.
اعتبار کاربر؟ خب، حساب کاربری گیتهاب JiaTan75 طبق گذشته کارهای خلاف قانون انجام نمیداد. commitس. تنها پس از جمعآوری شواهد به حالت تعلیق درآمد، اما تا ۲۹ مارس، یک کاربر معمولی بود که کارهای عادی انجام میداد. خب، نه چندان عادی. بعداً commitها (این, این, اینو این که کد سوءاستفاده را تنظیم کرد) سعی کرد خطاهای valgrind و خرابیها را در برخی پیکربندیها، به دلیل تفاوت با طرح پشته مورد انتظار درب پشتی، برطرف کند. Commit بررسیها میتوانند این را تشخیص دهند، اما چه کسی حوصله دارد تغییرات در یک فایل آزمایشی دودویی یا انگیزه واقعی برای تغییر در ویژگیهای GCC در کد منبع C را تجزیه و تحلیل کند؟
آیا باید هنگام SSH هشدار داد؟ login به جای ۳۰۰ میلیثانیه، ۸۰۰ میلیثانیه طول میکشد؟ احتمالاً فقط افراد بسیار محتاط به این نکته توجه میکنند. سیسرو گفت، «عجول بودن مال جوانی است و احتیاط مال پیری.»
زیرساخت ifunc در ژوئن 2023 توسط "هانس جانسن" و "جیا تان" اضافه شد. این اولین ... commit اضافه کردن پشتیبانی ifunc به crc64_fast.c (که بعداً برای تزریق درِ پشتی استفاده شد). ماهها قبل از تزریق فایلهای باینری درِ پشتی در فایلهای آزمایشی!
یادداشت: نویسنده و commitاینجا اختلاف نظر وجود دارد، اما این طبیعی است: لاس کالین نگهدارنده پروژه است و او تغییرات را ادغام کرده است. او حتی از «هانس یانسن» تشکر میکند...
هیچکس قبل از پست آندرس فروند و CVE ایجاد شده توسط RedHat نگرانیای مطرح نکرده بود. اگر مجموعهای از ابزارها را ببینید که این مشکل را تشخیص میدهند، اکنون مؤلفه آسیبدیده را شناسایی میکنند. ex post facto.
احتمالاً بهترین پیشگیری از ماهیت توزیعهای لینوکس ناشی میشود، و اینکه چگونه نسخههای ناپایدار و بهروز، تنها پس از طی یک فرآیند منظم به توزیعهای پایدار بعدی منتقل میشوند.
درسهایی از حملهی XZ bBackdoor
ما متوجه شدیم که تشخیص آن چقدر دشوار است عمدی درهای پشتی. درهای پشتی باید یک تهدید داخلی در نظر گرفته شوند، زیرا توسط کارکنان داخلی یا از طریق حسابهای داخلی آسیبدیده تعبیه میشوند. و این افراد عمدتاً مورد اعتماد هستند. و وقتی در پشتی در یک مصنوع توزیعشده تعبیه میشود، تشخیص آن دشوارتر میشود.
برخی از نویسندگان مانند کوین بومونت اشاره کرد به سیستم، که سطح حمله بزرگی از سرویسهای شخص ثالث را برای ایجاد یک در پشتی باز میکند. این همان چیزی است که عامل مخرب در اینجا از آن سوءاستفاده کرده است. Systemd تعداد زیادی چشم دارد، اما XZ یک کتابخانه مبهم در زنجیره است. "وقتی جریان بالادست آلوده باشد، همه در جریان پاییندست آب مسموم مینوشند".
یک درخواست تغییر نامرتبط در سیستم برای بارگذاری پویای کتابخانههای فشردهسازیکه باعث حذف درِ پشتی میشد، قبلاً در سیستم ادغام شده بود اما هنوز تحویل داده نشده بود. وابستگیهای اضافی معرفیشده توسط libsystemd ممکن است منبع آسیبپذیریها باشند.، و دیروز این درخواست باز شد.
A توضیح در قسمت «xz: برای رفع مشکل، ifunc را غیرفعال کنید» commit بینش دقیقی در مورد اینکه اگر میخواهیم از چنین فعالیتهایی جلوگیری کنیم، تمرکز را روی کجا قرار دهیم، ارائه داد (تأکید از من است):
«درسی که ما به عنوان یک جامعه باید بیاموزیم، بیشتر برای ایمنسازی است.» software supply chain security به طور کلی، حسابرسی سیستمهایی را فراتر از کد منبع میسازد. مانند نقض SolarWinds که در آن مهاجمان بهروزرسانیهای نرمافزاری را برای نرمافزار مانیتورینگ متنباز SolarWinds تغییر دادند.
سوالات متداول
آیا درب پشتی XZ هنوز هم یک خطر است؟
تقریباً مهار شده، اما کاملاً از بین نرفته است. در آگوست 2025، محققان دریافتند که این درِ پشتی هنوز در چندین ایمیج Debian Docker Hub وجود دارد که توسط دبیان به عنوان مصنوعات تاریخی غیرفعال تلقی میشوند. تیمها باید تأیید کنند که در حال ساخت و ساز بر روی ایمیجهای پایه قدیمی و وصله نشده نیستند، نه اینکه فرض کنند وصله 2024 کاملاً در را بسته است.
