IngressNightmare: الثغرة الأمنية في تنفيذ التعليمات البرمجية عن بُعد CVE-2025-1974 وعلاجها

شهد شهر مايو 2025 الكشف العلني عن ثغرة أمنية خطيرة، CVE-2025-1974، التي أطلق عليها اسم IngressNightmare، والتي تؤثر على وحدة تحكم Kubernetes ingress-nginx المنتشرة على نطاق واسع عبر البنى التحتية السحابية الأصلية. تسمح هذه الثغرة للمهاجمين غير المصادق عليهم بحقن تكوينات عشوائية في NGINX، مما قد يؤدي إلى تنفيذ تعليمات برمجية عن بُعد غير مصرح بها واختراق كامل للمجموعة.

كجزء من برنامج زمالة OPSWAT أجرى زملاؤنا تحليلاً تقنيًا متعمقًا لفهم السبب الجذري لهذه المشكلة شديدة الخطورة ومسار استغلالها واستراتيجيات التخفيف من حدتها.

1. يتم تحليل كل تهيئة وتمريرها إلى generTemplate ليتم تنسيقها وفقًا لقوالب NGINX المحددة مسبقًا.
2. بعد ذلك، يقوم testTemplate بالتحقق من صحة التكوين الذي تم إنشاؤه مقابل ثنائي NGINX الأساسي.

تستند جميع تكوينات NGINX إلى قوالب محددة مسبقًا موجودة في ملف nginx.tmpl ضمن الشيفرة المصدرية لـ ingress-nginx:

ضمن دالة إنشاء القالب، تتم معالجة التكوين كما هو موضح في المقتطف البرمجي التالي:

ومع ذلك، فإن التحقق من صحة المدخلات والتعقيم غير كافيين. على وجه التحديد، يتم إدراج حقل uid من كائن Ingress مباشرةً في قالب تكوين NGINX، مما يؤدي إلى إنشاء نقطة حقن. يمكن للمهاجم استغلال ذلك من خلال توفير مدخلات مصممة مثل uid="1234#؛ \n\n\n\n\nn\nحقن_قيمة_الحقنة".

تسمح هذه المدخلات الخبيثة بحقن النطاق العام في قالب NGINX، مما يتيح للمهاجمين تشغيل توجيهات NGINX عشوائية واحتمال تحقيق RCE.

لاستغلال الثغرة، يحتاج المهاجم إلى تحديد توجيه قادر على تنفيذ تعليمات برمجية خبيثة. في البداية، حدّد زملاؤنا توجيه load_module على أنه من المحتمل أن يكون مفيدًا، لأن هذا التوجيه يسمح لـ NGINX بتحميل المكونات الإضافية الخارجية. ومع ذلك، فإن هذا التوجيه مسموح به فقط في المرحلة المبكرة من تحليل التكوين، وهو ما لا يتطابق مع نقطة الحقن التي حددناها.

لحل هذا التحدي، واصلنا المزيد من البحث، مما أدى إلى توجيه ssl_engine، الذي وُصف بأنه "قد يتم تحميل الوحدة النمطية ديناميكيًا بواسطة OpenSSL أثناء اختبار التكوين". أثار هذا الأمر الفضول بسبب قدرته على تحميل الوحدات النمطية ديناميكيًا، مما استلزم إجراء فحص أعمق.

عند بدء التشغيل، يقوم NGINX بتحميل حالته الأولية، ثم يقوم بتحليل ملفات التكوين سطراً بسطر. يتم التعامل مع كل توجيه من خلال بنية nginx_command_t، حيث يستدعي التوجيه ssl_engine مباشرةً أوامر ngx_openssl_commands.

عند تحليل دالة ngx_openssl_commands، اكتشف زملاؤنا أنها تعتمد على دعم OpenSSL، وتحديدًا الدالة ENGINE_by_id التي تُستخدم لوحدات SSL المُسرّعة للأجهزة.

وأثناء تحليل الدالة ENGINE_by_id، قررنا أنها تتيح التحميل الديناميكي للمكتبات المشتركة. علاوة على ذلك، إذا تم تجميع المكتبة بامتداد __attribute_____((المُنشئ) )، يمكن تنفيذ الدالة المرتبطة بها فور تحميلها. يشير هذا إلى أنه من خلال استغلال توجيه ssl_engine، يمكن للمهاجم تحميل مكتبات مشتركة عشوائية على المضيف، مما قد يؤدي إلى RCE.

بشكل افتراضي، عندما يتجاوز الطلب الوارد 8 كيلوبايت، يكتب NGINX نص الطلب إلى ملف مؤقت موجود في /tmp/nginx/client-body، باستخدام اسم ملف بالصيغة cfg-{random_value}. يتم الاحتفاظ بهذه الملفات المؤقتة لمدة تصل إلى 60 ثانية بين الأجزاء الناجحة للرسالة المستلمة.

بعد كتابة نص طلب جزئي إلى ملف مؤقت، يؤجل NGINX الحذف حتى يتم استلام النص بالكامل. إذا ظلّ الطلب غير مكتمل ولم يتم استلام أي بيانات لمدة تصل إلى 60 ثانية، يتم حذف الملف في النهاية. ومع ذلك، من خلال حجب الجزء الأخير من البيانات عن قصد، يمكن للمهاجم الاحتفاظ بالملف المؤقت قيد الاستخدام، مما يجعله قابلاً للاستغلال.

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

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

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

ثم صاغ زملاؤنا طلبًا بقيمة مضخمة لطول المحتوى (على سبيل المثال، 1 ميغابايت) لإحداث عدم تطابق في الحجم. وقد تسبب ذلك في قيام NGINX بتخزين الجسم بالكامل بدلاً من معالجته على الفور، مما يضمن كتابة الكائن المشترك في موقع يمكن التنبؤ به.

يتطلب نجاح RCE بنجاح أن يشير توجيه ssl_engine إلى المسار الصحيح للملف المخزن مؤقتًا. يمكن تحقيق ذلك من خلال برنامج نصي آلي للقوة الغاشمة يقوم بشكل منهجي بتكرار مجموعات محتملة من معرّفات العمليات وواصفات الملفات لتحديد الرابط الرمزي الصحيح الذي يشير إلى الكائن المشترك المخزن مؤقتًا.

فيما يلي عينة من قالب NGINX الذي تم إنشاؤه والذي أدى إلى تشغيل الثغرة.

عند الاستغلال الناجح، يمكن للمهاجم الوصول إلى shell في سياق جراب ingress-nginx، والذي يمكنه افتراضيًا الوصول إلى أسرار مجموعة Kubernetes الحساسة.