لتثبيت واجهة Bitwarden الرسمية 93 دقيقة حوّلت أجهزة الكمبيوتر إلى منصات لاختراق حسابات GitHub

في ٢٢ أبريل، ظهرت نسخة ضارة من أداة الأوامر النصية الخاصة بمدير كلمات المرور Bitwarden على منصة npm، وذلك تحت اسم الحزمة الرسمية @bitwarden/[email protected]. لمدة ٩٣ دقيقة، كل من قام بتحميل الأداة عبر npm حصل على نسخة مزيفة خطيرة بدلاً من الأداة الأصلية.

اكتشفت Bitwarden الاختراق، وأزالت الحزمة الضارة، وأصدرت بيانًا أكدت فيه عدم وجود أي دليل على أن المخترقين تمكنوا من الوصول إلى بيانات خزائن المستخدمين النهائيين أو اختراق أنظمة الإنتاج.

قامت شركة أبحاث الأمن السيبراني JFrog بتحليل الحمولة الضارة، ووجدت أنها لا تستهدف خزائن Bitwarden بشكل خاص. بل كانت تهدف إلى سرقة رموز GitHub، ورموز npm، ومفاتيح SSH، وسجل الأوامر الطرفية، وبيانات اعتماد AWS، وGCP، وAzure، وأسرار GitHub Actions، وملفات تكوين أدوات الذكاء الاصطناعي.

هذه هي بيانات الاعتماد التي تتحكم في كيفية بناء الفرق لتطبيقاتها ونشرها والوصول إلى بنيتها التحتية.

يخدم Bitwarden أكثر من ٥٠,٠٠٠ شركة و١٠ ملايين مستخدم، وتصف وثائقه الأداة النصية بأنها طريقة “قوية ومتكاملة” للوصول إلى الخزنة وإدارتها، بما في ذلك في سير العمل الآلي الذي يستخدم متغيرات البيئة للمصادقة.

تعتبر Bitwarden منصة npm هي الطريقة الأسهل والأكثر تفضيلاً للتثبيت للمستخدمين الذين يعرفون هذه المنصة بالفعل. هذا المزيج من الاستخدام الآلي، والتثبيت على أجهزة المطورين، والتوزيع عبر npm الرسمي، يجعل الأداة النصية متواجدة في المكان الذي تتركز فيه أسرار البنية التحتية عالية القيمة.

كيف عملت الحزمة الضارة؟

يظهر تحليل JFrog أن الحزمة الضارة أعادت برمجة كل من خطاف ما قبل التثبيت (preinstall hook) وملف التشغيل الرئيسي (bw binary) ليؤديا إلى أداة تحميل تقوم بجلب بيئة تشغيل Bun وإطلاق حمولة مشفرة. هذا يعني أن الاختراق يحدث وقت التثبيت وأيضًا وقت التشغيل.

يمكن لأي مؤسسة تشغيل الأداة المزيفة دون لمس أي كلمات مرور مخزنة، بينما تقوم البرمجية الخبيثة بجمع بيانات الاعتماد التي تتحكم في خطوط CI/CD الخاصة بها، وحساباتها السحابية، وأتمتة النشر.

تقول شركة الأمن Socket إن الهجوم يبدو أنه استغل إجراء GitHub Action مخترق ضمن خط أنابيب CI/CD الخاص بـ Bitwarden، وهو نمط تتبعه باحثو Checkmarx.

أكدت Bitwarden أن الحادثة مرتبطة بحملة سلسلة التوريد الأوسع التي تتبعها Checkmarx.

مشكلة الثقة في سلسلة التوريد

طورت منصة npm نموذج النشر الموثوق (Trusted Publishing) لمواجهة هذا النوع من المخاطر تحديدًا.

من خلال استبدال رموز npm طويلة الأجل بمصادقة CI/CD قائمة على OIDC، يزيل النظام أحد أكثر المسارات شيوعًا التي يستخدمها المخترقون لاختطاف إصدارات الحزم. وتوصي npm بهذا النموذج وتعتبره خطوة مهمة للأمام.

ولكن السطح الأكثر صعوبة هو منطق الإصدار نفسه، مثل سير العمل والإجراءات التي تستدعي خطوة النشر. توصي وثائق npm بإجراءات تحكم إضافية تتجاوز OIDC، مثل بيئات النشر التي تتطلب موافقة يدوية، وقواعد حماية العلامات، وقيود الفروع.

تتيح إعدادات البيئة في GitHub للمؤسسات طلب موافقة المراجعين قبل أن يتمكن سير العمل من النشر. ويذهب إطار SLSA إلى أبعد من ذلك، حيث يطلب من المستهلكين التحقق من أن بيانات المصدر (Provenance) تطابق المعايير المتوقعة، مثل المستودع والفرع والعلامة وسير العمل وتكوين البناء الصحيحين.

حادثة Bitwarden تظهر أن المشكلة الأصعب تقع في طبقة سير العمل. إذا تمكن المخترق من استغلال سير عمل الإصدار نفسه، فإن شارة “رسمي” (Official) ستظل مرافقة للحزمة الضارة.

نموذج النشر الموثوق ينقل عبء الثقة إلى الأعلى، أي إلى سلامة سير العمل والإجراءات التي تستدعيه، وهي طبقة لم تفحصها معظم المؤسسات جيدًا.

رمز واحد يفتح أبوابًا كثيرة

