Phát hiện rò rỉ IP qua WebRTC: từ lỗi thành tính năng

WebRTC — Web Real-Time Communication — được thiết kế để cho phép gọi video, chia sẻ tệp và truyền dữ liệu ngang hàng (peer-to-peer) trực tiếp trong trình duyệt. Để thiết lập các kết nối này, trình duyệt cần khám phá các giao diện mạng của chính nó và đàm phán khả năng kết nối với các peer từ xa. Quá trình này liên quan đến các server STUN (Session Traversal Utilities for NAT) và TURN (Traversal Using Relays around NAT), giúp trình duyệt khám phá địa chỉ IP công khai của mình và vượt qua tường lửa NAT.

Tác dụng phụ rất mạnh: ngay cả khi người dùng kết nối qua VPN, stack WebRTC của trình duyệt vẫn có thể làm lộ địa chỉ IP thật đằng sau đường hầm. Điều này xảy ra vì các candidate ICE (Interactive Connectivity Establishment) của WebRTC bao gồm địa chỉ của các giao diện mạng cục bộ mà VPN không che giấu.

Cơ chế rò rỉ hoạt động thế nào

Khi trình duyệt tạo một RTCPeerConnection và thu thập các candidate ICE, nó truy vấn các server STUN để khám phá IP công khai của mình. Nhưng nó cũng liệt kê các giao diện mạng cục bộ — bao gồm cả IP riêng (private) của bộ chuyển đổi mạng vật lý. Nếu VPN chỉ tạo đường hầm cho lưu lượng ở tầng IP mà không cấu hình stack WebRTC của trình duyệt để dùng riêng giao diện đường hầm, thì IP thật sẽ lọt ra ngoài qua host candidate.

Tại tracio.ai, chúng tôi dò hành vi này một cách cẩn trọng. Hệ thống IP Intelligence của chúng tôi tạo một yêu cầu STUN có kiểm soát và phân tích các candidate ICE mà trình duyệt trả về. Khi IP công khai từ STUN khác với IP mà chúng tôi nhìn thấy tại server, chúng tôi đánh dấu là có VPN hoặc proxy. Khi IP giao diện cục bộ để lộ một dải mạng riêng mâu thuẫn với vị trí địa lý được cho là đúng, chúng tôi tăng điểm nghi ngờ.

Từ lỗi thành tín hiệu phát hiện

Hầu hết các trình duyệt chú trọng quyền riêng tư đã vá lỗ hổng này — Chrome yêu cầu người dùng cấp quyền rõ ràng cho WebRTC, và Firefox cung cấp tùy chọn để tắt UDP không đi qua proxy. Nhưng cuộc chạy đua vũ trang vẫn tiếp diễn: một số client VPN không cấu hình WebRTC đúng cách, các phiên bản trình duyệt cũ vẫn dễ bị tổn thương, và bản thân mẫu hành vi giữa một phản hồi WebRTC "đã vá" và "đang rò rỉ" cũng là một tín hiệu hữu ích.

Cách tiếp cận của chúng tôi coi phản hồi WebRTC như một tín hiệu tổng hợp: sự hiện diện của host candidate, số lượng candidate ICE trả về, các loại candidate (host, srflx, relay), và thời gian phản hồi đều góp phần vào fingerprint của thiết bị. Ngay cả khi không có IP nào bị rò rỉ, mẫu hành vi của WebRTC vẫn mang tính đặc trưng.

Dò server TURN

Ngoài STUN, chúng tôi còn dò hành vi của server TURN. Các relay TURN thường được dùng khi kết nối ngang hàng trực tiếp thất bại — điều phổ biến trong các mạng doanh nghiệp nằm sau tường lửa nghiêm ngặt. Phản hồi cấp phát TURN để lộ thông tin về đường relay: giao thức truyền tải (UDP so với TCP so với TLS), địa chỉ relay, và thời gian tồn tại của phần cấp phát.

Hệ thống SignalProbe của chúng tôi gửi các yêu cầu cấp phát TURN được dựng cẩn thận đến các server relay của chính chúng tôi. Thời gian phản hồi, các giao thức truyền tải được hỗ trợ, và các mẫu thành công/thất bại của việc cấp phát thay đổi theo môi trường mạng và cung cấp thêm sự đa dạng tín hiệu cho fingerprint thiết bị.

Cân nhắc về quyền riêng tư

Chúng tôi muốn nói rõ: tracio.ai không khai thác các rò rỉ WebRTC để phi ẩn danh (deanonymize) người dùng. Hệ thống của chúng tôi phát hiện khi có VPN đang được dùng và báo cáo điều này như một tín hiệu rủi ro. Chúng tôi không bao giờ lưu trữ hay để lộ địa chỉ IP bị rò rỉ. Tín hiệu này là nhị phân: "Phát hiện VPN kèm bất nhất WebRTC" hoặc "Hành vi WebRTC nhất quán với kết nối trực tiếp".

Cách tiếp cận này cung cấp cho các đội ngũ phòng chống gian lận thông tin họ cần — rằng một khách truy cập đang che giấu vị trí thật của mình — mà không xâm phạm quyền riêng tư của từng cá nhân. Tín hiệu này giúp phát hiện các cuộc tấn công gian lận có phối hợp, nơi nhiều tài khoản cùng bắt nguồn từ một vị trí ẩn giấu.