القفل كان صالحًا والموقع كان مزيفًا: شرح اختراق سجلات النطاقات .gh و.sl و.as

في 6 أكتوبر 2026، نشر فريق أمان Chrome في Google تدوينة قصيرة بعنوان جاف ومضمون مقلق: مهاجمون سيطروا على ثلاثة سجلات نطاقات قُطرية، .gh في غانا و.sl في سيراليون و.as في ساموا الأمريكية، وغيّروا سجلات DNS الموثوقة وحصلوا على شهادات HTTPS صالحة لنطاقات Google ولـ«عدة علامات تجارية عالمية رائدة» لم تسمّها الشركة. أي شخص كان سيهبط على أحد المواقع المزيفة كان سيرى قفل متصفح لا غبار عليه إطلاقًا.

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

تعريف واحد يحمل هذه الصفحة كلها: شهادة التحقق من النطاق تثبت شيئًا واحدًا فقط، أن طالبها كان يسيطر على DNS النطاق لحظة الإصدار. وعندما يُسرق السجل الذي يعلو الـDNS، يصبح اللص، في نظر كل فحص آلي على وجه الأرض، هو المالك.

ماذا حدث لـ.gh و.sl و.as؟

سجل النطاق القُطري هو المؤسسة التي تدير قاعدة البيانات الرئيسية لكل ما يقع تحت نطاقها ذي الحرفين: فـ.gh تديره Network Computer Systems في أكرا، و.sl تديره شركة الاتصالات Sierratel، و.as تديره AS Domain Registry. اخترق هذه القاعدة ولن تحتاج إلى اختراق أي موقع بعينه، لأنك تستطيع إعادة تفويض أي اسم تحت النطاق العلوي إلى خوادم تسيطر عليها.

هذا ما حدث بالضبط، سجلًا تلو الآخر. فقد ظهرت الشهادات في السجلات العامة لأسماء .gh في 22 سبتمبر، و.sl في 25 سبتمبر، و.as في 27 سبتمبر، وهو ما يُقرأ وكأنه فريق يشتغل على قائمة. تقول Google إن المهاجمين «عدّلوا سجلات DNS الموثوقة وحصلوا على شهادات HTTPS غير مصرح بها تغطي عدة نطاقات لـGoogle، إضافة إلى نطاقات تخص مؤسسات أخرى»، وإن أنظمتها هي نفسها لم تُمس.

يبقى قدر لافت من الأمور غير معلن: كيف اختُرقت السجلات، ومن الفاعل، وهل استُخدمت أي شهادة ضد مستخدمين حقيقيين، وما القائمة الكاملة للضحايا. ولم يكن أي من مشغّلي السجلات الثلاثة قد نشر بيانًا حتى كتابة هذه السطور. نحن نكتب «غير معلن» حيث يكون هذا هو واقع الحال، وهكذا ينبغي أن يفعل كل تقرير تقرؤه.

كيف حصل المهاجمون على شهادات صالحة لنطاقات Google؟

بالطلب بأدب. فقد أحصت The Hacker News، انطلاقًا من سجل Certificate Transparency العام، ما لا يقل عن 12 شهادة تغطي 7 نطاقات لـGoogle وYouTube، من بينها google.com.gh وgoogle.sl وgoogle.as ومتغيراتها: 11 أصدرتها Let’s Encrypt وواحدة أصدرتها ZeroSSL، وكلها بالتحقق من النطاق. وقد أكد أحد العاملين في Let’s Encrypt الإصدار والإلغاء في منتدى المشروع.

وهنا الجزء المزعج: جهات إصدار الشهادات اتبعت قواعدها. فقد كتبت Google نفسها أنه «لا سبب لديها للاعتقاد بأن جهات إصدار الشهادات (CA) التي أصدرت الشهادات المتأثرة ارتكبت أي خطأ». يطلب التحقق من النطاق من مقدم الطلب إثبات سيطرته على DNS النطاق، عادة بنشر قيد فيه. والمهاجمون كانوا هم الـDNS. كل فحص آلي واجهوه اجتازوه بصدق، بالمعنى الضيق الذي تفهم به الآلات الصدق.

تفصيل واحد يُظهر كيف تبدو اليقظة في هذه الطبقة: في قيود السجلات التي جرت مراجعتها، وحتى 10 سبتمبر على الأقل، كانت كل شهادة أخرى لـgoogle.com.gh وgoogle.sl وgoogle.as قد جاءت من Google Trust Services، جهة الإصدار التابعة لـGoogle نفسها. اثنتا عشرة شهادة من جهتي إصدار لا علاقة لهما بالأمر كانت بذاتها هي الشذوذ، جاثمة في سجل عام، تنتظر من ينظر.

من اكتشف الأمر، وكيف أُوقف؟

ثلاث آليات، مرتبة بحسب السرعة.

