الباب الخلفي SSH
قام أحد المشرفين الشائنين أو المخترقين بإدراج سلوك ضار في مكتبة اسمها liblzma، وهي جزء من أدوات ومكتبات ضغط xz، مما يؤدي إلى وجود باب خلفي في SSH. يعد هذا هجومًا متقدمًا على سلسلة توريد البرامج، حيث تم تعديل المكتبة عمدًا لتناسب الباب الخلفي، باستخدام تقنيات التشويش والتخفي لإخفاء حمولة الهجوم عن المراجعين.
تم اكتشافه والكشف عنه مؤخرًا (في التاسع والعشرين من مارس الماضي)، وما زال التعامل مع الهجوم مستمرًا. ومع ذلك، تم احتواؤه بسرعة لأنه يبدو أنه يؤثر فقط على إصدارات ما قبل الإصدار لمجموعة محدودة من البيئات (حزم DEB وRPM، للهندسة المعمارية x29_86، والمبنية باستخدام GCC). على أي حال، CVE تم منحه النتيجة الأساسية لـ CVSS من أصل ١٠، وهو مخصص لأخطر ثغرات الأمن السيبراني. في حال دخوله إلى توزيعات مستقرة، سيكون التأثير هائلاً.
التحليل الفني للهجوم بما في ذلك شرح مفصل لـ xz backdoorتم تحليل هذا الهجوم في مكان آخر. سيركز هذا المنشور على الجدول الزمني للهجوم، وكيف تم اكتشافه، وكيف تم التعامل مع الحادث حتى الآن، وما هي الدروس التي يمكن استخلاصها من الهجوم.
استمر تأثير الثغرة الأمنية لفترة طويلة بعد صدور التحديث الأولي. ففي أغسطس 2025، أي بعد أكثر من عام على الكشف عن الثغرة CVE-2024-3094، وجد باحثو الأمن في شركة Binarly أن الثغرة لا تزال موجودة في اثنتي عشرة صورة من صور Debian Docker المنشورة على Docker Hub، وقد رفض فريق Debian إزالتها، معتبرًا إياها من مخلفات التطوير القديمة وليست خطرًا قائمًا. وفي سياق منفصل، OpenSSF وأصدرت OpenJS تحذيراً مشتركاً بعد وقت قصير من حادثة XZ مفاده أن محاولات الاستيلاء على الهندسة الاجتماعية المماثلة قد استهدفت بالفعل مشاريع JavaScript، مما يشير إلى أن نمط هجوم الثقة في القائمين على الصيانة المستخدم هنا يتم إعادة استخدامه في أماكن أخرى.
كيف تم حقن الباب الخلفي XZ
ملاحظة: مستودع git موجود git.tukaani.org. ومع ذلك، كان هناك أيضًا أ مستودع GitHub المستضاف (محظور حاليًا) حيث كان حساب GitHub ينشر التغييرات التي تم دمجها لاحقًا في مستودع Git.
يبدو أن جزءًا واحدًا من الباب الخلفي موجود فقط في كرات القطران الموزعة للإصدارين 5.6.0 و5.6.1، وليس في مستودعات git ويعتمد على سطر واحد في build-to-host.m4 ملف الماكرو المستخدم بواسطة autoconf. وكان الجزء الآخر في ملفين اختباريين مفترضين bad-3-corrupt_lzma2.xz و good-large_compressed.lzma
التي كانت commitتيد بواسطة حساب GitHub "جيا تان" (جياT75) في مستودع xz في 23 فبراير. لقد كان تغييرًا غير ضار بإضافة ملفات اختبار (من المفترض أن تكون كتل مضغوطة بتنسيق .lzma و.xz). ومن المثير للاهتمام أن ملفات الاختبار لم يتم استخدامها في الاختبارات! يقوم السطر الموجود في الملف .m4 بإدخال برنامج نصي مبهم (مضمن في كرة القطران) ليتم تنفيذه في نهاية التكوين إذا تطابقت بعض الشروط. يقوم بتعديل ملف Makefile لـ liblzma مكتبة تحتوي على تعليمات برمجية تستخرج البيانات من ملف .xz، والذي ينتهي بعد إزالة التشويش في هذا البرنامج النصي، يتم استدعاؤه في نهاية التكوين. فهو يقرر ما إذا كان سيتم تعديل عملية الإنشاء لإدخال التعليمات البرمجية: فقط ضمن رابط مجلس التعاون الخليجي ورابط مجلس التعاون الخليجي، ضمن Debian أو rpm، وفقط لنظام التشغيل x86_64 Linux. عند المطابقة، يعترض الكود المُدخل التنفيذ عن طريق استبدال اثنين com.ifunc وحدات الحل بحيث يتم استبدال بعض المكالمات. يؤدي هذا إلى تحليل جداول الرموز في الذاكرة (وهذا يستغرق وقتًا، مما أدى إلى الاكتشاف، كما هو موضح لاحقًا).
ثم تصبح الأمور مثيرة للاهتمام: يقوم الباب الخلفي بتثبيت خطاف تدقيق في الرابط الديناميكي، في انتظار وصول رمز الوظيفة RSA_public_decrypt، والذي تتم إعادة توجيهه إلى نقطة في رمز الباب الخلفي، والذي بدوره يتصل مرة أخرى libcrypto، ويفترض لإجراء المصادقة العادية. ويتم تنشيط الحمولة إذا كان البرنامج قيد التشغيل يحمل اسم العملية /usr/sbin/sshd. كان من الواضح أن خوادم SSH كانت الهدف. تقليديا، سشد لم يتم ربط خوادم مثل OpenSSH بها liblzma، ولكن SSHD هو في كثير من الأحيان مصححة لدعم systemd-notify حتى تتمكن الخدمات الأخرى من البدء عند تشغيل sshd. وبعد ذلك يتم تحميل liblzma بشكل غير مباشر بواسطة سيستم دي، إغلاق الدائرة.
لم يتم بعد تحليل الباب الخلفي بشكل كامل، ولكن يبدو أنه كذلك السماح بتنفيذ الأوامر عن بعد (آر سي إي) مع امتيازات البرنامج الخفي sshd، يعمل في سياق المصادقة المسبقة. يتم فك تشفير المعلومات الواردة من الشهادة البعيدة، عند مطابقتها بواسطة الباب الخلفي، باستخدام ChaCha20، وعندما يتم فك التشفير بنجاح، يتم تمريرها إلى النظام(). لذا فإن هذا في الأساس عبارة عن RCE مسور، وهو أسوأ بكثير من مجرد تجاوز المفتاح العام.
أظهرت نسخة 5.6.1 لاحقة من كرة القطران جهودًا إضافية لإخفاء الآثار، وإضافة المزيد من التشويش لأسماء الرموز، ومحاولة إصلاح الأخطاء التي تمت رؤيتها. ان آلية التمديد حيث تم أيضًا وضع ملفات اختبار إضافية بحثًا عن توقيعات معينة لإضافتها إلى الباب الخلفي.
يمكن أن يمر هذا الهجوم المعقد إلى حد ما دون أن يلاحظه أحد حتى يتم الوصول إلى توزيعات Linux المستقرة. ولحسن الحظ، يرغب بعض الأشخاص في التحقق من سبب حدوث أشياء غير طبيعية.
اكتشاف هجوم الباب الخلفي XZ
في كثير من الأحيان يتم اكتشاف السلوك الخبيث عن طريق الصدفة أو الصدفة. وخير مثال كان أ تحذير الإهمال ("من يهتم بالتحذيرات؟") التي أدت إلى اكتشاف هجوم تيار الحدث في أكتوبر 2018. والآخر هو المستخدم الذي حذر كوديكوف في أبريل 2021 أن البرنامج النصي لبرنامج تحميل bash الخاص بهم لم يجتاز المجموع الاختباري ("من يتحقق من سلامة العناصر باستخدام المجاميع الاختبارية"؟) الشذوذات والأعراض الغريبة مع ssh loginق (loginأخذ الكثير من وحدة المعالجة المركزية وزيادة الوقت المنقضي، وأخطاء valgrind) أثار فضول أندريس فرويند، مطور PostgreSQL اليقظ ولكنه ليس محللًا أمنيًا (كما ذكر). بعد بعض التحقيقات مع OpenSSH على Debian Sid، خلص إلى أن مشكلة وقت الاستجابة تعتمد على مكتبة، liblzma، وهي جزء من xz- يوتيلس مكتبة الضغط. السبب: "تم وضع مستودع xz المنبع وكرات القطران xz في باب خلفي". كان هذا التشخيص دقيقًا جدًا! في 29 مارس 2024، نشر أندريس التحليل الأول في Openwall: "الباب الخلفي في المنبع xz/liblzma يؤدي إلى اختراق خادم ssh". الحقيقة: تحتوي كرات القطران XZ Utils 5.6.0 و5.6.1 على باب خلفي. تم إنشاء كرات القطران هذه وتوقيعها بواسطة حساب جيا تان المذكور أعلاه. He نشرت في مستودون في وقت لاحق من ذلك اليوم، أدرك أن الاكتشاف كان عرضيًا وتطلب الكثير من المصادفات. التعليقات من المستخدمين الآخرين تستحق القراءة. مستخدم جيثب com.thesamesam (المعروف أيضًا باسم سام جيمس) نشر جوهرًا لطيفًا الأسئلة المتداولة حول الباب الخلفي xz-utils حيث تم تلخيص الهجوم وربطه بالمزيد تحليلات متعمقة من حمولة الهجوم. كانت هذه التحليلات مثيرة للاهتمام من الناحية الفنية، وساعدتنا على فهم عملية الحقن بشكل أفضل، والتي كانت مفصلة للغاية:- xz/liblzma: شرح التشويش في مرحلة Bash. تحليل جميل لإزالة التشويش بواسطة نص الحقن، في أربع "مراحل".
- خيط فيليبو فالسوردا الأزرق السماوي تحليل الباب الخلفي نفسه في RSA_public_decrypt، والذي يوضح طبيعته: RCE، وليس تجاوز المصادقة، ومسور (يقبل المفتاح الخاص للمؤلف وإذا لم يكن كذلك، يعود إلى السلوك الطبيعي) / غير قابل للسداد. كان المؤلف ينوي الابتعاد عن الأضواء لتجنب اكتشافه!
- تحليل الباب الخلفي XZ بواسطة @smx-smx (WIP) – تحليل إضافي للباب الخلفي (لقد تهت في البداية تقريبًا 😀)
- وثائق الباب الخلفي xz ويكي، تحليل آخر لنص الحقن 5.6.1.
كيف تم التعامل مع الحادثة
كان إفصاح أندرياس فرويند حذرًا لأنه، على حد تعبيره:نظرًا لتداخل المشكلة مع المصدر، لم أُبلغ عن أي خلل في المصدر. ظننتُ في البداية أنها مشكلة خاصة بإصدار ديبيان، فأرسلتُ تقريرًا أوليًا إلى security@...ian.org. ثم أبلغتُ عن المشكلة إلى distros@. CIS"تم إخطار أ بالتوزيع."
من يتعرض للهجوم؟
إما أن حساب GitHub JiaT75 قد تم اختراقه (تذكر أن GitHub قام بتفويض المصادقة الثنائية مؤخرًا) أو أن المستخدم الفعلي الذي يملك الحساب قد ذهب إلى الجانب المظلم. ولكن هناك أسباب مقنعة للتفكير في التهديد المستمر المتقدم (APT)، ربما المدعوم من الدولة، وذلك بسبب التعقيد الفني للهجوم. المزيد من التحقيقات التي تجريها وكالات الأمن السيبراني وإنفاذ القانون ستخبرنا … هذا الدخول في أخبار YCombinator Hacker حول جيا تان يلقي بعض الضوء على "من" ونشاطه. مُستَحسَن! إنه يوفر الكثير من المعلومات حول كيفية محاولة الأشرار خداع المستخدمين الآخرين باستخدام الهندسة الاجتماعية."مزعج للغاية - كان المؤلف الواضح للباب الخلفي على اتصال معي (rwmj) على مدار عدة أسابيع محاولًا إضافة xz 5.6.x إلى Fedora 40 & 41 بسبب "ميزاته الجديدة الرائعة". لقد عملنا معه أيضًا لإصلاح مشكلة valgrind (والتي اتضح الآن أن السبب فيها هو الباب الخلفي الذي أضافه). كان علينا أن نتسابق الليلة الماضية لإصلاح المشكلة بعد الكسر غير المقصود للحظر. لقد كان جزءًا من مشروع xz لمدة عامين، مضيفًا جميع أنواع ملفات الاختبار الثنائية، ولكي أكون صادقًا مع هذا المستوى من التطور، سأكون متشككًا حتى في الإصدارات الأقدم من xz حتى يثبت العكس.
اتخذ جيا تان إجراءات لمنع تعقبه: يبدو أنه استخدم VPN (vpn.singapore.witopia.net) للاتصال - وهو أمر جيد في حد ذاته. ويبدو أن العديد من التغييرات مدعومة برسائل بريد إلكتروني مؤقتة تستخدم لمرة واحدة (من ProtonMail في هذه الحالة) تحث على دمج التغييرات.
قد ينوي الممثل التعمق أكثر، حتى نواة Linux، بصفته المساهم في xy-embedded مشروع. لم يجد التحليل الأولي أي دليل على الإجهاض، حتى اليوم.
ملاحظة: آخر مساهم XZ منخفض المستوى "هانز يانسن" (مستخدم GitHub "hansjans162") هو تحت المجهر. حسابه في دبيان الآن سدت. لقد أجرى العديد من التحديثات على Debian Games لإخفاء التحديث الذي أراده على debian/xz-utils، وهو تحديث للإصدار 5.6.1 من المنبع للإسراع بتوزيع الباب الخلفي على ديبيان/غير مستقر.
كل ما يمكننا قوله، في الوقت الحالي، هو أن هذه التهديدات المستمرة المستمرة (لم يتم التعرف عليها بعد) تستخدم حسابات مختلفة، وتعمل لمدة عامين على الأقل في هذه الحملة، وتعمل بصبر على زرع RCE في SSH.
حتى وقت كتابة هذا التقرير، لا تزال هوية "جيا تان" غير مؤكدة. لم يتم التحقق علنًا من أي نسبة موثوقة إلى فرد أو منظمة أو جهة حكومية محددة، مما يؤكد مدى فعالية انضباط هذه الشخصية في العمليات.
هل كان من الممكن منع هجوم الباب الخلفي XZ؟
صعبة نوعا ما.
أولاً، وصل جزء من البرمجيّة الخبيثة المحقونة إلى ملفات اختبار مضغوطة لم تُستخدم من قِبل الاختبارات. بأثر رجعي، قد يُثير ذلك بعض المخاوف (المزعجة)، ولكن من يهتم بالتحقق من استخدام جميع ملفات الاختبار من قِبل الاختبارات الفعلية في العالم الحقيقي؟ ثانياً، وصل جزء من البرمجيّة الخبيثة المحقونة إلى ملفات ماكرو في ملفات tarballs الإصدارية، ويصعب التحقق يدويًا من الاختلافات مع ملفات tarballs المتوقعة. كما أن الأتمتة مُعقّدة، حيث يصعب نمذجة النتيجة المتوقعة من عملية البناء نفسها (لمن يعرف آلية عمل automake/autoconf) لتحليل ما إذا كانت ملفات tarball الحقيقية تُطابق التوقعات. البعض طرحه as "عدم تطابق كرات القطران من شجرة git هو ميزة، وليس خطأ". يعد مصدر كرات القطران الثنائية من الكود المصدري الخاص بها مشكلة لم يتم حلها.
سمعة المستخدم؟ حسنًا، حساب JiaTan75 GitHub لم يكن يقوم بأشياء مارقة وفقًا للماضي commitس. تم تعليقه فقط بعد تراكم الأدلة، ولكن حتى 29 مارس كان هناك مستخدم عادي يقوم بأعمال عادية. حسنا، ليس طبيعيا جدا. لاحقاً commitق ( , , و (الذي قام بتعديل كود الاستغلال) حاول إصلاح أخطاء valgrind والأعطال في بعض التكوينات، بسبب الاختلافات في تخطيط المكدس المتوقع بواسطة الباب الخلفي. Commit يمكن للمراجعات اكتشاف ذلك، ولكن من لديه الصبر لتحليل التغييرات في ملف اختبار ثنائي أو الدافع الحقيقي للتغيير في سمات مجلس التعاون الخليجي في كود مصدر C؟
ينبغي للمرء أن يثير الإنذارات عندما يكون SSH login يستغرق 800 مللي ثانية بدلا من 300 مللي ثانية؟ من المحتمل أن الأشخاص شديدي الحذر فقط هم من سيأخذون هذه الملاحظة. قال شيشرون، «التهور ينتمي إلى الشباب؛ الحكمة حتى الشيخوخة."
تمت إضافة البنية التحتية لـ ifunc في يونيو 2023 بواسطة "Hans Jansen" و"Jia Tan". هذا هو الاول commit إضافة دعم ifunc إلى crc64_fast.c (تم استخدامه لاحقًا لحقن الباب الخلفي). قبل أشهر من حقن الثنائيات الخلفية في ملفات الاختبار!
ملاحظة: المؤلف و commitهناك اختلاف هنا، ولكن هذا أمر طبيعي: Lasse Collin هو مشرف المشروع، وقد قام بدمج التغييرات. حتى أنه يشكر "هانز يانسن"...
لم يثير أحد المخاوف قبل منشور أندريس فرويند ومكافحة التطرف العنيف الذي أنشأته RedHat. إذا رأيت سلسلة من الأدوات التي يمكنها اكتشاف ذلك، فإنها تكتشف المكون المتأثر الآن، بأثر رجعي.
ربما جاء أفضل وسيلة للوقاية من طبيعة توزيعات Linux، وكيف أن الإصدارات المتطورة غير المستقرة لا تنتقل إلا إلى التوزيعات المستقرة بعد عملية سريعة.
الدروس المستفادة من هجوم XZ bBackdoor
لقد لاحظنا مدى صعوبة اكتشافه مقصود أبواب خلفية. يجب اعتبار الأبواب الخلفية تهديدًا داخليًا، حيث يتم زرعها من قبل موظفين داخليين أو عبر حسابات داخلية معرضة للخطر. وهؤلاء الرجال موثوق بهم في الغالب. وعندما يتم زرع الباب الخلفي في القطعة الأثرية الموزعة، يصبح من الصعب اكتشافها.
بعض المؤلفين مثل كيفن بومونت أشار إلى نظام، الذي يفتح سطح هجوم كبير لخدمات الطرف الثالث إلى الباب الخلفي. وهذا ما أساء إليه الفاعل السيئ هنا. لدى Systemd الكثير من الاهتمام، لكن XZ هي مكتبة غامضة في أعلى السلسلة. "عندما يتلوث أعلى النهر، يشرب الجميع المياه المسمومة عند مجرى النهر".
طلب تغيير غير ذي صلة في النظام لـ تحميل مكتبات الضغط ديناميكيًا، والذي من شأنه إزالة الباب الخلفي، تم دمجه بالفعل في النظام ولكن لم يتم تسليمه بعد. قد تكون التبعيات الإضافية التي يقدمها libsystemd هي مصدر الثغرات الأمنية، وأمس تم فتح هذا الطلب.
A التعليق في "xz: تعطيل ifunc لإصلاح المشكلة" commit أعطى نظرة ثاقبة حول مكان التركيز إذا أردنا منع مثل هذا النشاط (التأكيد هو خاصتي):
"إن الدرس الذي يجب أن نتعلمه كمجتمع هو أكثر أهمية من ذلك software supply chain security بشكل كلي، يتم تدقيق أنظمة البناء بما يتجاوز مجرد كود المصدر. مثل اختراق SolarWinds حيث قام المهاجمون بتعديل تحديثات البرامج لعرض برنامج المراقبة مغلق المصدر الخاص بـ SolarWinds.
الأسئلة الشائعة
هل لا يزال الباب الخلفي XZ يشكل خطراً اليوم؟
تم احتواء الثغرة الأمنية إلى حد كبير، لكنها لم تختفِ تمامًا. في أغسطس 2025، اكتشف الباحثون وجود ثغرة أمنية لا تزال موجودة في العديد من صور Debian Docker Hub، والتي تعاملت معها Debian على أنها بقايا تاريخية غير نشطة. لذا، ينبغي على الفرق التحقق من أنها لا تستخدم صورًا أساسية قديمة وغير مُحدَّثة، بدلًا من افتراض أن تحديث 2024 قد أغلق الثغرة تمامًا.
