قبل بضعة أيام كشف GitHub عن حادثتين في البنية التحتية لمستودع حزمة NPM ، والتي توضح أنه في 2 نوفمبر ، اكتشف باحثو الأمان التابعون لجهات خارجية ، كجزء من برنامج Bug Bounty ، ثغرة أمنية في مستودع NPM مما يسمح بنشر إصدار جديد من أي حزمة باستخدام حتى لو لم يكن مصرحًا به لإجراء مثل هذه التحديثات.
كانت الثغرة الأمنية ناتجة عن فحوصات التخويل غير الصحيحة في رمز الخدمات المصغرة تطلب هذه العملية إلى NPM. أجرت خدمة التفويض فحصًا للإذن على الحزم بناءً على البيانات التي تم تمريرها في الطلب ، لكن خدمة أخرى كانت تقوم بتحميل التحديث إلى المستودع حددت الحزمة للنشر بناءً على محتوى البيانات الوصفية في الحزمة التي تم تحميلها.
وبالتالي ، يمكن للمهاجم أن يطلب نشر تحديث لحزمته ، التي يمكنه الوصول إليها ، ولكن يشير في الحزمة نفسها إلى معلومات حول حزمة أخرى ، والتي سيتم تحديثها في النهاية.
خلال الأشهر القليلة الماضية ، استثمر فريق npm في تحسينات البنية التحتية والأمان لأتمتة مراقبة إصدارات الحزم التي تم إصدارها مؤخرًا وتحليلها لتحديد البرامج الضارة وغيرها من التعليمات البرمجية الضارة في الوقت الفعلي.
هناك فئتان رئيسيتان من أحداث نشر البرامج الضارة التي تحدث في النظام البيئي npm: البرامج الضارة التي يتم نشرها بسبب سرقة الحساب ، والبرامج الضارة التي ينشرها المهاجمون من خلال حساباتهم الخاصة. على الرغم من ندرة عمليات الاستحواذ على الحسابات عالية التأثير نسبيًا ، مقارنة بالبرامج الضارة المباشرة التي ينشرها المهاجمون باستخدام حساباتهم الخاصة ، إلا أن عمليات الاستحواذ على الحسابات يمكن أن تكون بعيدة المدى عند استهداف مشرفي الحزم المشهورين. بينما كان وقت اكتشافنا واستجابتنا لعمليات الاستحواذ على الحزم الشائعة منخفضًا يصل إلى 10 دقائق في الحوادث الأخيرة ، فإننا نواصل تطوير قدراتنا للكشف عن البرامج الضارة وإستراتيجيات الإشعارات من أجل نموذج استجابة أكثر استباقية.
المشكلة تم إصلاحه بعد 6 ساعات من الإبلاغ عن الثغرة الأمنية ، لكن الثغرة كانت موجودة في NPM لفترة أطول مما تغطي سجلات القياس عن بعد. يوضح GitHub أنه لا توجد أي آثار للهجمات التي تستخدم هذه الثغرة الأمنية منذ سبتمبر 2020ولكن ليس هناك ما يضمن عدم استغلال المشكلة من قبل.
ووقعت الحادثة الثانية في 26 أكتوبر / تشرين الأول. في سياق العمل الفني مع قاعدة بيانات خدمة replicant.npmjs.com ، تم الكشف عن وجود بيانات سرية في قاعدة البيانات متاحة للتشاور الخارجي، كاشفة عن معلومات حول أسماء الحزم الداخلية التي تم ذكرها في سجل التغيير.
معلومات عن تلك الأسماء يمكن استخدامها لتنفيذ هجمات التبعية على المشاريع الداخلية (في فبراير ، سمح مثل هذا الهجوم بتشغيل التعليمات البرمجية على خوادم PayPal و Microsoft و Apple و Netflix و Uber و 30 شركة أخرى.)
وبالإضافة إلى ذلك، فيما يتعلق بتزايد حالات الاستيلاء على مستودعات المشاريع الكبيرة والترويج للشفرات الضارة من خلال اختراق حسابات المطورين ، قررت GitHub تقديم المصادقة الثنائية الإلزامية. يسري التغيير في الربع الأول من عام 2022 وسينطبق على المشرفين والمسؤولين عن الحزم المدرجة في قائمة الأكثر شهرة. بالإضافة إلى ذلك ، فهي تقدم تقارير عن تحديث البنية التحتية ، والتي ستقدم المراقبة والتحليل الآليين للإصدارات الجديدة من الحزم للكشف المبكر عن التغييرات الضارة.
تذكر أنه وفقًا لدراسة أجريت في عام 2020 ، يستخدم 9.27٪ فقط من مديري الحزم مصادقة ثنائية لحماية الوصول ، وفي 13.37٪ من الحالات ، عند تسجيل حسابات جديدة ، حاول المطورون إعادة استخدام كلمات المرور المخترقة التي تظهر في كلمات المرور المعروفة .
أثناء التحقق من قوة كلمات المرور المستخدمة ، تم الوصول إلى 12٪ من الحسابات في NPM (13٪ من الحزم) بسبب استخدام كلمات مرور بسيطة يمكن التنبؤ بها مثل "123456". من بين المشكلات ، كانت هناك 4 حسابات مستخدمين من أكثر 20 حزمة شيوعًا ، و 13 حسابًا تم تنزيل حزمها أكثر من 50 مليون مرة شهريًا ، و 40 حسابًا - أكثر من 10 ملايين تنزيل شهريًا و 282 مع أكثر من مليون عملية تنزيل شهريًا. بالنظر إلى حمل الوحدات على طول سلسلة التبعيات ، فإن المساس بالحسابات غير الموثوق بها يمكن أن يؤثر على ما يصل إلى 1٪ من جميع الوحدات في NPM بشكل إجمالي.
وأخيرا، إذا كنت مهتمًا بمعرفة المزيد عنها يمكنك التحقق من التفاصيل في الرابط التالي.