- Trong một số tổ hợp ứng dụng và trạng thái trên Android, truy vấn DNS có thể đi ra ngoài đường hầm VPN; Mullvad cho rằng nguyên nhân là lỗi của Android OS hơn là của ứng dụng VPN
- Rò rỉ có thể xảy ra trong các khoảng chuyển tiếp ngắn như khi VPN đã bật nhưng máy chủ DNS đang trống, khi tái cấu hình đường hầm, hoặc khi ứng dụng VPN bị buộc dừng/bị crash
- Ảnh hưởng tập trung vào các ứng dụng gọi trực tiếp
getaddrinfo; không phát hiện rò rỉ ở các ứng dụng chỉ dùng Android API DnsResolver - Ngay cả khi bật Always-on VPN và “Block connections without VPN”, vấn đề vẫn không được ngăn chặn hoàn toàn; đã xác nhận trên nhiều phiên bản, bao gồm Android 14
- Mullvad dự định tạm thời thiết lập máy chủ DNS giả để giảm nhẹ một số tình huống, nhưng rò rỉ trong lúc kết nối lại khó có thể chặn hoàn toàn nếu không có bản sửa ở OS
Điều kiện gây rò rỉ DNS trên Android
- Ngày 22/4, thông qua báo cáo của một người dùng Reddit, Mullvad xác nhận rằng rò rỉ DNS có thể xảy ra khi tắt rồi bật lại VPN trong lúc “Block connections without VPN” đang được bật
- Cuộc điều tra nội bộ cho thấy thêm các kịch bản mà Android OS có thể gửi lưu lượng DNS ra ngoài VPN
- VPN đang hoạt động nhưng chưa cấu hình máy chủ DNS
- Trong khi ứng dụng VPN đang tái cấu hình đường hầm
- Trong khoảng thời gian ngắn khi ứng dụng VPN bị buộc dừng hoặc bị crash
- Hành vi này không phải là hành vi mong đợi của Android OS và cần được sửa ở cấp OS cao hơn
Ứng dụng bị ảnh hưởng và đường dẫn phân giải tên
- Rò rỉ dường như xảy ra ở các ứng dụng gọi trực tiếp hàm C
getaddrinfođể phân giải tên miền - Không phát hiện rò rỉ ở các ứng dụng chỉ sử dụng Android API DnsResolver
- Trình duyệt Chrome là một ví dụ về ứng dụng có thể dùng trực tiếp
getaddrinfo- Vị trí mã Chromium liên quan cũng đã được công khai
- Bản thân việc dùng
getaddrinfokhông phải là sai; để bảo vệ mọi người dùng Android, cần có giải pháp ở cấp OS
Giới hạn của Always-on VPN và thiết lập chặn
- Các rò rỉ đã xác nhận xảy ra bất kể Always-on VPN và “Block connections without VPN” có được bật hay không
- Khi “Block connections without VPN” được bật, ngoài lưu lượng WireGuard đã mã hóa thì không có gì được phép đi ra khỏi thiết bị, nhưng trong quá trình tái hiện, DNS dạng plaintext đã được quan sát thấy tại router
- Mullvad đánh giá rằng thiết lập này không đáp ứng đúng tên gọi hoặc hành vi đã được tài liệu hóa, và có nhiều khiếm khuyết
- Lưu lượng DNS có thể bị rò rỉ trong các điều kiện trên
- Như đã báo cáo trước đó, lưu lượng kiểm tra kết nối vẫn tiếp tục bị rò rỉ
Biện pháp giảm nhẹ tạm thời của ứng dụng Mullvad và vấn đề còn lại
- Ứng dụng Mullvad hiện không thiết lập máy chủ DNS trong trạng thái chặn
- Nếu việc thiết lập đường hầm thất bại theo cách không thể khôi phục, ứng dụng sẽ chuyển sang trạng thái chặn
- Ở trạng thái này, ứng dụng ngăn lưu lượng đi ra khỏi thiết bị, nhưng vì máy chủ DNS trống nên có thể tạo điều kiện rò rỉ
- Để обход lỗi OS, Mullvad dự định tạm thời ứng phó bằng cách thiết lập máy chủ DNS giả, và có kế hoạch sớm cung cấp bản phát hành có kèm bản sửa này
- Rò rỉ xảy ra trong lúc kết nối lại đường hầm khó được giảm nhẹ hơn ở phía ứng dụng
- Mullvad đang tìm giải pháp
- Có khả năng giảm số lần tái cấu hình đường hầm, nhưng hiện tại họ không cho rằng có thể chặn hoàn toàn rò rỉ này
- Mullvad đã báo cáo vấn đề và đề xuất cải tiến cho Google
Quan sát tái hiện bằng WireGuard và Chrome
- Kịch bản thứ hai, rò rỉ trong lúc thay đổi cấu hình đường hầm VPN, có thể được tái hiện bằng ứng dụng WireGuard và Chrome
- WireGuard được dùng như trường hợp chuẩn cho triển khai VPN trên Android
- Mullvad cho rằng khả năng cao cũng có thể tái hiện trên các ứng dụng VPN Android khác
- Chrome được dùng để kích hoạt rò rỉ vì đã xác nhận ứng dụng này dùng
getaddrinfo
- Quy trình tái hiện bao gồm các yếu tố sau
- Tải xuống spam_get_requests.html
- Cài đặt ứng dụng WireGuard và Chrome
- Nhập wg1.conf, wg2.conf vào WireGuard
- Kích hoạt đường hầm wg1 trong WireGuard và cho phép quyền VPN
- Trong cài đặt VPN của Android, bật Always-on VPN và “Block connections without VPN” cho WireGuard
- Trên router, bắt đầu capture bằng
tcpdump -i <INTERFACE> host <IP of android device> - Mở WireGuard và Chrome ở chế độ chia đôi màn hình, chạy
spam_get_requests.htmltrong Chrome, rồi chuyển qua lại giữa wg1 và wg2 trong WireGuard
- Trên router, quan sát thấy truy vấn bản ghi A từ thiết bị Android đến cổng 53 của router OpenWrt và phản hồi NXDomain
- Rò rỉ DNS có thể được dùng để xác định vị trí tương đối của người dùng hoặc website/dịch vụ họ truy cập, nên có thể có tác động lớn đến quyền riêng tư
- Tùy theo mô hình đe dọa, với các mục đích nhạy cảm, người dùng có thể cần tránh dùng Android hoặc áp dụng các biện pháp giảm nhẹ khác để ngăn rò rỉ
- Người dùng ứng dụng Mullvad nên duy trì ứng dụng ở phiên bản mới nhất vì có thể có biện pháp giảm nhẹ một phần
1 bình luận
Ý kiến trên Hacker News
Tôi không dùng Mullvad nhưng thực sự càng thêm tôn trọng họ. Phần giải thích vấn đề, cách lách tạm thời trong ngắn hạn, các cách lách tiềm năng mà người khác có thể dùng, cho tới cả những phần cần được sửa ở Android đều có mật độ thông tin cao và được sắp xếp rất tốt
Điểm trừ là trong trường hợp của tôi, thời gian ping khá cao hơn so với quad9 hay cloudflare
Tôi đã ghi thông tin về cách chặn quảng cáo ở mức DNS và thông tin liên quan đến cloudflare trong thread này: https://news.ycombinator.com/item?id=40056162
Họ giải quyết nhanh chuyện thanh toán, và cả về iptables tôi cũng nhận được câu trả lời chi tiết, bao gồm ưu và nhược điểm của nhiều cách xử lý. Nói ngắn gọn là tuyệt vời
Tôi là nhà phát triển của rethinkdns
Về câu “để bảo vệ mọi người dùng Android bất kể họ dùng ứng dụng nào thì các vấn đề này phải được giải quyết ở cấp OS”, thì kiến trúc mạng mang tính hoang tưởng của Android từ trước tới nay vẫn luôn có ngoại lệ cho ứng dụng hệ thống và ứng dụng OEM, tức cả ứng dụng của Google
Phần lớn các bản sửa lỗi kiểu này có lẽ cũng sẽ không thể thay đổi giả định cốt lõi đó. Tham khảo mã liên quan tại đây: https://github.com/celzero/rethink-app/issues/224
Về đoạn “rò rỉ trong lúc đường hầm kết nối lại thì ứng dụng khó giảm thiểu hơn. Chúng tôi vẫn đang tìm giải pháp”, Android có hỗ trợ chuyển đổi liền mạch giữa hai thiết bị TUN trong lúc tái cấu hình. Triển khai cho đúng thì khá khó, nhưng là khả thi
Đây là vấn đề đã tồn tại từ lâu trên Android. Ngay cả khi bạn chỉ muốn dùng DNS nội bộ, Android vẫn sẽ chuyển sang di động và dùng DNS đó nếu nó cho là cần hoặc muốn
Gần đây tôi theo dõi adb debug để xem vì sao/khi nào kết nối không dây bị ngắt, và cuối cùng phát hiện rằng nếu trong quá trình kiểm tra khả năng sống còn nó không nhìn thấy hoặc không diễn giải được điều gì đó, nó sẽ bật dữ liệu di động để thử
Điều đặc biệt khó chịu là khi dùng các bản ghi DNS chỉ tồn tại nội bộ, điện thoại lại hoạt động một cách thất thường. Thiết bị đang kết nối vào Wi‑Fi cung cấp máy chủ DNS nội bộ có chứa bản ghi đó, vậy mà vì một lý do nào đó của Android, nó lại đi phân giải từ bên ngoài
Tôi không biết phía Apple thế nào, nhưng nhìn vào việc mặc định họ muốn proxy cả DNS qua DoH bằng VPN “privacy” của riêng họ, tôi khó mà tưởng tượng mọi thứ sẽ tốt hơn khi dùng thứ gì đó có thể xem là sản phẩm cạnh tranh, và chúng ta cũng biết Apple đối xử với những sản phẩm như vậy ra sao
Một ví dụ thực tế là trình chặn quảng cáo toàn hệ thống này: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
Vấn đề duy nhất tôi gặp là thiết bị hiển thị không có Internet dù đang kết nối với một AP không dây hoạt động bình thường. Thực tế mọi thứ vẫn chạy, nhưng có vẻ vì mục đích của biểu tượng trên thanh trạng thái và các đoạn mã hệ thống nội bộ khác, nó dùng máy chủ Google để kiểm tra Internet có hoạt động hay không
Nếu coi trọng quyền riêng tư thì nên tránh xa Android, và có lẽ cũng nên cẩn trọng với công nghệ nói chung
Vài năm trước khi tôi thử nhiều cấu hình VPN cho một dự án, tôi thường đặt thiết bị tường lửa MikroTik giữa máy tính và router chính. Mục tiêu chỉ là chặn mọi lưu lượng không có đích là địa chỉ IP máy chủ VPN mà PC đang cố kết nối tới
Cách này hoạt động rất tốt để bảo đảm lưu lượng không rò rỉ ra ngoài đường đi từ PC tới máy chủ VPN. Địa chỉ IP máy chủ VPN đang dùng hầu như không thay đổi, và nếu có đổi thì cũng dễ sửa trên tường lửa MikroTik
Nếu bạn không biết IP máy chủ hoặc nó thay đổi, cũng có thể chặn mọi lưu lượng không thuộc cặp cổng/giao thức mà máy chủ VPN dùng. Ví dụ, tùy loại VPN mà loại bỏ mọi lưu lượng không có đích là UDP 1194
Router MikroTik còn có một công cụ nhỏ tên là torch để xem lưu lượng nhanh và dễ, đồng thời cũng hỗ trợ bắt gói. Giá dao động từ 30 đến 3000 USD, không có giấy phép phần mềm, và nếu biết cách dùng thì cực kỳ mạnh mẽ và hiệu quả
Nói chính xác thì slug thật là một tường lửa lớp 2 trong suốt không có địa chỉ IP được định nghĩa, nhưng ở đây không cần quá câu nệ chi tiết đó
https://john.kozubik.com/pub/NetworkSlug/tip.html
Lọc lưu lượng đi ra dựa trên địa chỉ/port nguồn và đích là khái niệm cơ bản của tường lửa và là cấu hình tiêu chuẩn của mọi nền tảng tường lửa-định tuyến. Định tuyến dựa trên chính sách lọc theo gateway cũng cùng một mạch như vậy: https://en.wikipedia.org/wiki/Policy-based_routing
Thông thường, chỉ các sản phẩm dành cho người tiêu dùng hoặc bán chuyên mới mặc định cho phép toàn bộ lưu lượng đi ra. Trong cấu hình này, không rõ “router chính” là gì. Có phải thiết bị do ISP cung cấp không?
Sẽ tốt hơn nếu bọn tôi cũng có thể chèn một tường lửa vào giữa ứng dụng điện thoại và modem
Vấn đề DNS trên Android nằm ở chỗ nền tảng này không cho tự đặt máy chủ DNS IPv6. Nó sẽ thay đổi mỗi khi có biến động gì đó trên Wi-Fi
Ngay cả trên Android đã root cũng không có ứng dụng nào ngăn hệ điều hành thay đổi nó
Nếu bạn dùng router luôn phát địa chỉ IPv6 mà không thể tắt đi, thì coi như bị kẹt
Tôi cũng không rõ liệu có thể đặt một thiết bị tường lửa sau router đó để loại bỏ máy chủ DNS IPv6 mà router đang quảng bá hay không
Nếu đã lo chuyện rò rỉ truy vấn DNS thì đằng nào bạn cũng nên dùng DoT hoặc DoH
Không biết khi phát Wi-Fi tethering thì có y hệt không. Nếu dùng VPN trên laptop kết nối qua Wi-Fi của điện thoại thì có bị rò theo cách tương tự không?
Có vẻ cấu hình an toàn nhất là tắt dữ liệu di động trên điện thoại và mang theo một điểm phát OpenWRT xử lý VPN ở lớp trên điện thoại
“VPN luôn bật” chỉ có thể cấu hình trên thiết bị ở trạng thái “supervised” thông qua giải pháp MDM của tổ chức đã được Apple phê duyệt. Cần nộp hồ sơ được ghi nhận và gọi điện với nhân viên hiện tại
Hoặc bạn chỉ có thể dùng ứng dụng Apple Configurator trên Mac để tạo hồ sơ cấu hình có khóa “always-on VPN”
Thông báo cũng thường bị trễ
Nếu không phải mạng của mình, tốt hơn là đừng kết nối trực tiếp nếu không có router di động
The Grugq đã làm một công cụ cho mục đích này từ 10 năm trước. Giờ tiếc là không còn được duy trì: https://github.com/grugq/portal
Nó là một phần của bài thuyết trình về an ninh tác chiến dành cho hacker, và đáng xem nếu bạn quan tâm đến những trường hợp nhiều hacker nổi tiếng hoặc tai tiếng từng nghĩ mình an toàn nhưng rồi vẫn bị bắt: https://www.youtube.com/watch?v=9XaYdCdwiWU
Hệ thống không có quyền truy cập root thì theo định nghĩa là không an toàn. Android và iOS thì buồn cười đến mức lố bịch
Thật đáng buồn cho những đứa trẻ đã lớn lên hoặc sẽ lớn lên chỉ với những thiết bị “máy tính” được thiết kế chủ yếu để tiêu thụ nội dung và thu thập dữ liệu riêng tư
https://en.wikipedia.org/wiki/PinePhone_Pro
Nếu bạn lấy được bản sao khóa riêng SSH của tôi trên những thiết bị đó, tôi sẽ trả ngay 100.000 USD tiền mặt, không hỏi han gì
Định nghĩa đó vô nghĩa và chẳng hữu ích gì cho suy luận hay giao tiếp
“Chặn kết nối nếu không có VPN” đang tỏ ra đáng tin chẳng hơn gì sự tự chủ của tôi ở quầy buffet. Nếu tôi không nhầm thì kiểu rò rỉ DNS này có thể để lộ khá nhiều, từ các trang đã truy cập đến cả vị trí, qua đó phá hỏng chính mục đích của VPN
Android có thể vẫn làm lộ thông tin DNS dù đã bật VPN, nên nếu bạn thực sự nhạy cảm về quyền riêng tư thì tốt hơn nên nghĩ xa hơn cả việc dùng Android, hoặc chuyển các tác vụ nhạy cảm ra khỏi điện thoại
Thỉnh thoảng tôi lại nghi những “lỗi” kiểu này có phải được cài vào rất có chủ ý hay không. Nhất là khi các công ty công nghệ lớn đã nhiều lần hợp tác với các cơ quan tình báo khác nhau
Đây cũng không phải lần đầu tôi nghe về loại lỗi này trên Android, nên giờ thật khó tin rằng ngần ấy lỗi lại đều lọt vào một cách “vô tình”
Từ lâu tôi đã phần nào nghi là như vậy. Trên Android, ngay cả khi bật VPN thì MMS và Visual Voicemail vẫn hoạt động
Cả hai đều có lúc cần hoặc từ chối truy cập di động trực tiếp. Có khi chúng chỉ hoạt động trong mạng di động, hoặc sẽ từ chối nếu yêu cầu không đến từ bên trong mạng di động. Tôi nghi VoLTE cũng vậy. Khi có VPN thì các tính năng kiểu này có thể bị rối
Trên Mobile Linux thì chỉ cần bật VPN là toàn bộ các tính năng đó hỏng hết, nên tôi mới nhận ra
Có vẻ không có cách rõ ràng nào để sửa việc này trên Android mà không phá vỡ quá nhiều tính năng vốn được mong đợi
Tôi từng phải vật lộn với AT&T Advanced Support Team vì vấn đề VVS trên iOS khi bật VPN, nên có thể xác nhận rằng vấn đề này không chỉ giới hạn ở Android
Các bearer khác nhau có thể có mức ưu tiên/QCI khác nhau, tức là chất lượng dịch vụ khác nhau. Trên mạng LTE bị tắc nghẽn, VoLTE lẽ ra phải mang lại trải nghiệm tốt hơn VOIP trên bearer ưu tiên thấp hơn