الهجوم لم يتطلب وجود ثغرة أمنية في التطبيق نفسه. فبمجرد سحب اعتمادية ملوثة وتشغيل أمر Cargo build، كان ذلك كافياً لتفعيل حمولة ضارة عن بُعد، وفقاً للتقرير الأصلي. هذا التحول نقل الخطر من قابلية استغلال التطبيق إلى جهاز المطور وبيئة التكامل المستمر، حيث تتواجد عادةً الأسرار ومفاتيح التوقيع وصلاحيات الوصول للبنية التحتية.
قام باحثو الأمن من SlowMist وSocket وStepSecurity بتحديد إصدارات ضارة من الحزم التالية: [email protected] و[email protected] و[email protected]. هذه الحزم الملوثة أدخلت اعتماداً مشابهاً لاسم حزمة proc-macro1 (بهدف التضليل). وأثناء عمليات بناء Cargo، كان سكربت البناء الخاص بهذه الاعتمادية يقوم بتحميل وتنفيذ حمولة ضارة عن بُعد قبل أن تتمكن معظم الفرق من فحص الكود.
قام فريق أمن Rust بإزالة الإصدارات الضارة وقفل حساب المشرف على الحزمة، مشيراً إلى احتمال تعرض جهاز المشرف أو بيانات النشر الخاصة به للاختراق. هذا التفصيل مهم لأنه يعني أن سطح الهجوم لم يكن عيباً تقنياً لمرة واحدة في كود الحزمة، بل كان اختراقاً على مستوى الحساب داخل سلسلة توريد الحزم نفسها.
لماذا التعرض لـ Solana يجعل هذا مختلفاً؟
حزمة arrayref مستخدمة على نطاق واسع في نظام Rust البيئي، بما في ذلك سلاسل الاعتماديات التي تلمس مكونات مرتبطة بـ Solana. وجود هذه الحزم في الرسم البياني لمشروع معين لا يعني أن المشاريع النهائية تعرضت للاختراق. لكنه يعني أن العديد من الفرق اضطرت لمراجعة ملفات قفل الاعتماديات وسجلات البناء بشكل عاجل، لأن الإصدار الضار يمكن أن يدخل المشروع من خلال اعتماديات غير مباشرة دون تحديث مباشر.
تحتل Solana باستمرار مرتبة متقدمة بين أكثر الأنظمة البيئية نشاطاً لمطوري البلوكشين، وتظهر البيانات الحديثة عن أفضل سلاسل الكتل من حيث نشاط المطورين حجم هذا السطح البنائي. الحزمة المخترقة بالقرب من قاعدة شجرة الاعتماديات يمكن أن تستقر داخل المحافظ والمدققين والمفهرسات وواجهات DeFi دون أي تغيير مرئي في التطبيق النهائي.
القلق الأكبر ليس أي مشروع محدد أصدر ثنائياً خبيثاً، بل هو حجم اعتماد البنية التحتية للعملات الرقمية على سجلات الحزم مفتوحة المصدر المشتركة. حساب مشرف واحد مخترق يمكنه الانتشار عبر الرسوم البيانية للبناء بين فرق ومنتجات مختلفة. بالنسبة لفرق الأمن، المهمة الفورية هي فحص ملفات Cargo.lock بحثاً عن الإصدارات الضارة الثلاثة وتدقيق بيئات التكامل المستمر بحثاً عن اتصالات صادرة غير معتادة.
أحد العوامل التي تعقد الاستجابة هي الفجوة بين إزالة الإصدار من السجل والتنظيف المحلي. يمكن لسجل الحزم إلغاء نشر إصدار ضار بسرعة، لكن ذلك لا يعيد كتابة ملفات Cargo.lock على أجهزة المطورين أو يعيد بناء الحاويات التي تم شحنها بالفعل. الفرق التي تبني من اعتماديات مخزنة مؤقتاً في بيئة التكامل المستمر قد لا تسحب النسخة النظيفة ما لم تقم بتحديث ملف القفل بشكل صريح. هذا التأخير التشغيلي يمنح المهاجمين نافذة لاستخدام بيانات الاعتماد المسروقة حتى بعد صدور التحذير العام.
هجمات وقت البناء تسبق مراجعة الكود
سكربتات البناء تحتل موقعاً خطيراً لأنها تُنفذ في وقت الترجمة. في هذه الحالة، الاعتمادية المتضللة لم تكن مجرد خدعة في التسمية، بل استخدمت مرحلة البناء لجلب وتشغيل حمولة ضارة عن بُعد، مما يعني أن السلوك الخبيث حدث قبل أن تتاح لأي فريق فرصة مراجعة الكود. هذا النوع من الهجمات يشكل تحدياً خاصاً لأن معظم أدوات الفحص الأمني تركز على تحليل الكود المكتوب، وليس على ما يحدث أثناء عملية البناء نفسها.
الأسئلة الشائعة
ما هي الحزم التي تأثرت بهذا الهجوم؟
تأثرت ثلاث حزم شهيرة في نظام Rust البيئي وهي: arrayref بإصدار 0.3.10، وinternment بإصدار 0.8.7، وappend-only-vec بإصدار 0.1.9. هذه الإصدارات تمت إزالتها من السجل الرسمي، لكن يجب على المطورين فحص ملفات Cargo.lock لديهم للتأكد من عدم استخدامها.
كيف يحمي المطورون مشاريعهم من هذه الهجمات؟
يجب على الفرق تحديث ملفات قفل الاعتماديات بانتظام، ومراجعة سجلات البناء بحثاً عن اتصالات شبكة غير معتادة، وتدقيق بيانات اعتماد حسابات النشر، واستخدام أدوات فحص الحزم الآلية التي تراقب سلوك سكربتات البناء وليس فقط الكود المكتوب.
هل مشاريع Solana معرضة للخطر بشكل خاص؟
حزمة arrayref تستخدم في سلاسل اعتماديات تلامس مكونات مرتبطة بـ Solana، لكن وجودها لا يعني اختراق المشاريع. ومع ذلك، فإن حجم النظام البيئي وكثرة الاعتماديات غير المباشرة يجعلان فرق الأمن في مشاريع Solana بحاجة إلى فحص شامل وسريع لملفات القفل وسجلات البناء للتحقق من عدم تأثرها.
