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

لا تعتمد هذه الطريقة الهجومية على ثغرات أمنية غير معلنة ولا على اختراق كلمات المرور بالقوة. بل تستغل بروتوكولاً قديماً يعود إلى أواخر تسعينيات القرن الماضي لا يزال مفعلاً افتراضياً في مئات الملايين من أجهزة الحاسوب الحديثة: بروتوكول الاكتشاف التلقائي لوكيل الويب (Web Proxy Auto-Discovery أو WPAD).

جذور البنية الهندسية: التضحية بالحدود الأمنية من أجل الراحة

لفهم أسباب الخطورة البالغة لبروتوكول WPAD في الشبكات العامة، ينبغي العودة إلى الدوافع التي أدت إلى ابتكاره. فخلال طفرة شبكات الشركات في أواخر التسعينيات، كان مسؤولو تقنية المعلومات بحاجة إلى آلية تلقائية توجه أجهزة الموظفين لتمرير بيانات الويب عبر خوادم البروكسي الداخلية (للتخزين المؤقت وفحص المحتوى) دون الحاجة إلى ضبط كل جهاز يدوياً.

أنتجت تلك الجهود مسودة اعتمدتها منظمة IETF عام 1999، رسخت بروتوكولاً يعمل بالكامل تقريباً خلف الكواليس. ففي كل مرة يتصل فيها نظام التشغيل بواجهة شبكة جديدة، تبدأ حزمة بروتوكولات الشبكة سلسلة من الاستعلامات للإجابة عن سؤال محدد: "أين يقع ملف التكوين التلقائي للبروكسي (PAC) الخاص بهذه الشبكة؟"

[ حاسوب المستخدم ]
       |
       | 1. إرسال حزمة DHCP Inform (الخيار 252) -> "أين ملف wpad.dat؟"
       +---------------------------------------------> [ بوابة الشبكة المحلية ]
       |                                                    (لا يوجد رد)
       | 2. استعلام نظام أسماء النطاقات: wpad.local / wpad.cafe.internal
       +---------------------------------------------> [ خادم تحليل DNS المحلي ]
       |                                                    (الاسم غير موجود NXDOMAIN)
       | 3. بث محلي جماعي عبر LLMNR / NetBIOS يسأل عن "WPAD"
       +---------------------------------------------> [ كامل نطاق شبكة Wi-Fi ]
                                                             |
                                                             v
                                               [ مهاجم على الشبكة ذاتها ]
                                               (يرد فوراً: "أنا هو WPAD! قم بتحميل ملف PAC!")

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

التسلسل التنازلي للاكتشاف: دعوة مفتوحة للمتنصتين

عندما يبحث نظام ويندوز أو متصفحات الإنترنت عن إعدادات البروكسي، يتم اتباع هذه الخطوات بدقة:

1. خيار بروتوكول التكوين الديناميكي DHCP Option 252

