الكتابات/blog/2026/05
Blog16 مايو 2026·6 دقيقة

تدقيق إضافات ماجنتو: كشف الباب الخلفي في 30 دقيقة

أبريل 2026: شراء 31 إضافة ووردبريس عبر Flippa، دفع تحديث ملوّث بعد 8 أشهر. النمط نفسه يطال ماجنتو. هذا تدقيق ذاتي في 30 دقيقة.

في أبريل 2026، اشترى مهاجمون 31 إضافة ووردبريس مشروعة عبر منصة Flippa، تركوا الشفرة ساكنة ثمانية أشهر، ثم دفعوا تحديثًا ملوّثًا عبر صلاحيات SVN الرسمية. وصل عدد المواقع المتضررة إلى 400,000 موقع تقريبًا — كلها استقبلت الباب الخلفي البرمجي عبر قناة التحديث الاعتيادية، موقّعًا من المؤلف الصحيح، ومُجازًا من WordPress.org.

هذا الهجوم ليس حكرًا على ووردبريس. النمط ذاته — شراء وحدة، الانتظار، ثم دفع تحديث ملوّث — يعمل تمامًا على Magento. سوق Adobe، وحدات Tigren وMGS وMeetanshi المُلوَّثة في أبريل 2025 (500 إلى 1000 متجر متضرر، ضمنها شركة متعددة الجنسيات بإيرادات 40 مليار دولار)، النسخ "Nulled" المنزَّلة من المنتديات: سلسلة توريد الإضافات أصبحت اليوم الناقل الأول لاختراق متجر Magento يحافظ على نواته محدّثة.

الخبر السار: إذا كان لديك وصول SSH إلى متجرك، فبإمكانك تدقيق إضافاتك كاملة في 30 دقيقة عبر سطر الأوامر. تقدّم هذه المقالة الإجراء خطوة بخطوة. في النهاية، ستعرف:

  • ما الإضافات المثبّتة، ومن ينشرها
  • أيّها يحمل بصمات أبواب خلفية معروفة
  • ما إذا كانت ملفات PHP مشبوهة أُودعت في vendor/ أو app/code/ حديثًا
  • ما إذا كان قد أُنشئ حساب مدير شبحي
  • ما إذا كان جافاسكربت يسرّب مدفوعاتك

لماذا أصبحت الإضافات الناقل الأول

ثلاثة أنماط تطبّعت منذ 2024:

  1. الناشر يتخلى. الوحدة تبقى في composer.json، لا أحد يصونها. أول CVE تُكتشف تُستغل لأشهر قبل أن يستيقظ أحد المشرفين — أو لا أحد يستيقظ أبدًا.
  2. الناشر يبيع. مطوّر مستقل يتنازل عن وحدته على Flippa أو Acquire أو في السوق. المشتري الجديد يحصل على صلاحيات commit مشروعة. يدفع تحديثًا بريئًا، ينتظر (ثمانية أشهر في حملة ووردبريس أبريل 2026)، ثم يحقن الحمولة. لا إشارة تصيّد، ولا fork مشبوه: إنه ناشرك الذي يدفع.
  3. النسخة "Nulled". منزَّلة من wpnull24 أو gpldl أو قنوات تليغرام أو ديسكورد. 90% من هذه النسخ تحمل على الأقل غلاف ويب، أو حاقن سبام SEO، أو سكيمر بطاقات. متفشية في وكالات MENA التي تتجنّب رسوم الترخيص.

الأنماط الثلاثة تتقاطع عند النقطة ذاتها: مجلد vendor/ لديك يحوي شفرة قابلة للتنفيذ في الإنتاج لم تدقّقها بنفسك، موقّعة من سلسلة ثقة لم تعد تتحكم فيها.

التدقيق في 30 دقيقة — خطوة بخطوة

المتطلبات: وصول SSH إلى جذر المتجر (عادة /var/www/html)، أداة bin/magento قابلة للتنفيذ، وcomposer مثبّت.

الخطوة 1 — جرد كل الإضافات (3 دقائق)

cd /var/www/html
 
# كل الوحدات التي يعرفها ماجنتو (المفعّلة والمعطّلة)
bin/magento module:status
 
# تفاصيل composer: الناشر، الإصدار، المصدر
composer show --installed | grep -iE "^(magento|adobe|tigren|mgs|meetanshi|amasty|mageplaza|webkul|landofcoder|aheadworks|wyomind)"
 
# قائمة الوحدات الطرف الثالث الموجودة فعليًا (باستثناء نواة Adobe)
ls -la app/code/ 2>/dev/null
ls -la vendor/ | grep -vE "^(magento|adobe|composer|symfony|laminas|psr|monolog|guzzle|phpunit|webonyx|tedivm|ramsey|graphql|zendframework)"