أولًا، Certificate Transparency هي التي جعلت الشهادات مرئية أصلًا. فمنذ 30 أبريل 2018 يرفض Chrome أي شهادة لم يُفصح عنها في سجلات CT العامة، فالمهاجم الذي يريد شهادة تعمل في أكثر متصفحات العالم استخدامًا عليه أن يسلّم العالم في الوقت نفسه اعترافًا موقّعًا بوجودها. العداد العام للمنظومة تجاوز 2.5 مليار شهادة مسجلة، وتخطت Let’s Encrypt وحدها عشرة ملايين شهادة صادرة في يوم واحد في أواخر سبتمبر 2025؛ والعثور على 12 شهادة فاسدة في كومة القش تلك هو بالضبط ما وُجدت بنية السجلات لأجله.

ثانيًا، حجب Chrome الشهادات عبر CRLSets، قائمة الحظر الطارئة لديه، التي تُشحن عبر مُحدِّث مكونات المتصفح وتسري دون تحديث أو إعادة تشغيل. وقد دأب فريق أمان Chrome لسنوات على القول إن فحوص الإلغاء عبر الإنترنت تفشل تمامًا حين تحتاج إليها، لأن المهاجم في المنتصف يستطيع حجب الفحص نفسه؛ أما قائمة الحظر فتسافر مع المتصفح. ثم نقّبت Google في بيانات CT عن ضحايا آخرين، وحجبت تلك الشهادات أيضًا، وتقول إنها تواصلت مع المؤسسات المتضررة حيثما استطاعت.

ثالثًا، المسار البطيء الذي يغطي كل من عداهم: ألغت جهات الإصدار الشهادات الـ12 كلها، شهادتي .gh وشهادة ZeroSSL الوحيدة في 26 سبتمبر، والتسع الباقية في 1 أكتوبر. أقصر نافذة بين ظهور شهادة في السجل وموتها كانت نحو يوم ونصف؛ وأطولها قاربت الأسبوع. وبند الصدق الخاص بـGoogle يستحق الاقتباس: «لا يمكننا أن نضمن أن تحليلنا حدد كل نطاق متأثر، كما أن تدخلات Chrome لا تحمي مستخدمي المتصفحات الأخرى بشكل موثوق».

هل كانت DNSSEC أو سجلات CAA ستمنع هذا؟

هذه الحادثة أنظف عرض منذ سنوات لما يشتريه لك هذان الاختصاران وما لا يشترانه.

لنبدأ بـDNSSEC. بمراجعة منطقة الجذر المنشورة: .gh و.sl غير موقّعين إطلاقًا، ما يضعهما بين نطاقات ccTLD الكثيرة التي لم تنشر DNSSEC قط، وهي تقنية بلغ تبنّيها بين سجلات أوروبا 99 بالمئة مقابل 65 بالمئة في أفريقيا. أما .as فموقّع، واختُطف رغم ذلك. يتيح DNSSEC للمحلل التحقق من أن الإجابة تطابق ما نشره السجل. وعندما يكون السجل نفسه معاديًا، فإنه ينشر بيانات المهاجم، بمفاتيحها وكل شيء. فالتوقيع على كذبة يبقى توقيعًا صالحًا.

أما سجلات CAA، التي تتيح لمالك النطاق إعلان جهات الإصدار المسموح لها بالإصدار له، فشكلها أدق. أثناء الاختطاف هي عديمة الجدوى، لأن قيد CAA يسكن في الـDNS ذاته الذي يسيطر عليه المهاجم؛ ومعيار CAA نفسه يقرّ بأن مهاجمًا قادرًا على تحرير DNS يستطيع إزالة القيد. وبعد الاختطاف تصبح مهمة جدًا، لأن جهات الإصدار يجوز لها بموجب قواعد CA/Browser Forum الحالية إعادة استخدام تحقق مكتمل حتى 200 يوم، وهي نافذة ستنخفض إلى 100 يوم في مارس 2027 وإلى 10 أيام في 2029، فالمهاجم الذي فقد الـDNS كان سيظل قادرًا على سك شهادات جديدة من فحوص مخزنة. وبحلول 7 أكتوبر كانت نطاقات Google الضحية السبعة المعروفة كلها تحمل سجلات CAA لا تسمّي سوى جهة إصدار Google نفسها. هذا هو القفل الذي تركّبه بعد هذه السرقة بعينها، وهو قفل حقيقي.

هل حدث هذا من قبل؟

هجمات السجلات والبنية التحتية لـDNS صنف قائم بذاته، لا طارئ جديد. السجل المؤرخ:

هناك 316 نطاقًا علويًا قُطريًا بين نحو 1,400 نطاق في منطقة الجذر، كل منها مرتبط بدولة أو إقليم، ولكل منها ميزانيته وحوكمته ووضعه الأمني، وبعضها يديره مشغّلون من القطاع الخاص. وهيئة النطاقات القانونية في غانا نفسها أمضت سنوات في نزاع علني حول من ينبغي أصلًا أن يشغّل .gh. فنموذج الثقة في الويب يرتكز، جزئيًا، على أن تمتلك أقل هذه المؤسسات تمويلًا فريق أمان جيدًا.

ماذا كنت سترى، وما الذي يحميك فعلًا؟

