كيف يحدث اختطاف النطاقات فعلياً: خمسة مسارات للهجوم والضوابط التي توقفها

مصطلح "اختطاف النطاق" (Domain hijacking) هو أحد تلك العبارات التي تبدو درامية، لكنها تعني أشياء مختلفة تماماً بناءً على كيفية حدوثها. الاستيلاء على حساب مسجل النطاق عبر رسالة بريد إلكتروني تصيدية هو اختطاف. وتبديل سجل خادم الأسماء (nameserver) خلسةً لدى مزود خدمة DNS هو اختطاف. والنطاق منتهي الصلاحية الذي يستولي عليه شخص آخر ويعيد توجيهه يعتبر أيضاً، بمعنى ما، اختطافاً.

في كل حالة، تكون النتيجة واحدة: شخص آخر يخبر العالم الآن إلى أين يشير اسم نطاقك. البريد الإلكتروني، والمدفوعات، وعمليات تسجيل الدخول، وتكاملات البرمجيات كخدمة (SaaS) تبدأ جميعها في إرسال البيانات (traffic) إلى المهاجم. غالباً ما تستغرق عملية الاسترداد أياماً، وأحياناً أسابيع. إذا تم نقل النطاق إلى مسجل آخر، فقد تكون سياسة حل نزاعات النقل (TDRP) الخاصة بـ ICANN ذات صلة؛ بينما تتطلب الحالات الأخرى غالباً التصعيد للمسجل، أو التصعيد لسجل النطاقات (registry)، أو استرداد المنصة، أو استصدار أمر قضائي. الحل الأسرع هو ألا تضع نفسك في هذا الموقف من الأساس.

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

1. الهندسة الاجتماعية ضد فريق دعم مسجل النطاق

أشهر عمليات الاختطاف البارزة في العقد الماضي لم تتضمن أي استغلال لثغرات تقنية. بل تضمنت مكالمة هاتفية.

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

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

ما الذي يوقفه:

• قاعدة صارمة من جانب مسجل النطاق تنص على أن تغييرات الملكية تتطلب إما مستنداً موثقاً أو تحدياً للمصادقة متعددة العوامل عبر القناة الحالية للمالك المسجل.
• قفل السجل (Registry lock) (وهو منفصل عن قفل المسجل)، حيث يرفض مشغل سجل النطاقات نفسه اتخاذ أي إجراء بشأن تغييرات النقل أو جهات الاتصال دون تأكيد خارجي (out-of-band). متوفر في نطاقات .com و .net والعديد من نطاقات المستوى الأعلى لرموز البلدان (ccTLDs).
• التحقق من مسجل النطاق الذي تستخدمه فعلياً وإزالة المسجلين الآخرين. غالباً ما تمتلك العلامات التجارية التي بدأت في عام 2007 حسابات قديمة ومتروكة لدى ثلاثة أو أربعة مسجلين ببيانات اعتماد ضعيفة.

2. اختراق حساب مسجل النطاق (مسار بيانات الاعتماد)

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

ما الذي يوقفه:

• المصادقة الثنائية (2FA) المقاومة للتصيد على حساب مسجل النطاق. استخدام كلمات المرور لمرة واحدة المستندة إلى الوقت (TOTP) عبر تطبيق المصادقة هو الحد الأدنى؛ ومفاتيح الأجهزة (WebAuthn / FIDO2) هي الحد الأقصى. المصادقة الثنائية المعتمدة على الرسائل القصيرة (SMS) غير كافية — فقد تمكنت هجمات تبديل بطاقة SIM من هزيمتها مراراً وتكراراً. وتوصي إرشادات CISA التابعة للحكومة الأمريكية صراحةً بالابتعاد عن استخدام الرسائل القصيرة.
• مسجل نطاقات يدعم الأقفال على مستوى النطاق بالإضافة إلى الأقفال على مستوى الحساب، بحيث لا يؤدي اختراق حساب واحد إلى إلغاء قفل كل شيء دفعة واحدة.
• سجل التدقيق والتنبيهات لتغييرات جهات الاتصال، وتغييرات خوادم الأسماء، وطلبات النقل. الخطوة الأولى للمهاجم هي إسكات تلك التنبيهات؛ وإذا تم إرسالها إلى قناة لا يتحكم فيها المهاجم، فستحصل على وقت كافٍ للإنذار.