دوّن كل ناشر غير رسمي. هذه قائمة الأهداف التي ستدقّقها.

الخطوة 2 — التحقق من أصالة المصدر (5 دقائق)

لكل وحدة طرف ثالث، تحقّق من مصدرها. وحدة من marketplace.adobe.com ليست كوحدة من github.com/مجهول/clone.

# المصدر الحقيقي لكل حزمة (رابط المستودع)
composer show vendor/اسم-الوحدة | grep -E "source|dist|name"
 
# مقارنة الإصدار المثبّت بآخر إصدار رسمي
composer outdated vendor/اسم-الوحدة
 
# التحقق من توقيع `composer.lock` — أي تعديل يدوي مشبوه
git log --all -p composer.lock | grep -E "tigren|mgs|meetanshi" | head -50

علامات حمراء: dist.url يشير إلى نطاق مجهول (*.ru أو *.tk أو IP عارٍ)، أو name لا يطابق أي حزمة عامة، أو نسخة "1.0.0" مؤرّخة 2026 لوحدة إصدارها الرسمي 4.x.

الخطوة 3 — فحص بصمات IOC المعروفة (8 دقائق)

تتشارك الأبواب الخلفية في PHP حفنة من البصمات. أربعة أوامر تغطي 80% من الحالات.

# 1. eval + base64_decode — بصمة غلاف الويب الكلاسيكية
grep -rEn "eval\s*\(\s*base64_decode" vendor/ app/code/ 2>/dev/null
 
# 2. gzinflate + base64 — متغيّر مُعمّى
grep -rEn "gzinflate\s*\(\s*base64_decode|str_rot13\s*\(\s*base64_decode" vendor/ app/code/ 2>/dev/null
 
# 3. preg_replace مع المعدّل /e — تنفيذ شفرة عبر regex (محظور منذ PHP 7 لكن يعود في الشفرة المحقونة)
grep -rEn "preg_replace\s*\(\s*['\"][^'\"]*/[a-z]*e[a-z]*['\"]" vendor/ app/code/ 2>/dev/null
 
# 4. أبواب خلفية معروفة لـ Tigren / MGS / Meetanshi — بصمة وثّقتها Sansec (أبريل 2025)
grep -rE "License\.php|registration\.php" vendor/ | grep -iE "tigren|mgs|meetanshi"
 
# 5. متغيرات superglobals تُمرَّر إلى eval — نمط "غلاف HTTP"
grep -rEn "eval\s*\(\s*\\\$_(GET|POST|REQUEST|COOKIE|SERVER)" vendor/ app/code/ pub/ 2>/dev/null
 
# 6. assert() مع مدخلات المستخدم — مكافئ eval متجاوز
grep -rEn "assert\s*\(\s*\\\$_(GET|POST|REQUEST)" vendor/ app/code/ pub/ 2>/dev/null

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

الخطوة 4 — الملفات المعدّلة حديثًا في vendor/ (3 دقائق)

vendor/ لا يجب أن يتغيّر إلا مع composer install / update. أي ملف عُدّل خارج هذه النافذة شاذٌ.

# ملفات PHP المعدّلة في vendor/ خلال آخر 180 يومًا
find vendor/ -name "*.php" -mtime -180 -type f -ls | head -50
 
# المقارنة مع تاريخ composer.lock — أي mtime لاحق لآخر `composer install` مشبوه
stat -c "%y %n" composer.lock

في pub/media/ وpub/static/ — اللذين لا يجب أن يحويا أبدًا ملفات PHP قابلة للتنفيذ:

find /var/www/html/pub/media/ /var/www/html/pub/static/ \
  -name "*.php" -o -name "*.phtml" -o -name "*.php7" -o -name "*.phar" 2>/dev/null

أي نتيجة هنا — بحكم البناء — خبيثة.

الخطوة 5 — حسابات المدير الشبحية (دقيقتان)

# سرد كل مستخدمي المدير في ماجنتو
mysql -u $(grep -A1 '\[default\]' app/etc/env.php | grep -oP "(?<=username' => ')[^']+" | head -1) \
      -p$(grep -oP "(?<=password' => ')[^']+" app/etc/env.php | head -1) \
      -e "SELECT user_id, username, email, created, modified, is_active FROM admin_user ORDER BY created DESC;" \
      $(grep -oP "(?<=dbname' => ')[^']+" app/etc/env.php | head -1)

ابحث عن: حساب أُنشئ خارج خطة التوظيف، أو بريد gmail/protonmail عشوائي، أو تاريخ إنشاء حديث جدًا، أو is_active=1 لحساب لا يعرفه أحد.

