هجوم “TunnelVision” يترك جميع شبكات VPN تقريبًا عرضة للتجسس

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

TunnelVision، كما أطلق الباحثون على هجومهم، ينفي إلى حد كبير الغرض الكامل ونقطة البيع للشبكات الافتراضية الخاصة، وهي تغليف حركة مرور الإنترنت الواردة والصادرة في نفق مشفر وإخفاء عنوان IP الخاص بالمستخدم. ويعتقد الباحثون أن هذا يؤثر على جميع تطبيقات VPN عندما تكون متصلة بشبكة معادية، وأنه لا توجد طرق لمنع مثل هذه الهجمات إلا عندما تعمل شبكة VPN الخاصة بالمستخدم على Linux أو Android. وقالوا أيضًا إن أسلوب الهجوم الخاص بهم ربما كان ممكنًا منذ عام 2002 وربما تم اكتشافه بالفعل واستخدامه في البرية منذ ذلك الحين.

قراءة أو إسقاط أو تعديل حركة مرور VPN

وأوضح فيديو توضيحي أن تأثير TunnelVision هو أن “حركة مرور الضحية أصبحت الآن مكشوفة ويتم توجيهها عبر المهاجم مباشرة”. “يمكن للمهاجم قراءة أو إسقاط أو تعديل حركة المرور المسربة ويحتفظ الضحية باتصاله بكل من VPN والإنترنت.”

يعمل الهجوم عن طريق التلاعب بخادم DHCP الذي يخصص عناوين IP للأجهزة التي تحاول الاتصال بالشبكة المحلية. يسمح الإعداد المعروف بالخيار 121 لخادم DHCP بتجاوز قواعد التوجيه الافتراضية التي ترسل حركة مرور VPN عبر عنوان IP محلي يبدأ النفق المشفر. باستخدام الخيار 121 لتوجيه حركة مرور VPN عبر خادم DHCP، يقوم الهجوم بتحويل البيانات إلى خادم DHCP نفسه. وأوضح باحثون من شركة Leviathan Security:

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

نستخدم خيار DHCP رقم 121 لتعيين مسار على جدول التوجيه الخاص بمستخدم VPN. المسار الذي حددناه تعسفي ويمكننا أيضًا تعيين مسارات متعددة إذا لزم الأمر. من خلال دفع المسارات الأكثر تحديدًا من نطاق /0 CIDR الذي تستخدمه معظم شبكات VPN، يمكننا إنشاء قواعد توجيه لها أولوية أعلى من مسارات الواجهة الافتراضية التي تنشئها VPN. يمكننا تعيين مسارات متعددة /1 لإعادة إنشاء قاعدة 0.0.0.0/0 لكل حركة المرور التي تحددها معظم شبكات VPN.

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

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

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

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

ومن المثير للاهتمام أن Android هو نظام التشغيل الوحيد الذي يقوم بتحصين تطبيقات VPN بشكل كامل من الهجوم لأنه لا ينفذ الخيار 121. وبالنسبة لجميع أنظمة التشغيل الأخرى، لا توجد إصلاحات كاملة. عند تشغيل التطبيقات على Linux، يكون هناك إعداد يقلل من التأثيرات، ولكن حتى في هذه الحالة يمكن استخدام TunnelVision لاستغلال قناة جانبية يمكن استخدامها لإلغاء إخفاء هوية حركة مرور الوجهة وتنفيذ هجمات رفض الخدمة المستهدفة. يمكن أيضًا تكوين جدران الحماية للشبكة لمنع حركة المرور الواردة والصادرة من وإلى الواجهة الفعلية. يمثل هذا العلاج مشكلة لسببين: (1) لا يستطيع مستخدم VPN الذي يتصل بشبكة غير موثوقة التحكم في جدار الحماية، و(2) يفتح نفس القناة الجانبية الموجودة مع تخفيف Linux.

تتمثل الإصلاحات الأكثر فاعلية في تشغيل VPN داخل جهاز افتراضي لا يكون محول الشبكة الخاص به في وضع الجسر أو توصيل VPN بالإنترنت من خلال شبكة Wi-Fi لجهاز خلوي. البحث الذي أجراه الباحثون في شركة Leviathan Security، ليزي موراتي وداني كرونس، متاح هنا.

ظهرت هذه القصة في الأصل على آرس تكنيكا.