3. الاستيلاء على مزود خدمة DNS

حتى لو كان حساب مسجل النطاق مغلقاً بإحكام، فإن خوادم الأسماء التي ينشرها المسجل قد تشير إلى مزود خدمة DNS يمتلك حساباً منفصلاً — مثل Cloudflare أو Route 53 أو NS1 أو DNSimple أو خادم BIND الخاص بك. إذا تمكن المهاجم من الدخول إلى حساب DNS هذا، فلن يحتاج إلى المساس بمسجل النطاق. كل ما عليه فعله هو إعادة كتابة سجلات A و MX و TXT وستتبعه حركة المرور مباشرة.

غالباً ما يكون هذا المسار أسهل للمهاجمين، لأن العلامات التجارية تستثمر في أمان مسجل النطاق ولكنها تتعامل مع مزود خدمة DNS كـ "بنية تحتية" بضوابط أضعف.

ما الذي يوقفه:

• نفس صرامة المصادقة الثنائية على حساب مزود خدمة DNS كما هو الحال مع مسجل النطاق. تعامل معه بنفس مستوى الحساسية والأهمية، لأنه كذلك بالفعل.
• DNSSEC، الموقع على مستوى النطاق (zone). لا يمنع بروتوكول DNSSEC اختراق حساب مزود خدمة DNS: فإذا تمكن المهاجم من نشر سجلات عبر المزود وقام المزود بتوقيعها باستخدام المفاتيح النشطة للمنطقة، فإن المُحللات (resolvers) التي تتحقق من الصحة ستتعامل مع هذه الإجابات على أنها أصلية. ما يمنعه DNSSEC حقاً هو التلاعب في المسار (in-path tampering)، وتسمم ذاكرة التخزين المؤقت، والإجابات المزيفة غير الموقعة أو الموقعة بشكل خاطئ، بافتراض أن النطاق الأب ينشر سجلات DS الصحيحة. راجع RFC 4033-4035 للحصول على تفاصيل البروتوكول.
• DNS متعدد المزودين (Multi-provider DNS) بحسابات وبيانات اعتماد منفصلة، باستخدام DNSSEC متعدد الموقعين. يساعد هذا في التوافر وعزل المزود، ولكنه يعمل فقط إذا كان كل مزود يقدم بيانات النطاق المقصودة وتم تنسيق مجموعات DNSKEY/DS بشكل صحيح. إنه ليس تجاوزاً سحرياً حيث تفضل المُحللات تلقائياً المزود غير المخترق.

4. اختطاف خوادم الأسماء (NS) عبر التفويضات القديمة والسجلات المعلقة (Dangling records)

تغيير أكثر دقة: النطاق نفسه بخير، ولكن هناك نطاق فرعي (subdomain) يشير (عبر سجل CNAME أو NS) إلى خدمة تابعة لجهة خارجية لم يعد المالك الأصلي يتحكم فيها. يقوم المهاجم بتسجيل المورد على جانب الجهة الخارجية ويصبح الآن هو من يرد بالنيابة عن النطاق الفرعي.

أمثلة:

• نطاق فرعي موجه عبر CNAME إلى أصل قديم على Heroku أو S3 أو Azure تم التخلي عنه. يقوم المهاجم بالمطالبة باسم الأصل هذا مرة أخرى ويحصل على شهادة TLS صالحة.
• سجل NS مفوض يشير إلى حساب مزود خدمة DNS تم حذفه. ينشئ المهاجم حساباً جديداً باستخدام نفس نمط المضيف بالظبط، ويقدم أي سجلات يريدها للنطاق الفرعي.

تُصنف هذه الحالات تحت مصطلح شامل هو DNS المعلق (Dangling DNS)، وهي الشكل الأكثر شيوعاً لاختطاف النطاقات "الحقيقي" على شبكة الإنترنت المفتوحة اليوم، لأن معظم المؤسسات الكبيرة تمتلك المئات أو الآلاف من النطاقات الفرعية ولا تقوم بتدقيق سوى جزء بسيط منها.

ما الذي يوقفه:

