TunnelCrack در برابر TunnelVision: هر یک واقعاً چه چیزی را می‌شکند
TunnelCrack و TunnelVision از استثناهای مسیریابی متفاوتی سوءاستفاده می‌کنند: استثنای شبکه محلی، مسیر سرور و گزینه 121 DHCP را برای هر نسخه کلاینت بررسی کنید.
دو نام پژوهشی به‌جای یکدیگر برای هر ترافیک VPN که از تونل خارج می‌شود به کار می‌رود، اما سازوکارهای پشت آن‌ها یکسان نیست. TunnelCrack دو خانواده از استثناهای مسیریابی را توصیف می‌کند؛ TunnelVision مسیری را توصیف می‌کند که DHCP روی دستگاه پایانی تحویل می‌دهد. هیچ‌یک رمزنگاری را نمی‌شکند و هیچ‌یک به شما نمی‌گوید یک نسخه مشخص از کلاینت امروز چه می‌کند. پنج بررسی سازوکارها را از تیتر جدا می‌کند.
گام یک: سازوکاری را که بررسی می‌کنید نام ببرید
افشای TunnelCrack در اوت 2023 دو خانواده حمله را توصیف می‌کند. در حالت شبکه محلی، ترافیکی که کلاینت آن را متعلق به شبکه محلی می‌داند استثنای دسترسی محلی می‌گیرد و از تونل خارج می‌شود. در حالت نشانی سرور، مسیری که کلاینت برای رسیدن به خود سرور VPN لازم دارد بیرون از تونل است، و مهاجمی که آن نشانی را کنترل می‌کند می‌تواند از این استثنا بهره ببرد.
TunnelVision گزارشی جداگانه درباره مسیرهای ایستای بدون کلاس است که DHCP تحویل می‌دهد. یک سرور DHCP مخرب می‌تواند به دستگاه پایانی مسیرهایی بدهد که مسیر حرکت ترافیک را تغییر می‌دهند، از جمله مسیر به سوی سرور VPN. گزارش کار پیشین درباره اثرهای مرتبط مسیریابی را می‌پذیرد، که یادآور است سازوکار زیربنایی از نام قدیمی‌تر است.
| Case | Exception it abuses |
|---|---|
| TunnelCrack local network | Traffic classified as local bypasses the tunnel |
| TunnelCrack server address | The route to the VPN server sits outside the tunnel |
| TunnelVision | DHCP option 121 installs routes that redirect traffic |
نام‌ها را به سازوکارهایشان چسبیده نگه دارید. اعمال اصلاح برای یکی به این دلیل که دیگری در خبرهاست، همان راهی است که یک بازبینی حرکت بدون پوشش تولید می‌کند.
گام دو: به استثنای دسترسی محلی نگاه کنید
بیشتر کلاینت‌ها ترافیک شبکه محلی را مستثنا می‌کنند تا چاپگرها، پخش تصویر و اشتراک فایل هنگام بالا بودن تونل کار کنند. این استثنا تصمیمی سیاستی با هزینه امنیتی است: مهاجم در همان شبکه می‌تواند خود را میزبان محلی جا بزند، و ترافیکی که به آن می‌رسد هرگز وارد تونل نشده است.
بپرسید آیا پروفایل مستقرشده اصلاً به این استثنا نیاز دارد. نیروی کار دورکاری که هرگز از کشف محلی استفاده نمی‌کند می‌تواند آن را خاموش کند، و به سرویس‌های محلی باقی‌مانده می‌توان از مسیری مستند رسید. جایی که استثنا لازم است، بگویید کدام مقصدها را پوشش می‌دهد، به‌جای اینکه آن را ترافیک محلی بنامید.
بررسی یک پرسش پیکربندی است، نه ضبط بسته. تنظیم پروفایل و مستندات کلاینت را برای نسخه‌ای که مستقر می‌کنید بخوانید، چون مقدار پیش‌فرض میان محصول‌ها و میان نسخه‌های یک محصول فرق می‌کند. پاسخ را کنار پروفایل بنویسید تا بازبین بعدی مجبور نباشد آن را از رفتار استنباط کند. استثنایی که هیچ‌کس مستند نکرده باشد، استثنایی است که هیچ‌کس بازبینی نمی‌کند.
گام سه: ببینید نشانی سرور چگونه آموخته می‌شود
کلاینت باید پیش از وجود هر تونلی به سرور VPN برسد، پس آن مقصد بر اساس طراحی بیرون از تونل مسیریابی می‌شود. اگر نشانی از یک نام آموخته شود، گام تحلیل بخشی از مسیر اعتماد است، و مهاجمی که می‌تواند به آن پرس‌وجو پاسخ دهد می‌تواند کلاینت را به میزبانی که کنترل می‌کند بفرستد.
تثبیت نشانی، استفاده از گواهی تأییدشده با نام درست و خودداری از بازگشت به سرور تأییدنشده همه مواجهه را کم می‌کنند. هیچ‌یک از آن‌ها نیاز به رسیدن به سرور بیرون از تونل را برنمی‌دارد؛ آن‌ها تغییر می‌دهند چه کسی می‌تواند پاسخگوی آن نشانی باشد.
resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule showجست‌وجوی مسیر رابطی را نشان می‌دهد که کلاینت برای نشانی سرور به کار می‌برد، که همان استثنا در شکل عینی است. اگر آن جست‌وجو رابط تونل را برگرداند، کلاینت اصلاً نمی‌تواند تونل را برپا کند، پس مسیری بیرونی انتظار می‌رود و پرسش تنها این است که مقصد آن چگونه انتخاب می‌شود.
گام چهار: به مسیرهایی که DHCP می‌دهد نگاه کنید
مسیرهای ایستای بدون کلاس به سرور DHCP اجازه می‌دهند ورودی‌های جدول مسیریابی را توزیع کند، و دستگاه پایانی معمولاً آن‌ها را بدون پرسیدن می‌پذیرد. در شبکه‌ای که مهاجم می‌تواند سریع‌تر از سرور مشروع به DHCP پاسخ دهد، آن ورودی‌ها می‌توانند ترافیکی را که کاربر گمان می‌کند داخل تونل است تغییر مسیر دهند.
مسیرهای دستگاه پایانی را با مسیرهایی که انتظار دارید مقایسه کنید. مسیر پیش‌فرض یا پیشوند گسترده‌ای که هنگام بالا بودن تونل به دروازه محلی اشاره می‌کند همان امضایی است که ارزش بررسی دارد، و بدون هیچ ترافیک حمله‌ای دیده می‌شود.
ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"آخرین تنظیم، کنترل سمت دستگاه پایانی است که بسیاری از کلاینت‌ها و سکوها به شکلی آن را ارائه می‌دهند: نادیده گرفتن مسیرهایی که شبکه تحویل می‌دهد. خاموش کردن پذیرش خودکار مسیر یک معامله است، چون مسیریابی تقسیم‌شده مشروع از یک سرور DHCP سازمانی را هم خاموش می‌کند، پس آن را بر پایه کلاس شبکه تصمیم بگیرید نه به‌صورت جهانی.
گام پنج: اعلان را از نسخه کنونی جدا کنید
حمله منتشرشده رفتاری را توصیف می‌کند که در نسخه‌های مشخصی از کلاینت در زمانی مشخص مشاهده شده است. این ثابت نمی‌کند لپ‌تاپ پیش روی شما متأثر است و ثابت نمی‌کند اصلاح شده است. هر دو ادعا به شماره ساخت واقعی و اعلان کنونی فروشنده نیاز دارند.
نسخه کلاینت، سکو، تنظیم‌های پروفایلی که استثناهای بالا را اداره می‌کنند و تاریخی که بررسی کردید را ثبت کنید. آن سابقه صادقانه کهنه می‌شود، اما یادداشتی که بگوید VPN برای TunnelCrack وصله شده است این‌گونه نیست. هر بار که کلاینت به‌روزرسانی می‌شود دوباره آن را بخوانید، چون پیش‌فرض یک پروفایل می‌تواند زیر نسخه‌ای که به آن دست نزده‌اید تغییر کند.
وقتی واقعاً اعتبارسنجی می‌کنید، از طرحی تأییدشده علیه دستگاه پایانی خودتان و مقصدی بی‌خطر استفاده کنید. بازتولید حمله علیه کاربران دیگر در شبکه‌ای مشترک آزمون نیست، و خاموش کردن تأیید همتا یا رمزنگاری برنامه برای آسان‌تر کردن مشاهده، همان حفاظتی را که می‌کوشیدید بسنجید برمی‌دارد.
سرانجام، حفاظت سطح برنامه را در تصویر نگه دارید. یک استثنای مسیریابی می‌تواند ترافیکی را که تونل حمل می‌کرد افشا کند، و TLS برنامه هنوز آن ترافیک را سرتاسر محافظت می‌کند. دو لایه مستقل از هم شکست می‌خورند، و به همین دلیل یک کانال کنترل متصل شاهد آن نیست که هر جریان مسیر درنظرگرفته‌شده را پیموده است.