Bạn ngồi xuống một quán cà phê đông đúc bên trong nhà ga, kết nối máy tính xách tay vào mạng Wi-Fi công cộng miễn phí và mở trình duyệt để kiểm tra hòm thư công việc. Biểu tượng ổ khóa màu xanh lá hiển thị vững vàng trên thanh địa chỉ, xác nhận một phiên mã hóa HTTPS an toàn. Bạn không hề nhận được bất kỳ thông báo lỗi chứng chỉ SSL nào, không cài đặt cấu hình lạ và cũng không nhấp vào liên kết đáng ngờ. Mọi thứ diễn ra bình thường như mọi ngày. Thế nhưng trong hậu trường, hệ điều hành của bạn vừa âm thầm tải về một tệp cấu hình mã nguồn JavaScript từ một máy tính của kẻ tấn công đang ngồi cùng phòng, tự động chỉ định máy tính lạ đó làm máy chủ trung gian (Proxy) cho toàn bộ phiên duyệt web và âm thầm chuyển tiếp cookie xác thực của bạn qua cổng giám sát của đối phương.

Phương thức tấn công tinh vi này hoàn toàn không cần khai thác lỗ hổng zero-day hay phá mã mật khẩu. Nó tận dụng triệt để một giao thức cổ điển từ cuối thập niên 1990 vẫn đang bật mặc định trên hàng trăm triệu máy tính hiện nay: giao thức Tự động phát hiện Proxy Web (Web Proxy Auto-Discovery - WPAD).

Nguồn gốc kiến trúc: Ưu tiên sự tiện lợi hơn ranh giới bảo mật

Để hiểu rõ vì sao WPAD tạo ra rủi ro bảo mật nghiêm trọng trên mạng công cộng, cần xem xét bối cảnh ra đời của nó. Trong giai đoạn bùng nổ mạng doanh nghiệp cuối thập niên 1990, các quản trị viên hệ thống cần một cơ chế tự động hướng dẫn máy tính của nhân viên gửi lưu lượng web qua các máy chủ proxy nội bộ (nhằm lưu đệm và lọc nội dung) mà không bắt buộc đội ngũ IT phải cấu hình thủ công từng thiết bị.

Đặc tả này, được chuẩn hóa dưới dạng bản thảo của IETF năm 1999, đã tạo ra một giao thức vận hành gần như vô hình. Mỗi khi hệ điều hành kết nối vào một giao diện mạng mới, ngăn xếp mạng sẽ tự động khởi động một chuỗi truy vấn để trả lời một câu hỏi duy nhất: "Tệp cấu hình proxy tự động (Proxy Auto-Configuration - PAC) của mạng này nằm ở đâu?"

[ Máy tính cá nhân ]
       |
       | 1. Gói tin DHCP Inform (Option 252) -> "wpad.dat nằm ở đâu?"
       +---------------------------------------------> [ Cổng mạng nội bộ (Gateway) ]
       |                                                    (Không phản hồi)
       | 2. Truy vấn DNS: wpad.local / wpad.cafe.internal
       +---------------------------------------------> [ Máy chủ phân giải DNS ]
       |                                                    (Báo không tồn tại - NXDOMAIN)
       | 3. Phát sóng đa hướng nội bộ: LLMNR / NetBIOS tìm "WPAD"
       +---------------------------------------------> [ Toàn bộ dải mạng Wi-Fi ]
                                                             |
                                                             v
                                               [ Kẻ tấn công trên cùng Wi-Fi ]
                                               (Trả lời ngay: "Tôi là WPAD! Hãy tải file PAC!")

Điểm yếu chí mạng của giao thức này nằm ở chuỗi truy vấn dự phòng dạng bậc thang (fallback cascade). Nếu cổng mạng chính thức không phản hồi, máy tính nạn nhân sẽ tự động nới rộng phạm vi tìm kiếm, chuyển từ các truy vấn đơn hướng sang phát loa hỏi khắp toàn bộ dải mạng cục bộ.

Chuỗi truy vấn bậc thang: Lời mời béo bở cho kẻ nghe lén

Khi hệ điều hành Windows hoặc các trình duyệt máy tính tìm kiếm cài đặt proxy, quy trình tìm kiếm diễn ra theo thứ tự nghiêm ngặt sau:

1. Tùy chọn DHCP Option 252

Ngay khi nhận địa chỉ IP, máy khách gửi gói tin DHCPINFORM hỏi xem máy chủ DHCP nội bộ có thiết lập Tùy chọn 252 (Option 252) hay không. Nếu có, tùy chọn này trả về đường dẫn trực tiếp tới tệp PAC, ví dụ http://192.168.1.1/wpad.dat. Tuy nhiên, hầu hết bộ định tuyến dân dụng tại quán cà phê hay sân bay không bao giờ cấu hình tùy chọn này, khiến truy vấn đầu tiên thất bại.