بمجرد الارتباط بالشبكة، يرسل الجهاز حزمة استعلام يسأل فيها عما إذا كان خادم DHCP قد عيّن الخيار 252. في حال تفعيله، يُعاد رابط مباشر لملف الإعدادات (مثل http://192.168.1.1/wpad.dat). إلا أن موجهات المقاهي والشبكات العامة نادراً ما تفعل هذا الخيار، مما يؤدي إلى فشل الخطوة الأولى.

2. البحث المتسلسل عبر نظام DNS

عند تعذر الحصول على الخيار 252، يدمج نظام التشغيل اسم wpad مع لاحقة النطاق المعينة للشبكة. فإذا كان النطاق المحلي مثلاً corp.local، يستعلم الجهاز عن wpad.corp.local ثم wpad.local. وفي الشبكات العامة ذات الإعدادات غير الدقيقة، قد يتسرب الاستعلام إلى نطاقات المستوى الأعلى الحقيقية (مثل wpad.com)، مسبباً تداخلاً خطيراً في أسماء النطاقات حذر منه مركز CERT/CC رسمياً.

3. بروتوكولات البث المحلي LLMNR وNetBIOS

إذا أفاد نظام DNS بعدم وجود السجل (NXDOMAIN)، يلجأ الحاسوب إلى الطبقة الأكثر هشاشة: البث المحلي غير الموثق. يرسل الجهاز حزم UDP لكافة المتصلين بشبكة Wi-Fi سائلاً: "هل يعرف أحدكم عنوان IP الخاص بـ WPAD؟"

في الشبكات العامة، يتربص المهاجم المزود بأدوات مثل Responder أو Inveigh بهذه الاستفسارات. وبمجرد صدور النداء، يرد المهاجم فوراً: "أنا هو wpad. حمل ملف التكوين من خادمي على العنوان 192.168.1.145/wpad.dat."

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

تشريح ملف PAC الخبيث: توجيه منتقى للبيانات

لا يُعد ملف PAC مجرد جدول عناوين جامد، بل هو برنامج مكتمل بلغة جافا سكريبت يحتوي على دالة إلزامية: FindProxyForURL(url, host).

قبل أن يُجري النظام أي اتصال بالإنترنت، يستدعي هذه الدالة لتحديد مسار الحزم. ويصمم المهاجمون المنطق الداخلي للملف بدقة بالغة:

function FindProxyForURL(url, host) {
    // حركة المرور العادية تمر مباشرة منعاً للشك
    if (isPlainHostName(host) || dnsDomainIs(host, ".local")) {
        return "DIRECT";
    }

    // اعتراض البوابات الحساسة وحسابات البريد والخدمات المالية
    if (dnsDomainIs(host, "login.microsoftonline.com") ||
        dnsDomainIs(host, "mail.google.com") ||
        dnsDomainIs(host, "github.com") ||
        shExpMatch(host, "*bank*")) {
        return "PROXY 192.168.1.145:8080; DIRECT";
    }

    // السماح لبقية المواقع بالمرور المباشر
    return "DIRECT";
}

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

البيانات التي تقع في قبضة المهاجم

بمجرد عبور حركة المرور عبر البروكسي الخبيث:

  • حزم HTTP غير المشفرة: تُقرأ بالكامل، بما يشمل كلمات المرور ومعرفات الجلسات وعناوين الصفحات.
  • اتصالات HTTPS المشفرة: على الرغم من حماية محتوى البيانات عبر بروتوكول TLS، يستقبل البروكسي طلب المصافحة الأولي HTTP CONNECT. ويكشف هذا الطلب اسم النطاق المقصود (SNI)، والمنفذ المستخدم، وتوقيت الاتصال وحجمه.
  • خفض مستوى المصادقة وهجمات ترحيل NTLM: تحاول خدمات ويندوز في الخلفية المصادقة التلقائية عند الاتصال بالبروكسي. يمكن للبروكسي المزيف طلب ترويسة Proxy-Authenticate: NTLM، مما يجبر جهاز الضحية على تسليم بصمات كلمات المرور المشفرة لاستخدامها في هجمات الترحيل داخل شبكات الشركات.

التدابير الوقائية: تفكيك فخ البروكسي الخفي

يتطلب تحصين الأجهزة ضد استغلال WPAD الجمع بين إيقاف وظائف الاكتشاف التلقائي بنظام التشغيل وتشفير حركة المرور داخل نفق معزول.

1. تعطيل الاكتشاف التلقائي للبروكسي في النظام

ما لم تكن تعمل داخل شبكة مؤسسية تلزم استخدام WPAD وفق سياسات محددة، يجب إيقاف هذا الخيار نهائياً:

  • في نظام ويندوز 11 و10: افتح Settings، وانتقل إلى Network & Internet > Proxy. وتحت قسم Automatic proxy setup، اضبط خيار Automatically detect settings على وضع Off.
  • في نظام macOS: افتح System Settings، واختر Network، ثم حدد شبكة Wi-Fi المتصلة واضغط على Details > Proxies وتأكد من إلغاء تفعيل خياري الاكتشاف التلقائي والتكوين التلقائي.
  • في متصفحات الويب: في فايرفوكس، توجه إلى إعدادات الشبكة واختر No proxy أو الالتزام بإعدادات النظام بعد تحصينها.

2. إيقاف بروتوكولات البث المحلي LLMNR وNetBIOS

يمنع تعطيل إرسال حزم البث في الشبكة المحلية المهاجمين من إرسال ردود زائفة:

  • افتح محرر سياسات المجموعة المحلي Local Group Policy Editor (gpedit.msc).
  • انتقل إلى مسار Computer Configuration > Administrative Templates > Network > DNS Client.
  • انقر نقراً مزدوجاً فوق سياسة Turn off multicast name resolution واضبطها على وضع Enabled.

3. العزل الشامل لحركة البيانات عبر VPNRice

على الرغم من أهمية تعديل إعدادات النظام يدوياً، قد تتجاهل بعض التطبيقات هذه التفضيلات وتبادر بإرسال استعلامات اكتشاف منفصلة. وتظل وسيلة الحماية الأكثر متانة على شبكات Wi-Fi العامة هي توجيه جميع الحزم الصادرة داخل نفق مشفر توفره خدمة VPNRice.

يساهم الاتصال عبر تطبيق VPNRice بالاعتماد على بروتوكولات حديثة مثل RiceGuard أو RiceGuardX في إبطال التهديدات المحلية:

  • تحييد خديعة البوابة المحلية: تُغلف جميع حزم البيانات داخل درع تشفيري قبل مغادرة بطاقة الشبكة اللاسلكية، مما يحرم خوادم DHCP المزيفة والمتنصتين في الشبكة العامة من إرسال ردود WPAD مضللة.
  • خوادم DNS مشفرة وخاصة: تُوجه كافة طلبات استعلام أسماء النطاقات مباشرة نحو خوادم التحليل التابعة لـ VPNRice عبر القناة الآمنة، مانعة الانزلاق نحو LLMNR أو تسميم سجلات DNS المحلية.
  • عزل أمني تام للمنفذ: يمنع جدار حماية التطبيق بقية الأجهزة في شبكة Wi-Fi من التفاعل مع منافذ جهازك أو توجيه اتصالاتك نحو خوادم وسيطة متطفلة.

وللتأكد من سلامة جهازك وعدم تسريب أي تفاصيل للمسارات الداخلية عبر المتصفح، يُنصح بإجراء اختبار تسريب WebRTC من VPNRice ومراجعة مسار التوجيه الخارجي عبر أداة فحص عنوان IP. إن إغلاق بروتوكولات الاكتشاف القديمة واستخدام شبكة VPN مشفرة هما الركيزتان الأساسيتان لضمان سرية بياناتك على كافة الشبكات العامة.