الخطوة 6 — سجلات var/log/ وشذوذ الجلسات (4 دقائق)

# تسجيلات دخول مدير ناجحة في آخر 30 يومًا
grep -rE "admin.*login.*success" var/log/ | tail -50
 
# عناوين IP المميّزة التي وصلت إلى /admin
grep -E "/admin" /var/log/nginx/access.log* 2>/dev/null | awk '{print $1}' | sort -u
 
# نمط محاولات سحب بطاقات — وصول مفرط الكثافة إلى صفحة الدفع
grep -E "/checkout/onepage|/rest/V1/carts" /var/log/nginx/access.log* 2>/dev/null \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

المهاجم الذي يجهّز سكيمر يستطلع صفحة الدفع للتأكد من نجاح الحقن. IP وحيد بـ 200+ زيارة على /checkout/onepage في غضون ساعات هو إشارة.

الخطوة 7 — تكاملات REST API غير المرخّصة (3 دقائق)

كثيرًا ما يُنشئ المهاجم رمز API ليظل ثابتًا حتى لو غيّرت كلمة مرور المدير.

mysql -e "SELECT entity_id, name, status, created_at FROM integration ORDER BY created_at DESC;" \
  $(grep -oP "(?<=dbname' => ')[^']+" app/etc/env.php | head -1)
 
# رموز OAuth الفعّالة
mysql -e "SELECT consumer_id, key, created_at, user_type FROM oauth_token WHERE revoked=0 ORDER BY created_at DESC LIMIT 20;" \
  $(grep -oP "(?<=dbname' => ')[^']+" app/etc/env.php | head -1)

أي تكامل لم تُنشئه أنت هو باب دخول مستديم.

الخطوة 8 — جافاسكربت صفحة الدفع (دقيقتان)

الحمولة النهائية لسكيمر Magecart نادرًا ما توجد في vendor/ — تُحقَن عادة في قاعدة البيانات عبر core_config_data أو في القالب عبر وحدة مخترقة.

mysql -e "SELECT path, value FROM core_config_data WHERE value LIKE '%<script%' OR value LIKE '%javascript:%';" \
  $(grep -oP "(?<=dbname' => ')[^']+" app/etc/env.php | head -1)
 
# كل النطاقات الخارجية التي تخدم JS في صفحة الدفع
curl -s https://متجرك.tld/checkout | grep -oE 'src="https?://[^"]+\.js"' | sort -u

كل نطاق خارجي لا تعرفه (باستثناء التحليلات المشروعة) يجب التحقق منه وحجبه عبر CSP.

إذا وجدت شيئًا

لا تعد تشغيل الخادم. ستفقد ذاكرة وصول عشوائية ضرورية للتحليل الجنائي الرقمي.

  1. العزل: اقطع الوصول العام (جدار ناري داخل/خارج أو صفحة صيانة).
  2. التصوير: صورة قرص كاملة + تفريغ ذاكرة RAM إن أمكن.
  3. الإبلاغ: في تونس، تجب إعلام الهيئة الوطنية لحماية المعطيات الشخصية (INPDP) خلال 72 ساعة إذا تسرّبت بيانات شخصية (القانون 2004-63). في المملكة العربية السعودية، يفرض نظام حماية البيانات الشخصية (PDPL) إبلاغ هيئة سدايا (SDAIA) خلال 72 ساعة كذلك (سارٍ منذ 14 سبتمبر 2024).
  4. الاستعانة بفريق متخصص في الاستجابة للحوادث — لا بمدمج Magento المعتاد، إلا إذا كان لديه فريق جنائي رقمي مخصص.
  5. تدوير كل الأسرار: MySQL، SMTP، مفاتيح API لـ Stripe/PayPal، حسابات المدير، مفاتيح SSH، تكاملات OAuth.
  6. الاستعادة من نسخة احتياطية سابقة للاختراق (تحقق من mtime الأبواب الخلفية لتأريخ الحدث) — وليس نسخة احتياطية البارحة.

الوقاية: تحويل هذا التدقيق إلى خط أنابيب مستمر