2. Phân giải tên miền qua hệ thống DNS

Khi DHCP Option 252 không phản hồi, hệ điều hành ghép tiền tố wpad với hậu tố tên miền tìm kiếm hiện tại. Ví dụ nếu mạng cấp tên miền nội bộ là corp.local, máy tính sẽ truy vấn wpad.corp.local. Nếu tiếp tục thất bại, hệ thống rút gọn truy vấn thành wpad.local. Tại các mạng Wi-Fi công cộng cấu hình ẩu hoặc gán tên miền kỳ dị, cơ chế này thậm chí làm lộ truy vấn ra các tên miền cấp cao quốc tế (như wpad.com), gây ra hiện tượng xung đột tên miền đã từng được tổ chức CERT/CC cảnh báo khẩn cấp.

3. Phát sóng đa hướng qua LLMNR và NetBIOS

Nếu DNS báo tên miền không tồn tại (NXDOMAIN), máy tính kích hoạt tầng dự phòng cuối cùng và nguy hiểm nhất: phát sóng đa hướng không cần xác thực qua giao thức LLMNR (Link-Local Multicast Name Resolution) và NetBIOS. Máy tính phát một gói tin UDP tới toàn bộ các máy khác trong mạng Wi-Fi với thông điệp: "Có ai trong mạng này nắm giữ địa chỉ của WPAD không?"

Trong môi trường Wi-Fi công cộng, kẻ tấn công chạy các công cụ nghe lén tự động như Responder hoặc Inveigh liên tục trực chờ tín hiệu này. Ngay khi máy tính của bạn vừa phát lời hỏi tìm wpad, máy kẻ tấn công sẽ mạo danh phản hồi tức thì: "Tôi chính là wpad! Hãy lấy cấu hình proxy từ máy chủ web của tôi tại địa chỉ 192.168.1.145/wpad.dat."

Hệ điều hành của nạn nhân cả tin tiếp nhận phản hồi giả mạo, kết nối tới máy chủ của kẻ tấn công, tải tệp wpad.dat và áp dụng luật proxy lên toàn bộ lưu lượng của máy mà người dùng không hề hay biết.

Bóc tách tệp PAC độc hại: Điều hướng lưu lượng có chủ đích

Tệp PAC không phải là một danh sách IP tĩnh đơn thuần; nó thực chất là một chương trình JavaScript hoàn chỉnh chứa hàm bắt buộc: FindProxyForURL(url, host).

Mỗi khi máy tính chuẩn bị kết nối tới bất kỳ trang web nào, hệ thống sẽ thực thi hàm này để quyết định đường đi của gói tin. Kẻ tấn công lập trình tệp PAC với độ chính xác tuyệt đối:

function FindProxyForURL(url, host) {
    // Cho phép lưu lượng cục bộ đi thẳng để tránh gây nghi ngờ
    if (isPlainHostName(host) || dnsDomainIs(host, ".local")) {
        return "DIRECT";
    }

    // Đánh chặn có chọn lọc các cổng đăng nhập, email và ngân hàng
    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";
    }

    // Các lưu lượng đọc báo, xem video thông thường vẫn cho đi thẳng
    return "DIRECT";
}

Bằng cách chỉ chuyển tiếp các trang đăng nhập quan trọng qua máy chủ proxy độc hại và giữ nguyên kết nối trực tiếp cho các dịch vụ xem video, đọc báo, kẻ tấn công đảm bảo tốc độ mạng của nạn nhân vẫn mượt mà, không hề có dấu hiệu giật lag hay ngắt kết nối để đánh động người dùng.

Những gì kẻ tấn công thu thập được

Một khi lưu lượng bị buộc chuyển hướng qua máy chủ proxy lạ:

  • Lưu lượng HTTP không mã hóa: Bị đọc rõ toàn bộ, bao gồm mật khẩu tài khoản, mã phiên đăng nhập và nội dung biểu mẫu.
  • Lưu lượng HTTPS mã hóa: Dù nội dung bên trong được bảo vệ bởi TLS, proxy lạ vẫn tiếp nhận yêu cầu bắt tay HTTP CONNECT ban đầu. Yêu cầu này làm lộ chính xác tên miền máy chủ (SNI), cổng kết nối, thời gian và dung lượng truyền tải của nạn nhân.
  • Tấn công hạ cấp xác thực & Chuyển tiếp NTLM: Nhiều tiến trình nền của Windows tự động xác thực danh tính với máy chủ proxy. Proxy WPAD độc hại có thể gửi lại tiêu đề Proxy-Authenticate: NTLM, buộc máy tính nạn nhân gửi mã băm mật khẩu Windows của người dùng, mở đường cho kẻ tấn công bẻ khóa offline hoặc chiếm đoạt phiên làm việc nội bộ doanh nghiệp.

