هجوم xz Utils: إزاي Jia Tan كسب الثقة وزرع باب خلفي؟

في 29 مارس 2024، نشر مهندس البرمجيات Andres Freund تحذيرًا عن اكتشاف باب خلفي في XZ Utils. القصة بدأت بملاحظة غير عادية: محاولات تسجيل الدخول عن طريق SSH على جهاز تجريبي يعمل بنسخة تطوير من Debian بقت أبطأ بحوالي 500 مللي ثانية، مع استهلاك أعلى للموارد وأخطاء غريبة ظهرت في أداة Valgrind. وهو بيدور على السبب، وصل لمكتبة ضغط اسمها liblzma، واكتشف إن الإصدارين 5.6.0 و5.6.1 من XZ Utils احتووا على كود خبيث كان ممكن يسمح بتنفيذ أوامر عن بُعد قبل اكتمال المصادقة، في أنظمة وتكوينات معينة.

لكن أخطر جزء في القصة إن الهجوم ما بدأش باختراق تقني مباشر. حساب باسم Jia Tan قضى أكتر من سنتين في تقديم مساهمات وبناء سمعة كمطور موثوق، وبالتزامن معاه حسابات تانية يُشتبه إنها وهمية مارست ضغطًا على المشرف الأصلي للمشروع، Lasse Collin، لحد ما Jia Tan حصل على صلاحيات داخل المشروع.

دي مش مجرد قصة ثغرة في Linux؛ دي واحدة من أشهر أمثلة هجمات سلسلة التوريد البرمجية (Supply Chain Attacks)، اللي فيها المهاجم بيستغل ثقة المطورين في مشروع أو مكتبة بيعتمدوا عليها. في المقال هنحكي القصة بالترتيب: إيه هي XZ Utils وليه كانت هدفًا مهمًا، وإزاي اتبنت الثقة واتزرع الباب الخلفي، وإزاي اتكشف قبل ما ينتشر على نطاق واسع، والأهم: إيه الدروس العملية اللي أي مطور يقدر يتعلمها من الحادثة دي.

الخلاصة في أربع نقط:

• في مارس 2024 اتكشف باب خلفي (CVE-2024-3094) في مكتبة xz ، كان ممكن يسمح بتنفيذ أوامر عن بُعد قبل اكتمال المصادقة عبر SSH، لكن في أنظمة وتكوينات محددة.
• الهجوم اتبنى على الصبر: أكتر من سنتين لكسب ثقة المشروع وصلاحيات المشرف، مش على اختراق تقني مباشر.
• اتكشف قبل ما ينتشر على نطاق واسع، بعد ملاحظة تأخير غير طبيعي في اتصالات SSH وأخطاء في أدوات الفحص.
• هوية Jia Tan لسه مش مؤكدة، وأي كلام عن الجهة اللي وراه هو تخمين.

المحتويات

• أولاً: هجوم xz Utils: إيه هي المكتبة وليه كانت هدف
• ثانياً: حملة الصبر: إزاي اتبنت الثقة
• ثالثاً: الباب الخلفي بشكل مبسط
• رابعاً: إزاي اتكشف الهجوم؟
• خامساً: رد الفعل وخط زمني
• سادساً: مين ورا Jia Tan؟ اللي نعرفه واللي لأ
• سابعاً: الصور القديمة على Docker Hub
• ثامناً: دروس عملية للمطور
• تاسعاً: أخطاء شائعة هتقابلك

أولاً: هجوم xz Utils: إيه هي المكتبة وليه كانت هدف

XZ Utils مجموعة أدوات ومكتبة (liblzma) لضغط الملفات. مشروع صغير ومش مشهور بره عالم لينكس، لكنه موجود في توزيعات Linux كتير، وبتستخدمه أدوات تانية بشكل غير مباشر، حتى لو أنت ما اخترتوش بنفسك.

