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