CVE-2024-3094: اكتشاف ثغرة أمنية خطيرة في RCE في XZ Utils

تم التعرف على الباب الخلفي في الإصدارات 5.6.0 و 5.6.1 من XZ Utils (المعين CVE-2024-3094)، والتي قد تسمح في بعض الظروف بـ RCE عبر مصادقة SSH في إصدارات محددة من توزيعات Linux معينة.

• 31 مارس 2024 – رسم تخطيطي محدث بناءً على المعلومات التي تم الكشف عنها حديثًا

• 1 أبريل 2024 – تم تحديث جدول الإصدارات المتأثرة بناءً على أحدث النصائح

• 3 أبريل 2024 – تمت إضافة نتائج بحثية جديدة

تم العثور على تعليمات برمجية ضارة في الحزم المصدرية لمشروع XZ، بدءًا من الإصدار 5.6.0. من خلال سلسلة من عمليات التشويش المعقدة، يتم استخدام ملف اختبار مخفي داخل الكود المصدري أثناء عملية التشويش liblzma عملية تجميع لاستخراج ملف كائن مترجم مسبقًا. يقوم هذا الملف بعد ذلك بتغيير وظائف معينة داخل الملف liblzma شفرة. ونتيجة لذلك، يؤدي هذا إلى التسوية liblzma المكتبة، والتي تؤثر على OpenSSH عندما تكون مدعومة systemd إشعار. هذا بسبب libsystemd يعتمد على lzmaويمكن للباب الخلفي اعتراض عمليات تبادل البيانات وتغييرها. على وجه التحديد، تستخدم بعض توزيعات Linux هذه المكتبة لـ SSH، وبالتالي قد تكون عرضة لتنفيذ التعليمات البرمجية عن بعد.

التعليمات البرمجية الضارة غامضة ولا يمكن العثور عليها إلا في الإصدارات التي تم إصدارها (لتوزيعات Linux محددة)، وليس في توزيع جيت، الذي يفتقر إلى الماكرو M4، الذي يؤدي إلى تشغيل عملية إنشاء الباب الخلفي. في حالة وجود الماكرو الضار، فسيتم حقن عناصر المرحلة الثانية الموجودة في مستودع Git أثناء وقت الإنشاء.

مؤلف الكود الخبيث (@JiaT75) وبحسب ما ورد قدم أيضًا رمزًا لمشروع oss-fuzz ربما يكون ذلك قد منع هذا الضباب على وجه التحديد من اكتشاف الباب الخلفي الذي زرعوه في XZ Utils.

وفقًا لبيانات Wiz، على الرغم من أن XZ Utils نفسها منتشرة بشكل كبير، إلا أن ما يقرب من 2٪ فقط من البيئات السحابية لديها مثيلات ذات إصدارات عرضة لـ CVE-2024-3094.

وفق ريبولوجي، هناك العديد من التوزيعات التي من المحتمل أن تتأثر بـ CVE-2024-3094، لكن Wiz سيقوم بتحديث هذا الجدول بمعلومات محددة حيث يقوم البائعون بمعالجة الثغرة الأمنية علنًا:

• اتبع الإرشادات الواردة في الجدول أعلاه لكل توزيعة Linux.

• نصحت CISA بالرجوع إلى إصدار XZ Utils غير المنقوص (أقدم من 5.6.0) والبحث عن أي نشاط ضار أو مشبوه على الأنظمة التي تم تثبيت الإصدارات المتأثرة عليها.

يمكن لعملاء Wiz استخدام الاستعلام والاستشارات المعدة مسبقًا في Wiz Threat Center للبحث عن المثيلات الضعيفة في بيئتهم. لمزيد من التفاصيل، راجع الاستشارة داخل المنتج.

يعتمد هذا القسم على التحليل الذي أجراه أندريس فرويند، الذي اكتشف هذا الباب الخلفي بعد ملاحظة سلوك غير عادي مرتبط به sshd. لاحظ ذلك sshd كان يستهلك كمية كبيرة بشكل مدهش من وحدة المعالجة المركزية أثناء عملية تسجيل الدخول. بالإضافة إلى ذلك، واجه العديد من الأخطاء أثناء استخدام الملف “فالغريند” أداة للتوصيف وتصحيح أخطاء الذاكرة، مما دفعه إلى إجراء مزيد من التحقيق.

كجزء من عملية بناء XZ، تم إنشاء Build-to-Host.m4 يتم تنفيذ البرنامج النصي. يحتوي هذا البرنامج النصي على السطر التالي: gl_[$1]config='sed "r\n" $gl_am_configmake | eval $gl_path_map | $gl[$1]_prefix -d 2>/dev/null'، والذي يقوم بإدخال برنامج نصي مبهم ليتم تنفيذه في نهاية البرنامج النصي للتكوين. هذا البرنامج النصي مسؤول عن إنشاء ملفات MakeFiles لـ xz-utils وliblzma.

