هجوم القوس الذري: كيف تحولت 1900 حزمة في مستودع AUR إلى أسلحة رقمية

في النهاية، قامت صفحة حملة SafeDep والقوائم التي جمعها المجتمع بتعداد 1,937 اسم حزمة متأثرة من AUR، مما يؤكد المدى الهائل للهجوم . والأمر الحاسم هنا أن مستودعات Arch Linux الرسمية (core, extra, community) لم تتأثر، بل كان الحادث مقتصراً على مستودع AUR فقط .

أسلوب الهجوم: استغلال آلية عمل قائمة على الثقة

لم يكن هجوم القوس الذري اختراقاً للبنية التحتية لـ Arch بحد ذاتها. بل كان استغلالاً دقيقاً لـ آلية تبنّي الحزم المهجورة في AUR، وهي عملية تسمح لأي عضو في المجتمع بالمطالبة بملكية الحزم المتروكة .

تطور الهجوم على موجتين منفصلتين، حيث قام المنفذون بتحسين نهجهم لتجنب الاكتشاف.

الموجة الأولى: خطاف npm (11 يونيو)

تبنى المهاجمون بشكل منهجي الحزم المهجورة. وبمجرد حصولهم على صلاحيات المشرف، لم يقوموا بتعديل الشيفرة المصدرية للبرنامج نفسه، وهي خطوة كانت ستكسر التوقيعات وتطلق الإنذارات. بدلاً من ذلك، قاموا بتعديل سكريبتات البناء المسماة PKGBUILD لحقن تبعيات npm خبيثة هي: atomic-lockfile (الإصدار 1.4.2) و js-digest (الإصدار 4.2.2) . تم إعداد هذه الحزم لتعمل تلقائياً أثناء عملية makepkg. ولإخفاء النشاط الخبيث بشكل أكبر، تم تضمين الكود في سكريبتات .install وإخفائه باستخدام تقسيم النصوص في واجهة الشِل، والاقتباس المختلط، والترميز السداسي العشري .

الموجة الثانية: التحول إلى Bun (12 يونيو)

بعد يوم واحد فقط، ظهرت موجة ثانية. هذه المرة، استبدل المهاجمون مسار تثبيت npm بـ عملية تثبيت تعتمد على Bun، مستخدمين حزمة خبيثة مختلفة اسمها lockfile-js (الإصدار 1.4.2) . زاد هذا التحول من صعوبة الاكتشاف، حيث ركزت العديد من مؤشرات الاختراق الأولية على سجل npm، وكان لا بد من تحديث أدوات الأمان لمراقبة بيئة التشغيل والتبعيات الجديدة .

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

الحمولات الخبيثة: برمجية سرقة وجذر خفي

تلقت الأجهزة التي قامت ببناء الحزم المخترقة حمولة على مرحلتين صُممت للتجسس والثبات داخل النظام.

• برمجية سرقة بيانات الاعتماد المبنية بـ Rust: برنامج ثنائي مركز يحصد أسرار المطورين، بما في ذلك جلسات المتصفح، ومفاتيح SSH، ورموز GitHub و npm، وجلسات Slack/Teams، ورموز Vault، وبيانات اعتماد Docker/Podman، ومفاتيح الوصول السحابية .
• الجذر الخفي eBPF (للمستخدمين الجذر فقط): إذا تم بناء الحزمة بصلاحيات المستخدم الجذر (root)، تقوم البرمجية الخبيثة بنشر جذر خفي يعتمد على eBPF قادر على إخفاء ملفاته وعملياته ونشاط الشبكة الخاص به عن أدوات الكشف المعتادة مثل ps و htop. استخدم الجذر الخفي المسار /sys/fs/bpf/ للثبات، مما يجعل إزالته صعبة للغاية .

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

استجابة المجتمع والمطورين

تحرك مجتمع Arch Linux وقطاع الأمن السيبراني بسرعة، لكن تعقّد الاستجابة بسبب حجم الهجوم.

• إجراءات فريق Arch: افتتح المساهمون في Arch موضوعاً موحداً للإبلاغ عن الحزم المخترقة في AUR في 11 يونيو وبدأوا عملية إعادة التعديلات الخبيثة، وحظر حسابات المهاجمين، وتنظيف مجموعة الحزم المهجورة. كما علقت Arch Linux تسجيلات الحسابات الجديدة على AUR يوم الاثنين التالي لمنع المزيد من الإساءة . وأكد مشرف الحزم في Arch، جوناثان غروتيلوشن، أن الفريق يعمل على "استعادة أو حذف جميع التعديلات الخبيثة وحظر الحسابات المسؤولة" .

