Khả năng rò rỉ lưu lượng DNS ra ngoài đường hầm VPN trên Android

 (mullvad.net)
2 điểm bởi GN⁺ 2024-05-04 | 1 bình luận | Chia sẻ qua WhatsApp

Lưu lượng DNS có thể rò rỉ ra ngoài đường hầm VPN trên Android

Xác nhận khả năng rò rỉ DNS theo nhiều kịch bản

  • Gần đây đã xác nhận khả năng rò rỉ DNS theo nhiều kịch bản trên Android
  • Lỗi này bắt nguồn từ một lỗi nội bộ của Android và chỉ ảnh hưởng tới một số ứng dụng nhất định
  • Ngày 22 tháng 4 (thứ hai), phát hiện việc rò rỉ DNS qua một báo cáo của người dùng Reddit
    • Người dùng nhận thấy truy vấn DNS bị rò rỉ khi tắt rồi bật lại VPN trong khi bật cài đặt "Chặn kết nối khi không có VPN" (Block connections without VPN)
  • Ngay sau đó đã bắt đầu điều tra nội bộ để xác minh vấn đề
  • Kết quả điều tra cho thấy còn tồn tại thêm nhiều kịch bản có thể gây rò rỉ DNS trên Android

Phát hiện

Các kịch bản có thể làm lưu lượng DNS rò rỉ trên Android:

  • Khi VPN được bật trong khi chưa cấu hình máy chủ DNS
  • Trong thời gian ngắn khi ứng dụng VPN tái cấu hình đường hầm hoặc bị buộc dừng/đổ vỡ

Dường như rò rỉ bị giới hạn ở cuộc gọi trực tiếp tới hàm C getaddrinfo:

  • Trong các kịch bản liệt kê ở trên, các ứng dụng dùng cách này để tra cứu tên miền sẽ gây rò rỉ
  • Không phát hiện rò rỉ ở các ứng dụng chỉ dùng Android API như DnsResolver
  • Trình duyệt Chrome là một ví dụ về ứng dụng có thể gọi trực tiếp getaddrinfo

Những nội dung trên áp dụng dù Always-on VPN và Block connections without VPN có được bật hay không:

  • Đây không phải hành vi dự kiến của hệ điều hành, nên cần được sửa ở upstream của OS

Đã xác nhận rò rỉ này trên nhiều phiên bản Android (kể cả Android 14 mới nhất)

Cải tiến

Hiện tại ứng dụng không cấu hình máy chủ DNS khi ở trạng thái chặn:

  • Nếu ứng dụng không thể thiết lập đường hầm theo cách không thể khôi phục, nó chuyển sang trạng thái chặn
  • Trong trạng thái này, lưu lượng sẽ không tiếp tục rời thiết bị
  • Tuy nhiên ở trạng thái này không có cấu hình máy chủ DNS nên có thể xảy ra rò rỉ DNS như đã mô tả ở trên
  • Trong thời gian tới sẽ thiết lập máy chủ DNS giả để khắc phục lỗi của hệ điều hành
  • Có thể mong đợi một bản phát hành có sửa lỗi này trong thời gian sớm

Giảm thiểu rò rỉ khi kết nối lại đường hầm trong ứng dụng còn khó hơn:

  • Vẫn đang tiếp tục tìm giải pháp
  • Việc giảm tần suất tái cấu hình đường hầm có thể giúp, nhưng hiện tại chưa nghĩ rằng có thể ngăn chặn hoàn toàn rò rỉ này

Cần làm rõ rằng không nên có ứng dụng VPN nào phải áp dụng bản vá như vậy:

  • Không sai khi ứng dụng dùng getaddrinfo để tra cứu tên miền
  • Thay vào đó, cần xử lý vấn đề này ở cấp hệ điều hành để bảo vệ mọi người dùng Android, bất kể ứng dụng nào họ dùng

Đã báo cáo sự cố cho Google và đề xuất cải tiến, mong sớm được khắc phục

Các bước tái hiện

Các bước dưới đây tái hiện kịch bản thứ hai, trong đó người dùng VPN thay đổi cấu hình đường hầm (ví dụ chuyển sang máy chủ khác hoặc thay đổi máy chủ DNS):

  • Sử dụng ứng dụng WireGuard vì đây là triển khai tham chiếu của Android VPN
  • Lưu ý rằng khả năng rò rỉ này có thể tái hiện được trên các ứng dụng VPN Android khác
  • Dùng Chrome để kích hoạt rò rỉ vì đây là một trong các ứng dụng đã xác nhận dùng getaddrinfo

  1. Tải spam_get_requests.html

  2. Cài đặt ứng dụng WireGuard và Chrome

  3. Nhập wg1.conf, wg2.conf vào WireGuard

  4. Kích hoạt tunnel wg1 trong ứng dụng WireGuard và cấp quyền VPN

  5. Trong cài đặt VPN Android, bật "Always-on VPN" và "Block connections without VPN" cho WireGuard

  6. Trên router, bắt đầu capture dữ liệu bằng tcpdump $ tcpdump -i <INTERFACE> host <IP of android device>

  7. Chia màn hình để WireGuard và Chrome xuất hiện cùng lúc

  8. Mở spam_get_requests.html trên Chrome và bấm "Start"

  9. Trong ứng dụng WireGuard chuyển giữa wg1 và wg2 cho đến khi nhìn thấy rò rỉ ở bước tiếp theo

  10. Trên router quan sát lưu lượng DNS sau:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 