أثناء تنفيذ البرنامج النصي المبهم، فإنه يتحقق من شرطين من بين أمور أخرى: فهو يحدد ما إذا كان نظام التشغيل هو x86-64 Linux وما إذا كان جزءًا من بنية حزمة Debian أو RPM. يهدف البرنامج النصي بشكل أساسي إلى تعديل ملف MakeFile الخاص بـ liblzma من أجل التدخل في عملية تحليل الرموز الخاصة به في وقت التشغيل، ولا سيما التسبب في RSA_public_decrypt@....pl رمز للإشارة إلى رمز الباب الخلفي الخبيث الخاص به.

وكشف المزيد من التحليل أنه خلال عملية مصادقة المفتاح العام sshd، ال RSA_public_decrypt@....pl يتم استدعاء الوظيفة، مما يتسبب في تنفيذ التعليمات البرمجية للمهاجم. يعمل هذا الرمز من خلال محاولة استخراج حمولة من المفتاح العام الذي يتم تمريره إليه أثناء عملية المصادقة. تخضع هذه الحمولة لسلسلة من خطوات التحقق وفحوصات التوقيع. إذا نجحت الحمولة في اجتياز هذه الاختبارات، فسيتم نقلها بعد ذلك إلى مكتبة libc system() وظيفة. تم تصميم هذه الوظيفة لتنفيذ الحمولة. ولذلك، فهو عبارة عن تنفيذ تعليمات برمجية عن بعد (RCE)، وليس تجاوز المصادقة.

علاوة على ذلك، تشير متطلبات الاستغلال الملحوظة إلى أن المهاجم كان ينوي تعقيد عملية التحليل للباحثين.

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

if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1); then 

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64"; then

بالإضافة إلى ذلك، تمت ملاحظة العديد من متطلبات وقت التشغيل للاستغلال:

• لا يجب تعيين متغير البيئة TERM – يتم تعيين هذا المتغير في اتصال خادم وعميل SSH بعد بدء عملية المصادقة، وبالتالي إذا لم يتم تعيينه، فهذا يعني أن العملية لم تبدأ بعد، وهي على وجه التحديد المرحلة التي يستهدفها استغلال الثغرات.

• المسار إلى الثنائي قيد التشغيل حاليًا، argv[0]، يجب أن يكون /usr/sbin/sshd – وهذا يعني أن التعليمات البرمجية الضارة لن تعمل إلا عندما يستخدم sshd مكتبة libzlma. لن يكون ذا صلة عندما تستخدم الثنائيات الأخرى مكتبة liblzma المصابة.

• متغيرات البيئة LD_DEBUG و LD_PROFILE يجب ألا يتم ضبطه – لتجنب كشف عملية تداخل دقة الرمز وغيرها من عمليات التلاعب بالرابط/المحمل.

• ال LANG يجب تعيين متغير البيئة – كما يتم تعيين sshd دائمًا LANG.

• يكتشف الاستغلال ما إذا كانت أدوات التصحيح مثل rr و gdb يتم استخدامها، وإذا كان الأمر كذلك، فلن يتم تشغيلها – وهي تقنية كلاسيكية لمكافحة تصحيح الأخطاء.

تعمل Wiz Research حاليًا على إجراء هندسة عكسية للباب الخلفي لـ XZ Utils من أجل دعم جهودنا الهندسية في الكشف ذات الصلة. وفي سياق بحثنا، توصلنا إلى النتائج التالية التي نعتقد أنها مفيدة جزئيًا لهذا الغرض، وقررنا مشاركتها علنًا حتى يتمكن الآخرون من الاستفادة منها أيضًا. لم نر هذه النتائج المحددة تمت مناقشتها في مكان آخر حتى وقت النشر.

خطافات متعددة

لقد حددنا منطقًا لربط أكثر من وظيفة واحدة:

1. RSA_public_decrypt – الخطاف الأساسي، وهو معروف بالفعل في هذه المرحلة.

2. EVP_PKEY_set1_RSA – خطاف آخر سيتم استخدامه في حالة عدم وجود الخطاف الأساسي.

3. RSA_get0_key – خطاف آخر سيتم استخدامه في حالة عدم وجود الخطاف الأساسي.

هنا يمكننا أن نرى عمليات التحقق التي تقارن أسماء الرموز بوظائف متعددة محتملة للربط. يتم تشويش جميع السلاسل الموجودة في الكود والإشارة إليها بمعرف فريد كما هو موضح هنا:

نحن نقدر أنه ربما تمت إضافة هذه الوظيفة بسبب RSA_public_decrypt تم إهماله حاليًا وقد لا يتم استخدامه في المستقبل. نحن نفترض أن هذا ربما كان وسيلة لمنفذ التهديد لتأمين الباب الخلفي في المستقبل، حيث أن تحديث هذه المنطقة من كود المصدر بشكل منتظم قد يثير الشكوك؛ يقع أصل النقطة التي تحتوي على الباب الخلفي في ملف اختبار محدد للغاية ولا يضمن إجراء تحديثات متكررة، لذا فإن تحديثه بشكل دوري قد يثير الدهشة.

إخفاء المفتاح العام من سجلات SSH المطولة

كما وثق أنتوني ويمز، يتم إخفاء الأوامر التي يرسلها المهاجم إلى الباب الخلفي كمعلومات مفتاح عام كجزء من مصافحة SSH. وهذا يعني أنه عندما sshd يقوم الخادم بتسجيل تلك المعلومات عند تعيين التسجيل على مطول أو أعلى، فمن المحتمل أن يكون المستخدم (أو أي شخص يراجع السجلات في وقت لاحق) قد لاحظ سلسلة من حالات فشل المصادقة الواضحة، كل منها بتجزئة RSA-CERT مختلفة. على سبيل المثال:

Failed publickey for root from 172.17.0.1 port 55794 ssh2: RSA-CERT ...

ومع ذلك، من أجل التخفيف من هذا الأمر وتجنب الشك (وجعل أي تحقيقات مستقبلية أكثر صعوبة)، نفذ المهاجم 3 طرق على الأقل لإخفاء المفتاح العام من السجلات المطولة:

الطريقة الأولى: المفتاح العام المزيف المشفر

بعد تنفيذ الأمر الذي أرسله المهاجم (باستخدام system)، يستبدل الباب الخلفي كائن مفتاح RSA العام بمفتاح ثابت تم إنشاؤه مسبقًا. هنا يمكننا أن نرى منطق إنشاء مفتاح RSA الوهمي وتجاوز المفتاح الأصلي:

ومن المثير للاهتمام، أنه إذا فشلت هذه الخطوة لأي سبب من الأسباب، فسيخرج الباب الخلفي من العملية فجأة بدلاً من استئناف التدفق الطبيعي للبرنامج. ونقدر أن هذا قد يشير إلى أهمية وظيفة التهرب الدفاعي للمهاجم.

سيظهر المفتاح العام المزيف في السجلات المطولة بالتنسيق التالي. لاحظ أن تجزئة RSA في السجل متسقة (RSA-CERT G1Q+4a0TgAHnlq2B8BKLZUP6wDHsjX6F5nVtUTU3dBQ و CA RSA s3cBHP6c4j0tLaNyEE5f/1n7gjKuOJn8AWxp+nRPD7c)، مما يعني أن هذه الطريقة تولد عناصر يمكن استخدامها لأغراض الكشف على خوادم SSH مع تمكين التسجيل المطول، ما لم يستخدم المهاجم إحدى الطريقتين الأخريين الموضحتين أدناه.

Connection from 172.17.0.1 port 51300 on 172.17.0.2 port 22 rdomain ""
Failed publickey for root from 172.17.0.1 port 51300 ssh2: RSA-CERT SHA256:G1Q+4a0TgAHnlq2B8BKLZUP6wDHsjX6F5nVtUTU3dBQ ID  (serial 0) CA RSA SHA256:s3cBHP6c4j0tLaNyEE5f/1n7gjKuOJn8AWxp+nRPD7c
Connection from 172.17.0.1 port 51316 on 172.17.0.2 port 22 rdomain ""
Failed publickey for root from 172.17.0.1 port 51316 ssh2: RSA-CERT SHA256:G1Q+4a0TgAHnlq2B8BKLZUP6wDHsjX6F5nVtUTU3dBQ ID  (serial 0) CA RSA SHA256:s3cBHP6c4j0tLaNyEE5f/1n7gjKuOJn8AWxp+nRPD7c

الطريقة الثانية: تصفية إدخال السجل

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

Connection from 172.17.0.1 port 49038 on 172.17.0.2 port 22 rdomain ""
Connection from 172.17.0.1 port 59032 on 172.17.0.2 port 22 rdomain ""

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

الطريقة الثالثة: استبدال إدخال السجل

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

في هذه الطريقة البديلة، يستبدل الباب الخلفي إدخالات السجل التي تصف الاتصالات الناجحة بإدخالات تصف محاولات الاتصال الفاشلة، والتي ستبدو كما يلي:

Connection from 172.17.0.1 port 46722 on 172.17.0.2 port 22 rdomain ""
Connection closed by authenticating user root 172.17.0.1 port 46722 [preauth]

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