Công bố kỹ thuật theo dõi web-ứng dụng bí mật trên Android bằng Localhost
(localmess.github.io)- Đã bị phanh phui rằng các ứng dụng lớn như Meta (Facebook), Yandex đã sử dụng cổng cục bộ (127.0.0.1) trên Android để bí mật chia sẻ định danh và cookie giữa trình duyệt web và ứng dụng native
- Các script Facebook Pixel, Yandex Metrica được nhúng trong website đã trực tiếp truyền phiên duyệt web và định danh từ trình duyệt Android sang ứng dụng native (Facebook, Instagram, các ứng dụng thuộc hệ Yandex), khiến việc nhận diện người dùng và khử ẩn danh trở nên khả thi
- Cách làm này vượt qua toàn bộ các biện pháp bảo vệ quyền riêng tư hiện có như xóa cookie, chế độ ẩn danh, thiết lập quyền, đặt lại ID quảng cáo, và nếu ứng dụng độc hại chỉ cần lắng nghe đúng cổng thì còn có thể thu thập lịch sử truy cập trình duyệt
- Sau khi được công bố ngày 3/6/2025, phía Facebook đã gỡ bỏ phần lớn đoạn mã liên quan, nhưng kỹ thuật này đã được sử dụng trong nhiều năm trên hàng trăm triệu thiết bị Android trên toàn thế giới. Yandex vẫn liên tục dùng phương thức tương tự từ năm 2017
- Các trình duyệt lớn như Chrome, Firefox, Brave đã đưa vào biện pháp chặn khẩn cấp, nhưng do giới hạn mang tính cấu trúc của nền tảng nên vẫn thiếu giải pháp gốc rễ hoàn chỉnh, làm nổi bật nhu cầu tăng cường bảo mật Android IPC và mạng cục bộ
Disclosure: Kỹ thuật theo dõi web-ứng dụng bí mật thông qua Localhost
- Nhóm nghiên cứu phát hiện Meta và Yandex đã nhắm tới hàng tỷ người dùng Android, bằng cách để ứng dụng native mở sẵn các cổng cục bộ cố định (ví dụ: 12580~12585, 29009~30103) trong nền và giao tiếp với JavaScript chạy trên web
- Nhờ vậy, cookie, metadata và lịch sử sử dụng từ trình duyệt web được truyền sang ứng dụng native, sau đó kết hợp với thông tin tài khoản ứng dụng và Android Advertising ID để liên kết danh tính người dùng với các lượt truy cập web
How does this work?
Lạm dụng cổng cục bộ trên Android
- Trên Android OS, mọi ứng dụng chỉ cần quyền INTERNET là có thể mở socket trên 127.0.0.1 (loopback)
- Trình duyệt cũng có thể truy cập giao diện này mà không cần sự đồng ý riêng từ người dùng
- JavaScript được nhúng trong website có thể gửi và nhận dữ liệu giữa trình duyệt và ứng dụng native bằng Web API tiêu chuẩn
Cách Meta/Facebook Pixel liên kết web-ứng dụng
- Khi JavaScript Meta Pixel được tải trong trình duyệt Android, giá trị cookie _fbp sẽ được gửi tới ứng dụng native qua gói STUN của WebRTC (UDP cổng 12580–12585)
- Các ứng dụng Facebook, Instagram trên thiết bị (tùy phiên bản như 515.0.0.23.90/382.0.0.43.84) lắng nghe tại các cổng đó, nhận giá trị _fbp từ trình duyệt rồi gửi tiếp lên máy chủ riêng bằng GraphQL
- _fbp là cookie quan trọng được cài trên khoảng 25% trong top một triệu website; trước đây nó tách biệt theo từng website nên khó theo dõi chéo, nhưng với cách này có thể ghép nhiều _fbp của một người dùng vào cùng một tài khoản
- Sau tháng 5/2025, script còn bổ sung phương thức WebRTC TURN để né kỹ thuật SDP Munging
- Cookie _fbp có thời hạn 90 ngày và cực kỳ phổ biến, được dùng trên khoảng 25% các website hàng đầu
- Sau khi các trình duyệt lớn như Chrome phản ứng, đoạn mã đã bị gỡ ngày 3/6
Cách Yandex Metrica liên kết web-ứng dụng
- Script Yandex Metrica từ năm 2017 đã gửi request qua HTTP(S) tới các cổng cục bộ (29009, 29010, 30102, 30103, v.v.)
- Các ứng dụng Yandex (Yandex Maps, Navigator, Browser, Search, v.v.) mở sẵn các cổng này và phản hồi bằng dữ liệu chứa Android Advertising ID (AAID) được mã hóa Base64 cùng các định danh thiết bị khác, UUID, v.v.
- Script trong trình duyệt thu thập thông tin này rồi gửi ngược về máy chủ Yandex, hoàn tất việc liên kết định danh giữa trình duyệt, ứng dụng và máy chủ
- Tên miền yandexmetrica.com được phân giải về 127.0.0.1 để né phát hiện và che giấu luồng thu thập
- Do sử dụng HTTP localhost, nếu một ứng dụng khác đang lắng nghe cùng cổng thì còn có nguy cơ làm lộ lịch sử truy cập website của người dùng
Rủi ro thực tế: rò rỉ lịch sử truy cập trình duyệt
- Khi dùng giao tiếp cục bộ dựa trên HTTP, bất kỳ ứng dụng Android nào chỉ cần lắng nghe đúng cổng cũng có thể lấy được URL truy cập và lịch sử duyệt web
- Nhóm nghiên cứu đã phát triển ứng dụng Proof-of-Concept và thử nghiệm trên Chrome, Firefox, Edge, qua đó chứng minh rằng private browsing và chế độ ẩn danh đều dễ bị ảnh hưởng
- Chỉ một số trình duyệt như Brave, DuckDuckGo có thể phòng vệ nhờ danh sách chặn riêng và cơ chế yêu cầu người dùng đồng ý
Affected Sites
- Meta Pixel: được dùng trên 5,8 triệu website; kết quả crawling thực tế quan sát thấy chia sẻ ID cục bộ tại 15 nghìn website ở EU và 17 nghìn website ở Mỹ trong top 100 nghìn website
- Yandex Metrica: được dùng trên 3 triệu website; với cùng cách thức, xác nhận có giao tiếp cổng cục bộ tại 1.260 website ở EU và 1.312 website ở Mỹ
- Trong số đó, phần lớn website còn tự động chạy theo dõi ngay cả khi không có quy trình xin đồng ý cookie
History
- Yandex: bắt đầu dùng cổng HTTP/HTTPS từ năm 2017
- Meta: chuyển dần từ HTTP vào tháng 9/2024, WebSocket vào tháng 11/2024, WebRTC STUN trong năm 2025 và TURN vào tháng 5
Abuse Vectors
- Nguyên nhân chính là Android không có hạn chế truy cập socket localhost và chính sách sandbox còn thiếu chặt chẽ
- Mọi biện pháp bảo vệ hiện có như thiết lập quyền, chế độ ẩn danh của trình duyệt, đặt lại ID quảng cáo đều bị vượt qua
- Dù khó phân biệt với mục đích hợp pháp trong phát triển web, đây vẫn là một trường hợp đã được chứng minh về theo dõi trên diện rộng
- Các trình duyệt như Chrome, Firefox, DuckDuckGo, Brave đang triển khai bản vá khẩn cấp, nhưng về căn bản vẫn cần tăng cường quyền hạn, cảnh báo, sandbox và chính sách IPC ở cấp độ nền tảng
Disclosure
- Đã yêu cầu công bố có trách nhiệm và hợp tác với các nhà cung cấp trình duyệt như Chrome, Firefox, DuckDuckGo, Brave
- Chrome (phiên bản 137), Firefox (phiên bản 138), Brave, v.v. đã áp dụng các biện pháp ngắn hạn như chặn cổng dễ bị khai thác, chặn SDP Munging
- Về dài hạn, cần nhấn mạnh sự cần thiết của các cải tiến mang tính cấu trúc như kiểm soát truy cập mạng cục bộ, tăng cường sandbox, hướng dẫn người dùng
| Trình duyệt | Phiên bản | Yandex | Tình trạng ứng phó/chặn | |
|---|---|---|---|---|
| Chrome | 136.0+ | Bị ảnh hưởng | Bị ảnh hưởng | Từ 137 chặn cổng và SDP munging, đang triển khai dần |
| Edge | 136.0+ | Bị ảnh hưởng | Bị ảnh hưởng | Chưa rõ (dựa trên Chromium) |
| Firefox | 138.0.2 | Bị ảnh hưởng | Không bị ảnh hưởng(1) | Chặn SDP munging, UDP sẽ được chặn sau |
| DuckDuckGo | 5.233.0 | Bị ảnh hưởng một phần(2,3) | Không bị ảnh hưởng(2,3) | Chặn dựa trên blocklist |
| Brave | 1.78.102 | Không bị ảnh hưởng(3,4) | Không bị ảnh hưởng(3,4) | Từ năm 2022 yêu cầu người dùng đồng ý với request localhost, áp dụng blocklist |
- 1: Chặn SDP Munging, cổng TURN vẫn chưa bị chặn (dự kiến áp dụng sau)
- 2,3,4: Có nhiều lớp phòng vệ như blocklist, chặn cổng, yêu cầu người dùng đồng ý
Tình trạng nhận thức của người dùng và nhà vận hành
Nhà vận hành website
- Tài liệu chính thức của Meta và Yandex chưa từng công khai phương thức này
- Từ tháng 9/2024, trên diễn đàn nhà phát triển Facebook đã liên tục xuất hiện câu hỏi như "vì sao script Pixel lại truy cập localhost", nhưng không có phản hồi chính thức nào
- Phần lớn nhà vận hành website và người dùng cuối đều không hề hay biết. Người dùng vẫn có thể bị theo dõi cả khi chưa đăng nhập, ở chế độ ẩn danh, hoặc đã xóa cookie
Người dùng phổ thông
- Việc theo dõi hoạt động không phụ thuộc vào trạng thái đăng nhập
- Chế độ ẩn danh, xóa cookie và các biện pháp bảo vệ khác đều bị vô hiệu hóa
- Có nhiều trường hợp vẫn hoạt động cả trên website không có quy trình xin đồng ý cookie
Tóm tắt FAQ
- Q: Vì sao Meta dừng phương thức này ngay sau khi bị công bố?
A: Không có phản hồi chính thức; sau khi bị công bố, đã xác nhận việc gửi packet tới người dùng Android đã dừng lại - Q: Nghiên cứu đã được peer review chưa?
A: Đã được một số tổ chức xác minh nhưng chưa qua phản biện học thuật; do quy mô lạm dụng nên quyết định công bố sớm - Q: Có được công khai trong tài liệu chính thức của Meta/Yandex không?
A: Không có tài liệu kỹ thuật chính thức, chỉ có các câu hỏi trên diễn đàn nhà phát triển - Q: iOS hay nền tảng khác có bị ảnh hưởng không?
A: Tính đến hiện tại mới xác nhận trên Android, nhưng về mặt kỹ thuật thì iOS/desktop/smart TV cũng có thể tiềm ẩn rủi ro
11 bình luận
Thấy pin hao bất thường nên trước đây tôi đã xóa hết các ứng dụng bên Meta, hóa ra là có chuyện như thế này... Có lẽ tôi cũng phải dùng adb để xóa nốt các ứng dụng hệ thống được cài sẵn trên mấy máy Galaxy còn lại.
Tôi cũng không thể tin tưởng ứng dụng Meta nên không dùng, thay vào đó chỉ sử dụng bằng Chrome trong Thư mục bảo mật.
Các loại framework được gọi là ứng dụng web lai, phần lớn đều chạy webserver
localhost(dù mục đích thì khác nhau). Những thứ không giải quyết được qua thiết lập thư viện trình duyệt nhúng (WebKit...) hay tùy biến (phần web) sẽ được xử lý ở phía webserver chạy trênlocalhost(phần native). Hóa ra cũng có thể bị tận dụng theo cách này... tiếc thật.Theo tôi, trong ứng dụng hybrid, cách giao tiếp thông thường giữa web và app là thông qua các API do hệ điều hành và phía trình duyệt cung cấp, còn gọi là bridge. Tôi cho rằng máy chủ web cục bộ không phải là thứ bắt buộc.
Lý do việc dùng máy chủ web cục bộ ở đó trở thành vấn đề, theo tôi, là vì nó có thể dẫn tới những lỗ hổng như việc truy cập vào cổng localhost từ Chrome ở chế độ ẩn danh để phá vỡ tính ẩn danh của người dùng. Nếu kỹ thuật này là bắt buộc trong ứng dụng hybrid thì... ứng dụng hybrid nên biến mất.
Việc mở và dùng một máy chủ web bên trong ứng dụng để xử lý các tính năng bắt buộc phải có tên miền,
localStoragevà những thứ tương tự nhìn chung là cách làm phổ biến.Nếu không trả tiền cho dịch vụ thì bản thân tôi chính là sản phẩm. Những nỗ lực theo dõi cá nhân thông qua ngày càng nhiều dữ liệu rồi sẽ chỉ tăng lên, và có vẻ như không thể đảo ngược xu hướng này. Chúng ta cần những lựa chọn thay thế tốt hơn, nhưng dưới chủ nghĩa tư bản thì thật khó nghĩ ra lựa chọn nào tốt hơn.
Tôi tò mò không biết liệu quyền truy cập localhost từ bên trong và bên ngoài Thư mục bảo mật trên Galaxy có được cô lập hay không
Không được cách ly nhỉ. Chạy Python
http.serverbằng Termux bên ngoài Thư mục bảo mật rồi truy cập bằng Chrome ở bên trong thì vẫn vào được.Cái này chẳng phải là lỗ hổng bảo mật sao -_-??
Có vẻ như đáp án đúng là không dùng SNS..
Ý kiến Hacker News
Nếu tóm tắt toàn bộ quy trình theo dõi mà Meta đang dùng theo cách tôi hiểu, nội dung tham khảo từ blog Localmess
Ngay cả ở chế độ ẩn danh vẫn có thể bị theo dõi
_fbp(chứa thông tin duyệt web) sang ứng dụng Instagram hoặc Facebook bằng kỹ thuật WebRTC (STUN) SDP MungingPhần này cũng không hiển thị trong công cụ dành cho nhà phát triển của trình duyệt
Ứng dụng sẽ gửi thông tin
_fbpvà ID người dùng lên máy chủ của MetaNgoài ra còn có vài điểm đáng chú ý,
Cách chia sẻ ID từ web sang app này vượt qua các biện pháp bảo vệ quyền riêng tư thông thường như xóa cookie, chế độ ẩn danh, hay kiểm soát quyền trên Android
Thậm chí còn mở ra khả năng cho ứng dụng độc hại theo dõi hoạt động web của người dùng
Từ giữa tháng 5, script Meta Pixel cũng bắt đầu gửi cookie
_fbpbằng cơ chế WebRTC TURN; cách này được đưa vào sau khi đội ngũ Chrome chặn SDP MungingTính đến ngày 2/6/2025, chưa quan sát thấy ứng dụng Facebook/Instagram thực sự nhận dữ liệu qua cổng mới đó
Nếu trường hợp sử dụng chính của WebRTC là lấy thông tin như IP nội bộ của người dùng để phá ẩn danh, thì tôi không hiểu vì sao tính năng như vậy lại có thể chạy mà không cần xin quyền riêng biệt
Ở một số quốc gia, việc truy cập các trang như something-embarassing.com có thể dẫn đến hậu quả nghiêm trọng hơn nhiều chứ không chỉ là xấu hổ
Tôi chưa hoàn toàn hiểu rõ, nhưng tự hỏi liệu chuyện này có bao gồm cả việc lợi dụng thông báo xin đồng ý cookie theo GDPR để theo dõi người dùng một cách bí mật hay không
Tôi chỉ muốn cấm hẳn quảng cáo và theo dõi trên internet
Chính vì những thứ này mà quá nhiều thứ vô nghĩa bị đẩy ra đời
Theo tôi thì tất cả chỉ là để các CEO mua thêm một chiếc du thuyền nữa
Reddit cũng thu thập fingerprint thiết bị khá nhiều
Họ còn bán dữ liệu này để huấn luyện mô hình AI
Tôi đoán rồi sẽ đến ngày họ tích cực bán cả dữ liệu riêng tư chỉ dùng được trong ứng dụng premium
Vấn đề còn lại là làm sao cấm được chuyện này, và làm sao chứng minh được ai đã vi phạm luật đó
Việc loại bỏ cookie bên thứ ba khỏi trình duyệt thực tế là bước đầu tiên khả thi nhất
Nhưng Google đã dùng thế thống trị của Chrome để làm trật bánh việc này vào năm ngoái
Có thể không trái luật, nhưng đó là hành vi thao túng thị trường phi đạo đức lẽ ra phải khiến người tiêu dùng nổi giận
Có vẻ ban lãnh đạo Google lúc đầu tin rằng vẫn có thể giữ doanh thu mà không cần cookie; thực tế có thể là họ hoàn toàn không hiểu ý nghĩa của cookie, hoặc ngay từ đầu chưa từng có ý định loại bỏ chúng
Kiểu hành vi này đơn thuần là lòng tham
Những nhà quản lý truyền thống thành công suốt hàng thế kỷ thường tránh sự ám ảnh quá mức với lợi ích cá nhân như vậy
Ngay cả những lãnh đạo tạm ổn cũng thường có thể vượt lên trên kiểu hành xử thấp kém này để điều hành công ty tốt hơn
Nhưng trong một thế giới chỉ còn lòng tham, có lẽ chỉ biết cười cho qua
Thật tốt nếu có nhiều CEO vừa giỏi vừa trung thực hơn
Nói thêm về câu đùa “du thuyền của CEO”, thực ra đa số người tiêu dùng chọn mô hình quảng cáo vì họ thích dịch vụ/sản phẩm miễn phí
Trên thực tế nếu có cả bản trả phí và bản có quảng cáo, bản có quảng cáo thường được chuộng hơn theo tỷ lệ 10:1
Việc chặn quảng cáo lại còn làm tình hình tệ hơn — sự phản kháng thực sự nên là tẩy chay dịch vụ hoặc trả tiền trực tiếp cho phương án thay thế
Tôi nghĩ các mô hình như BAT (Brave Attention Token), phân phối vi thanh toán trực tiếp cho website, hợp lý hơn
Về lý thuyết, đó là cấu trúc: tôi trả tiền đúng theo mức sử dụng, và tôi là khách hàng thật sự chứ không phải nhà quảng cáo
Báo cáo sự cố thực tế: blog Localmess
Google nói đang điều tra các trường hợp lạm dụng, nhưng trớ trêu là bản thân Google cũng đang theo dõi mọi người bằng nhiều side channel như tên Wi-Fi AP
Các công ty ứng dụng lớn vẫn tiếp tục thu thập dữ liệu bằng những cách tương tự để né các giới hạn của hệ điều hành
Thêm một lý do nữa để không cài ứng dụng của Big Tech nếu có thể, và chỉ dùng website khi thật sự cần
Website tuy chậm và bất tiện hơn, nhưng được sandbox nên an toàn hơn nhiều
Ví dụ, điện thoại Samsung có nhiều ứng dụng Meta được cài sẵn, và kể cả khi xóa ứng dụng Facebook thì các dịch vụ ẩn như
com.facebook.servicesvẫn có thể còn lạiNhững dịch vụ này chỉ có thể gỡ bằng công cụ cho nhà phát triển (ADB/UAD)
Hoặc có thể chọn iPhone hoặc điện thoại Pixel
Thông tin kỹ thuật liên quan đến script Meta Pixel:
Meta Pixel đã gửi dữ liệu qua HTTP cho tới tháng 10/2024, và ứng dụng Facebook/Instagram hiện vẫn đang chờ nhận trên cổng đó
Chúng cũng đang chờ trên cổng 12388 mới, nhưng chưa phát hiện script nào gửi dữ liệu đến cổng này
Vì vậy, có một sự tò mò mang tính khoa học(?) là liệu ứng dụng khác có thể gửi thông điệp giả đến cổng đó hay không
Một là không gửi gì cả, hai là gửi thật nhiều dữ liệu giả
Tôi cũng muốn có một thiết bị chia sẻ cookie theo dõi quảng cáo kiểu P2P
Tôi tự hỏi liệu việc theo dõi này có thể vượt qua giữa các profile hay không
Nếu có thì đây là một vấn đề bảo mật cực lớn với doanh nghiệp
Tôi đã thử chạy một server trên cổng 8080 bằng ứng dụng userland và thấy cả hai profile đều truy cập được
Điều đó có nghĩa là ứng dụng bị nhiễm ở một profile có thể trao đổi dữ liệu với website được truy cập ở profile khác
Tôi tự hỏi nếu cá nhân thu thập thông tin từ máy tính của người khác bằng cách này thì có thể bị xử theo CFAA (Computer Fraud and Abuse Act) hay không
Cách này đòi hỏi kiểm soát mã nguồn ở cả một phía (website đang truy cập) lẫn phía bên kia (ứng dụng đang chạy trên điện thoại)
Nó không phải kiểu kỹ thuật hack ma thuật có thể tự động đánh cắp lịch sử trình duyệt bất kỳ
Vì vậy khó mà coi đây là hack theo nghĩa rõ ràng, và kể cả khi Google/Meta theo dõi không có sự đồng ý thì cũng không thuộc CFAA
Thực ra dưới CFAA từng có người bị truy tố chỉ vì đơn giản dùng “xem mã nguồn trang” trong trình duyệt
Có vẻ không phải hành vi phạm tội tự thân quan trọng bằng việc bạn đụng đến ai, và mối quan hệ mạng lưới xung quanh nó
Có thể bị xử phạt
Hệ thống ID này quá dễ bị lạm dụng, và tôi đoán Google cũng biết điều đó, biết rằng họ bắt buộc phải đặt ra quy định ngăn lạm dụng
Đây là chuyện có thể dẫn tới án phạt nặng (cấm vĩnh viễn trên Play Store, hành động pháp lý, thậm chí truy tố hình sự)
Nhưng trên thực tế, với công ty quá lớn như Meta thì gần như không thể áp đặt chế tài thực chất
(Và ngay cả nếu không phải Meta, cũng có thể những động thái mờ ám như vậy đang được cơ quan tình báo hoặc thực thi pháp luật ngầm chấp thuận — rất khó để ngăn lại, thậm chí nói ra cũng không dễ)
Họ có hơn 50 cách tự theo dõi người dùng
Các công ty khác cũng kiếm được rất nhiều tiền bằng cách đàm phán lại điều khoản chia sẻ dữ liệu người dùng với các tập đoàn lớn
Các thỏa thuận đã được chốt, quyền cũng đã được cấp, chỉ là có một số người dùng đang làm ầm lên vì chuyện này mà thôi
Trên Firefox có thể chặn WebRTC bằng cách đổi tùy chọn
media.peerconnection.enabledtrongabout:configthànhfalseKết hợp Netguard và Nebulo ở chế độ non-VPN có thể chặn các kết nối không cần thiết tới máy chủ Meta
Tôi nghĩ Liên minh châu Âu (EU) nên áp các mức phạt kỷ lục với những vấn đề như thế này
Cũng nên có một loại thuế tăng lũy tiến thêm 1~X% mỗi lần tái phạm
Và cần có cả một website để nhìn nhanh các vụ vi phạm của từng công ty
Meta dù mỗi năm đều nộp phạt vẫn ghi nhận khoảng 70 tỷ USD lợi nhuận ròng
Không chỉ phạt tiền, mà trong một số trường hợp còn cần biện pháp mạnh hơn, vì đã có những cá nhân bị bỏ tù vì các vi phạm nhẹ hơn nhiều