تعتبر الثغرات الأمنية في البرمجيات من أخطر التهديدات التي تواجه المؤسسات، حيث يمكن أن تؤدي إلى تسرب البيانات أو استغلال الأنظمة. في هذا المقال، نستعرض ثغرة حرجة في Splunk Enterprise وكيف يمكن للمهاجمين استغلالها.
ثغرة حرجة في Splunk Enterprise تتيح للمهاجمين تنفيذ التعليمات البرمجية دون مصادقة
أصدرت شركة Splunk تحديثات أمنية لمعالجة ثغرة أمنية حرجة في Splunk Enterprise يمكن استغلالها لإجراء عمليات ملفات غير مصادق عليها وحتى تنفيذ التعليمات البرمجية عن بُعد.
تُعَد الثغرة، التي تم تتبعها على أنها CVE-2026-20253، مصنفة بمعدل 9.8 على نظام تقييم CVSS.
قالت Splunk في تنبيهها هذا الأسبوع: “في إصدارات Splunk Enterprise التي تقل عن 10.2.4 و10.0.7، يمكن لمستخدم غير مصادق عليه إنشاء أو تقليص ملفات عشوائية من خلال نقطة نهاية خدمة PostgreSQL sidecar.”
“توجد الثغرة لأن نقطة نهاية خدمة PostgreSQL sidecar تفتقر إلى ضوابط المصادقة، مما يسمح لأي مستخدم يمكنه الوصول إلى الشبكة بتنفيذ عمليات الملفات دون الحاجة إلى بيانات اعتماد.”
تم معالجة المشكلة في الإصدارات التالية –
- Splunk Enterprise 10.0.0 إلى 10.0.6 – تم إصلاحها في 10.0.7
- Splunk Enterprise 10.2.0 إلى 10.2.3 – تم إصلاحها في 10.2.4
- Splunk Enterprise 10.4 – غير متأثر
قالت Splunk، التي هي جزء من Cisco، إن Splunk Cloud غير متأثر بالثغرة لأن PostgreSQL sidecars غير مستخدمة في المنتج.
ما هي الثغرة؟
في يوم الجمعة، أصدرت مختبرات watchTowr تفاصيل فنية إضافية حول CVE-2026-20253، مشيرة إلى أنه يمكن استغلالها لتحقيق تنفيذ التعليمات البرمجية عن بُعد قبل المصادقة على الأنظمة المعرضة من خلال نقاط النهاية “/v1/postgres/recovery/backup” و”/v1/postgres/recovery/restore”.
تعمل سلسلة الهجمات كما يلي –
- الاتصال بقاعدة بيانات يتحكم فيها المهاجم وتفريغ محتوياتها في ملف عشوائي باستخدام نقطة النهاية /backup
- تحميل تفريغ قاعدة البيانات التي يتحكم فيها المهاجم إلى مثيل PostgreSQL المحلي باستخدام نقطة النهاية /restore من خلال تضمين وسيط “passfile” الذي يحدد المسار إلى ملف “.pgpass” (“/opt/splunk/var/packages/data/postgres/.pgpass”) الذي يحتوي على كلمة مرور المستخدم “postgres_admin”
- سيتم تنفيذ الاستعلامات SQL المعرفة في تفريغ قاعدة البيانات بواسطة مثيل PostgreSQL الخاص بـ Splunk
يمكن للمهاجم استغلال هذه الثغرة لتعريف وظيفة جديدة تستخدم lo_export – وهي وظيفة تستخدم لاستخراج BLOB من قاعدة البيانات وحفظه كملف على نظام الملفات – لكتابة محتوى يتحكم فيه المهاجم إلى ملف، ثم يتم تنفيذ الوظيفة خلال عملية الاستعادة.
“في هذه المرحلة، يمكننا المصادقة، واستعادة SQL الذي يتحكم فيه المهاجم، والتفاعل مع قاعدة البيانات المحلية،” قال باحثو الأمن بيتر بازيدلو ويوردان غانتشيف. “بمجرد أن نتمكن من استعادة SQL الذي يتحكم فيه المهاجم إلى مثيل PostgreSQL المحلي، قمنا بسرعة بتجميع قالب تفريغ قاعدة البيانات الذي منحنا كتابة ملف متحكم فيه.”
مسلحين بكتابة ملف عشوائي على نظام ملفات Splunk، يمكن للمهاجم التصعيد أكثر إلى تنفيذ التعليمات البرمجية عن بُعد من خلال الكتابة فوق نص برمجي بلغة بايثون يتم تنفيذه بشكل متكرر بواسطة Splunk (مثل “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”) ليشمل الحمولة الخبيثة.
تسلسل الإجراءات بالكامل أدناه –
- إنشاء قاعدة بيانات وتكوينها بحيث يمكن للمستخدم المصادقة دون كلمة مرور ومنحها أذونات كافية لاستدعاء وظائف مثل lo_export
- استخدام نقطة النهاية /backup لإسقاط تفريغ قاعدة البيانات البعيدة على نظام ملفات Splunk
- استخدام نقطة النهاية /restore لتحميل تفريغ قاعدة البيانات الخبيثة، وتحفيز تنفيذ الوظيفة الخبيثة خلال عملية الاستعادة، وكتابة نص برمجي بايثون يتحكم فيه المهاجم إلى نظام ملفات Splunk
على الرغم من عدم وجود دليل على استغلال الثغرة في البرية، إلا أن توفر تفاصيل الاستغلال يمكن أن يكون كافياً لدفع المهاجمين إلى تنفيذ محاولات انتهازية. من الضروري أن يتحرك المستخدمون بسرعة لتطبيق الإصلاحات للبقاء محميين.
للحفاظ على أمان أنظمتك، تأكد من تحديث برنامج Splunk الخاص بك إلى أحدث الإصدارات المتاحة. البقاء على اطلاع دائم بأحدث التهديدات الأمنية أمر ضروري لحماية بياناتك.