وده جزء من سبب جاذبيته كهدف: مكتبة بتعتمد عليها أدوات كتير، ومشروع مفتوح المصدر كان بيعتمد بدرجة كبيرة على مشرف متطوع واحد. استهداف حلقة موثوقة في سلسلة التوريد ممكن يكون أسهل من مهاجمة كل مستخدم بشكل منفصل. ده اللي بيسموه supply chain attack: بدل ما تهاجم الضحية، بتهاجم حاجة هي بتثق فيها.

ثانياً: حملة الصبر: إزاي اتبنت الثقة

التحقيقات بعد الحادثة لقت إن الحملة بدأت سنة 2021 تقريبًا، ودامت أكتر من سنتين. المراحل العامة كانت كده:

1. حساب باسم Jia Tan بدأ يساهم في المشروع بتعديلات عادية ومفيدة، وبنى سمعة كمساهم موثوق.
2. حسابات تانية يُشتبه إنها وهمية (منها Jigar Kumar وkrygorin4545 وmisoeater91) ضغطت على المشرف الأصلي Lasse Collin علشان يسلّم صلاحيات لناس جداد.
3. Jia Tan خد صلاحيات مشرف على المشروع.
4. الباب الخلفي اتحط في الإصدارين 5.6.0 و5.6.1 في فبراير 2024 تقريبًا.

لاحظ إن التقنية هنا مكانتش المهارة الوحيدة المطلوبة. الاستغلال الحقيقي كان للجانب البشري: مشرف متطوع، ومشروع محتاج مساعدة، وضغط مستمر. للتفاصيل الكاملة مع التواريخ، فيه خط زمني مفصل كتبه Russ Cox، وشرح Lasse Collin نفسه على tukaani.org.

ثالثاً: الباب الخلفي بشكل مبسط

ده شرح مفاهيمي لفهم الفكرة، مش خطوات لإعادة الهجوم. الباب الخلفي كان على مراحل:

• ملفين مضغوطين فيهم كود خبيث، موجودين في مستودع Git لكنهم ساكنين ومحدش بيستخرجهم.
• نسخة خبيثة من ملف البناء m4/build-to-host.m4 كانت موجودة في ملفات الإصدار (tarball) المنشورة، لكنها لم تكن موجودة في مستودع Git بالشكل نفسه.
• الملف ده كان بيستخرج الحمولة الخبيثة من ملفات اختبار متخفية ويضيفها للمكتبة أثناء البناء، مع فحوصات بتخلي تنفيذ المراحل الخبيثة مرتبطًا بظروف وبيئات محددة، منها أنظمة Linux x86-64 وبعض طرق بناء الحزم.

ليه SSH بالذات؟ OpenSSH في حد ذاته مش محتاج xz عادةً. لكن في بعض التوزيعات، تعديلات بتربط sshd بـsystemd بتخلي عملية تسجيل الدخول تحمّل مكتبات مرتبطة بـliblzma. في البيئة دي، الباب الخلفي كان بيقدر يتدخل في التحقق من مفتاح SSH: لو الطلب جاي من صاحب المفتاح الخاص المطابق للمفتاح العام المضمّن في الحمولة الخبيثة، كان ممكن تمرير أوامر للتنفيذ قبل اكتمال المصادقة. ده ما كانش معناه إن أي مستخدم SSH يقدر يستغل الثغرة؛ الاستغلال كان مشروطًا بوجود المكتبة المصابة والتكوين المتأثر وامتلاك المفتاح المطابق.

وده بيوضح نقطة مهمة: الفرق بين الكود اللي بتراجعه في Git والملفات اللي بتتوزع فعليًا. المراجعة على الأول مكانتش هتلقط الثاني. للتفاصيل التقنية، راجع إعلان Andres Freund الأصلي، وتحليل CERT-EU، وسجل CVE-2024-3094 الذي حصل على أعلى تقييم خطورة (CVSS 10.0).

رابعاً: إزاي اتكشف الهجوم؟