Chiến lược phòng vệ: Vô hiệu hóa cái bẫy proxy ngầm

Bảo vệ thiết bị cá nhân và máy tính doanh nghiệp trước hiểm họa WPAD đòi hỏi sự kết hợp giữa việc tắt các tính năng dò tìm tự động của hệ điều hành và thiết lập kênh truyền mã hóa cách ly.

1. Tắt tính năng tự động phát hiện proxy trong hệ điều hành

Trừ khi bạn làm việc trong mạng nội bộ công ty bắt buộc sử dụng WPAD theo chính sách IT, tính năng tự động phát hiện proxy nên được tắt vĩnh viễn:

  • Trên Windows 11 và 10: Mở Cài đặt (Settings), vào mục Mạng & Internet > Proxy (Network & Internet > Proxy). Tại phần Thiết lập proxy tự động (Automatic proxy setup), gạt tùy chọn Tự động phát hiện cài đặt (Automatically detect settings) sang trạng thái Tắt (Off).
  • Trên macOS: Mở Cài đặt hệ thống (System Settings), vào mục Mạng (Network), chọn giao diện kết nối Wi-Fi, bấm Chi tiết > Máy chủ proxy (Details > Proxies) và đảm bảo bỏ chọn mục Tự động phát hiện proxy (Auto Proxy Discovery) cùng Cấu hình proxy tự động (Automatic Proxy Configuration).
  • Trên trình duyệt Web: Trong Firefox, vào phần Cài đặt > Cài đặt mạng (Settings > Network Settings) và chọn Không dùng proxy (No proxy) thay vì chế độ tự động nhận diện từ hệ thống.

2. Vô hiệu hóa phân giải tên miền LLMNR và NetBIOS

Chặn hệ điều hành phát sóng các gói tin truy vấn đa hướng trong mạng Wi-Fi cục bộ để triệt tiêu cơ hội mạo danh của kẻ xấu:

  • Mở công cụ Trình chỉnh sửa chính sách nhóm cục bộ (Local Group Policy Editor - gpedit.msc) trên Windows.
  • Điều hướng tới thư mục Cấu hình máy tính > Mẫu quản trị > Mạng > Máy khách DNS (Computer Configuration > Administrative Templates > Network > DNS Client).
  • Nhấp đúp vào chính sách Tắt tính năng phân giải tên đa hướng (Turn off multicast name resolution) và chọn Bật (Enabled).

3. Cô lập lưu lượng toàn diện với VPNRice

Mặc dù điều chỉnh thủ công các cài đặt hệ điều hành là bước đi cần thiết, nhiều ứng dụng bên thứ ba hoặc tiện ích chạy ngầm vẫn có thể gửi các yêu cầu dò tìm proxy độc lập. Tuyến phòng thủ vững chắc nhất trên mọi mạng Wi-Fi công cộng là đóng gói toàn bộ luồng dữ liệu ra Internet bên trong đường hầm mã hóa của VPNRice.

Khi kích hoạt kết nối VPNRice bằng các giao thức thế hệ mới như RiceGuard hoặc RiceGuardX, toàn bộ bề mặt tấn công cục bộ bị vô hiệu hóa:

  • Loại trừ bẫy cổng mạng cục bộ: Mọi gói tin xuất phát từ thiết bị đều được đóng gói mật mã trước khi rời ăng-ten Wi-Fi. Các máy chủ DHCP giả mạo hay thiết bị nghe lén cùng mạng không thể trả lời giả mạo WPAD hoặc can thiệp vào đường đi của dữ liệu.
  • Hệ thống DNS mã hóa chuyên biệt: Mọi truy vấn phân giải tên miền được dẫn thẳng tới máy chủ DNS đệ quy nội bộ của VPNRice qua đường hầm bảo mật, loại bỏ hoàn toàn cơ chế dự phòng LLMNR, NetBIOS hay đầu độc DNS cục bộ.
  • Cách ly tuyệt đối thiết bị: Tường lửa của ứng dụng cô lập hoàn toàn giao diện mạng, ngăn các máy tính lạ trong cùng mạng Wi-Fi gửi gói tin thăm dò hoặc điều hướng lưu lượng qua máy chủ trung gian.

Để kiểm tra chắc chắn rằng hệ thống của bạn không bị rò rỉ địa chỉ IP hay lộ thông tin định tuyến nội bộ qua các giao diện trình duyệt, bạn có thể thực hiện kiểm tra qua công cụ kiểm tra rò rỉ WebRTC của VPNRice và theo dõi địa chỉ IP đầu ra với công cụ tra cứu IP. Khóa chặt các giao thức tự động dò tìm cổ điển kết hợp cùng lớp mã hóa toàn diện của VPN là giải pháp tối ưu để bạn hoàn toàn an tâm làm việc trên mọi mạng Wi-Fi công cộng.