بالنسبة لفرق المطورين والبنية التحتية، فإن اختراق سير عمل الإصدار يعرض خطوط CI/CD، وأتمتة البنية التحتية، وبيانات الاعتماد التي تتحكم بها للخطر.

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

الحصول على الرمز يخلق سلسلة آلية تحول رمزًا مسروقًا واحدًا إلى وصول دائم عبر البنية التحتية الآلية للمؤسسة.

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

تشابه مع حادثة Bybit

حادثة Bybit تشبه هذه الحادثة من حيث البنية. كمبيوتر مطور مخترق سمح للمهاجمين بتسميم واجهة موثوقة، والتي وصلت بعد ذلك إلى عملية الضحية.

الفرق هو أن Bybit تضمنت واجهة Safe على الويب تم التلاعب بها، بينما تضمنت Bitwarden حزمة npm رسمية تم التلاعب بها.

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

هجمات متسارعة في ٦٠ يومًا

خلال ٦٠ يومًا، كشفت Checkmarx عن اختراق إجراءات GitHub Actions وملحقات OpenVSX، بينما حذر تحالف أمن السحابة (CSA) من أن حملة TeamPCP تخترق بنشاط مشاريع مفتوحة المصدر ومكونات أتمتة CI/CD.

وثقت JFrog كيف أن إجراء GitHub Action مخترق لأداة Trivy سرق رمز نشر مشروع LiteLLM ومكن من إصدار حزم PyPI ضارة. وكشفت Axios عن تداول نسختين ضارتين من حزمة npm لمدة ٣ ساعات تقريبًا عبر حساب مسئول مخترق.

أحصت Sonatype أكثر من ٤٥٤,٦٠٠ حزمة ضارة جديدة في عام ٢٠٢٥ وحده، ليصل المجموع التراكمي إلى أكثر من ١.٢ مليون حزمة. Bitwarden تنضم الآن إلى سلسلة من الحوادث التي تؤكد أن سير عمل الإصدار ومنصات الحزم هي سطح الهجوم الرئيسي.

السبب الجذري الدقيق للاختراق لم يُكشف عنه بعد، حيث أكدت Bitwarden وجود صلة بحملة Checkmarx، لكنها لم تنشر تفصيلاً لكيفية وصول المهاجم إلى خط أنابيب الإصدار.

نتائج الهجوم وتأثيره

أقوى نتيجة للمدافعين هي أن هذه الحادثة تسرع إعادة تعريف معنى “رسمي” (Official).

اليوم، يضيف النشر الموثوق (Trusted Publishing) بيانات المصدر (Provenance) لكل حزمة منشورة، مما يؤكد هوية الناشر في المنصة. إطار SLSA يحدد بوضوح معيارًا أعلى يتطلب من المدققين التحقق مما إذا كانت بيانات المصدر تطابق المستودع والفرع وسير العمل ومعايير البناء المتوقعة.

إذا أصبح هذا المعيار هو السلوك الافتراضي للمستهلكين، فإن “رسمي” سيبدأ في أن يعني “بني بواسطة سير العمل الصحيح ضمن القيود الصحيحة”. عندها، المخترق الذي يخترق إجراءً لكنه لا يستطيع تلبية جميع قيود بيانات المصدر، سينتج حزمة يرفضها المستهلكون الآليون قبل أن تصل إليهم.

المسار الأكثر واقعية على المدى القريب يسير في الاتجاه المعاكس. لقد أثبت المخترقون، عبر ٤ حوادث على الأقل في ٦٠ يومًا، أن اختراق سير عمل الإصدار، وتبعيات الإجراءات، وبيانات اعتماد المسئولين يحقق نتائج عالية القيمة مع جهد منخفض نسبيًا.

كل حادثة متتالية تضيف تقنية موثقة جديدة إلى دليل هجومي عام يشمل اختراق الإجراءات، وسرقة الرموز من مخرجات CI، واختطاف حسابات المسئولين، وإساءة استخدام مسار النشر الموثوق.

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

أسئلة شائعة

هل تأثرت حسابات مستخدمي Bitwarden العاديين في هذا الهجوم؟

لا. أكدت Bitwarden أنه لا يوجد دليل على وصول المخترقين إلى خزائن كلمات المرور الخاصة بالمستخدمين النهائيين أو أنظمة الإنتاج. الهجوم كان يستهدف بالأساس سرقة بيانات اعتماد المطورين والبنية التحتية مثل رموز GitHub وأسرار الخدمات السحابية.

كيف يمكنني التأكد من أن حزمة Bitwarden التي قمت بتثبيتها أصلية؟

الحزمة الضارة كانت على npm لمدة ٩٣ دقيقة فقط وتمت إزالتها. تأكد من تثبيت أحدث إصدار رسمي من موقع Bitwarden الإلكتروني أو عبر القنوات الرسمية. يمكنك أيضًا التحقق من توقيعات الحزمة الرقمية وأرقام الإصدارات عبر صفحة التنزيلات الرسمية.

ما الدرس الأهم الذي يجب على فرق التطوير وأمن المعلومات استخلاصه من هذه الحادثة؟

الدرس الأهم هو أن الثقة في اسم الحزمة الرسمي لم تعد كافية. يجب على الفرق تطبيق التحقق من بيانات المصدر (Provenance) لكل حزمة يتم تثبيتها، وتقييد أذونات سير عمل CI/CD، واستخدام نموذج النشر الموثوق، ومراجعة تبعيات الإجراءات في خطوط الأنابيب بانتظام لضمان عدم وجود ثغرات يمكن استغلالها.