StyleSmuggler في Magento وAdobe Commerce: إجراءات عاجلة قبل صدور إصلاح رسمي

تُطلق شركة Sansec اسم StyleSmuggler على ثغرة يوم-صفر مُبلّغ عنها ويجري استغلالها بنشاط في Magento Open Source وAdobe Commerce. والخطورة هنا كبيرة: يمكن للمهاجم تنفيذ شيفرة على خادم المتجر عن بُعد من دون تسجيل دخول أو بيانات اعتماد. وقالت Sansec إن الاستغلال بدأ في 4 سبتمبر/أيلول 2026، ثم كُشف عنه في 5 سبتمبر/أيلول. 2223

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

ما الذي كان معروفاً في نافذة الإفصاح الأولى؟

أفادت Sansec بأن جميع الإصدارات الحالية متأثرة، بما في ذلك Magento Open Source 2.4.9، وأنها أعادت إنتاج سلسلة الهجوم الكاملة دون مصادقة على تثبيتات نظيفة من Magento Open Source 2.4.7 و2.4.8 و2.4.9. 22 كما وصفت تقارير حالة ضحية تعمل على الإصدار 2.4.6-p15 مع تطبيق تحديثَي الأمان لشهري يوليو/تموز وأغسطس/آب 2026؛ ما يؤكد أن حداثة التحديثات السابقة لا تعالج ثغرة كُشف عنها حديثاً. 32

وبحسب ما نُشر في 6 سبتمبر/أيلول، لم تكن Adobe قد أصدرت معرّف CVE خاصاً بـStyleSmuggler، أو نشرة أمنية، أو تصحيحاً، أو حلاً مؤقتاً. 23 وكان من المقرر إصدار إنتاجي لخدمة Adobe Commerce as a Cloud Service في 8 سبتمبر/أيلول، لكن جدول الإصدار لا يؤكد معالجة StyleSmuggler ضمنه. 8

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

كيف تعمل سلسلة الهجوم المُبلّغ عنها؟

وفق Sansec، يستغل الهجوم خصائص styles ضمن مدخلات GraphQL غير الموثقة لتجاوز الضوابط القائمة وحقن PHP يتحكم به المهاجم في معالجة القوالب لدى Magento. وتُوصف السلسلة بأنها تمر بمرحلتين: أولاً، كتابة الشيفرة في محتوى ينشئه Magento، مثل تقرير فشل؛ ثم تشغيل المحتوى المسموم أثناء مسار عرض رسالة بريد إلكتروني خاصة بفشل الدفع. 22

إشعار فشل معاملة الدفع ميزة بريد إلكتروني اعتيادية وقابلة للتهيئة في Commerce. 18 والنقطة الحاسمة في السلسلة المُبلّغ عنها هي عرض القالب على الخادم، لا فتح مستلم البريد للرسالة. وهذا مهم في الاستجابة للحوادث: قد يكون نشاط فشل الدفع المشبوه ذا صلة حتى لو لم تُسلّم رسائل البريد الصادرة أو لم يتفاعل معها أي مستلم.

ووصفت تقارير عامة حمولة ما بعد الاستغلال بأنها باب خلفي دائم على Linux، مع تمويه العملية بأسماء مثل kworker واستمرارية عبر مهام cron. 2035 هذه التفاصيل مفيدة كنقاط بحث، لكنها ليست قائمة مؤشرات شاملة أو دائمة؛ إذ يستطيع المشغّلون تغيير أسماء الملفات والعمليات والمسارات والبنية الشبكية.

أمور لم تثبت بصورة مستقلة

تضمنت بعض تقارير استخبارات الحوادث مزاعم إضافية، منها سرقة بيانات جلسات مدعومة بـRedis من دون رصد حركة اتصال وتحكم خارجية، والتهرب من البحث المعتمد على var/report/ عبر تسميم var/log/system.log. لكن المواد المتاحة لا تتضمن تحليلاً قابلاً لإعادة الإنتاج للبرمجية الخبيثة أو مصدراً جنائياً مستقلاً ثانياً يثبت تلك السلوكيات تحديداً.

لذلك ينبغي التعامل معها بوصفها معلومات استخباراتية غير مؤكدة لا حقائق محسومة. ولا يقلل هذا الغموض من ضرورة التحقيق؛ بل يعني أن على فرق الدفاع جمع أدلة أوسع من تقارير Magento وحدها، بما يشمل بيانات الخادم والعمليات وcron وخوادم الويب وPHP-FPM وRedis وDNS والجدار الناري.

أولويات الاحتواء الفوري

1. تقييد وصول GraphQL العام

