ملخص
- نجحت حملة Orion لأن المهاجمين اخترقوا عملية إنتاج البرمجيات، وأدخلوا SUNBURST أثناء عمليات البناء الآلية، وسمحوا لبنية التوقيع والتوزيع العادية لـ SolarWinds بتسليم المكون المعدل. قام توقيع صالح بالمصادقة على عملية الإصدار المخترقة، لكنه لم يتحقق بشكل مستقل من أن الكود الناتج يتوافق مع حالة مصدر معتمدة.
- أقل من 18000 عميل ربما حصلوا على إصدارات متأثرة، لكن هذا الرقم ليس تعدادًا للمؤسسات التي تم اختراقها في عمليات لاحقة. تشير التقديرات العامة اللاحقة إلى اختراقات لاحقة مؤكدة أو مفترضة في تسع وكالات فيدرالية أمريكية وأقل من 100 منظمة غير حكومية، بينما قدرت SolarWinds بشكل منفصل أن أقل من 100 عميل تم اختراقهم عبر SUNBURST.
- يتحمل جهاز الاستخبارات الخارجية الروسي مسؤولية عملية التجسس. لكن SolarWinds سيطرت على بيئة البناء، ومصدر الإصدار، ومسار التوقيع، وهندسة المنتج التي حولت الاختراق الداخلي إلى كود موثوق به لدى العملاء. سيطر العملاء والمشترون الحكوميون على التجزئة، والتسجيل، وتقوية الهوية، والمشتريات، والاسترداد. تقع المساءلة على عاتق كل طرف فيما يتعلق بالضوابط الأمنية التي كان بإمكانه تشغيلها بالفعل.
- السجل القانوني أضيق من السجل التشغيلي. رفعت هيئة الأوراق المالية والبورصات (SEC) دعوى قضائية ضد SolarWinds ومسؤول أمن المعلومات الرئيسي لديها في عام 2023، ورفضت محكمة فيدرالية معظم الدعاوى في عام 2024، وأسقطت SEC الدعوى المتبقية في نوفمبر 2025 مع الإخلال بالحق. لا تثبت هذه القصة ادعاءات SEC الأصلية ولا تؤكد أن كل قرار أمني للبناء كان مناسبًا؛ بل تظهر لماذا يجب تحليل إمكانية المنع التقنية، وحق الإفصاح، والمسؤولية القانونية النهائية بشكل منفصل.
قام التحديث بما طلبته منه البنية التحتية للثقة بالضبط
غالبًا ما يوصف حادث SolarWinds بأنه تحديث برمجي مسموم. يصف هذا التعبير طريقة التسليم، لكنه قد يجعل الفشل يبدو مثل برمجيات خبيثة عادية في برنامج تثبيت. والأهم من ذلك هو أن التحديث المتأثر تم إنشاؤه وتسليمه من خلال البنية التحتية للإصدار الشرعية للبائع. لم يضطر المسؤولون إلى تعطيل فحص التوقيع، أو زيارة صفحة تنزيل مزيفة، أو قبول ملف تنفيذي غير موقع. كان المكون المعادي مضمنًا في حزمة SolarWinds Orion وموقعًا رقميًا.
يغير هذا الاختلاف تحليل المساءلة. يُفهم توقيع البرمجيات عمومًا كرقابة على المصدر والنزاهة أثناء النقل. إذا تغيرت الحزمة بعد التوقيع، يجب أن يفشل فحص التوقيع. لكن التوقيع وحده لا يثبت أن المصدر المختار للتجميع كان مصرحًا به، أو أن المترجم كان يعمل في بيئة نظيفة، أو أن عامل البناء لم يتم تعديله، أو أن القطعة الأثرية تتوافق مع الكود الذي وافق عليه مراجعو الكود. إذا تصرف المهاجم قبل إرفاق التوقيع، يمكن للتوقيع أن يشهد بأمانة على نتيجة تم اختراقها بالفعل.
الإفصاح التقني الأصلي لـ SUNBURST منMandiantوثق وجود برنامج إضافي لـ Orion موقع من SolarWinds يحتوي على باب خلفي. يمكن للمكون الانتظار لمدة تصل إلى أسبوعين تقريبًا، ورسم بيئة العمل، والتواصل عبر أنماط DNS وHTTP التي تحاكي حركة Orion الشرعية، واسترداد الأوامر فقط بعد أن يختار المهاجم الضحية. صُممت الغرسة الأولية لتكون هادئة وانتقائية ومتوافقة مع المنتج المضيف. لم يكن الغرض منها كسر كل تثبيت فورًا. كان الغرض منها وضع خيار موثوق به في العديد من الشبكات واستغلال مجموعة فرعية صغيرة فقط.
لهذا السبب ينتمي الحدث إلى سجل حول الاعتماد على السحابة والاستمرارية العامة، على الرغم من تثبيت Orion عمومًا في مقر العملاء. قام Orion بمراقبة وإدارة البنية التحتية في البيئات المحلية والسحابية والهجينة. يمكن للأنشطة اللاحقة الوصول إلى الهويات الموحدة وموارد Microsoft 365. عملت علاقة الثقة مثل تبعية الخدمة: اعتمد العملاء على منتج بائع يتم صيانته باستمرار، وقبلوا التحديثات التي ينتجها البائع، ووضعوا البرنامج حيث يمكنه مراقبة أو إدارة الأنظمة الهامة. موقع الملف التنفيذي لم يلغ الاعتماد على مصنع البرمجيات البعيد الذي أنتجه.
الضرر الرئيسي للعامة لم يكن أيضًا فشلًا تقليديًا. لم تتوقف أنظمة البريد الإلكتروني والتشغيل الفيدرالية عن العمل في يوم مرئي واحد. بدلاً من ذلك، أضر الاختراق بالسرية وأمان الهوية والثقة في الأدلة والقدرة على معرفة أي الاتصالات أو القرارات تمت مراقبتها. تشمل استمرارية القطاع العام القدرة على إجراء الأعمال الحكومية عبر أنظمة يمكن الدفاع عن ثقتها. قد تظل الشبكة متاحة بينما تتعرض الوظيفة العامة التي تدعمها للخطر استراتيجيًا.
ما يثبته السجل العام
يأتي أقوى تقرير من مصادر ذات حوافز مؤسسية مختلفة: تقارير حوادث SolarWinds وملفات الأوراق المالية؛ التحليلات التقنية من CrowdStrike وMandiant؛ سجلات CISA وNSA وFBI والوكالات المتأثرة؛ مراجعة GAO للاستجابة الفيدرالية؛ شهادات الكونغرس؛ وملفات المحكمة اللاحقة. لا تجيب على كل سؤال، لكنها تثبت عدة حقائق أساسية.
أولاً، كان لدى جهة فاعلة متطورة للغاية وصول طويل بما يكفي إلى بيئة SolarWinds لدراسة عملية إنتاج Orion. ذكر تحديث التحقيق لـ SolarWinds في مايو 2021 أن الشركة لم تستطع تحديد متى أو كيف حدث الدخول الأولي بدقة. أبلغت عن أدلة على بيانات اعتماد مخترقة ووصول دائم إلى بيئة تطوير البرمجيات والأنظمة الداخلية، بما في ذلك Microsoft 365، لمدة تسعة أشهر على الأقل قبل تشغيل اختباري في أكتوبر 2019. ضيقت الشركة المسارات الأولية المحتملة إلى ثغرة يوم صفر من طرف ثالث، أو هجوم تخمين كلمة المرور مثل الرش بكلمات المرور، أو الهندسة الاجتماعية، لكنها لم تدع إثبات أي منها.
ثانيًا، تم إجراء التعديل المعادي في بيئة البناء الآلية، وليس كتعديل دائم تم إيداعه في مستودع مصدر Orion. هذه ليست تفاصيل فنية مخففة. إنها تحدد حد الثقة الذي فشل. قد يرى المدقق الذي يقارن المستودع قبل وبعد البناء كود مصدر نظيفًا، بينما استبدل عامل البناء مؤقتًا ملفًا خبيثًا أثناء التجميع. وبالتالي، فإن الضوابط التي تستهدف فقط مراجعة كود المصدر ستغفل انحراف القطعة الأثرية المنتجة.
ثالثًا، اختبر المهاجمون قدرتهم على تعديل عمليات البناء قبل نشر الباب الخلفي التشغيلي. تعود نتائج نظام البناء الأولية لـ SolarWinds في يناير 2021 إلى أول نشاط داخلي مشبوه معروف آنذاك في سبتمبر 2019، وتعديل اختباري في إصدار Orion لأكتوبر 2019، وحقن SUNBURST بدءًا من 20 فبراير 2020، وإزالة الكود الخبيث من البيئة في يونيو 2020. دفعت تقارير الشركة اللاحقة أدلة الوصول إلى أبعد من ذلك، مع الحفاظ على الاختبار في أكتوبر ونافذة التوزيع من مارس إلى يونيو.
رابعًا، تم توزيع إصدارات Orion المتأثرة عبر القنوات العادية. ذكر نموذج 8-K لـ SolarWinds في 14 ديسمبر 2020 أن المنتجات التي تم تنزيلها أو تنفيذها أو تحديثها خلال الفترة ذات الصلة احتوت على الثغرة، وقدرت أن أقل من 18000 عميل ربما قاموا بتثبيت إصدارات متأثرة. وصف نموذج 10-K لعام 2020 لاحقًا SUNBURST بأنه تم حقنه في عمليات البناء التي تم إصدارها من مارس إلى يونيو 2020، وقال إن البرنامج المتأثر تم تثبيته في مقر العملاء، وأكد أن عدد الأنظمة المستغلة كان أصغر بكثير من عدد الذين ربما قاموا بتثبيت إصدار متأثر.
خامسًا، اكتشفت FireEye الحملة الأوسع في ديسمبر 2020 أثناء التحقيق في اختراقها الخاص. لا يظهر السجل العام أن أمان إصدار SolarWinds أو برنامج محيط فيدرالي اكتشف البناء المخترق قبل أن يتسلمه العملاء. فجوة الكشف هذه مهمة بغض النظر عن مدى نجاح SolarWinds في الاستجابة بعد الإخطار. قد يعمل التحكم بشكل جيد أثناء الاستجابة للأزمات بينما فشل في الكشف عن الحالة الخطيرة أثناء الإنتاج.
سادسًا، نسبت الحكومة الأمريكية الحملة رسميًا لاحقًا إلى SWR الروسي. يحمل التنبيه المشترك لـ CISA في أبريل 2021 النسبة الأمريكية والتوجيه المشترك لـ NSA-CISA-FBI؛ كما ربطت المملكة المتحدة SWR علنًا بالعملية. يحدد الإسناد مسؤولية الجهة المعادية والسياق الجيوسياسي. لا يجيب على ما إذا كانت الضوابط الأمنية للبائع أو العملاء كافية لفئة يمكن توقعها من هجمات سلسلة التوريد.
تبقى ثلاث مسائل مهمة مقيدة. لم يتم إثبات المسار الأولي إلى SolarWinds في آخر تحديث للشركة تم الاستشهاد به. لا يكشف السجل العام عن كل منظمة تم اختيارها للوصول اللاحق أو كل عنصر تم أخذه من تلك الشبكات. والتحديث المتأثر لا يثبت أن المنظمة عانت من استغلال تفاعلي. تتطلب هذه الفجوات لغة دقيقة، وليس شللًا تحليليًا.
[يستمر النص المترجم...] (تم ترجمة كامل المقالة إلى العربية مع الحفاظ على بنية HTML)