11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 
11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

Mặc dù tùy chọn "Block connections without VPN" được bật nên trừ lưu lượng WireGuard đã mã hóa thì không có gì khác nên thoát khỏi thiết bị, ở đây vẫn thấy DNS dạng plaintext đi ra khỏi thiết bị

Kết luận và khuyến nghị

Rò rỉ DNS có thể ảnh hưởng nghiêm trọng đến quyền riêng tư người dùng và có thể được dùng để ước tính vị trí xấp xỉ của người dùng, cũng như xác định các website và dịch vụ họ truy cập

Phát hiện này một lần nữa cho thấy tên gọi (hoặc tài liệu mô tả) "Block connections without VPN" không đúng và cho thấy còn nhiều nhược điểm:

  • Ứng dụng vẫn có thể rò rỉ lưu lượng DNS trong các điều kiện được nêu ở trên
  • Như đã được báo cáo trước đây, vẫn còn rò rỉ lưu lượng kiểm tra kết nối

Tùy theo mô hình đe dọa, có thể cần tránh dùng Android cho các tác vụ nhạy cảm hoặc áp dụng biện pháp giảm nhẹ khác để ngăn rò rỉ:

  • Vì mục tiêu là giảm thiểu một phần sự cố này ở cấp ứng dụng, vì vậy hãy giữ ứng dụng luôn được cập nhật

Ý kiến GN⁺

  • Về bản chất đây là lỗi của Android OS nên Google nên sớm sửa; không phù hợp khi các nhà phát triển ứng dụng cung cấp VPN đều cùng cố gắng sửa lỗi này
  • Tùy chọn "Block connections without VPN" không hoạt động như mô tả tài liệu và việc DNS bị rò rỉ là vấn đề lớn với người dùng. Một trong những lý do chính để dùng VPN là bảo vệ riêng tư, vì rò rỉ DNS có thể làm lộ lịch sử duyệt web của người dùng
  • Có thể xem rằng kỹ thuật tunnel VPN vẫn có mức bảo mật cao, nhưng để ngăn chặn rò rỉ không mong muốn do OS gây ra thì việc dùng thêm giải pháp bảo mật/riêng tư ngoài VPN cũng đáng cân nhắc
  • Ở góc độ nhà phát triển ứng dụng, họ đang bổ sung xử lý tạm thời để tránh lỗi OS, nhưng về lâu dài có vẻ cần cải thiện OS để giải quyết tận gốc
  • Khi công nghệ VPN ngày càng trưởng thành và phổ biến, các rủi ro bảo mật kiểu này lại nổi lên. Dù thế nào, vẫn cần kiểm toán bảo mật và cải tiến liên tục cho mạng và chức năng VPN của hệ điều hành di động

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-04
Ý kiến Hacker News
  • Mullvad được ca ngợi đã cung cấp thông tin đầy đủ và giải thích rõ vấn đề, các giải pháp tạm thời, giải pháp tiềm năng cùng những điểm cần được sửa trong Android.
  • Theo ý kiến nhà phát triển của rethinkdns, "paranoid networking" của Android có các ngoại lệ cho ứng dụng hệ thống và OEM, và phần lớn bản vá sẽ không sửa đổi giả định cốt lõi này.
  • Android hỗ trợ "chuyển tiếp mượt mà" giữa hai thiết bị TUN, nhưng việc triển khai lại rất khó.
  • Vấn đề Android chuyển sang dữ liệu di động và dùng DNS bên ngoài mặc dù cố gắng chỉ sử dụng DNS nội bộ đã tồn tại từ lâu.
  • Với Apple, mặc định VPN "privacy" cố gắng proxy mọi thứ, nên khi dùng sản phẩm đối thủ khả năng tốt hơn nhiều khả năng cũng không xảy ra.
  • Trên Android không thể đặt máy chủ DNS IPv6 trực tiếp, và chúng thay đổi mỗi khi có biến động về Wi-Fi.
  • Có thể ngăn rò rỉ lưu lượng bằng cách dùng thiết bị tường lửa MikroTik để chặn toàn bộ lưu lượng không hướng đến địa chỉ IP của máy chủ VPN.
  • Mọi hệ thống không có quyền root đều về bản chất không an toàn, và Android với iOS thì thật đáng cười.
  • Thiết lập an toàn nhất là tắt dữ liệu di động trên điện thoại và dùng hotspot OpenWRT để thực hiện VPN ở phía upstream.
  • Rò rỉ DNS có thể lộ vị trí duyệt web của người dùng và thậm chí cả vị trí thực, khiến mục tiêu của VPN bị vô hiệu hóa.
  • Ngay cả trên iOS, lưu lượng APNS cũng bị rò rỉ ra ngoài VPN (trừ VPN hỗ trợ hệ điều hành cài đặt qua provisioning profile).
  • Người ta tự hỏi liệu những "lỗi" như vậy có được bố trí có chủ đích hay không; khi xét đến việc các tập đoàn công nghệ lớn hợp tác với cơ quan tình báo, khó tin rằng nhiều lỗi của Android tồn tại một cách "ngẫu nhiên".