نداء استغاثة النطاقات الحلقة 14: لما شركة أمن سيبراني اتعرضت لاختطاف DNS — حادثة Fox-IT

الشيء المميّز في هجوم رجل-في-المنتصف إنه وهو بيحصل، كل حاجة بتبان عادية تماماً.

الموقع بيفتح. شريط العنوان بيوري النطاق الصح. القفل مقفول. الشهادة سليمة. الملفات بترفع، وتسجيل الدخول بيشتغل، والإيميلات بتوصل. مفيش خطأ، مفيش تحذير، مفيش صورة مكسورة — بس في طرف تالت هادي جالس في نص المحادثة، بيقرا كل حاجة بتعدي عليه ثم بيبعتها للجهة التانية، عشان أي حد من الطرفين ميحسّش بالتأخير.

دلوقتي تخيّل إن ده حصل مع الناس اللي شغلتهم بالظبط إنهم يلاقوا زي ده.

في سبتمبر 2017، شركة Fox-IT الهولندية للأمن السيبراني — الشركة اللي بتحقق في الاختراقات وبتبني أجهزة استشعار لكشف الاعتراض وبتنصح الحكومات بشأن طريقة تحرك المهاجمين — اكتشفت إن مهاجم اختطف DNS نطاق الشركة نفسها، وحصل على شهادة TLS بإسمها، وقضى معظم يوم كامل وهو بيقرا المرور من وإلى بوابة العملاء. قفل الحدّاد نفسه اتكسر. وبعدين Fox-IT عملت الحاجة اللي قلّة من الشركات المتضررة بتعملها: نشرت رواية مفصّلة بالظبط لكيفية حدوث ده.

حتى شركة أمن سيبراني بتعتمد على مسجّل النطاقات بتاعها

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

نطاقك — الاسم اللي عملاؤك بيكتبوه، العنوان اللي الشهادات بتتصدر عليه، الوجهة اللي الإيميل بتاعك بيشير إليها — بيتضبط عند مسجّل نطاقات. اللي بيتحكم في حساب المسجّل ده بيتحكم في مكان انحلال اسمك. يقدر يعيد توجيه موقعك، ويحوّل مسار إيميلك، ويُثبت "ملكيته" لنطاقك أمام جهة إصدار الشهادات. كل ده من غير ما يلمس سيرفراتك أو جدران الحماية أو الكود بتاعك. بس بيتطلب تسجيل الدخول لبانل ويب واحد.

Fox-IT كانت بكل المقاييس مؤسسة أمنية جادة. كانت بتشغّل التقاط حزم بيانات كاملة وأجهزة استشعار شبكة خاصة بيها. وكانت بتستخدم المصادقة الثنائية على بوابتها أمام العملاء. وبعدين اتّضمت في NCC Group. ومع ذلك كانت مكشوفة من خلال الحساب الواحد اللي ما كانتش بتسجّل فيه دخول تقريباً — لأن الشركة نفسها قالت، إعدادات DNS بشكل عام بتتغير نادراً جداً، فالبيانات اللي كانت بتحرسها اتقدمت بهدوء.

زي ما Fox-IT صاغت الأمر في مقدمة تقريرها: لو هجوم زي ده قدر يضرب شركة أمن، فعلى الأغلب يقدر يضرب كتير من الأنواع التانية من الأعمال اللي مش متخصصة في الأمن.

19 سبتمبر 2017: الاختطاف وهجوم MITM

رواية Fox-IT بتبدأ بسطر أصبح حجر أساس في كتابة الاستجابة للحوادث: بالنسبة لـ Fox-IT كلمة "لو" بقت "لما" في يوم الثلاثاء 19 سبتمبر 2017، لما الشركة وقعت ضحية هجوم رجل-في-المنتصف.

اللي حصل ما كانش استغلال سيرفر. في الصباح الباكر من 19 سبتمبر، مهاجم وصل لسجلات DNS لنطاق Fox-IT.com عند مسجّل النطاقات الخارجي بتاعنا. بالتحكم في السجلات دي، المهاجم عدّل سجل DNS لسيرفر معيّن عشان يشير لسيرفر في حوزته ويعترض المرور ويعيد توجيهه تاني للبنية التحتية الحقيقية لـ Fox-IT.

التفصيلة دي الأخيرة — إعادة توجيه المرور — هي اللي خلّته هجوم رجل-في-المنتصف بدل مجرد انقطاع خدمة. الزوار لسه وصلوا لبوابة شغّالة. بس وصلوا إليها من خلال المهاجم الأول.

الهدف كان محدداً. الهجوم كان موجّه تحديداً لـ ClientPortal، تطبيق الويب لتبادل الوثائق بتاع Fox-IT، النظام اللي كانت بتستخدمه Fox-IT لتبادل الملفات بأمان مع العملاء والموردين والمؤسسات التانية. بمعنى تاني، المهاجم مشي مباشرة للقناة اللي بتتدفق فيها وثائق العملاء الحساسة.

عشان Fox-IT اكتشفته واحتوته، الشركة حصرت إجمالي وقت MitM الفعّال في 10 ساعات و24 دقيقة. التغطية المستقلة أكّدت نفس الرقم: الحادثة وقعت في 19 سبتمبر واستمرت 10 ساعات و24 دقيقة.

إيه اللي اتعمل اعتراضه فعلاً

عشر ساعات من هجوم رجل-في-المنتصف على بوابة تبادل وثائق بيبان كارثياً. لكن الغنيمة الفعلية كانت صغيرة — وصغرها ده نفسه هو الحكاية.

خلال الفترة دي، تسعة مستخدمين دخلوا وبياناتهم اتعترضت. لكن البيانات دي كانت عديمة الفايدة في الأغلب: بوابة Fox-IT كانت بتطلب عامل مصادقة تاني ما قدرش المهاجم، اللي كان جالس في مسار الشبكة، يعيد استخدامه. Help Net Security لاحظت إن بيانات دخول التسعة مستخدمين اتسُرّقت لكنها كانت عديمة الفايدة من غير عامل المصادقة التاني.

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

حقيقتان خلّتا الضرر محدوداً. الأولى، Fox-IT صرّحت بوضوح إن الملفات المصنّفة كسرية للدولة ما بتتنقلش أبداً عبر ClientPortal بتاعنا — المواد الأكثر حساسية ما كانتش موجودة أصلاً في القناة المكشوفة. تانياً، العامل الثاني للشركة نفسها خفّف من سرقة البيانات. التصميم المعماري حدّد نطاق الأضرار حتى بعد فشل المحيط الأمني — وهو DNS.

كيف حصل: كلمة مرور قديمة واحدة، من غير عامل ثاني

الآلية بتبان زي قايمة مراجعة لكيفية الاستيلاء على نطاق من غير سطر واحد من البرمجيات الخبيثة على سيرفرات الضحية.

الخطوة الأولى — الدخول لحساب المسجّل. المهاجم نجح في تسجيل الدخول لبانل تحكم DNS لمزوّد مسجّل النطاقات الخارجي بتاعنا باستخدام بيانات دخول صحيحة. تحقيق Fox-IT خلص إن المهاجم على الأغلب حصل على بيانات الدخول لبانل تحكم DNS من خلال اختراق طرف ثالث. ضعفان متراكمان خلّوا عملية الدخول دي تنجح: كلمة المرور ما اتغيّرتش من سنة 2013، والمسجّل ما كانش بيقدّم أي عامل ثاني على الإطلاق — في وقت الكتابة، Fox-IT لاحظت إن المسجّل لسه ما بيدعمش 2FA.

الخطوة التانية — تغيير DNS وإثبات "الملكية" لجهة إصدار الشهادات. بفتح البانل، المهاجم أعاد توجيه DNS. لكن عشان ينفّذ هجوم رجل-في-المنتصف موثوق على موقع HTTPS، كان محتاج شهادة صحيحة لـ fox-it.com — والطريقة الحديثة للحصول عليها هي إثبات إنك بتتحكم في النطاق. فالمهاجم عمل بالظبط ده. في فترة ضيّقة حوالي 02:05–02:15، عدّل مؤقتاً مسار إيميل Fox-IT واعترضه لغرض محدد هو إثبات امتلاكه لنطاقنا في سياق التسجيل الاحتيالي لشهادة SSL لـ ClientPortal بتاعنا. ده هو الجزء اللي المفروض يخلّي كل قارئ يوقف عنده: التحكم في DNS هو في الحقيقة تحكم في التحقق من النطاق. الشهادة المُتحقَّق منها بالنطاق بتتمنح لأي حد يقدر يجاوب على تحدي جهة الإصدار — وهنا، التحكم في DNS سمح للمهاجم بإعادة توجيه إيميل التحقق والرد عليه. DNS بيقرر أين تهبط إثبات الملكية دي.

الخطوة التالتة — الجلوس في المنتصف. مسلّحاً بشهادة صادرة بشكل قانوني (لكن محصول عليها بالاحتيال)، المهاجم وجّه النطاق لـ VPS في الخارج واعترض المرور. زي ما وصفت SecurityWeek، شهادة SSL المزوّرة استُخدمت في هجوم MitM على ClientPortal، مع توجيه المرور للبوابة عبر مزوّد خادم خاص افتراضي (VPS) في الخارج. بالنسبة للزائر، ما كانش في حاجة غلط. القفل كان حقيقي. الشهادة اتحقّقت. الرجل في المنتصف كان شايل مفتاح المتصفح وثق فيه.

تلاتة طبقات — DNS، وجهة إصدار الشهادات، وTLS نفسه — كلها كانت شغّالة تقنياً بشكل صحيح. المهاجم ما كسرش أي واحدة منهم. أقنع التلاتة إنه Fox-IT، والحاجة الوحيدة اللي خلّته يعمل ده كانت تسجيل دخول واحد قديم بعامل مصادقة واحد عند مسجّل نطاقات.

استجابة Fox-IT: الكشف والاحتواء، ثم إخبار الجميع

اللي بيميّز الحادثة دي عن مئة حادثة أهدأ هو الاستجابة — سواء التقنية أو التحريرية.

الكشف كان سريعاً. Fox-IT اكتشفت إن خوادم الأسماء بتاعتها لنطاق fox-it.com اتحوّلت، وضبطت الاختراق بعد حوالي خمس ساعات من بدايته — حوالي خمس ساعات بعد ما الهجوم بدأ، زي ما أفادت Help Net Security. التقاط الحزم الكامل وأجهزة الاستشعار اللي الشركة كانت بتشغّلها على نفسها أعطتها السجل الجنائي لإعادة بناء بالظبط إيه اللي اتلمس وإيه اللي ما اتلمسش.

الاحتواء كان مدروساً. بدل ما تسحب البوابة من الإنترنت وتنبّه المهاجم، Fox-IT اختارت تخفيفاً أهدأ: عطّلت المصادقة الثنائية لنظام مصادقة تسجيل الدخول في ClientPortal بتاعنا — خطوة عكسية للوهلة الأولى، لكنها سمحت بإدارة الموقف مع استعادة التحكم في DNS، كل ده من غير الكشف إن الشركة اكتشفت الاختراق. ثم تواصلت مع العملاء المتضررين بخصوص الملفات دي فوراً.

ثم جاء الجزء اللي حوّله لدراسة حالة. بعد تلاتة أشهر، عقب التحليل ومع سير تحقيق قضائي، Fox-IT نشرت تقرير ما بعد الحادث الكامل المؤرَّخ تحت فكرة بسيطة: الشفافية بتبني ثقة أكتر من السرية وفي دروس لازم نتعلمها. شركة أمن اتحرجت بأكتر طريقة مرتبطة بنشاطها — وبدل ما تطمر الأمر، سلّمت الصناعة تحليلاً تفصيلياً. عنوان BleepingComputer التقط النبرة اللي ستلحظة كانت تستحقها: شركة الأمن الكبرى تعترف بحادثة أمن MitM.

إيه اللي بيعلّمنا إياه ده عن أمان المسجّل وأقفال السجل

لو جرّدنا التفاصيل، حادثة Fox-IT هي درس في مكان وجود المحيط الحقيقي. بالنسبة لمعظم المؤسسات، المحيط مش بس جدار الحماية. هو تسجيل الدخول لمسجّل النطاقات. إليك ما بتحتج عليه القضية دي:

1. اعتبر حساب مسجّل النطاقات زي البنية التحتية الإنتاجية. قلّة ما بيتغير فيه، فسهل تنساه — وده بالظبط السبب اللي بيخلّيه يتردّى. كلمة مرور ما اتلمستش من 2013 مش "خطر منخفض لأن المرور قليل"؛ ده بيان عالي القيمة من غير أي مراقبة عليه.

2. اطلب المصادقة متعددة العوامل عند المسجّل — واشيل حسابك لو ما توفرتش. مسجّل Fox-IT ما كانش بيدعم 2FA على الإطلاق. الحساب الأهم في سلسلة أمان نطاقك كان محمياً بكلمة مرور وحدها. وجود أو غياب 2FA عند المسجّل هو معيار شراء لازم، مش مجرد ميزة إضافية.

3. استخدم قفل السجل. فوق تسجيل الدخول للمسجّل، كتير من السجلات بتقدّم قفل السجل — تثبيت من جهة السيرفر بيمنع إجراء تغييرات على خوادم الأسماء وسجلات الاتصال إلا لو اتمت خطوة تحقق يدوي خارج النطاق. قفل السجل كان معناه إن حتى كلمة مرور المسجّل المخترقة بالكامل ما كانتش تقدر تعيد توجيه DNS بهدوء. بيحوّل "بانل واحد على بُعد" لـ "أكتر من إنسان ومكالمة تليفون على بُعد."

4. وظّف DNSSEC لما تقدر. DNSSEC بيوقّع ردود DNS تشفيرياً عشان المحلّلات تقدر تكشف العبث في مسار الاستحلال. مش رصاصة فضية هنا — مهاجم بيتحكم في السجلات الموثوقة يقدر يعيد توقيعها — لكنه بيرفع التكلفة ويغلق فئات كاملة من التلاعب بـ DNS في الطريق. الدفاع بالعمق على طبقة DNS مهم بالظبط لأن، زي ما أثبتت القضية دي، DNS بيقع فوق TLS وإصدار الشهادات في هرم الثقة.

5. افتكر إن التحكم في DNS يعني التحكم في الشهادات. المهاجم حصل على شهادة TLS صحيحة بإثبات ملكية النطاق عبر إيميل محوَّل المسار. راقب سجلات شفافية الشهادات لأي شهادات غير متوقعة صادرة ضد نطاقاتك. شهادة مجهولة ظهرت في CT هي واحدة من الإشارات الخارجية النادرة على إن اختطاف DNS ربما بيحصل.

6. حافظ على عامل ثاني في التطبيق نفسه. 2FA بوابة Fox-IT هو السبب اللي خلّى تسع كلمات مرور مسروقة عديمة الفايدة من غير عامل المصادقة التاني. لما الطبقة الخارجية (DNS) فشلت، الطبقة الداخلية (MFA على مستوى التطبيق) لسه حدّت الضرر.

الخيط الرابط: نطاقك هو نقطة فشل واحدة بتاستعين فيها جزئياً بالغير. تقويته مش بهرجة، وبيُجدي فقط في اليوم اللي حد يحاول فيه بالظبط ما حصل مع Fox-IT.

زاوية Namefi

حادثة Fox-IT في جوهرها هي مشكلة تحكم ومصدر. المهاجم ما احتاجش إنه يبقى Fox-IT. بس احتاج نظام واحد — بانل المسجّل — يُصدّق إنه كده، لفترة كافية يعيد فيها توجيه DNS ويصدر شهادة. كل حاجة تعلو على ده وثقت في ده.

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

ده مش هيجعل مهاجماً مصمّماً مستحيلاً. لكن قصة Fox-IT في نهاية الأمر عن تسجيل دخول مسروق واحد بيترجم لتحكم كامل في اسم. كلما كان التحكم في النطاق قريباً من الملكية القابلة للتحقق — وكلما صعب تغيير اسم بهدوء بكلمة مرور قديمة واحدة — كلما قلّت فرصة إن لحظة زي "لو بقت لما" تتمدد قبل ما حد يلاحظها.

شركة أمن اكتشفت اختطافها في خمس ساعات وأخبرت العالم بالطريقة دي. معظم المؤسسات مش هتكتشفها في أيٍّ من الحالتين. أرخص درس هو اللي Fox-IT دفعته: قفّل المسجّل قبل ما يبقى الباب المفتوح.

المصادر والمزيد من القراءة

• Fox-IT (NCC Group) — دروس مستفادة من هجوم رجل-في-المنتصف (تقرير ما بعد الحادث الأساسي)
• BleepingComputer — Top Security Firm Admits to MitM Security Incident
• Help Net Security — Security company Fox-IT reveals, details MitM attack they suffered in September
• Graham Cluley — Fox-IT reveals hackers hijacked its DNS records, spied on clients' files
• SecurityWeek — Hackers Target Security Firm Fox-IT
• GBHackers — Leading IT Security Firm Fox-IT hit by Cyber Attack
• Krebs on Security — A Deep Dive on the Recent Widespread DNS Hijacking Attacks (ذات صلة: تقنية اختطاف DNS + شهادة مزوّرة على نطاق واسع)