• جرد كامل لكل سجل NS و CNAME و ALIAS في كل منطقة (zone) تمتلكها، مع تحديد مالك لكل منها.
• أدوات المسح الآلي للـ DNS المعلق والتي تقوم بإعادة تحليل كل سجل وفقاً لجدول زمني محدد وتضع علامة على السجلات التي تشير إلى خدمات تابعة لجهات خارجية لم تعد تستجيب. تمتلك مدونة GitHub و Detectify Labs مقالات مفصلة ومستمرة حول هذه الفئة من الهجمات.
• إلغاء تنشيط السجلات في نفس اليوم الذي تلغي فيه تنشيط الخدمة الأساسية التي تعتمد عليها.

5. استرجاع النطاقات منتهية الصلاحية

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

يبدو هذا كفشل تشغيلي، وليس كحادثة أمنية، لكن التأثير متطابق — فهناك شخص آخر يتحكم الآن في الاسم، وجميع إشارات الثقة التي تم بناؤها على مدار سنوات (SPF و DKIM وعمليات إعادة الاتصال الخاصة بـ OAuth ورسائل إعادة تعيين كلمة المرور وتكاملات الدفع) تبدأ في التدفق إلى شخص غريب. تضمنت العديد من الحوادث العامة قيام المهاجمين بشراء نطاقات منتهية الصلاحية خصيصاً لأن المالك السابق قام بتسجيلها كمُطالبة iss في رموز OAuth أو كمُرسل للبريد الإلكتروني للمعاملات.

ما الذي يوقفه:

• التجديد لعدة سنوات (من 5 إلى 10 سنوات) لأي نطاق يمس المصادقة أو المدفوعات أو حركة مرور بيئة الإنتاج. التكلفة ضئيلة؛ بينما الحماية كبيرة جداً.
• التجديد التلقائي باستخدام طريقة دفع لا يمكن أن تفشل بصمت. انتهاء صلاحية البطاقات الائتمانية هو السبب الأكثر شيوعاً لانتهاء صلاحية النطاق العرضي.
• تذكيرات التقويم عند 90، و60، و30، و7 أيام تُرسل إلى عنوان بريد إلكتروني خاص بـ فريق، وليس إلى صندوق وارد شخص واحد قد يغادر الشركة.

كيف يبدو الوضع المثالي

بجمع هذه الضوابط معاً، يبدو خط الأساس لأي نطاق مهم كما يلي:

إذا كنت مسؤولاً عن نطاق ولا يمكنك وضع علامة أمام كل صف، فإن مهمة المهاجم ستكون أسهل بشكل ملموس.

كيف يغير Namefi المشهد

توجد معظم الضوابط المذكورة أعلاه كميزات لدى مسجل نطاق واحد، أو مزود خدمة DNS واحد، أو أداة سير عمل واحدة، ويعتمد الأمان على أضعف حساب بينها. يقوم Namefi بترميز علاقة المالك المسجل (registrant) على تقنية البلوكتشين (on-chain)، مما يعني أن السجل الموثوق الذي يحدد من يملك هذا الاسم يقع خارج قاعدة بيانات العملاء لأي مسجل نطاقات فردي. لا يمكن لموظف الدعم لدى أي مزود تغيير الملكية خلسةً دون معاملة موثقة يجب أن يوافق عليها المالك الشرعي. لا يزال مسجل النطاق يدير التفويض التقني، ولكن تم نقل طبقة التحكم إلى مكان لا تُجدي فيه الهندسة الاجتماعية نفعاً.

لا يُعد هذا بديلاً كاملاً للضوابط الواردة في الجدول أعلاه — فما زلت بحاجة إلى بروتوكول DNSSEC، وما زلت بحاجة إلى المصادقة الثنائية لدى مزود خدمة DNS، وما زلت بحاجة إلى التجديد. ولكنه يزيل مسار الاختطاف الأكثر شيوعاً والأكثر تأثيراً (المسار 1) من نموذج التهديد بالكامل.

المصادر وقراءات إضافية

• ICANN — نطاق سياسة حل نزاعات النقل.
• IETF — DNSSEC RFCs 4033/4034/4035 و DNSSEC متعدد الموقعين RFC 8901.
• CISA — إرشادات المصادقة متعددة العوامل.
• Detectify Labs — مقال عن الاستيلاء العدائي على النطاقات الفرعية.
• Verisign — قفل السجل لنطاقات .com/.net.