تقول Grafana إن بيانات اعتماد مسروقة أدت إلى محاولة سرقة الشيفرة

تقول Grafana Labs، الشركة التي تقف وراء منصة المراقبة مفتوحة المصدر واسعة الاستخدام، إنها تعرضت للاختراق بعدما استغل مهاجمون رمزًا مسروقًا منحهم وصولًا إلى بيئة التطوير الخاصة بها على GitLab. ووفقًا للبيانات العامة للشركة، فإن الرمز المخترق لم يمنح وصولًا إلى سجلات العملاء أو المعلومات المالية، لكنه سمح للمهاجمين بالحصول على مستودعات الشيفرة المصدرية الخاصة بالشركة.

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

محاولة ابتزاز قوبلت بالرفض

تقول Grafana إن المهاجم طالب بدفع مقابل عدم نشر قاعدة الشيفرة. ورفضت الشركة ذلك. وفي شرحها لهذا القرار، أشارت Grafana إلى إرشادات طويلة الأمد صادرة عن مكتب التحقيقات الفيدرالي تنصح الضحايا بعدم الدفع للمبتزين لأن الدفع لا يضمن عودة البيانات بأمان ولا يمنع نشرها لاحقًا.

وتكتسب القضية طابعًا غير معتاد لأن البرنامج الرئيسي لـ Grafana مفتوح المصدر ومتاح بالفعل للجمهور. وهذا يعقّد ادعاء الابتزاز: فبينما قد يكون المهاجمون قد وصلوا إلى المستودعات، تقول الشركة إن شيفرتها الرئيسية عامة بطبيعتها، ما يترك سؤالًا مفتوحًا حول ما إذا كانت أي مواد داخلية خاصة قد أُخذت أيضًا.

لماذا لا يزال هذا مهمًا لشركة مفتوحة المصدر

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

لذلك فإن تصريح Grafana بأن بيانات العملاء والبيانات المالية لم يتم الوصول إليها مهم، لكنه غير كافٍ لجعل الحادثة بسيطة. إن الوصول إلى أنظمة الهندسة يخلق مخاطره الخاصة، خاصة إذا تمكن المهاجمون من رسم خريطة للعمليات الداخلية أو البحث عن أسرار تم التحقق منها في المستودعات عن طريق الخطأ.

نمط متزايد في أمن البرمجيات

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

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

مقارنة مع قرارات فدية حديثة في أماكن أخرى

تشير TechCrunch إلى مقارنة مع القضية الأخيرة المتعلقة بشركة تكنولوجيا التعليم Instructure، التي أفادت التقارير بأنها توصلت إلى اتفاق لدفع أموال للمهاجمين بعد خرق منفصل شمل بيانات مسروقة وتشويهًا لاحقًا للموقع. أما Grafana فقد اتخذت الموقف المعاكس، معتبرة أن الرفض هو الرد الأكثر قابلية للدفاع.

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

ما الذي يجب مراقبته لاحقًا

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

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

هذه المقالة مبنية على تقرير TechCrunch. اقرأ المقال الأصلي.

Originally published on techcrunch.com