إذا كان المتجر يعمل من دون GraphQL عام، فعطّل أو احجب /graphql مؤقتاً. وإذا كان GraphQL ضرورياً للأعمال، فقيّد الوصول إليه عبر CDN أو جدار حماية تطبيقات الويب (WAF) أو الوكيل العكسي، وقصره على العملاء والعمليات وأنماط الاستعلام المطلوبة. وحددت إرشادات Sansec العامة تعطيل GraphQL بوصفه الإجراء الفوري المتاح في غياب إصلاح رسمي. 22

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

2. استخدام التخفيفات الطارئة بحذر

قالت Sansec إن قواعد Shield الخاصة بها تحجب مرحلتي الهجوم المعروفتين. 22 وأعلنت Disrex أيضاً إصدار تصحيحات تخفيف طارئة تهدف إلى حجب السلسلة المعروفة، مع التنبيه إلى أنها لا تزيل إصابة قائمة. 35

ينبغي مراجعة أي تصحيح من طرف ثالث أو قاعدة WAF واختبارها في بيئة تجريبية، ثم نشرها عبر عملية تغيير مضبوطة. وأبقها قائمة إلى أن يُختبر الإصلاح الرسمي ويُثبت أنه يغلق مسار الهجوم المعني.

3. حفظ الأدلة قبل التنظيف

إذا كان الاختراق محتملاً، فاجمع السجلات ذات الصلة ولقطة من حالة الخادم والعمليات قبل حذف الملفات أو إعادة تشغيل الخدمات. أعطِ الأولوية إلى:

• طلبات خادم الويب والوكيل العكسي إلى /graphql، ولا سيما طلبات POST غير المعتادة التي تتضمن styles.
• سجلات PHP-FPM والتطبيق وcron وحسابات العمليات وDNS والجدار الناري.
• ارتفاع غير متوقع في رسائل فشل الدفع أو نشاط غير مألوف في عرض القوالب.
• مهام cron الجديدة أو المعدلة، خصوصاً الأوامر التي تعمل بحساب خدمة الويب.
• العمليات الفرعية غير المتوقعة من PHP-FPM، والعمليات التي تتنكر كأدوات نظام، والملفات التنفيذية غير المألوفة في المسارات القابلة للكتابة أو المخفية.
• المقابس المفتوحة والاتصالات الصادرة من حسابات خادم الويب وبيئة PHP.

لا تحصر جمع الأدلة في var/report/ أو سجلات تطبيق Magento؛ فقد تكون هذه المصادر غير مكتملة حتى من دون عبث متعمد.

خفض أثر الاختراق الناجح

تفيد خطوات التقوية التالية عموماً أثناء التحقيق في الواقعة:

• شغّل عمال الويب وPHP تحت حساب مخصص غير ذي امتيازات وبأقل وصول ممكن إلى نظام الملفات.
• اجعل شيفرة التطبيق للقراءة فقط بالنسبة إلى حساب وقت التشغيل، واسمح بالكتابة فقط في المواضع التي يحتاجها Commerce فعلاً.
• امنع التنفيذ من المسارات القابلة للكتابة، مثل المجلدات المؤقتة والتخزين المؤقت والرفع والوسائط والسجلات والتقارير والمحتوى المُولّد، متى كان ذلك متوافقاً مع التشغيل.
• فكّر في خيارات الربط noexec وnodev وnosuid لأنظمة الملفات المؤقتة أو كثيرة الكتابة، بعد اختبار التوافق.
• قيّد حركة الخروج من خوادم التطبيق بقائمة سماح صريحة، ونبّه إلى نشاط DNS أو UDP غير المتوقع.
• أبقِ Redis بعيداً عن الإنترنت العام، واحمه بالشبكات الخاصة وضوابط المصادقة والنقل المناسبة.
• أنشئ تنبيهات لمهام cron الجديدة، والعمليات غير المتوقعة التي يبدأها PHP-FPM، والتغييرات في مخرجات النشر.

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

عند العثور على مؤشرات اختراق

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

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

الخلاصة العملية

الدرس الأهم من StyleSmuggler هو أن سلسلة استغلال جديدة ونشطة قد تتجاوز مستوى تحديث Magento الذي كان حديثاً قبل الإفصاح. خلال نافذة الإفصاح الأولى، كان أفضل نهج متاح هو تقليل أو إزالة تعرّض GraphQL العام، ونشر ضوابط مؤقتة موثوقة، والبحث عن الاختراق عبر بيانات التطبيق والخادم، والاستعداد لتطبيق إصلاح Adobe الرسمي والتحقق منه عند توفره. 222335