اختطاف النطاقات الفرعية: الثغرة التي لم يسمع بها معظم المطوّرين

الثغرة في جملة واحدة

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

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

المثال الملموس

تخيّل أنّك فعلت هذا العام الماضي:

1. أعددت موقع تسويق على Heroku عند marketing-yourcompany.herokuapp.com.
2. أضفت CNAME: marketing.yourcompany.com → marketing-yourcompany.herokuapp.com.
3. انتهت الحملة التسويقية. حذفت تطبيق Heroku.
4. نسيت إزالة CNAME من DNS.

الآن يستطيع أيّ شخص التسجيل في Heroku، المطالبة باسم التطبيق marketing-yourcompany، وHeroku سيُقدّم محتواه لذلك المُضيف. CNAME ما زال يُشير هناك. فجأة marketing.yourcompany.com يعرض صفحة تصيّد — تحت قفل أخضر، على نطاقك الموثوق.

لماذا يحدث هذا كثيراً

سببان:

• المنصّات السحابية تسمح بالمطالبة على أساس الأوّل-فالأوّل. Heroku، GitHub Pages، AWS S3، Azure، Bitbucket، Tumblr، وعشرات أخرى تتيح لك تسجيل اسم مُضيف (أو اسم مشروع) يُربَط بنطاق فرعي ثابت. لا تحقّق من امتلاكك فعلياً للنطاق الأصل المُشير إليه.
• سجلّات DNS تعيش أطول من الموارد التي تُشير إليها. المهندسون يُنشئون موارد سحابية، يُوجّهون DNS إليها، ثمّ يُلغونها دون تنظيف DNS. CNAME يبقى كأثر.

دراسات لمناطق DNS مؤسّسية كبيرة تجد روتينياً عشرات إلى مئات CNAMEs المُتدلّية لكلّ منظّمة. كثير منها قابل للاختطاف.

أنماط الخدمات المتأثّرة

أيّ خدمة حيث:

• تستطيع تسجيل نطاق فرعي مُخصّص تحت نطاقهم (yourname.service.com).
• المنصّة تخدم زيارات لذلك النطاق الفرعي للمسجِّل.
• النطاق الفرعي يصبح متاحاً مجدّداً بعد أن يُحرّره أو يحذفه المسجِّل.

أهداف شائعة تاريخياً تشمل:

• Heroku (*.herokuapp.com)
• GitHub Pages (*.github.io)
• AWS S3 (*.s3.amazonaws.com)
• AWS CloudFront (*.cloudfront.net)
• Azure (*.azurewebsites.net، *.cloudapp.net)
• Tumblr (*.tumblr.com)
• Bitbucket (*.bitbucket.io)
• Fastly، Squarespace، Helpjuice، Pantheon، إلخ.

القائمة ليست ثابتة. أيّ منصّة بهذه البنية ناقل محتمل. منصّات Bug bounty تحتفظ بقوائم مستمرّة للخدمات القابلة للاختطاف حالياً.

ما يكسبه المهاجم فعلاً

هذا ليس "محرجاً". نطاق الانفجار حقيقي:

• تصيّد تحت علامتك. صفحة تسجيل دخول على نطاقك، بـHTTPS صالح، تُرسل الاعتمادات للمهاجم.
• سرقة الكوكيز. إن كان نطاقك الرئيسي يضع كوكيز لـ*.yourcompany.com، المهاجم على نطاق الاختطاف الفرعي يستطيع قراءتها.
• تجاوز OAuth والمصادقة. كثير من تدفّقات OAuth تثق بنطاقات فرعية لأصل مسموح. المهاجم على نطاق فرعي مُختطَف قد يستطيع إكمال تدفّقات OAuth في متصفّحات مستخدميك.
• ضرر SEO والعلامة. محرّكات البحث تُفهرس محتوى المهاجم تحت نطاقك.
• تجاوز SPF/DKIM. إن كانت بنية بريدك تثق بهوية النطاق الفرعي، المهاجم قد يُرسل "من" نطاقك بطرق تجتاز المصادقة.

كيف تجد الثغرات في DNS الخاصّ بك

