Lỗ hổng Android 16: Ứng dụng thường có thể rò rỉ lưu lượng ra ngoài VPN dù đã bật chế độ chặn kết nối

Một nghiên cứu bảo mật mới đã phát hiện ra một lỗ hổng nghiêm trọng trên hệ điều hành Android: các ứng dụng thông thường có thể khiến thiết bị gửi gói tin ra mạng vật lý bên ngoài đường hầm VPN, ngay cả khi người dùng đã bật Always-on VPN và tùy chọn "Chặn kết nối không dùng VPN" (Block connections without VPN). Đây là những cài đặt mà người dùng và quản trị viên hệ thống tin tưởng sẽ bảo vệ danh tính mạng thực của thiết bị.

Lỗ hổng nằm ở đâu?

Vấn đề nằm trong API NAT-T socket keepalive — cơ chế Android dùng để duy trì kết nối NAT trong các phiên IPsec. Cụ thể, ứng dụng thông thường có thể sử dụng API công khai IpSecManager.UdpEncapsulationSocket kết hợp với ConnectivityManager.createSocketKeepalive(...) để yêu cầu hệ thống duy trì một ánh xạ NAT.

Điểm mấu chốt là framework Android chuyển yêu cầu này qua hàm startNattKeepaliveWithFd(...) mà không xác minh quyền sở hữu tài nguyên IpSec của bên gọi, đồng thời không kiểm tra chính sách VPN lockdown hiện hành trước khi chuyển gói tin cho tầng Wi-Fi offload. Kết quả là các gói tin UDP/4500 vẫn được phát ra mạng vật lý dù ứng dụng đã bị chặn bởi VPN.

Lỗ hổng phá vỡ cam kết "fail closed" của chế độ lockdown: lẽ ra lưu lượng thuộc ứng dụng được bảo vệ phải bị chặn hoàn toàn khi VPN không khả dụng, thay vì để lộ danh tính mạng thực.

Bằng chứng thực tế từ ba hãng thiết bị

Nhóm nghiên cứu đã xác nhận lỗ hổng trên ba thiết bị từ ba nhà sản xuất khác nhau:

• Google Pixel 8 Pro (Android 16, chip Broadcom): gói tin UDP/4500 được ghi lại trên điểm truy cập Wi-Fi vật lý với chu kỳ tối thiểu 10 giây, trong khi Always-on VPN và lockdown đều đang bật.
• Samsung SM-F966B (Android 16, chip Qualcomm): duy trì một slot Wi-Fi vật lý hoạt động liên tục trong 24 giờ 32 phút, hướng thẳng tới cổng mặc định của router.
• Nothing A059 (Android 16, chip Qualcomm): xác nhận đường dẫn công khai được chấp nhận và callback hoạt động trên hãng thứ ba.

Đáng chú ý, kẻ tấn công chỉ cần một ứng dụng thông thường với quyền INTERNET và ACCESS_NETWORK_STATE. Không cần root, ADB, API ẩn, JNI hay quyền đặc biệt PACKET_KEEPALIVE_OFFLOAD.

Nguyên nhân gốc: mô hình tin cậy bị thu gọn

Lịch sử mã nguồn AOSP cho thấy vấn đề bắt nguồn từ việc hai mô hình tin cậy bị gộp chung. API NAT-T keepalive ban đầu chỉ dành cho tiến trình đặc quyền với fd thô. Đến năm 2019, khi API công khai UdpEncapsulationSocket được định tuyến qua cùng phương thức Binder này, việc kiểm tra quyền vô điều kiện đã bị gỡ bỏ.

Một lớp xác thực tài nguyên IpSec từng được thêm vào tháng 4/2019 nhưng bị hoàn tác chỉ một tháng sau đó vì lo ngại về phụ thuộc dịch vụ và deadlock. Thay vào đó, hệ thống dùng hạn ngạch theo UID và theo mạng — nhưng hạn ngạch chỉ giới hạn việc tiêu hao tài nguyên, không xác thực cặp fd/tài nguyên cũng như không thực thi chính sách VPN.

Phạm vi ảnh hưởng

Theo phân tích, đường dẫn admission bị lỗi là hành vi framework dùng chung từ Android 12 trở lên. Bảy dòng chip Wi-Fi Android phổ biến — Qualcomm, Broadcom/Cypress, MediaTek, Unisoc, Samsung Exynos và Huawei HiSilicon — đều có bề mặt hỗ trợ keepalive hoặc offload. Các dòng chip này chiếm khoảng 91,24% lượng thiết bị Android xuất xưởng từ quý 4/2021 đến quý 1/2026.

Nghiên cứu cũng khảo sát 4.679 kho mã nguồn trên F-Droid và IzzyOnDroid nhưng không tìm thấy ứng dụng nào sử dụng API framework IPsec/IKE/NAT-T — cho thấy nhu cầu tương thích thực tế rất thấp so với mức độ rủi ro.

Tác động và cách khắc phục

Giá trị tấn công chính là tiết lộ danh tính mạng thực của thiết bị. Kẻ tấn công kiểm soát điểm cuối UDP/4500 có thể biết địa chỉ IP thực (suy ra nhà mạng, tổ chức, vị trí địa lý), trạng thái online của thiết bị và nhịp thời gian gửi gói. Dù không truyền được nội dung tùy ý, tín hiệu định kỳ này vẫn đủ để thực hiện kiểm tra hiện diện và tương quan hóa dữ liệu.

Về khắc phục, nhóm nghiên cứu khuyến nghị platform cần:

• Xác thực cặp fd/tài nguyên IpSec trước khi chấp nhận yêu cầu keepalive
• Kiểm tra chính sách VPN/lockdown hiệu lực của UID gọi trước khi offload ra mạng vật lý
• Thu hồi hoặc xác thực lại bản ghi NAT-T đang hoạt động khi cấu hình VPN thay đổi
• Bổ sung bộ kiểm thử hồi quy cho các trường hợp tài nguyên giả, trùng lặp hoặc của UID khác

Tiết lộ có trách nhiệm

Lỗ hổng được báo cáo cho Android Vulnerability Reward Program ngày 15/05/2026. Google đã phân loại báo cáo trong cùng ngày và đánh dấu trùng với vấn đề chính thức số 386376240 vào ngày 19/05/2026. Tuy nhiên, theo ghi nhận của nhà nghiên cứu, hồ sơ VRP không có phản hồi phản đối, yêu cầu trì hoãn, phân công CVE hay quyết định thưởng nào. Công bố công khai bắt đầu từ ngày 29/07/2026.

Đối với người dùng Việt Nam đang sử dụng VPN để bảo vệ quyền riêng tư, đây là lời nhắc nhở rằng không nên tin tưởng tuyệt đối vào một lớp bảo vệ duy nhất. Việc kết hợp thêm các biện pháp như kiểm tra rò rỉ IP định kỳ, sử dụng ứng dụng VPN uy tín và cập nhật bản vá Android ngay khi có thể là cần thiết cho đến khi Google phát hành bản sửa lỗi chính thức.