لو جرى توجيهك إلى أحد المواقع المزيفة خلال تلك النافذة، لما رأيت شيئًا. شهادة صالحة، قفل عادي، لا تحذير من أي نوع؛ وكما صاغتها Ars Technica، فإن حيازة شهادات كهذه «تتيح للمهاجمين انتحال هوية البنية التحتية المتأثرة تشفيريًا». وهل جرى فعلًا توجيه أي شخص إلى هناك، فذلك من الحقائق غير المعلنة.

ما حمى المستخدمين لم يكن شيئًا فعله مستخدم. الأثر الورقي الإلزامي لـCT كشف الشهادات، وCRLSets قتلتها في Chrome دون أي إجراء مطلوب، والإلغاء غطى الباقي. وطبقة أخرى تستحق الذكر: التطبيقات الأصلية التي تثبّت مفاتيحها (key pinning). ففي حالة توغو عام 2017، كان تثبيت المفاتيح في Chrome سيرفض شهادة google.tg المزيفة في كل الأحوال، وتطبيقات Google نفسها وكثير من التطبيقات المصرفية ما زالت تثبّت مفاتيحها حتى اليوم. الدفاع المتعدد الطبقات هنا ليس شعارًا؛ إنه كومة محددة، وفي أواخر سبتمبر كانت كل طبقة منها تحمل وزنًا.

هل يحمي VPN من هذا؟

صفحة الأمان الصادقة تجيب عن هذا السؤال بدقة، فإليك الإجابة الدقيقة: لا بالنسبة إلى هذه الفئة من الهجمات، نعم بالنسبة إلى أقاربها الأكثر شيوعًا، ومعرفة أيها أيٌّ هي اللعبة كلها.

لا يشارك VPN في TLS. فمتصفحك يتحقق من الشهادات مقابل مخزن الثقة الخاص به بالطريقة نفسها على أي شبكة، وهذه الشهادات كانت صالحة. والأسوأ لأي أداة تقع بعد DNS في المجرى: المهاجمون سمّموا السجلات الموثوقة في السجل ذاته، فكان كل محلل نزيه على الكوكب، بما في ذلك محللات مزود VPN، يقدم إجابات المهاجم. ما من VPN، وخدمتنا منها، كان سيحجب هذا. ما أوقفه هو خط أنابيب CT وCRLSet والإلغاء المشروح أعلاه.

ما يدافع عنه VPN فعلًا هو جانبك أنت من الاتصال. فعلى شبكة محلية عدائية أو نقطة اتصال مارقة أو لدى مزود إنترنت يتلاعب بالبيانات، يجلس المهاجم بين جهازك والإنترنت، يحقن إجابات DNS أو يعيد توجيه حركة البيانات. ينقل VPN تحليل DNS ومسار حركة بياناتك إلى داخل نفق مشفر، وكما يقول دليل EFF، يخفي حركة بياناتك عن «مزود الإنترنت ومالك الشبكة المحلية (كمقهى أو فندق)». هذا هو سطح الهجوم الشائع اليومي، وهو ما نغطيه في دليلينا عن تشفير VPN وأمان شبكات Wi-Fi العامة، وهو بالضبط الطبقة التي لم يحتج مهاجمو السجلات إلى لمسها أصلًا. فالحمايتان متكاملتان لا متبادلتان، ولهذا أيضًا نحتفظ بصفحة صادقة منفصلة عن ما تظل المواقع قادرة على رؤيته أثناء تشغيل VPN.

ماذا ينبغي لأصحاب النطاقات أن يفعلوا الآن؟

نصيحة Google للمؤسسات خطوتان، وتنطبق على شركة لديها ثلاثة نطاقات كما تنطبق على شركة لديها ثلاثة آلاف. راقب سجلات Certificate Transparency لكل نطاق تملكه، بما فيها النطاقات المركونة والإقليمية؛ فالشهادات الـ12 المزيفة ظلت في سجلات عامة أيامًا، مرئية لكل من يراقب. وانشر سجلات CAA مقيِّدة تسمّي جهة الإصدار الخاصة بك، ويُفضَّل مع ربط حساب ACME بحيث لا تُصدر حتى جهة إصدارك نفسها إلا لحسابك أنت. ويضيف كتاب قواعد جهات الإصدار خطوة ثالثة: إذا ظهرت شهادة لم تُطلب، فقدّم Certificate Problem Report، الذي تُلزم Baseline Requirements في الصناعة جهة الإصدار بالتحقيق فيه والإبلاغ عن أولى النتائج خلال 24 ساعة.

ولكل من عداهم، الخلاصات أصغر لكنها حقيقية. أبقِ متصفحك محدّثًا، لأن قائمة الحظر التي أنقذت مستخدمي Chrome تسافر معه. وتعامل مع القفل على أنه ما هو عليه، تصريح عن التشفير أثناء النقل، لا عن هوية من في الطرف الآخر. وضع كل أداة في طبقتها: نظام الشهادات يوثّق المواقع، وVPN يحمي المسار الذي تسلكه حركة بياناتك، وحادثة سبتمبر احتاجت إلى أن يفشل الأول بأمان بينما الثاني لم يكن في اللعبة أصلًا.