• الجدل المجتمعي: أثار الهجوم نقاشاً حاداً. شهدت منصات مثل منتدى PrivacyGuides دعوات من بعض أفراد المجتمع لإغلاق مستودع AUR بالكامل، بحجة أن نموذجه القائم على الثقة قد فشل بشكل أساسي في مواجهة اختراق بهذا الحجم .

• استجابة الجهات الخارجية: نشرت شركات أمنية مثل Sonatype و Corgea و Cloud Security Alliance (CSA) و TrueSec تحليلات مفصلة ومؤشرات اختراق (IoCs) وسكريبتات كشف مجتمعية (مثل aur-malware-check) لمساعدة المستخدمين في تدقيق أنظمتهم .

كان أحد مصادر الاحتكاك الرئيسية أن فريق Arch الرسمي لم ينشر على الفور قائمة رسمية واحدة بجميع الحزم المتأثرة، مما دفع المستخدمين إلى الاعتماد على قوائم من جهات خارجية مثل SafeDep و Corgea .

دروس مستفادة لنظام Linux البيئي

يكشف هجوم القوس الذري عن نقاط ضعف هيكلية في المستودعات المجتمعية القائمة على الثقة والتي تعتمد على صيانة المتطوعين.

• "فخ الحزم المهجورة" هو خطر نظامي: قدرة أي مستخدم على تبني وتعديل حزمة مهجورة وتعديلها فوراً دون التحقق من الهوية أو مراجعة إجبارية للكود، حوّلت ميزة سهلة الاستخدام إلى ناقل هجوم عالي التأثير .
• الحقن في وقت البناء يتجاوز فحوصات السلامة: تعتمد آليات الدفاع التقليدية على التحقق من سلامة أرشيفات الشيفرة المصدرية. ولأن هجوم "القوس الذري" سمّم سكريبتات البناء بدلاً من الشيفرة المصدرية، لم توفر التوقيعات المعيارية أي حماية .
• سلاسل التوريد عبر الأنظمة البيئية هي الحدود الجديدة للهجمات: استخدم الهجوم سجلات npm و Bun كأسلحة لتوزيع البرمجيات الخبيثة على نظام Linux البيئي، مما يثبت أن حزمة واحدة مخترقة في سجل واحد يمكن أن يكون لها آثار متتالية عبر المنصات .

ما يجب على المستخدمين المتضررين فعله الآن

يجمع باحثو الأمن وتوجيهات مجتمع Arch على أمر واحد: هذا ليس موقفاً يكفي فيه إزالة حزمة واحدة فقط.

1. افترض الاختراق الكامل: تعامل مع أي جهاز قام ببناء أو تحديث حزمة من AUR بين 9 و 12 يونيو 2026 على أنه مخترق بالكامل .
2. أعد التثبيت من وسائط نظيفة: لا يمكن الاعتماد على فحص بسيط للبرمجيات الخبيثة لأن الجذر الخفي eBPF صُمم للاختباء من أدوات الكشف. الحل الوحيد المضمون هو إعادة بناء النظام المتأثر من وسائط تثبيت موثوقة .
3. غيّر جميع بيانات الاعتماد فوراً: افترض أن برمجية سرقة بيانات الاعتماد قد سرقت كل سر يمكن الوصول إليه على الجهاز: مفاتيح SSH، ورموز GitHub و npm، ورموز Vault، ومفاتيح الوصول السحابية، وجلسات المتصفح، وبيانات اعتماد Docker/Podman .
4. دقق تاريخ تثبيت AUR: شغل الأمر

   pacman -Qm

   لسرد جميع الحزم الخارجية المثبتة على النظام وقم بمقارنتها مع قوائم الحزم الخبيثة التي نشرها المجتمع .
5. تحقق من مؤشرات الاختراق: ابحث عن آثار atomic-lockfile أو lockfile-js أو js-digest في ذاكرة التخزين المؤقت للبناء، وكذلك عن أي مدخلات مشبوهة تحت المسار /sys/fs/bpf/ .
6. عامل الأمر كحدث استجابة أمنية: يجب على المؤسسات ألا تتعامل مع هذا التهديد كمجرد تمرين فحص بسيط. أي جهاز مطور يعمل بنظام Arch أو خادم بناء/تكامل مستمر قام بسحب تحديثات من AUR خلال فترة الهجوم يجب أن يعامل كحادث أمني يتطلب استجابة كاملة .