يعتقد كثير من المستخدمين أن تنشيط الاتصال المشفر يضمن بالضرورة حماية كاملة لكافة البيانات الصادرة بمجرد عمل خوارزميات التشفير. تؤمن الخوارزميات الحديثة مثل ChaCha20-Poly1305 وAES-256-GCM متانة رياضية عالية لحماية الحزم على الوسائط المادية. ومع ذلك، فإن وظائف التشفير لا تحدد مطلقاً المسار الفيزيائي الذي تسلكه البيانات؛ إذ يعود هذا القرار حصرياً إلى جدول التوجيه داخل نواة نظام التشغيل.

في عام 2023، كشف فريق بحثي ضم Mathy Vanhoef وNian Xue وYashaswi Malla وZihang Xiao وCristina Nita-Rotaru عن خلل معماري واسع النطاق أُطلق عليه اسم TunnelCrack. وقد تم توثيق هذا القصور تحت المعرفين CVE-2023-36664 وCVE-2023-35838، حيث أثبت البحث قدرة الشبكات المحلية غير الموثوقة ونقاط الاتصال اللاسلكية المزيفة على التلاعب بقواعد التوجيه لإخراج حركة البيانات المستهدفة خارج النفق في صورة نصوص صريحة غير مشفرة.

لفهم أبعاد TunnelCrack، يتعين تفكيك آليتي الهجوم الرئيستين: هجوم LocalNet وهجوم ServerIP.

+-----------------------------------------------------------------------------+
|                     مسار تسريب التوجيه في هجوم LOCALNET                     |
|                                                                             |
|  [جهاز المستخدم المستهدف]                                                   |
|         │                                                                   |
|         ├── الوجهة: عنوان IP عام لخدمة مستهدفة (مثل 142.250.190.46)         |
|         │                                                                   |
|         ▼                                                                   |
|  [قرار جدول التوجيه بنواة النظام]                                           |
|         │                                                                   |
|         ├─► المسار (أ): نفق VPN الافتراضي (0.0.0.0/1 عبر utun0)             |
|         │                                                                   |
|         └─► المسار (ب): الشبكة المحلية المحقونة (142.250.0.0/16 عبر wlan0)  |
|                    (أولوية أطول تطابق للبادئة Longest Prefix Match)         |
|                                                                             |
|         ▼                                                                   |
|  [واجهة الشبكة المادية: wlan0] ─────────────► [موجه شبكة Wi-Fi المهاجم]     |
|  (إرسال حزم Ethernet غير مشفرة إلى الخارج)    (اعتراض البيانات الصريحة)     |
+-----------------------------------------------------------------------------+

هجوم LocalNet (CVE-2023-36664): استغلال استثناءات الشبكة المحلية

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

عند الاتصال بنقطة وصول لاسلكية، يرسل خادم DHCP إعدادات تتضمن عنوان IP وقناع الشبكة الفرعية والبوابة الافتراضية. في الحالات الطبيعية، تُستخدم نطاقات RFC 1918 الخاصة مثل 192.168.1.0/24، حيث تضيف النواة تلقائياً مساراً محلياً:

192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

توضح السمة scope link للنواة أن الحزم المتجهة إلى هذا النطاق يمكن تسليمها محلياً دون الحاجة للمرور عبر بوابة خارجية. وعادة ما تبقي تطبيقات النفق على هذا المسار دون تعديل للحفاظ على التوافق مع الأجهزة المنزلية.

تستغل نقطة الوصول المعادية هذا السلوك بإعلان نطاق عناوين IP عامة كشبكة محلية. على سبيل المثال، يمنح خادم DHCP جهاز الضحية عنواناً ضمن 142.250.0.0/16 بقناع 255.255.0.0:

# تثبيت مسار محلي لنطاق عام واسع على بطاقة الشبكة اللاسلكية
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45

عندما يتصل المتصفح أو أي تطبيق بأحد الخوادم التابعة لهذا النطاق، تفحص النواة قاعدة بيانات التوجيه (FIB). ووفقاً لقواعد التوجيه المعيارية:

  1. تعلن الواجهة الافتراضية للنفق عن مسارين يغطيان النصفين ببادئة /1 (0.0.0.0/1 و128.0.0.0/1).
  2. يمتلك مسار الشبكة الفرعية المحقونة بادئة /16، وهي أكثر دقة وتحديداً من بادئة /1.
  3. بموجب مبدأ أطول تطابق للبادئة (Longest Prefix Match)، تمنح النواة الأسبقية للمسار /16 المباشر.

