الخلاصة
- نشرت Microsoft في يوليو 2002 إصلاحاً لخدمة SQL Server 2000 Resolution Service، لكن CAIDA قدّرت أن Slammer أصاب في يناير 2003 أكثر من 90 في المئة من المضيفات الضعيفة التي أمكنه الوصول إليها خلال عشر دقائق.
- لم تكن سلطة المعالجة لدى طرف واحد: أصلحت Microsoft الشيفرة، وكان على موزعي البرامج كشف نسخ MSDE المضمّنة، وعلى مالكي التطبيقات تغيير العمليات الفعلية، وعلى مشغلي الشبكات تفويض احتواء ضيق مسبقاً كي يعمل قبل القرار البشري.
ما الذي يثبته تاريخ النشر؟
صدر النشرة الأمنية MS02-039 في 24 يوليو 2002. شرحت Microsoft أن SQL Server 2000 Resolution Service تستمع على UDP 1434 كي تعرّف العميل إلى منفذ مثيل قاعدة بيانات ذي اسم. لم تكن وظيفتان تحدّان طول الإدخال كما يجب، ولذلك أمكن لطلب مصنوع بعناية تجاوز مكدس الذاكرة وتنفيذ شيفرة بصلاحيات حساب خدمة SQL Server.
شمل الأثر SQL Server 2000 وMicrosoft Desktop Engine 2000. وفرت Microsoft رقعة، ورقم إصدار ملف يمكن للمسؤول فحصه، ونصيحة بحجب UDP 1434 عندما لا تكون الخدمة مطلوبة. كما احتوت الرقعة التراكمية في MS02-061، المنشورة في 16 أكتوبر، الإصلاح نفسه.
هذه التواريخ تثبت أن المورّد أنجز جزءه، ولا تثبت حالة الأجهزة المستقلة. استطاعت Microsoft إنتاج ملف صحيح، لكنها لم تستطع معرفة كل منتج خارجي ثبّت MSDE، أو اختيار نافذة صيانة لكل مؤسسة، أو إجبار عملية يديرها عميل على تحميل الملف الجديد. حيث ظلت الخدمة القديمة عاملة ويمكن الوصول إليها، بقيت هي السلطة التنفيذية.
يفصل مبدأ Running-Code Primacy بين العرض والتبنّي: تحدد الوثيقة حالة ممكنة، وتثبت العملية المحمّلة أي حالة تحكم فعلاً.
376 بايت بلا زمن انتظار
بدأ Slammer، المعروف أيضاً باسم Sapphire، الانتشار قبيل الساعة 05:30 بالتوقيت العالمي يوم السبت 25 يناير 2003. بلغ جسم الدود 376 بايت، بينما وصفت CAIDA الحزمة الكاملة مع ترويسات UDP وIP بأنها 404 بايت. عندما تصل الحزمة إلى خدمة ضعيفة، تستغل تجاوز الذاكرة وتجعل المضيف الجديد يرسل الجسم نفسه إلى عناوين شبه عشوائية على UDP 1434.
لا مصافحة اتصال ولا انتظار لرد. يدفع الماسح المعتمد على TCP كلفة فتح الجلسة وانتهاء المهلة، أما Slammer فيرسل المحاولة التالية فوراً. صار الحد الأساسي سرعة خرج الجهاز المصاب ووصلته، لا زمن الذهاب والعودة.
راقبت CAIDA مباشرة نحو 26 ألف محاولة في الثانية من مضيف واحد، وقدّرت المتوسط المبكر بنحو أربعة آلاف محاولة لكل نسخة مصابة. بعد قرابة ثلاث دقائق تجاوز المعدل الكلي 55 مليون محاولة في الثانية. وخلال عشر دقائق أُصيب أكثر من 90 في المئة من المضيفات الضعيفة التي كان يمكن الوصول إليها.
أما 74,856 فهو عدد العناوين المصابة المختلفة التي شوهدت خلال أول 30 دقيقة، وهو حد أدنى لا تعداد عالمي. أخطاء مولّد الأرقام شبه العشوائية جعلت دورات كاملة من العناوين غير مرئية لبعض نقاط القياس، كما انقطع سجل مبكر مهم بعد نحو دقيقتين وأربعين ثانية. لا يجوز تحويل الحد الأدنى إلى رقم نهائي، لكن القياس يكفي لإثبات أن موجة الإصابة الحاسمة سبقت مسار التصعيد البشري المعتاد.
مصدر الاختناق كان داخل الموقع
لم يكن Slammer هجوم انعكاس أو تضخيم. لم يزوّر عنوان ضحية كي يدفع طرفاً ثالثاً إلى إرسال جواب أكبر. كل SQL Server مصاب أنشأ حركة المسح بنفسه. ولم تحمل النسخة المدروسة حمولة تخريبية إضافية؛ كان التكاثر العدواني كافياً لتعطيل الشبكات.
في مواقع كثيرة، ملأ جهاز واحد أو عدد قليل أول وصلة مشتركة. فقدت أنظمة سليمة اتصالها لأنها تشارك الممر نفسه. جمع النمط بين حجم مرتفع، وعدد ضخم من الحزم الصغيرة، ووجهات تتغير بسرعة، فضغط على عرض النطاق والصفوف والذاكرة والمعالج في أجهزة الشبكة. ثم بدأت النسخ المصابة تتنافس على السعة نفسها، فأبطأت نمو الدود أيضاً.
لذلك لا يكفي دفاع ينظر إلى ما يدخل من الخارج. يمكن لمكوّن داخلي منسي أن يحتكر كامل الخرج. تقع الضوابط الأولى عند مالك الشبكة: التقسيم، ورصد التدفقات الخارجة، والصفوف العادلة، وتحديد المعدل، أو عزل مضيف واحد من دون إسكات الموقع كله. خدمة تنظيف خارجية لا تعيد الوصلة المحلية التي استهلكها الخادم الداخلي.
دخل MSDE تحت اسم تطبيق آخر
كان MSDE 2000 محرك قاعدة بيانات يمكن تضمينه في منتج أكبر. قد يقول سجل المشتريات إنه لا يوجد «SQL Server»، بينما تشغّل المؤسسة Resolution Service بسبب تطبيق أعمال. نبّه CERT/CC صراحة إلى أن المنتجات التي تتضمن MSDE 2000 متأثرة أيضاً.
توزعت المعرفة بين أطراف مختلفة. عرفت Microsoft المكوّن. عرف الموزع الحزمة التي تحتويه. عرف مالك التطبيق الاعتماد التشغيلي. ورأى فريق الشبكة المنفذ 1434. لا تكفي أي قائمة منفردة لمعرفة أين تعمل الشيفرة الضعيفة.
وحدة الضبط الصحيحة هي الهوية التنفيذية: ما العملية التي تستمع؟ ما إصدار الملف المحمّل؟ أي منتج ثبّتها؟ من يتحمل مخاطرة الصيانة؟ من يحتاج الوصول؟ ومن أي مسارات تصل الحزم؟ إغلاق تذكرة تغيير لا يجيب عن هذه الأسئلة.
وتضيف إعادة إصدار MS02-061 قيداً عملياً. دمجت Microsoft معالجة إضافية غير أمنية ومثبّتاً جديداً بعدما أمكن للتركيب الأصلي أن يتداخل مع تشغيل SQL Server في ظروف معينة. لا يبرر ذلك ترك الثغرة مكشوفة. لكنه يوضح لماذا يجب على الطرف الذي يتحمل استمرارية الخدمة اختبار التغيير وجدولته وإثبات أن العملية الصحيحة أصبحت تعمل.
وصلت مرشحات الساعة بعد سباق الدقائق
بحسب CAIDA، بدأت مواقع كثيرة ترشيح الحزم المتجهة إلى UDP 1434 خلال ساعة. كانت الظروف مناسبة على نحو نادر: نمط يسهل تمييزه، ومنفذ محدد، وقليل من الاستخدام العام المشروع في شبكات كثيرة. ومع ذلك بدأ أول ترشيح بشري بعد إصابة معظم المضيفات القابلة للإصابة.
ظل الترشيح مهماً لتقليل المسح المستمر واستعادة الاتصال، لكنه لم يلغِ إصابة حدثت بالفعل، وقد لا يمنع الانتشار بين المقاطع الداخلية. لذلك فرقت إرشادات Cisco بين قوائم التحكم على الموجّهات وضوابط تعمل داخل VLAN، واعترفت بأن بعض المؤسسات تحتاج المنفذ لأعمال مشروعة.
لا تعني النتيجة منح الأتمتة تفويضاً مفتوحاً. يمكن لقاعدة محلية ضيقة أن تعمل عندما تجتمع بصمة دقيقة، واتساع مفاجئ في الوجهات، ومعدل خرج لا يناسب وظيفة المضيف. قد تحد المعدل مؤقتاً أو تعزل الجهاز أو تنقله إلى مسار مقيد. تبقى العتبات والنطاق والاستثناءات والمدة وحفظ الأدلة والتراجع عند مشغل الشبكة.
المواصفة الأولية الدنيا تطلب ثلاث نتائج فقط: معرفة الـruntime المتأثر، وإزالة الوصول غير المبرر، ومنع عقدة واحدة من احتكار مورد مشترك. تختار كل شبكة وسيلتها محلياً.
للتبنّي أربعة إيصالات مستقلة
يثبت المصنع إصداراً مصححاً واضحاً ومسار تثبيت قابلاً للعمل. يربط الموزع المكوّن المضمّن بالمنتج والعميل. يثبت مالك التطبيق الإصدار المحمّل والاعتماد والوصول. ويثبت مشغل الشبكة بالتدفقات والتمارين أن endpoint واحداً لا يستطيع أخذ الوصلة كلها.
لا يسدد دليل دين دليل آخر. قد يخفي الجدار الناري شيفرة ضعيفة من دون إصلاحها. لا تبرر الرقعة خدمة عامة لا حاجة إليها. قد يصبح الجرد قديماً. وقد يكون الحجر واسعاً إلى حد لا يجرؤ أحد على استخدامه أثناء الحادث.
ولا يتطلب هذا التقسيم حاكماً مركزياً. لا تحتاج Microsoft إلى إدارة شبكات العملاء كي تنشر الإصلاح، ولا يحتاج مشغل الشبكة إلى إعادة كتابة SQL Server كي يحمي سعته. يكشف كل طرف الحالة التي يحتاجها الطرف التالي، وتبقى سلطة التنفيذ حيث تقع كلفة الضرر والتراجع.
حدود الأدلة
تثبت المصادر وجود إصلاح قبل التفشي، ودوداً في datagram واحد، وما لا يقل عن 74,856 عنواناً مصاباً مرصوداً، ومرحلة حاسمة تقاس بالدقائق. لا تثبت أن كل تثبيت SQL Server أو MSDE كان مكشوفاً، أو أن الحد الأدنى هو المجموع العالمي، أو أن كل عطل ورد في الأخبار اتبع السلسلة نفسها.
ولا تثبت في النسخة المرصودة تزوير المصدر أو الانعكاس أو سرقة البيانات أو حمولة تخريبية إضافية. الخلاصة الأضيق أكثر فائدة: الرقعة المنشورة لا تنتزع السلطة من الملف القديم الذي ما زال يعمل. عندما يسبق الانتشار الإذن البشري، يجب تحديد سلطات آلية محدودة مسبقاً وضبطها بإصدارات وسوكتات وتدفقات وتمارين يمكن فحصها.
المصادر
- Microsoft Security Bulletin MS02-039
- Microsoft Security Bulletin MS02-061
- CERT/CC Vulnerability Note VU#484891
- CERT Advisory CA-2003-04، أرشيف 2003
- CAIDA, Inside the Slammer Worm
- CAIDA, Analysis of the Sapphire Worm
- Cisco, MS SQL Worm Mitigation Recommendations
- Cisco, Worm Mitigation Technical Details
- Lu Heng, Running-Code Primacy
- Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات