يمكن أن تؤدي هجمات إعادة التسلسل - أي التلاعب غير المصرح به بالبيانات المتسلسلة لتنفيذ تعليمات برمجية خبيثة - إلى إلحاق أضرار جسيمة بالمؤسسات. يجب على المطورين وفرق الأمن تحديد نقاط الضعف الرئيسية بشكل استباقي والتي تكشف عن كيفية حدوث الهجوم ومتى وأين حدث.
أحد الأمثلة الحديثة على هذا التهديد هو CVE-2023-3404040، وهو ناقل هجوم إلغاء التهيئة في Spring ل Apache Kafka والذي يمكن أن يؤدي إلى تنفيذ التعليمات البرمجية عن بُعد (RCE). في الواقع، تم تسليط الضوء على انتشار ثغرات إلغاء التهيئة من خلال قائمة OWASP لأهم 10 ثغرات، والتي تتضمن "إلغاء تهيئة البيانات غير الموثوق بها" كواحدة من أهم 10 مخاطر أمنية لتطبيقات الويب.
تُعدّ أدوات مثل OPSWAT MetaDefender Core™ مع محرك SBOMSoftware فاتورة الموادSoftware ) الخاص بها ضرورية في اكتشاف هجمات إلغاء التحويل ومنعها. فهي تسمح للمطوّرين بفحص وتحليل التعليمات البرمجية الخاصة بهم بكفاءة، مما يضمن عدم التغاضي عن أي ثغرات أمنية.
سيناقش زملاؤنا الخريجون في هذه المدونة تفاصيل CVE-2023-340404040 واستغلالها، وكيفية تأمين المكونات مفتوحة المصدر ضد التهديدات المماثلة.
حول CVE-2023-3404040
يكشف CVE-2023-3404040 عن ناقل هجوم إلغاء التسلسل في Spring لـ Apache Kafka، والذي يمكن استغلاله عند تطبيق تكوين غير عادي. تسمح هذه الثغرة الأمنية للمهاجمين بإنشاء كائن متسلسل خبيث في أحد رؤوس سجلات الاستثناءات لإلغاء التسلسل، مما قد يؤدي إلى حدوث عملية استيلاء على RCE. تؤثر هذه الثغرة على إصدارات Spring for Apache Kafka من 2.8.1 إلى 2.9.10 و3.0.0 إلى 3.0.9.
على وجه التحديد، يكون التطبيق/المستهلك عرضة للخطر في ظل التكوينات والشروط المحددة التالية:
- لم يتم تكوين فئة ErrorHandlingDeserializer لمفتاح و/أو قيمة السجل.
- يتم تعيين خاصيتي checkDeserExWhenKeyNull و/أو checkDeserExWhenValueNull للمستهلك على صواب.
- يُسمح للمصادر غير الموثوقة بالنشر إلى موضوع كافكا.
أباتشي كافكا
أباتشي كافكا، الذي طورته مؤسسة أباتشي Software هو عبارة عن منصة تدفق أحداث موزعة مصممة لالتقاط تدفقات البيانات في الوقت الحقيقي ومعالجتها والاستجابة لها وتوجيهها من مصادر مختلفة، بما في ذلك قواعد البيانات وأجهزة الاستشعار والأجهزة mobile .
على سبيل المثال، يمكنه بث الإشعارات إلى الخدمات التي تتفاعل مع أنشطة العملاء، مثل إكمال عملية دفع المنتج أو إجراء عملية دفع.
في Apache Kafka، يعمل الحدث - الذي يشار إليه أيضًا باسم السجل أو الرسالة - كوحدة بيانات تمثل حدثًا في التطبيق كلما تمت قراءة البيانات أو كتابتها. يتضمن كل حدث مفتاحًا وقيمة وطابعًا زمنيًا ورؤوس بيانات وصفية اختيارية.
| مفتاح ثنائي (يمكن أن يكون فارغًا) | قيمة-ثنائية (يمكن أن تكون فارغة) | ||||
| نوع الضغط [لا شيء، gzip، gzip، snappy، lz4، zstd] | |||||
الرؤوس (اختياري)
| |||||
| التقسيم + الإزاحة | |||||
| الطابع الزمني (تعيين النظام أو المستخدم) | |||||
يتم تخزين الأحداث بشكل دائم وتنظيمها في مواضيع. يُطلق على تطبيقات العميل التي ترسل (تكتب) الأحداث إلى مواضيع كافكا اسم "المنتجين"، بينما تُعرف التطبيقات التي تشترك في الأحداث (تقرأ وتعالج) باسم "المستهلكين".
سبرينغ لأباتشي كافكا
لربط Apache Kafka مع نظام Spring البيئي، يمكن للمطورين استخدام Spring for Apache Kafka، مما يبسط التكامل في تطبيقات Java.
يوفر Spring for Apache Kafka أدوات وواجهات برمجة تطبيقات قوية تبسّط عملية إرسال الأحداث واستقبالها مع Kafka، مما يمكّن المطورين من إنجاز هذه المهام دون الحاجة إلى ترميز واسع ومعقد.
التسلسل وإلغاء التسلسل
التسلسل هو آلية لتحويل حالة الكائن إلى سلسلة أو دفق بايت. في المقابل، فإن إعادة التسلسل هي العملية العكسية حيث يتم تحويل البيانات المتسلسلة إلى الكائن أو بنية البيانات الأصلية. تسمح التسلسلية بتحويل البيانات المعقدة بحيث يمكن حفظها في ملف أو إرسالها عبر شبكة أو تخزينها في قاعدة بيانات. التسلسل وإلغاء التسلسل ضروريان لتبادل البيانات في الأنظمة الموزعة وتعزيز التواصل بين المكونات المختلفة لتطبيق برمجي. في جافا، يتم استخدام كتابة كائن() للتسلسل وقراءة كائن() لإلغاء التسلسل.
نظرًا لأن إعادة التهيئة تسمح بتحويل دفق البايت أو السلسلة إلى كائن، فإن المعالجة غير السليمة أو عدم التحقق من صحة البيانات المدخلة بشكل صحيح يمكن أن يؤدي إلى ثغرة أمنية كبيرة، مما قد يؤدي إلى هجوم RCE.
تحليل نقاط الضعف
وفقًا لوصف مكافحة التطرف العنيف، قام زملاء OPSWAT بتهيئة CheckDeserExWhenKeyNull و checkDeserExWhenValueNull إلى صواب من أجل تفعيل الثغرة الأمنية. من خلال إرسال سجل بمفتاح/قيمة فارغ وإجراء تحليل مفصل عن طريق تصحيح أخطاء المستهلك أثناء تلقيه سجل كافكا من المنتج، اكتشف زملاؤنا الخريجون سير العمل التالي أثناء معالجة السجل
الخطوة 1: استلام السجلات (الرسائل)
عند تلقي السجلات، يقوم المستهلك باستدعاء طريقة invokeIfHaveRecords() ، والتي تستدعي بعد ذلك طريقة invokeListener() لتشغيل مستمع سجلات مسجل (فئة مشروحة بشرح @KafkaListener ) للمعالجة الفعلية للسجلات.
ثم يستدعي أسلوب invokeListener() أسلوب invokeOnMessage().
الخطوة 2: التحقق من السجلات
ضمن أسلوب invokeOnMessage() ، يتم تقييم العديد من الشروط مقابل قيمة السجل وخصائص التكوين، والتي تحدد لاحقًا الخطوة التالية التي سيتم تنفيذها.
إذا كان السجل يحتوي على مفتاح أو قيمة فارغة وتم تعيين خاصيتي checkDeserExWhenKeyNull و/أو checkDeserExWhenValueNull على صواب، فسيتم استدعاء أسلوب checkDeser() لفحص السجل.
الخطوة 3: التحقق من الاستثناء من الرؤوس
في checkDesr()، يستدعي المستهلك باستمرار getExceptionFromHeader() لاسترداد أي استثناءات من البيانات الوصفية للسجل، إن وجدت، ويخزن النتيجة في متغير يسمى استثناء.
الخطوة 4: استخراج الاستثناء من الرؤوس
تم تصميم طريقة getExceptionFromHeader() لاستخراج استثناء من رأس سجل كافكا وإرجاعه. يسترجع أولاً رأس السجل ثم يحصل على قيمة الرأس، والتي يتم تخزينها في مصفوفة بايت.
بعد ذلك، يُعيد توجيه مصفوفة البايت من قيمة الرأس إلى أسلوب byteArrayToDeserializationException() لمزيد من المعالجة.
الخطوة 5: إعادة ترميز البيانات
في الدالة byteArrayToDeserializationException()، يتم تجاوز الدالة resolClass() لتقييد إلغاء التحويل إلى فئات مسموح بها فقط. يمنع هذا الأسلوب إلغاء تهيئة أي فئة غير مسموح بها صراحةً. لا يمكن إلغاء تسلسل قيمة مصفوفة البايت للرأس داخل الدالة (byteArrayToDeserializationException() إلا إذا كانت تستوفي الشرط المحدد في الدالة (resolClass()، والتي تسمح بإلغاء التسلسل لفئة DeserializationException حصريًا.
ومع ذلك، فإن صنف DeserializationException يوسع صنف الاستثناء القياسي ويتضمن مُنشئًا بأربع معلمات. تمثل المعلمة الأخيرة، وهي السبب، الاستثناء الأصلي الذي أدى إلى حدوث DeserializationException، مثل استثناء IOException أو استثناء عدم العثور على الفئة.
تعمل فئة Throwable كفئة فائقة لجميع الكائنات التي يمكن طرحها كاستثناءات أو أخطاء في Java. في لغة برمجة جافا، يمكن إلغاء تسلسل فئات التعامل مع الاستثناءات مثل Throwable و Exrowception و Error بأمان. عندما يتم إلغاء تسلسل الاستثناء، تسمح جافا بتحميل الفئة القابلة للرمي للفئات القابلة للرمي وتكوينها مع عمليات فحص أقل تطلبًا من تلك المطبقة على الفئات العادية.
استنادًا إلى سير العمل والتحليل الشامل، إذا كانت البيانات المتسلسلة تتوافق مع فئة خبيثة ترث من الفئة الأم Throwable، فقد تتجاوز عمليات التحقق من الحالة. يسمح ذلك بإلغاء تسلسل كائن خبيث، مما قد يؤدي إلى تنفيذ تعليمات برمجية ضارة وربما يؤدي إلى هجوم RCE.
الاستغلال
كما هو مبين في التحليل، يتطلب استغلال هذه الثغرة إنشاء بيانات خبيثة يتم إرسالها إلى المستهلك عبر سجل رأس كافكا. في البداية، يجب على المهاجم إنشاء فئة خبيثة توسع فئة Throwable ثم استخدام سلسلة أدوات لتحقيق تنفيذ التعليمات البرمجية عن بعد. الأدوات الذكية عبارة عن مقتطفات من التعليمات البرمجية القابلة للاستغلال داخل التطبيق، ومن خلال ربطها معًا، يمكن للمهاجم الوصول إلى "أداة بالوعة" تؤدي إلى إجراءات ضارة.
فيما يلي فئة خبيثة يمكن استخدامها لاستغلال هذه الثغرة في Spring لـ Apache Kafka:
بعد ذلك، يتم إنشاء مثيل للفئة الخبيثة وتمريره كوسيطة إلى معلمة السبب في مُنشئ فئة DeserializationException. ثم يتم تسلسل مثيل DeserializationException إلى دفق بايت، والذي يُستخدم لاحقًا كقيمة في رأس سجل كافكا الخبيث.
إذا نجح المهاجم في خداع الضحية لاستخدام منتجه الخبيث، يمكنه التحكم في سجلات كافكا المرسلة إلى المستهلك، مما يخلق فرصة لاختراق النظام.
عندما يتلقى المستهلك الضعيف سجل Kafka من المنتج الخبيث الذي يحتوي على مفاتيح وقيم فارغة، إلى جانب مثيل متسلسل خبيث في رأس السجل، يقوم المستهلك بمعالجة السجل، بما في ذلك عملية إلغاء التسلسل. وهذا يؤدي في النهاية إلى تنفيذ التعليمات البرمجية عن بعد، مما يسمح للمهاجم باختراق النظام.
تخفيف حدة CVE-2023-3404040 باستخدام SBOM في MetaDefender Core
للتخفيف بفعالية من المخاطر المرتبطة بفيروس CVE-2023-3404040، تحتاج المؤسسات إلى حل شامل يوفر رؤية وتحكمًا في مكوناتها مفتوحة المصدر.
توفر SBOM، وهي تقنية أساسية في MetaDefender Core إجابة قوية. من خلال العمل كمخزون شامل لجميع مكونات البرمجيات والمكتبات والتبعيات المستخدمة، تمكّن SBOM المؤسسات من تتبع وتأمين وتحديث مكوناتها مفتوحة المصدر بطريقة استباقية وفعالة.
باستخدام SBOM، يمكن للفرق الأمنية
- تحديد موقع المكونات المعرضة للخطر بسرعة: التحديد الفوري للمكونات مفتوحة المصدر المتأثرة بهجمات إلغاء التسلسل. وهذا يضمن اتخاذ إجراء سريع إما في تصحيح المكتبات الضعيفة أو استبدالها.
- ضمان التصحيح والتحديثات الاستباقية: راقب باستمرار المكونات مفتوحة المصدر من خلال SBOM للبقاء في طليعة الثغرات الأمنية في عملية التصحيح. يمكن ل SBOM الكشف عن المكونات القديمة أو غير الآمنة، مما يسمح بإجراء التحديثات في الوقت المناسب وتقليل التعرض للهجمات.
- الحفاظ على الامتثال وإعداد التقارير: تساعد SBOM المؤسسات على تلبية متطلبات الامتثال حيث تفرض الأطر التنظيمية بشكل متزايد الشفافية في سلاسل توريد البرمجيات.
الأفكار إغلاق
تعتبر ثغرات إلغاء التهيئة تهديداً أمنياً كبيراً يمكن استخدامه لاستغلال مجموعة واسعة من التطبيقات. تحدث هذه الثغرات عندما يقوم التطبيق بإلغاء تهيئة البيانات الضارة، مما يسمح للمهاجمين بتنفيذ تعليمات برمجية عشوائية أو الوصول إلى معلومات حساسة. تُعد الثغرة الأمنية CVE-2023-3404040 في Spring ل Apache Kafka بمثابة تذكير صارخ بمخاطر هجمات إلغاء التهيئة.
للوقاية من هجمات التصحيح، من الضروري تطبيق أدوات متقدمة مثل OPSWAT MetaDefender Core وتقنية SBOM الخاصة بها. يمكن للمؤسسات الحصول على رؤية عميقة في سلسلة توريد البرمجيات الخاصة بها، وضمان تصحيح الثغرات الأمنية في الوقت المناسب، وحماية نفسها من مشهد التهديدات المتطور باستمرار. إن تأمين المكونات مفتوحة المصدر بشكل استباقي ليس مجرد ممارسة فضلى - بل هو ضرورة لحماية الأنظمة الحديثة من الاستغلال المحتمل.