ونتيجة لذلك، تُرسل الحزم غير المشفرة مباشرة عبر واجهة wlan0 المادية، متجاوزة القناة الآمنة بالكامل، مما يتيح للمهاجم رصد طلبات HTTP والبيانات النصية الصريحة.

هجوم ServerIP (CVE-2023-35838): استغلال مسارات إعداد البوابة

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

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

لتفادي هذا الخلل، تقوم البرمجيات بتثبيت مسار مضيف مباشر (/32 لـ IPv4 أو /128 لـ IPv6) نحو البوابة المادية قبل تفعيل الواجهة الافتراضية:

# مسار مضيف مباشر إلى خادم النفق عبر الموجه المادي
198.51.100.50/32 via 192.168.1.1 dev wlan0

تحدث الثغرة عندما يُترجم اسم نطاق الخادم باستخدام خوادم DNS غير موثوقة تقدمها الشبكة المحلية عند بدء الاتصال:

  1. عند بدء محاولة الاتصال، يطلب التطبيق ترجمة اسم الخادم البعيد.
  2. يعيد خادم DNS المزيف عنوان IP خاصاً بالخدمة التي يرغب المهاجم في التجسس عليها.
  3. يقبل التطبيق العنوان ويقوم بإنشاء مسار مضيف مباشر /32 لذلك العنوان عبر واجهة wlan0.
  4. حتى وإن فشلت المصافحة مع تلك الوجهة المزيفة، يظل مسار /32 نشطاً، مما يجبر حركة البيانات المستقبلية المتجهة لتلك الخدمة على الخروج خارج النفق.

وحتى عند الاعتماد على عناوين IP ثابتة، يمكن للمهاجم تزييف سجلات DNS لمواقع أخرى لربطها بعنوان الخادم، مما يدفع بيانات تلك المواقع للخروج دون حماية.

+-----------------------------------------------------------------------------+
|                      مقارنة بين هجومي LOCALNET وSERVERIP                    |
+------------------------+----------------------------------------------------+
| نوع الهجوم             | آلية الاستغلال الأساسية                            |
+------------------------+----------------------------------------------------+
| LocalNet               | إعلان أقنعة شبكات فرعية عامة واسعة عبر DHCP        |
| (CVE-2023-36664)       | أسبقية البادئة الأطول تلغي مسارات /1 للنفق         |
|                        | استغلال ميزة السماح بالوصول للأجهزة المحلية        |
+------------------------+----------------------------------------------------+
| ServerIP               | تزييف استجابات DNS أثناء مرحلة تمهيد الاتصال        |
| (CVE-2023-35838)       | مسار المضيف /32 يدفع بالبيانات إلى الواجهة المادية |
|                        | استغلال آلية منع الدوران التكراري لحزم الخادم      |
+------------------------+----------------------------------------------------+

أوجه الاختلاف بين TunnelCrack وTunnelVision

من الضروري التمييز بوضوح بين TunnelCrack وهجوم TunnelVision (CVE-2024-3661). فعلى الرغم من استغلالهما لمنطق جداول التوجيه، إلا أن أدواتهما متباينة:

  • يعتمد TunnelVision كلياً على خيار DHCP Option 121 (RFC 3442، خيار المسارات الثابتة عديمة الفئات). فالأنظمة التي تتجاهل هذا الخيار افتراضياً (مثل نظام Android القياسي) لا تتأثر به.
  • لا يتطلب TunnelCrack أي خيارات إضافية في DHCP؛ إذ يعتمد هجوم LocalNet على حقل قناع الشبكة الفرعية المدمج في بروتوكول DHCP منذ عام 1997 (RFC 2132). ونظراً لأن كافة الأنظمة تعالج أقنعة الشبكات إجبارياً، فقد شمل تأثير TunnelCrack أنظمة iOS وmacOS وWindows وLinux وAndroid.

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

ترتيب أسبقية التوجيه في نواة نظام التشغيل:
┌────────────────────────────────────────────────────────┐
│  مسار المضيف (/32): عنوان IP محدد للهدف (ServerIP)    │  ◄── أعلى أولوية
├────────────────────────────────────────────────────────┤
│  مسار الشبكة الفرعية (/16, /24): محلي (LocalNet)       │  ◄── يسبق النفق
├────────────────────────────────────────────────────────┤
│  مسار النفق الافتراضي المجزأ (/1): 0.0.0.0/1           │  ◄── النفق المعياري
├────────────────────────────────────────────────────────┤
│  البوابة الافتراضية العامة (/0): 0.0.0.0/0             │  ◄── أدنى أولوية
└────────────────────────────────────────────────────────┘

