نجات دنیا در تعطیلات؛ بزرگ‌ترین هک لینوکس چگونه خنثی شد؟
خطر از بیخ گوش سیستم‌های لینوکس و ویندوزی سراسر دنیا گذشت.
چند روز پیش، یکی از توسعه‌دهندگان مایکروسافت که در تعطیلات عید پاک به سر می‌برد، با کشف آسیب‌پذیری بسیار خطرناکی در ابزار فشرده‌سازی XZ Utils که تقریبا در تمام توزیع‌های لینوکس و سیستم‌عامل‌های شبه‌یونیکس حضور دارد و حتی در ویندوز نیز به کار برده می‌شود، دنیا را تکان داد. اگر این آسیب‌پذیری به موقع کشف نمی‌شد، فاجعه‌ی امنیتی بسیار گسترده‌ای رخ می‌داد و تعداد بی‌شماری از کامپیوترهای دنیا تا سال‌ها در معرض هک بودند، بدون اینکه صاحبان آن‌ها متوجه باشند.
اسم این فرشته‌ی نجات آندرس فریوند (Andres Freund) است که در وقت استراحت خود و زمانی که درحال بهینه‌سازی عملکرد کامپیوترش بود، متوجه این آسیب‌پذیری فاجعه‌آمیز شد. این بک‌دور که در لایه‌های عمیق کد ابزار متن‌باز و رایگان XZ Utils کار گذاشته شده و ظاهرا سال‌ها در دست توسعه بود، تنها در معرض یک کلید خاص آشکار می‌شد تا بدین‌ترتیب بتواند از چشم حتی بهترین برنامه‌های آنتی‌ویروس کامپیوترهای عمومی دور بماند.
به‌گفته‌ی مهندس نرم‌افزاری به‌نام فیلیپو والسوردا، «این بک‌دور احتمالا بهترین حمله‌ی زنجیره تامینی است که تاکنون از آن باخبر شده‌ایم و اگر کشف نمی‌شد، یک سناریوی کابوس‌وار تمام‌عیار را رقم می‌زد؛ یک آسیب‌پذیری مخرب و موثر در نسخه‌ی مجاز آپ‌استریم ابزاری که قرار بود در کتابخانه‌ای به‌شدت پرکاربرد در دسترس همه قرار گیرد.»
شروع ماجرا؛ نجات دنیا در اضافه‌کاری
ماجرای کشف بک‌دور XZ اوایل صبح روز ۲۹ مارس (۱۰ فروردین) شروع شد؛ زمانی که توسعهدهندهی مایکروسافت مستقر در سانفرانسیسکو به‌نام آندرس فرویند در شبکه‌ی اجتماعی ماستودن درباره‌اش خبررسانی کرد و ایمیلی را هم باعنوان «بک‌دور در نسخه‌ی آپ‌استریم xz/liblzma که سرور ssh را در معرض خطر قرار می‌دهد» به لیست پستی OpenWall فرستاد.
فرویند که به‌صورت داوطلبانه بر دیتابیس لینوکسی PostgreSQL نظارت می‌کند، در چند هفته‌ی گذشته هنگام انجام یک سری تست برای بهینه‌سازی عملکرد سیستم خود متوجه اتفاقات عجیبی شد. او متوجه شد که لاگین‌های رمزنگاری شده در liblzma که بخشی از کتابخانه‌ی فشرده‌سازی XZ است، مصرف CPU بسیار زیادی دارد، اما هیچ یک از نرم‌افزارهای تست عملکرد او دلیل مصرف CPU را نشان ندادند. او بلافاصله به این قضیه مشکوک شد و یادش آمد که یکی از کاربران Postgres چند هفته قبل از عملکرد Valgrind، برنامه‌ی لینوکسی که خطاهای حافظه را بررسی می‌کند، «نارضایتی عجیبی» داشت.
فرویند پس از بررسی دقیق سرانجام متوجه شد که کجای کار می‌لنگد. او در ایمیلش نوشت که «مخزن آپ‌استریم XZ و تاربال‌های XZ به بک‌دور آلوده شده‌اند.» کد مخرب به نسخه‌های 5.6.0 و 5.6.1 ابزارها و کتابخانه‌های XZ راه پیدا کرده بود.
هشدار به‌موقع فرویند از وقوع فاجعه‌ی بزرگی جلوگیری کرد
اندکی بعد از دریافت ایمیل فرویند، شرکت نرم‌افزار متن‌باز سازمانی Red Hat هشدار امنیتی اضطراری برای کاربران Fedora Rawhide و Fedora Linux 40 فرستاد تا استفاده از هر یک از این دو را برای مصارف کاری یا شخصی متوقف کنند. این شرکت به این نتیجه رسید که نسخه‌ی بتای Fedora Linux 40 حاوی هر دو نسخه‌ی آلوده از کتابخانه‌ی XZ است. نسخه‌های Fedora Rawhide هم به احتمال زیاد یکی از این دو نسخه‌ی آلوده را دریافت کرده بودند.
نسخه‌ی بتای Debian (توزیع رایگان لینوکس) هم حاوی پکیج‌های آلوده بود، اما خوشبختانه تیم امنیتی بلافاصله برای برگردان آن به نسخه‌ی قبل اقدام کرد. در پیام هشدار امنیتی آمده بود که «درحال‌حاضر هیچ نسخه‌ی پایدار Debian به این بک‌دور آلوده نشده است.»
بک‌دور XZ از طریق روشی که به آن «حمله به زنجیره‌ی تامین نرم‌افزار» گفته می‌شود، به ابزار XZ Utils راه پیدا کرد. این مدل حمله که به‌طور مستقیم زنجیره‌ی تامین محصولات نرم‌افزاری را هدف قرار می‌دهد، اغلب از روش‌های پیچیده‌ای مثل مهندسی اجتماعی برای تغییر کد منبع برنامه استفاده می‌کند؛ مثلا به سیستم توسعه‌دهنده دسترسی غیرمجاز پیدا می‌کند یا با دسترسی کاملا مجاز از طریق توسعهدهندهی خرابکار، زنجیره تامین را آلوده می‌کند.
خرابکار باهوش و صبور؛ عملیات بسیار پیچیده
فرویند بعدا مقصر اصلی بک‌دور XZ را شناسایی کرد؛ فردی که به‌گفته‌ی Ars Technica خودش را Jia Tan با نام کاربری JiaT75 می‌نامید. این فرد در واقع یکی از دو توسعهدهندهی اصلی نرم‌افزار XZ Utils بود.
همه‌چیز زیر سر یکی از دو توسعه‌دهنده اصلی XZ Utils بود
فرویند درحالی‌که دنبال سرنخی برای شناسایی هویت هکر بود، نوشت: «باتوجه به فعالیت‌هایی که طی چند هفته‌ی گذشته صورت گرفته، فرد خاطی یا پایش به‌طور مستقیم درگیر است یا اینکه سیستمش با آسیب‌پذیری بسیار جدی مواجه شده. متاسفانه حالت دوم احتمال بسیار کمتری دارد، چون این فرد در چندین لیست درباره‌ی «فیکس»هایی که در بالا به آن اشاره شد، صحبت کرده است.»
ژیا تان در میان انجمن‌های پروژه‌های متن‌باز لینوکسی نام آشنایی است؛ او برای مدتی با لسی کالین، توسعهدهندهی اولیه‌ی فرمت فایل xz. همکاری نزدیکی داشت. تان کارش را با ارسال پچ‌های ظاهرا معتبری به لیست پستی XZ در اکتبر ۲۰۲۱ شروع کرد. چند ماه بعد، دو کاربر دیگر با نام‌های جیگار کومار و دنیس انس در ایمیل‌هایی به کالین از باگ و روند کند توسعه‌ی پروژه‌ی XZ شروع به شکایت کردند. اما نکته اینجا بود که کومار و انس هیچ جای دیگری جز انجمن XZ حضور نداشتند. افرادی که پرونده‌ی بک‌دور لینوکس را بررسی می‌کردند به این نتیجه رسیدند که این دو نام کاربری جعلی است و صرفا برای این ایجاد شده بود تا ژیا تان بتواند به کد منبع پروژه دسترسی پیدا کند.
دو نام کاربری جعلی توسعه‌دهنده اصلی را به انتخاب ژیا تان ترغیب کردند
انس در پیغامی به کالین نوشته بود: «از بابت مشکلات روحیت متاسفم، اما مهمه که حد خودت را بدانی. متوجه‌ام که این پروژه برای تمام مشارکت‌کنندگان، پروژه‌ای تفننی محسوب می‌شود، اما انجمن کاربران بی‌صبرانه منتظر کامل‌شدنش هستند.» کومار هم در پیغام دیگری نوشته بود: «تا زمانی که مسئول نگه‌داری جدیدی برای پروژه انتخاب نشود، پیشرفتی صورت نخواهد گرفت.»
در میان این نامه‌نگاری‌ها، کالین نوشت که «من علاقه‌ام را به تکمیل پروژه از دست نداده‌ام، اما توانم برای ادامه‌‌ی پروژه به‌خاطر مشکلات روحی و موارد دیگر کمتر شده است.» بعد هم به ژیا تان پیشنهاد داد نقش پررنگ‌تری را در تکمیل پروژه به‌عهده بگیرد. در آخر هم گوشزد کرد که «این پروژه صرفا برای سرگرمی است و درآمدی ندارد.»
ایمیل‌ها از سمت کومار و انس ادامه پیدا کرد تا زمانی‌که ژیا تان اواخر سال به‌عنوان مسئول نگه‌داری پروژه انتخاب شد. او حالا می‌توانست در کد منبع تغییرات اعمال کند و بسته‌ی بک‌دور را با اعتبار بیشتری به توزیع‌های لینوکس منتقل کند.
عملیات بک‌دور XZ به‌شدت حرفه‌ای و کاملا حساب‌شده صورت گرفت و کد مخرب نیز به‌حدی پیچیده طراحی شده که کاربرد و هدف دقیق آن کماکان در دست بررسی است.
به‌گفته‌ی مدیر آی‌تی شرکت حقوق دیجیتال Electronic Frontier Foundation، «تلاشی که برای پنهان کردن بک‌دور در فایل‌های تست باینری صورت گرفته و همچنین زمان طولانی برای به‌دست آوردن اعتبار در پروژه‌ی متن‌باز تا اینکه بعد بتوان آن را دست‌کاری کرد به‌طرز عجیبی پیچیده است. اما هنوز مشخص نیست این عملیات از سمت دولت خاصی بوده یا گروه هکری یا توسعه‌دهنده‌ای تنها یا ترکیبی از این سه موارد.»
زشتی و زیبایی پروژه‌های متن‌باز
ماجرای بک‌دور XZ مثال خوبی از زیبایی پروژه‌های متن‌باز و درعین حال، آسیب‌پذیری وحشتناک زیرساخت‌های اینترنت است.
در دنیای متن‌باز برنامه‌نویسی لینوکس و البته در توسعه‌ی XZ Utils، همکاری بین توسعه‌دهندگان از طریق گروه‌های ایمیل و مخازن کد انجام می‌شود. تان در listserv پست گذاشت، با کالین چت کرد و تغییرات کد را در مخزن کد گیت‌هاب که متعلق به مایکروسافت است، اعمال کرد. از آن سو، چندین کاربر دیگر برای انتخاب تان به‌عنوان مسئول نگه‌داری پروژه پافشاری کردند و گروه دیگری در listserv مخصوص توزیع Debian مصرانه خواهان قرارگرفتن نسخه‌ی آلوده‌‌ی XZ Utils در این توزیع بودند.
به‌احتمال زیاد این عملیات از نوع مهندسی اجتماعی و کاملا حساب‌شده بود
بسیار محتمل است که فرد یا افراد پشت این عملیات کاملا عامدانه از تکنیک بسیار پیچیده‌ی مهندسی اجتماعی برای آلوده‌کردن XZ Utils به بک‌دور استفاده کرده‌اند؛ هرچند این احتمال هم وجود دارد که تمام این اتفاق‌ها تصادفی بوده باشد.
در این بین، توسعهدهندهی یکی از پکیج‌های رسانه‌ای متن‌باز محبوب به‌نام FFmpeg درباره‌ی معضل پروژه‌های متن‌باز در توییتی نوشت: «فاجعه‌ی xz به ما نشان داد که چطور متکی‌بودن به توسعه‌دهندگانی که به طور داوطلب و رایگان روی پروژه‌ای کار می‌کنند، می‌تواند مشکلات بزرگی به بار آورد. شرکت‌های بزرگ چند تریلیون دلاری از توسعه‌دهندگان داوطلب انتظار کار رایگان و سریع دارند.» این توسعه‌دهنده به‌طور مشخص به مایکروسافت اشاره کرد که چطور برای باگی که در ابزار FFmpeg برای مایکروسافت‌تیمز پیدا شده بود، برچسب «اولویت بالا» زده و از توسعه‌دهندگان داوطلب انتظار داشت در اسرع وقت این باگ را برطرف و به‌جای حقوق ثابت، برای همین پروژه فقط چند هزار دلار دریافت کنند.
جزییات مربوط به اینکه دقیقا چه کسی پشت نام کاربری JiaT75 قرار دارد، چطور توانست این عملیات را پیاده‌سازی کند و میزان آسیبی که وارد شده کماکان توسط ارتشی از توسعه‌دهندگان و متخصصان امنیت سایبری در دست بررسی است؛ اما حتی همین بررسی‌ها هم بدون حمایت مالی مستقیم بسیاری از شرکت‌‌ها و سازمان‌هایی انجام می‌شود که امن بودن نرم‌افزارهای متن‌باز برایشان اولویت است.
البته شاید فکر کنید احتمال بروز آسیب‌پذیری‌های این‌چنینی در نرم‌افزارهای حیاتی فقط به پروژه‌های متن‌باز مربوط می‌شود، اما واقعیت این است که این ماجرا می‌تواند در هر شرایط دیگری اتفاق بیفتد. درضمن، فراموش نکنیم اینکه توسعه‌دهنده‌ای مثل آندرس فریوند توانست در وقت استراحت خود و پیش از توزیع نرم‌افزار آلوده متوجه این بک‌دور فاجعه‌آمیز شود، فقط به‌لطف ماهیت متن‌باز پروژه بود.
از کجا مطمئن شویم سیستم ما به بک‌دور XZ آلوده نشده است؟
برای چک کردن سلامت سیستم خود می‌توانید به صفحه‌ی شرکت امنیت سایبری Binarly مراجعه کنید تا با آپلود فایلی با فرمت ELF، آلودگی به بک‌دور XZ به‌طور خودکار شناسایی شود. همچنین می‌توانید از پروژه‌ی xzbot در گیت‌بات استفاده کنید.