1. صدّر منطقة DNS. معظم المزوّدين يُتيحون تصدير ملفّ منطقة.
2. اسرد كلّ سجلّات CNAME وALIAS. هذه مرشّحات الاختطاف.
3. لكلّ هدف CNAME، تحقّق هل المورد موجود. زُره. إن كانت المنصّة تعرض صفحة "لا يوجد تطبيق كهذا" / "الصفحة غير موجودة" / "الـbucket غير موجود" بدلاً من محتواك، لديك مرشّح.
4. تحقّق هل المنصّة تسمح بإعادة تسجيل الهدف. بعض المنصّات الآن تحجز الأسماء المُستخدَمة سابقاً؛ كثير لا يفعل.

أدوات مثل subjack، SubOver، وcan-i-take-over-xyz تُؤتْمِت هذا الفحص ضدّ أكثر الخدمات شيوعاً. مفتوحة المصدر وتُشغَّل من قائمة بنطاقاتك الفرعية. لمناطق DNS صغيرة، مراجعة يدوية 5 دقائق تلتقط معظم المشاكل.

كيف تُصلحها

لكلّ سجلّ ضعيف:

• احذف سجلّ CNAME أو A إن لم تعد تستخدم المورد. هذا الإصلاح القانوني.
• أعد المطالبة بالمورد إن سمحت المنصّة بإعادة التسجيل. بعض الفرق "تركن" المورد على placeholder آمن معروف بدلاً من حذف سجلّ DNS.
• أعد توجيه السجلّ إلى مورد حالي مُتحكَّم به إن أردت بالفعل ذلك النطاق الفرعي حيّاً.

المبدأ العامّ: لا تدع سجلّات DNS تعيش أطول من الموارد التي تُشير إليها. عند إلغاء مورد سحابي، ألغ سجلّ DNS المقابل في نفس الوقت.

كيف تمنعها على المدى الطويل

• نظافة DNS كجزء من إلغاء التشغيل. عند حذف تطبيق Heroku، bucket S3، أو أيّ مورد طرف ثالث مُستضاف، احذف سجلّ DNS المقابل أيضاً. اجعل هذا بنداً في قائمة فحص.
• وسم سجلّات DNS بمالكها / غرضها. معظم مزوّدي DNS يدعمون البيانات الوصفية أو التعليقات على السجلّات. معرفة من أنشأ سجلّاً يُسهّل التنظيف.
• تدقيقات DNS دورية. مراجعة فصلية لكلّ سجلّات DNS، تركيز على CNAMEs المُشيرة لمنصّات طرف ثالث. للمنظّمات الأكبر، فحص آلي.
• خدمات قمّة فقط للجمهور. لتقليل أقصى لسطح الهجوم، تجنّب توجيه نطاقات فرعية لأطراف ثالثة ما لم تكن مطلوبة نشطاً. استخدم مسارات تحت قمّتك (yourcompany.com/blog) بدل نطاقات فرعية حيث ممكن.
• تحديد كوكيز صارم. ضع كوكيز على النطاق الفرعي المحدّد الذي يحتاجها، لا على .yourcompany.com (الذي يُعرّضها لكلّ النطاقات الفرعية).
• قوائم سماح OAuth بنطاقات فرعية صريحة. تجنّب أنماط wildcard في OAuth redirect URIs — اسرد كلّ نطاق فرعي مُصرَّح به.

واقع Bug Bounty

اختطاف النطاقات الفرعية من أكثر الفئات مكافأة على منصّات bug bounty. شركات كبرى تدفع 500–5,000$ لكل ناقل اختطاف مؤكَّد. إن أدارت مؤسّستك bug bounty، توقّع أن يُفحص الباحثون DNS بانتظام ويُقدّموا اكتشافات.

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

قائمة الإجراء السريع

1. اسرد كلّ CNAME وALIAS في مناطق DNS الخاصّة بك.
2. لكلّ، تحقّق أنّ المورد المُستهدَف ما زال موجوداً ولك.
3. احذف أو أعد توجيه أيّ ليس كذلك.
4. أضف تنظيف DNS إلى قائمة فحص إلغاء التشغيل القياسية.
5. اجدول مراجعة فصلية.

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