تدقيق الثلاثين دقيقة يجيب عن سؤال واحد: "هل أنا مخترَق اليوم؟". لتجنّب طرح هذا السؤال مجددًا:

  • composer audit في CI — حاجِب. أي CVE معروفة في تبعياتك تُكسر البناء.
  • سياسة إضافات مكتوبة: ممنوع التثبيت خارج سوق Adobe أو ناشر معتمد مسبقًا. ممنوع "Nulled". ممنوع "وجدته على GitHub".
  • اشتراك Sansec eComscan — ماسح ماجنتو متخصص، مدفوع لكنه يلتقط المتغيّرات المُعمّاة التي يتجاوزها grep.
  • حفظ شفرة مصدرية (Code Escrow) لوحداتك المخصّصة: كل commit يُدفع إلى مستودعك ومستودع طرف ثالث (BitBucket / GitLab.com لدى العميل) — الوكالة لا تستطيع احتجازك إذا تدهورت العلاقة.
  • مراجعة سنوية للإضافات: مصفوفة "الوحدة، الناشر، آخر تحديث، CVE مفتوحة، البديل". أي وحدة لم تُصَن منذ 18 شهرًا تُستبدل أو تُحذف.
  • جدار حماية تطبيقات WAF بقواعد ماجنتو (Sucuri أو Cloudflare Pro+ أو ModSecurity OWASP CRS): يحجب معظم محاولات PolyShell وSessionReaper (CVE-2025-54236) قبل أن تصل PHP.
  • مراقبة سلامة الملفات: tripwire أو aide، أو ببساطة cron يقارن مجاميع التحقق لـ vendor/ وapp/code/ بحالة مرجعية ويُنبّه على الفرق.

تدقيق إضافات ماجنتو من نقطة (Noqta)

تدقيق الثلاثين دقيقة أعلاه مصمّم ليُنفَّذ من قبل فريقك التقني. إذا أردت العمل نفسه مُسلَّمًا جاهزًا، مع تقرير مُرتّب حسب الأولوية، وخطة معالجة، ومرافقة للامتثال نظام PDPL (السعودية) أو القانون 2004-63 (تونس) — فهذا ما نقوم به.

تدقيق Noqta الكامل يشمل:

  • جردًا شاملًا لـ composer.lock + app/code + vendor/
  • مسح IOC موسّعًا (بصمات Sansec، أنماط مُعمّاة)
  • التحقق من سلامة قوالب صفحة الدفع
  • تدقيق حسابات المدير + تكاملات REST + رموز OAuth
  • مراجعة WAF + CSP + ترويسات الأمان
  • تقرير بالخطورة عالية/متوسطة/منخفضة + خطة عمل 30 / 60 / 90 يومًا

السعر ونافذة التدخل تُحسم مع الفريق حسب حجم متجرك.

اطلب تدقيق إضافات ماجنتو

الأسئلة الشائعة

هل يُعطّل التدقيق شيئًا؟ لا. كل الأوامر أعلاه للقراءة فقط (grep، find، mysql -e SELECT، composer show). لا أحد منها يعدّل الشفرة أو الإعدادات أو قاعدة البيانات.

هل يجب إيقاف المتجر أثناء التدقيق؟ لا. التدقيق يُنفَّذ على الإنتاج تحت الحمل. أوامر find قد تستهلك I/O على وحدات تخزين كبيرة — نفّذها في ساعات الذروة المنخفضة إن كان المتجر متوتّرًا.

ماذا إن لم يكن لديّ وصول SSH؟ اطلبه من مزوّد الاستضافة. إن رفضوا، فهذه راية حمراء على العقد ذاته — راجع ملفنا حول مخاطر مزوّدي IT في منطقة MENA.

Magento Open Source مقابل Adobe Commerce: هل تتغيّر الطريقة؟ لا. هيكل vendor/ + app/code/ واحد. Adobe Commerce تُضيف وحدات سحابية غير قابلة للتعديل، لكن النطاق التابع للطرف الثالث يُدقَّق بالطريقة نفسها.

كم تستغرق المدة بين اختراق ناشر واستغلال الإضافة؟ حملة ووردبريس في أبريل 2026 أظهرت 8 أشهر من السكون. أما حملة Magento Tigren/MGS/Meetanshi التي وثّقتها Sansec، فالشفرة الخبيثة كانت تنتظر منذ 2019 وفُعِّلت في أبريل 2025 — أي 6 سنوات من السكون. القاعدة: إن لم تدقّق أبدًا، فأنت محتمَل أن تكون قد وقعت في الفخ بالفعل.


المصادر العامة: Sansec (Tigren/MGS/Meetanshi backdoor أبريل 2025، PolyShell مارس 2026)، Blue Headline (حملة ووردبريس Flippa أبريل 2026)، Wordfence (La Studio Element Kit يناير 2026 — 20,000 موقع)، Adobe APSB25-88 (CVE-2025-54236 SessionReaper)، Wiz Research (تاريخ فديات قواعد البيانات)، Foregenix (التوثيق التقني لثغرة SSRF في Adminer). التشريعات: INPDP تونس (القانون 2004-63)، SDAIA السعودية (PDPL سارٍ منذ 14 سبتمبر 2024).