هجوم GlassWorm: كيف اخترقت أحرف يونيكود غير مرئية 400 مستودع برمجي

في الأسبوع الأخير من مارس 2026، كشف باحثون من Aikido وSocket وStep Security عن عودة حملة GlassWorm بموجة هجمات منسّقة استهدفت أكثر من 433 مكوّناً برمجياً عبر منصات GitHub وnpm وإضافات VSCode وOpenVSX. الهجوم يستغل أحرف يونيكود غير مرئية — حرفياً لا تراها بالعين المجردة في أي محرر أكواد — لإخفاء شيفرة خبيثة تسرق بيانات الاعتماد والمفاتيح السرية ومحافظ العملات الرقمية.

آلية الهجوم: يونيكود كسلاح تخفٍّ

يعتمد GlassWorm على تقنية ذكية تستغل منطقة الاستخدام الخاص (Private Use Area) في معيار يونيكود. هذه الأحرف تُعرض كمسافات صفرية العرض (zero-width whitespace) في جميع محررات الأكواد الرئيسية — بما فيها VS Code وSublime Text وVim — مما يجعل الشيفرة الخبيثة مخفية تماماً عن أعين المطورين أثناء مراجعة الكود. عند تنفيذ الملف، يقوم مفكّك مضمّن باستخراج البايتات من هذه الأحرف وتمريرها إلى دالة eval() في JavaScript، مما يُنفّذ حمولة المرحلة الثانية. هذه الحمولة تستعلم عن محفظة Solana للحصول على عنوان خادم التحكم والسيطرة (C2)، ثم تحمّل سكربتات إضافية مصممة لسرقة البيانات.

نطاق الحملة: من 151 مستودعاً إلى 433 مكوّناً

بدأت الموجة الأولى من GlassWorm في أكتوبر 2025 باستهداف مستودعات GitHub فقط، لكن حملة مارس 2026 توسّعت بشكل كبير. بين 3 و9 مارس وحدها، تأثر ما لا يقل عن 151 مستودعاً على GitHub. بالتوازي، اكتُشفت 72 إضافة خبيثة على منصة Open VSX منذ 31 يناير 2026. الهجوم استخدم رموز GitHub المسروقة لتنفيذ عمليات force-push تزرع الكود الخبيث في مستودعات Python مشروعة، بينما استهدفت حزم npm المُخترقة مطوري JavaScript مباشرة. البيانات المستهدفة تشمل: مفاتيح SSH، وتوكنات الوصول API، وبيانات اعتماد خدمات السحابة (AWS/Azure/GCP)، ومحافظ العملات الرقمية، ومتغيرات البيئة (.env) التي غالباً تحتوي أسرار الإنتاج.

لماذا يجب أن تقلق المؤسسات المالية السعودية؟

القطاع المالي السعودي يعتمد بشكل متزايد على التطوير البرمجي الداخلي والمنصات الرقمية — من تطبيقات الخدمات المصرفية إلى بوابات الدفع الإلكتروني وواجهات Open Banking. هذا يعني أن فرق التطوير تستخدم يومياً مكتبات npm وحزم Python وإضافات VS Code، مما يجعلها عرضة مباشرة لهجمات سلسلة التوريد مثل GlassWorm. إطار SAMA CSCC يُلزم المؤسسات المالية بتطبيق ضوابط أمن التطبيقات (Application Security) ضمن نطاق 3.3.5، ويشترط وجود آليات فحص للمكونات البرمجية الخارجية. كذلك، ضوابط NCA ECC في النطاق الفرعي 2-7-3 تتطلب إدارة مخاطر سلسلة التوريد الرقمية. أي اختراق عبر مكتبة برمجية مُخترقة قد يؤدي إلى تسريب مفاتيح API لبوابات الدفع أو بيانات اعتماد الأنظمة المصرفية الأساسية، مع عواقب تنظيمية ومالية وخيمة.

مؤشرات الاختراق (IoCs) التي يجب مراقبتها

فرق مركز العمليات الأمنية (SOC) يجب أن تبحث عن عدة مؤشرات محددة. أولاً، وجود أحرف يونيكود من نطاق Private Use Area (U+E000 إلى U+F8FF) في ملفات JavaScript أو Python في المستودعات الداخلية. ثانياً، اتصالات شبكية غير معتادة من بيئات التطوير إلى عناوين محافظ Solana أو نطاقات C2 غير معروفة. ثالثاً، تعديلات force-push غير مبررة على مستودعات Git الداخلية. رابعاً، سكربتات postinstall مشبوهة في حزم npm المثبّتة حديثاً. أدوات مثل Socket.dev وAikido Security وSnyk يمكنها كشف هذه الأنماط تلقائياً ضمن خطوط CI/CD.

التوصيات والخطوات العملية

1. تفعيل Software Composition Analysis (SCA): استخدم أدوات مثل Snyk أو Dependabot أو Socket لفحص كل تبعية برمجية خارجية قبل دمجها. اربط هذه الأدوات بخط CI/CD ليتم رفض أي حزمة تحتوي مؤشرات خبيثة تلقائياً.
2. تطبيق سياسة قفل التبعيات (Lockfile Policy): استخدم package-lock.json أو yarn.lock مع التحقق من التوقيعات الرقمية (integrity hashes). فعّل npm audit signatures للتأكد من أن الحزم المنشورة على npm Registry لم تُعدّل.
3. مراجعة إضافات VS Code: قم بجرد جميع إضافات VS Code المثبتة لدى فرق التطوير. احذف أي إضافة مصدرها Open VSX غير موثق، وقيّد التثبيت بقائمة بيضاء معتمدة من فريق أمن المعلومات.
4. تدوير الأسرار والمفاتيح: إذا كانت فرق التطوير لديك تستخدم حزم npm أو مستودعات GitHub تأثرت بالحملة، افترض أن مفاتيح SSH وتوكنات API ومتغيرات البيئة قد سُرّبت. قم بتدويرها فوراً وراقب سجلات الوصول بحثاً عن استخدام غير مصرّح.
5. فحص يونيكود في مراجعات الكود: أضف قاعدة في أداة الفحص الثابت (SAST) أو في Git pre-commit hooks للكشف عن أحرف يونيكود من نطاق PUA في ملفات الكود. أداة semgrep تدعم كتابة قواعد مخصصة لهذا الغرض.
6. تحديث خطة الاستجابة للحوادث: أضف سيناريو "اختراق سلسلة التوريد البرمجية" إلى خطة الاستجابة للحوادث، مع إجراءات واضحة للحجر والتحقيق وإخطار SAMA خلال الإطار الزمني المطلوب تنظيمياً.

الخلاصة

هجوم GlassWorm يُذكّرنا بأن سلسلة التوريد البرمجية أصبحت من أخطر نواقل الهجوم وأكثرها تعقيداً. الأحرف غير المرئية التي لا تظهر في محررات الأكواد قادرة على تجاوز مراجعات الكود اليدوية بالكامل، مما يجعل الأدوات الآلية والسياسات الصارمة ضرورة وليست رفاهية. المؤسسات المالية السعودية التي تطوّر تطبيقاتها داخلياً أو تعتمد على مكتبات مفتوحة المصدر يجب أن تتعامل مع أمن سلسلة التوريد كأولوية قصوى ضمن إطار SAMA CSCC وNCA ECC.

هل مؤسستك مستعدة؟ تواصل مع فريق فنترالينك لتقييم مجاني لمدى النضج السيبراني وفق SAMA CSCC، يشمل مراجعة شاملة لأمن سلسلة التوريد البرمجية وممارسات DevSecOps.