Andres Freund، مهندس في Microsoft، كان بيحقق في سلوك غير طبيعي على نسخة تطوير من Debian sid. لاحظ زيادة في زمن محاولات تسجيل الدخول عبر SSH بحوالي 500 مللي ثانية، واستهلاكًا غير معتاد للموارد، وأخطاء ظهرت في Valgrind. تتبّع المؤشرات لحد ما وصل للنسخ المصابة من XZ Utils. نشر تحذيره على قائمة oss-security يوم 29 مارس 2024، بعد ما أبلغ الجهات المعنية.

الدرس هنا مش عن حظ بس. اللي لقاه كان إنسان منتبه لقياس بسيط (زمن واستهلاك موارد) وكمل يسأل “ليه؟”. ده نفس مبدأ المراقبة اللي شرحناه في مقال المراقبة: أحيانًا أول إشارة لمشكلة أمنية بتبقى شذوذ في الأداء.

خامساً: رد الفعل وخط زمني

الإصدارين المصابين كانوا لسه في نسخ التطوير من التوزيعات الكبيرة، ومكانوش اتنشروا على نطاق واسع في أنظمة الإنتاج. الشركات رجعت الحزم لنسخ قديمة، ووكالة CISA الأمريكية نشرت تنبيه بنفس التوصية. وGitHub عطّلت مؤقتًا نسخ المستودع، وCanonical أجلت النسخة التجريبية من Ubuntu 24.04 أسبوع وعملت إعادة بناء كاملة للحزم، رغم إن النسخة المستقرة من Ubuntu مكانتش متأثرة.

سادساً: مين ورا Jia Tan؟ اللي نعرفه واللي لأ

اللي اتأكد منه: Jia Tan اسم مستعار اتستخدم في الحملة، وحسابات ناس تانية اتشتبه إنها وهمية ومكانش ليها أي حضور برمجي ظاهر خارج فترة الحملة.

اللي مش معروف: مين الشخص أو الجهة ورا الاسم، وهل هو شخص واحد أو فريق. ظهرت تحليلات وتكهنات عن احتمال وجود جهة منظمة وموارد كبيرة وراء الحملة، لكن مفيش إسناد علني قاطع يحدد المسؤول عنها. علشان كده، الأفضل نفرّق بين الوقائع المثبتة والتخمينات، وما ننسبش الهجوم لدولة أو مجموعة بعينها من غير دليل واضح.

وللخلفية الصحفية الأشمل، مقال Wired عن Jia Tan والغموض حوله مرجع مفيد.

سابعاً: الصور القديمة على Docker Hub

الحادثة مخلصتش عند اكتشافها في 2024. في أغسطس 2025، باحثون في شركة Binarly أبلغوا عن عشر صور Debian منشورة على Docker Hub، وكانت لا تزال تحتوي على نسخة من الباب الخلفي في وسوم قديمة مرتبطة بصور مارس 2024. رد فريق Debian Cloud أوضح إنه مش الجهة اللي بتدير الصور دي، ووجّه البلاغ إلى القائمين على مستودع صور Debian في Docker Hub؛ وده مختلف عن رفض حذفها. تقدر تراجع تقرير Binarly ورد Debian على البلاغ.

الدرس العملي لو بتبني حاويات زي اللي في مقال Docker: صورة الأساس بتاعتك جزء من سلسلة التوريد، فاختارها بوعي. ووقت تحديث المقال في نوفمبر 2026، كان Debian 13 (Trixie) هو الإصدار المستقر الحالي، وفقًا لـقائمة إصدارات Debian الرسمية.

# BAD: صورة تطوير (sid) بتتغير باستمرار
FROM debian:sid

# BETTER: إصدار مستقر محدد؛ وفي الإنتاج ثبّت الـ digest الموثوق أيضًا
FROM debian:13-slim

ثامناً: دروس عملية للمطور