المعالجات الهندسية: كيفية تحصين التوجيه ضد التسريب

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

1. جدار الحماية وقاطع الاتصال التلقائي على مستوى النواة

لا يمكن لمفتاح الإيقاف التلقائي (Kill Switch) أن يركن فقط إلى قياسات التوجيه، بل يجب أن يطبق قواعد ترشيح على مستوى النواة لإسقاط أي حزمة تخرج من البطاقة المادية ما لم تكن تابعة للمقبس المشفر الخاص بالخادم المعتمد.

في أنظمة Linux عبر أداة nftables، يتم حظر البيانات الصادرة غير المشفرة بدقة:

# حصر حركة البيانات في البطاقة المادية على حزم UDP المشفرة المتجهة للخادم
table inet vpn_filter {
    chain output {
        type filter hook output priority 0; policy drop;

        # السماح بحركة مرور الاسترجاع المحلي والواجهة الافتراضية
        oifname "lo" accept
        oifname "rice0" accept

        # السماح فقط بحزم النفق المشفرة نحو الخادم عبر الواجهة المادية
        oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
    }
}

وفي أنظمة Windows، تعتمد منصة Windows Filtering Platform (WFP) على برامج تشغيل لاعتراض الحزم غير المشفرة في طبقة النقل، بينما تعتمد أنظمة macOS على مرشح الحزم pf لمنع أي واجهة أخرى من إرسال البيانات.

2. تعطيل مشاركة الشبكة المحلية على شبكات Wi-Fi العامة

نظراً لاعتماد LocalNet على استثناءات الشبكة الداخلية، تعمد التطبيقات الرصينة إلى إيقاف الوصول المحلي عند التواجد في نقاط الاتصال العامة:

  • حذف كافة مسارات نطاق الرابط المباشرة.
  • توجيه سائر الحزم باستثناء الاتصال المحلي نحو النفق المشفر.
  • حتى في حال إعلان خادم DHCP عن نطاق شاسع ببادئة /8، يتولى جدار الحماية إسقاط أي محاولة إرسال مباشر.

3. نطاقات أسماء الشبكة وخيار SO_BINDTODEVICE

توفر نطاقات أسماء الشبكة (Network Namespaces) في أنظمة Linux وAndroid عزلاً كاملاً. فبنقل بطاقة الشبكة اللاسلكية إلى نطاق مستقل وإبقاء التطبيقات في النطاق الأساسي الذي لا يحتوي سوى على واجهة النفق، تفقد البرمجيات القدرة على الوصول المادي إلى مسارات الشبكة الخارجية.

كما يمكن للتطبيقات ربط مقابسها مباشرة بالواجهة الآمنة عبر خيار النظام:

// إلزام مقبس التطبيق بالارتباط المباشر بواجهة النفق
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));

عند ربط المقبس بجهاز محدد، تتجاوز النواة التقييم العام لجدول التوجيه وتدفع بالبيانات مباشرة إلى الواجهة الآمنة.

خطوات عملية للتحقق من أمان الجهاز ضد التلاعب

يمكن للمستخدمين ومديري النظم فحص أجهزتهم للتأكد من صمودها أمام هجمات TunnelCrack:

  1. فحص جداول التوجيه النشطة: استعرض مسارات التوجيه قبل وبعد إنشاء الاتصال المشفر للتأكد من عدم وجود مسارات مضيف /32 غير مبررة أو نطاقات ربط واسعة:
    ip route show table all
  2. اختبار محاكاة الشبكة الفرعية: اضبط موجه اختبار لبث نطاق IP عام (مثل 198.51.100.0/24) عبر DHCP المحلي، ثم اتصل بالنفق واختبر ما إذا كانت البيانات المتجهة إلى 198.51.100.1 تمر داخل النفق المشفر أو يتم إسقاطها.
  3. التأكد من إغلاق المشاركة المحلية: احرص دائماً على تعطيل خيار Local Network Sharing عند الاتصال بشبكات المطارات والمقاهي.

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

للحصول على أحدث إصدارات الحماية لكافة أجهزتك المكتبية والمحمولة، تفضل بزيارة صفحة تحميل VPNRice.