Tiếng Việt
English
中文
Español
हिन्दी
Français
Português
Русский
Deutsch
日本語
한국어
Italiano
Bahasa Indonesia
ไทย
বাংলা
ລາວ
မြန်မာ
العربية
فارسی
اردو
Українська
Română
Azərbaycan
Nhiều người dùng tin rằng khi biểu tượng mạng ảo kích hoạt, mọi dữ liệu gửi đi đều được mã hóa kiên cố qua các thuật toán hiện đại như ChaCha20-Poly1305 hay AES-256-GCM. Về mặt toán học, các thuật toán mã hóa bảo vệ toàn vẹn nội dung gói tin trên đường truyền vật lý. Tuy nhiên, thuật toán mật mã không bao giờ quyết định đường đi của gói tin. Quyền định đoạt hướng di chuyển của dữ liệu thuộc về bảng định tuyến của nhân hệ điều hành.
Năm 2023, nhóm nghiên cứu bảo mật gồm Mathy Vanhoef, Nian Xue, Yashaswi Malla, Zihang Xiao và Cristina Nita-Rotaru công bố lỗ hổng kiến trúc nghiêm trọng mang tên TunnelCrack. Được định danh qua hai mã CVE-2023-36664 và CVE-2023-35838, nghiên cứu này chứng minh mạng cục bộ không đáng tin cậy hoặc điểm phát Wi-Fi công cộng giả mạo có thể thao túng quy tắc định tuyến, buộc dữ liệu nhạy cảm thoát ra ngoài đường hầm bảo mật dưới dạng văn bản thuần rõ ràng.
Hiểu rõ bản chất TunnelCrack đòi hỏi bóc tách chi tiết hai phương thức tấn công chính: tấn công LocalNet và tấn công ServerIP.
+-----------------------------------------------------------------------------+
| SƠ ĐỒ RÒ RỈ ĐỊNH TUYẾN TUNNELCRACK |
| |
| [Thiết bị người dùng] |
| │ |
| ├── Đích đến: Địa chỉ máy chủ công cộng (Ví dụ: 142.250.190.46) |
| │ |
| ▼ |
| [Quyết định định tuyến nhân hệ điều hành] |
| │ |
| ├─► Tuyến A: Đường hầm VPN mặc định (0.0.0.0/1 qua utun0) |
| │ |
| └─► Tuyến B: Dải mạng cục bộ LocalNet (142.250.0.0/16 qua wlan0) |
| (Quy tắc tiền tố dài nhất Longest Prefix Match ưu tiên) |
| |
| ▼ |
| [Giao diện vật lý: wlan0] ────────────────► [Cổng phát Wi-Fi giả mạo] |
| (Gói tin Ethernet không mã hóa rò rỉ ngoài) (Kẻ tấn công thu thập) |
+-----------------------------------------------------------------------------+
Tấn công LocalNet (CVE-2023-36664): Lợi dụng ngoại lệ mạng cục bộ
Lỗ hổng LocalNet bắt nguồn từ tính năng chia sẻ mạng nội bộ được nhiều ứng dụng mạng cá nhân ảo tích hợp sẵn. Khi kết nối mạng bảo mật tại nhà riêng hoặc văn phòng, người dùng thường có nhu cầu in ấn qua máy in mạng, sao lưu dữ liệu vào ổ cứng mạng cục bộ hoặc kết nối màn hình thông minh. Để hỗ trợ nhu cầu này, hệ điều hành thiết lập các tuyến đường phạm vi liên kết trực tiếp cho mạng nội bộ.
Khi thiết bị kết nối vào trạm phát Wi-Fi, máy chủ DHCP sẽ phân phối cấu hình IP gồm địa chỉ cấp phát, mặt nạ mạng con và cổng mặc định. Trong điều kiện thông thường, mạng sử dụng dải riêng tư RFC 1918 như 192.168.1.0/24. Nhân hệ điều hành tự động thêm một mục định tuyến liên kết trực tiếp:
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105
Với thuộc tính liên kết trực tiếp này, nhân hệ điều hành hiểu rằng mọi gói tin hướng tới dải 192.168.1.0/24 có thể gửi thẳng qua giao thức phân giải địa chỉ mà không cần chuyển tiếp qua cổng ngoài. Nhằm duy trì tính năng mạng nội bộ, ứng dụng đường hầm thường giữ nguyên tuyến đường này hoặc tạo danh sách ngoại lệ định tuyến riêng.
Trạm phát Wi-Fi do kẻ tấn công kiểm soát biến cơ chế này thành vũ khí bằng cách khai báo một dải địa chỉ IP công cộng tùy ý làm mạng cục bộ. Chẳng hạn, máy chủ DHCP giả mạo cấp phát cho thiết bị một địa chỉ IP thuộc dải 142.250.0.0/16 kèm mặt nạ mạng con 255.255.0.0:
# Nhân hệ điều hành cài đặt tuyến liên kết cục bộ giả mạo trên card Wi-Fi
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45
Khi người dùng mở trình duyệt web hoặc dịch vụ chạy nền truy cập tới máy chủ nằm trong dải IP đó, nhân hệ điều hành đối chiếu bảng thông tin chuyển tiếp. Theo quy tắc định tuyến chuẩn:
- Giao diện mạng ảo thường sử dụng định tuyến mặc định hai nửa dải mạng gồm
0.0.0.0/1và128.0.0.0/1. - Tuyến mạng cục bộ giả mạo có độ dài tiền tố
/16, cụ thể hơn rất nhiều so với tiền tố/1của đường hầm. - Theo nguyên lý khớp tiền tố dài nhất, tuyến đường
/16được nhân hệ điều hành trao quyền ưu tiên xử lý cao hơn.
Hậu quả trực tiếp là gói tin IP không qua mã hóa được gửi thẳng ra card mạng vật lý wlan0. Đường hầm mã hóa hoàn toàn không được sử dụng cho luồng dữ liệu này, tạo điều kiện cho kẻ kiểm soát trạm phát mạng thu thập các yêu cầu HTTP, truy vấn DNS và nội dung truyền tải mà người dùng không hề hay biết.
Tấn công ServerIP (CVE-2023-35838): Thao túng định tuyến cổng kết nối
Nếu như LocalNet lợi dụng cấu hình mặt nạ mạng con, thì phương thức ServerIP lại nhắm vào chính yêu cầu khởi tạo kỹ thuật của giao thức mạng bảo mật.
Để truyền tải các gói tin đóng gói qua hạ tầng Internet công cộng tới máy chủ từ xa, card mạng vật lý bắt buộc phải biết đường truyền tới máy chủ đó. Nếu ứng dụng định tuyến toàn bộ lưu lượng qua giao diện ảo, các gói tin đóng gói gửi đến máy chủ đường hầm sẽ bị đẩy ngược lại vào chính giao diện ảo, dẫn đến hiện tượng vòng lặp định tuyến vô tận làm sập kết nối.
Nhằm giải quyết xung đột này, ứng dụng thiết lập một tuyến đường máy chủ chuyên biệt với độ dài tiền tố /32 hướng thẳng tới cổng mạng vật lý trước khi kích hoạt giao diện ảo:
# Tuyến đường máy chủ trực tiếp tới máy chủ đường hầm qua router vật lý
198.51.100.50/32 via 192.168.1.1 dev wlan0
Lỗ hổng ServerIP xuất hiện khi tên miền của máy chủ đường hầm được phân giải qua hệ thống máy chủ phân giải tên miền không tin cậy của mạng cục bộ lúc bắt đầu kết nối:
- Khi thiết bị bắt đầu kết nối, ứng dụng gửi truy vấn tên miền của máy chủ dịch vụ.
- Máy chủ phân giải tên miền giả mạo tại điểm Wi-Fi công cộng trả về địa chỉ IP của một dịch vụ mục tiêu mà kẻ tấn công muốn theo dõi (chẳng hạn máy chủ cổng nội bộ hoặc giao diện lập trình đám mây).
- Ứng dụng chấp nhận phân giải này và tự động thêm tuyến đường
/32cho địa chỉ IP đích đó hướng ra giao diện mạng vật lý. - Dù phiên kết nối bảo mật tới địa chỉ IP giả mạo đó không thành công, các lưu lượng thực tế sau đó từ thiết bị tới dịch vụ mục tiêu sẽ liên tục truyền ra ngoài đường hầm mã hóa.
Ngay cả khi ứng dụng sử dụng địa chỉ IP tĩnh để kết nối, kẻ xấu vẫn có thể làm sai lệch bản ghi tên miền của các trang web thông thường để trùng với IP máy chủ đường hầm, khiến dữ liệu gửi tới các trang đó thoát ra card mạng vật lý dưới dạng văn bản không mã hóa.
+-----------------------------------------------------------------------------+
| SO SÁNH TẤN CÔNG LOCALNET VÀ SERVERIP |
+------------------------+----------------------------------------------------+
| Hình thức | Cơ chế khai thác chính |
+------------------------+----------------------------------------------------+
| LocalNet | Mặt nạ mạng con công cộng lớn từ DHCP giả mạo |
| (CVE-2023-36664) | Khớp tiền tố dài nhất ghi đè tuyến /1 của đường hầm|
| | Khai thác tính năng chia sẻ mạng cục bộ |
+------------------------+----------------------------------------------------+
| ServerIP | Giả mạo phân giải tên miền khi khởi tạo kết nối |
| (CVE-2023-35838) | Tuyến đường máy chủ /32 chuyển dữ liệu ra ngoài |
| | Khai thác cơ chế chống lặp định tuyến máy chủ |
+------------------------+----------------------------------------------------+
So sánh TunnelCrack và TunnelVision: Điểm khác biệt mấu chốt
Cần phân biệt rõ TunnelCrack với hình thức tấn công TunnelVision (CVE-2024-3661). Cả hai phương thức đều nhắm vào bảng định tuyến hệ điều hành, nhưng điểm tựa khai thác hoàn toàn khác biệt:
- TunnelVision dựa hoàn toàn vào Tùy chọn DHCP 121 (RFC 3442, tùy chọn tuyến tĩnh không phân lớp) để cài cắm các mục định tuyến tùy ý. Những hệ điều hành không hỗ trợ Tùy chọn 121 theo thiết kế mặc định như Android sẽ không bị ảnh hưởng bởi TunnelVision.
- TunnelCrack không cần bất kỳ tùy chọn DHCP đặc thù nào. Đòn tấn công LocalNet hoạt động dựa trên các trường mặt nạ mạng con cơ bản đã có trong RFC 2132 từ năm 1997. Vì mọi hệ điều hành đều xử lý cấu hình mạng con, TunnelCrack tác động sâu rộng trên iOS, macOS, Windows, Linux lẫn Android.
Nhân hệ điều hành luôn ưu tiên định tuyến theo độ dài tiền tố mà không kiểm tra ngữ cảnh mật mã. Khi gói tin khớp với tuyến đường /16 hoặc /24 trên giao diện Wi-Fi vật lý, nhân sẽ không bao giờ chuyển gói tin đó qua giao diện mạng bảo mật ảo.
Thứ bậc ưu tiên định tuyến trong nhân hệ điều hành:
┌────────────────────────────────────────────────────────┐
│ Tuyến máy chủ đích (/32): Mục tiêu cụ thể (ServerIP) │ ◄── Ưu tiên cao nhất
├────────────────────────────────────────────────────────┤
│ Tuyến mạng con (/16, /24): Mạng cục bộ (LocalNet) │ ◄── Ghi đè đường hầm
├────────────────────────────────────────────────────────┤
│ Tuyến chia đôi mặc định (/1): 0.0.0.0/1 & 128.0.0.0/1 │ ◄── Đường hầm chuẩn
├────────────────────────────────────────────────────────┤
│ Cổng kết nối mặc định (/0): 0.0.0.0/0 │ ◄── Ưu tiên thấp nhất
└────────────────────────────────────────────────────────┘
Giải pháp kiến trúc: Cách bảo vệ hệ thống trước rò rỉ định tuyến
Để triệt tiêu triệt để nguy cơ từ TunnelCrack, các giải pháp bảo mật hiện đại không chỉ đơn thuần tinh chỉnh bảng định tuyến mà phải áp dụng phòng thủ nhiều lớp tại tầng tường lửa nhân, không gian tên mạng và cơ chế ràng buộc socket.
1. Tường lửa ngắt kết nối khẩn cấp cấp độ nhân
Cơ chế ngắt kết nối an toàn không thể chỉ trông cậy vào độ ưu tiên định tuyến. Giải pháp chuẩn mực triển khai các quy tắc lọc gói tin ngay tại nhân hệ điều hành, lập tức hủy bỏ mọi gói tin gửi ra card mạng vật lý nếu gói tin đó không khớp với cổng vận chuyển mã hóa đã xác thực.
Trên Linux, tường lửa nftables chặn đứng mọi luồng dữ liệu trần thoát ra giao diện vật lý:
# Chỉ cho phép gói tin UDP mã hóa gửi tới máy chủ đường hầm qua card vật lý
table inet vpn_filter {
chain output {
type filter hook output priority 0; policy drop;
# Cho phép luồng nội bộ loopback và giao diện đường hầm
oifname "lo" accept
oifname "rice0" accept
# Chỉ cho phép gói tin đường hầm tới đúng máy chủ qua giao diện vật lý
oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
}
}
Trên Windows, nền tảng lọc Windows Filtering Platform thực thi các trình điều khiển tại tầng truyền tải, loại bỏ gói tin không mã hóa trước khi chạm tới card mạng. Trên macOS, cơ chế neo bộ lọc gói tin pf đảm bảo không giao diện nào ngoài mạng ảo được phép truyền dữ liệu người dùng.
2. Tắt hoàn toàn tính năng chia sẻ mạng cục bộ trên Wi-Fi công cộng
Do tấn công LocalNet dựa trên ngoại lệ mạng nội bộ, ứng dụng bảo mật tiêu chuẩn chủ động khóa tính năng chia sẻ mạng cục bộ khi người dùng truy cập các mạng công cộng không đáng tin cậy. Khi tính năng này được tắt:
- Ứng dụng loại bỏ toàn bộ các tuyến mạng con liên kết trực tiếp.
- Mọi gói tin ngoài luồng loopback đều bị ép chuyển hướng qua đường hầm mã hóa.
- Kể cả khi trạm phát Wi-Fi quảng bá dải mạng con
/8bất thường, tường lửa vẫn ngăn chặn tuyệt đối việc chuyển phát dữ liệu trực tiếp.
3. Cách ly không gian tên mạng và ràng buộc giao diện SO_BINDTODEVICE
Trong môi trường Linux và Android, không gian tên mạng mang lại sự cách ly toàn diện. Bằng cách chuyển giao diện mạng vật lý sang một không gian tên riêng biệt và giữ các ứng dụng người dùng trong không gian tên chính nơi chỉ tồn tại giao diện mạng ảo, các tiến trình ứng dụng hoàn toàn không thể tiếp cận các tuyến đường vật lý ngoài Wi-Fi.
Đồng thời, các tiến trình có thể chủ động khóa socket mạng trực tiếp vào giao diện đường hầm thông qua tùy chọn SO_BINDTODEVICE:
// Ép buộc socket ứng dụng liên kết trực tiếp với giao diện đường hầm
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));
Khi socket được gắn chặt với một thiết bị mạng cụ thể, nhân hệ điều hành bỏ qua bảng định tuyến thông thường và chuyển thẳng dữ liệu vào giao diện được chỉ định.
Kiểm tra khả năng chống rò rỉ định tuyến trên thiết bị
Người dùng và chuyên gia quản trị mạng có thể chủ động rà soát cấu hình mạng của mình trước rủi ro TunnelCrack bằng các bước đơn giản:
- Rà soát bảng định tuyến hiện hành: Kiểm tra danh sách tuyến đường trước và sau khi bật kết nối bảo mật để bảo đảm không tồn tại tuyến phạm vi liên kết hoặc tuyến máy chủ
/32bất thường:ip route show table all - Thử nghiệm dải mạng con giả lập: Cấu hình một bộ định tuyến thử nghiệm phát dải mạng công cộng (chẳng hạn
198.51.100.0/24) qua DHCP cục bộ. Kết nối thiết bị, bật đường hầm và kiểm tra xem lưu lượng tới198.51.100.1có được đưa vào đường hầm hoặc bị chặn lại hay không. - Kích hoạt tùy chọn cách ly mạng cục bộ: Đảm bảo ứng dụng đang dùng có nút tắt chia sẻ mạng nội bộ khi hoạt động trên các trạm Wi-Fi ngoài quán cà phê, sân bay hoặc khách sạn.
Kiến trúc của VPNRice kết hợp giao thức RiceGuard và nhân đường hầm L3 hiện đại, thực thi cơ chế ràng buộc giao diện nghiêm ngặt cùng tường lửa tự động. Mọi ngoại lệ định tuyến không xác thực đều bị triệt tiêu, giữ cho dữ liệu người dùng luôn nằm trọn vẹn trong vùng bảo vệ mã hóa.
Để trang bị giải pháp bảo mật toàn diện cho máy tính xách tay, điện thoại di động và máy trạm làm việc, bạn có thể tải bản cài đặt cập nhật nhất tại trang Tải VPNRice.