مش محتاج تكون مشرف توزيعة عشان تستفيد من الحادثة. دي أهم الدروس لمطور تطبيقات:

• اعرف إيه اللي شغال عندك: أنت بتعتمد على مكتبات مكتبتك بتعتمد عليها. اعرف إصدار الحاجات الأساسية على سيرفراتك. الأوامر دي تساعدك في الجرد الأولي، لكنها مش فحصًا أمنيًا كاملًا:

# نسخة xz عندك (الإصدارات المتأثرة كانت 5.6.0 و 5.6.1)
xz --version

# Debian / Ubuntu
dpkg -l | grep xz-utils

# Fedora / RHEL
rpm -q xz

مهم: ما تعتمدش على رقم الإصدار وحده للحكم إن جهازك مصاب أو سليم؛ بعض التوزيعات بتطبّق إصلاحات أمنية على الحزم من غير ما تغيّر رقم الإصدار الأساسي. قارن رقم الحزمة بتنبيه الأمان الرسمي الخاص بتوزيعتك.

• ثبّت الإصدارات: استخدم ملفات القفل (package-lock.json مع npm ci في مشاريع Node) بدل ما كل بناء ياخد “أحدث نسخة” تلقائيًا.
• لا تسارع بالترقية الآلية في الإنتاج: أي نسخة جديدة تستاهل تتراجع وتتفحص في pipeline قبل ما توصل للإنتاج، زي ما شرحنا في مقال الـ CI/CD.
• قلل تعرض SSH: الباب الخلفي كان محتاج يوصل لـ sshd الأول. لو الـ SSH مفتوح بس لعنوانك على الـ firewall، عدد اللي يقدر يستغله بيقل بشكل كبير. ده مرتبط بالأساسيات اللي في مقال أساسيات الشبكات.
• راقب الشذوذ: زيادة غير مفسرة في استهلاك CPU أو زمن تسجيل الدخول تستاهل تحقيق، مش تجاهل.
• لو انت مشرف على مشروع مفتوح: ما تمنحش صلاحيات مشرف تحت ضغط أو إلحاح، وخلي التغييرات الحساسة تتراجع من شخصين. كمان قارن ملفات الإصدار المنشورة (tarballs) بمصدر Git والـtags الموقعة، واستخدم Reproducible Builds وبيانات إثبات مصدر البناء (Build Attestations) قدر الإمكان؛ لأن مراجعة مستودع Git وحده ما كانتش هتكشف الجزء الخبيث الموجود في ملف الإصدار. وتحذير OpenSSF وOpenJS قال إن محاولات مشابهة استهدفت مشاريع JavaScript، وطلبوا من المشرفين ينتبهوا لأي طلب مصحوب بإلحاح واستعجال غير مبرر.

تاسعاً: أخطاء شائعة هتقابلك

• الاعتقاد إن “الكود مفتوح المصدر يعني مراجَع”. المراجعة في الواقع محدودة، وقصة xz أكبر دليل.
• ترقية كل الاعتماديات لأحدث نسخة تلقائيًا في الإنتاج من غير فحص.
• استخدام صور Docker تطويرية أو قديمة كأساس لأنظمة حقيقية.
• التعامل مع الحادثة على إنها مشكلة لينكس بس. نفس الفكرة بتنطبق على npm وPyPI وأي مدير حزم.
• تجاهل الإشارات الصغيرة (بطء بسيط أو سلوك غريب) لأنها “مش مهمة”.
• الجزم بهوية المهاجم أو بحجم الضرر المحتمل من غير مصدر موثوق.

حادثة xz بتفكرنا إن أضعف حلقة في الأمان أحيانًا مش الكود نفسه، لكن سلسلة الثقة اللي بتوصل الكود للمستخدم، وكمان المشروع اللي بيعتمد على متطوع واحد من غير دعم كافٍ. لو استفدت من المقال أو عندك رأي في الدروس دي، قولّي في التعليقات.