Phá mã giao thức quảng cáo của AppLovin: Vấn đề riêng tư khi người dùng đã từ chối theo dõi

Phá mã giao thức quảng cáo của AppLovin: Vấn đề riêng tư khi người dùng đã từ chối theo dõi

Một nhà nghiên cứu bảo mật gần đây đã công bố kết quả điều tra của mình về AppLovin, một trong những nền tảng trung gian quảng cáo (ad mediation) lớn nhất trên di động. Bằng cách giải mã lớp bảo mật mà AppLovin áp dụng cho lưu lượng truy cập quảng cáo, nghiên cứu này đã hé lộ một thực tế đáng báo động: ngay cả khi người dùng từ chối tính năng theo dõi ATT (App Tracking Transparency) của Apple, các nhà quảng cáo vẫn có đủ dữ liệu để nhận diện xác định cùng một thiết bị iPhone qua nhiều ứng dụng khác nhau.

Cơ chế mã hóa "tự chế" đầy lỗ hổng

Mọi yêu cầu trung gian từ AppLovin đều được gửi qua HTTPS POST, nhưng bên trong lớp TLS, dữ liệu còn được bọc trong một lớp mã hóa do chính AppLovin xây dựng. Sau khi giải mã, cấu trúc của gói tin (wire envelope) bao gồm thẻ phiên bản, ID giao thức và hậu tố của khóa SDK.

Cấu trúc gói tin mã hóa của AppLovin

Thuật toán mã hóa này sử dụng hai thành phần chính: một "salt" (hạt muối) 32 byte được tích hợp cứng trong mọi tệp tin nhị phân của SDK AppLovin, và khóa SDK được cấp cho từng nhà xuất bản ứng dụng.

Điều đáng lo ngại là AppLovin đã sử dụng SplitMix64—một bộ tạo số giả ngẫu nhiên (PRNG) thường dùng trong các thư viện ngôn ngữ lập trình để tạo số ngẫu nhiên nhanh cho game hoặc mô phỏng—làm cơ sở để tạo dòng khóa (keystream). SplitMix64 có thể vượt qua các kiểm tra tính ngẫu nhiên thống kê nhưng hoàn toàn không được thiết kế để đáp ứng các tiêu chuẩn bảo mật mã hóa.

Hơn nữa, giao thức này hoàn toàn thiếu các cơ chế xác thực như MAC hay AEAD. Điều này cho phép kẻ tấn công có thể can thiệp vào văn bản mã hóa mà không bị phát hiện. Ngoài ra, bộ đếm trong thuật toán dựa trên System.currentTimeMillis(), nghĩa là mỗi gói tin gửi đi đều vô tình lộ thời gian hệ thống của thiết bị tính đến mili-giây.

Dữ liệu vân tay thiết bị vẫn bị thu thập

Sau khi giải mã thành công hàng nghìn gói tin từ nhiều ứng dụng khác nhau, nội dung bên trong được tiết lộ là dữ liệu JSON nén, chứa khoảng 30 trường thông tin. Quan trọng nhất trong số này là device_info (thông tin thiết bị) và signal_data (dữ liệu tín hiệu).

Dưới đây là ví dụ về dữ liệu device_info từ một yêu cầu mà người dùng đã từ chối ATT:

• revision: iPhone14,3 (Mã mô hình phần cứng - iPhone 13 Pro Max)
• os: 18.6.2 (Phiên bản hệ điều hành)
• tm: 5918212096 (Tổng dung lượng RAM)
• ndx × ndy: 1284 × 2778 (Kích thước màn hình pixel gốc)
• kb: en-US,es-ES (Các bàn phím đã cài đặt)
• tz_offset: -4 (Múi giờ)
• volume: 40 (Âm lượng hệ thống)
• mute_switch: 1 (Trạng thái nút tắt âm vật lý)
• bt_ms_2: 1770745989000 (Thời gian khởi động thiết bị)
• dnt / idfa: true / 00000… (Đã từ chối ATT - IDFA bị đưa về 0)

Các gói tin mini được gửi đến các đối tác quảng cáo

Mặc dù IDFA (mã định danh cho quảng cáo) đã bị zero hóa do người dùng từ chối theo dõi, nhưng gần như mọi thuộc tính hệ thống khác mà iOS để lộ cho mã của bên thứ ba đều được gửi đi. Điều này bao gồm dung lượng đĩa trống, mức pin, trạng thái sạc, kích thước vùng an toàn màn hình (notch), và danh sách bàn phím.

Sự lan truyền dữ liệu qua "Mini-envelopes"

Một ứng dụng điển hình tích hợp SDK AppLovin thường chứa khoảng 18 SDK quảng cáo của các đối tác khác nhau như Meta, Google, Unity, TikTok, v.v. Khi cần hiển thị quảng cáo, SDK AppLovin sẽ gọi từng đối tác này để yêu cầu "chuẩn bị tín hiệu đấu thầu".

AppLovin gom tất cả các tín hiệu này vào mảng signal_data[] và gửi chúng trong gói tin mã hóa của mình. Máy chủ AppLovin sau đó chuyển tiếp từng token đến máy chủ đấu thầu của đối tác tương ứng. Trong số các gói tin này, một số vẫn ở dạng văn bản rõ và có thể đọc được.

Ví dụ, tín hiệu từ InMobi chứa thêm cả dung lượng đĩa trống (6.275 MB - con số thay đổi theo giờ và có độ ngẫu nhiên cao), trạng thái chế độ tối, và các kích thước lề màn hình cụ thể theo mẫu máy. BidMachine thậm chí còn gửi thêm chuỗi múi giờ IANA (ví dụ: America/New_York) và một UUID riêng để nhận diện người dùng mà họ tự tạo ra.

Vân tay thiết bị vượt qua rào cản ATT

Nghiên cứu chỉ ra rằng giả định "ATT là cách duy nhất để nhận diện xác định người dùng" là sai lệch. Vân tay thiết bị (device fingerprinting) hoạt động hiệu quả tương tự.

Trong dữ liệu app_info, có một trường gọi là api_did do máy chủ AppLovin cấp. Đáng chú ý, đối với các thiết bị từ chối ATT, trường này luôn bắt đầu bằng tiền tố 10badd1d (đọc là "BADDID" - Bad Device ID). Điều này cho thấy AppLovin tôn trọng quyết định của người dùng ở cấp độ định danh của chính họ.

Nhận diện vân tay thiết bị qua nhiều ứng dụng

Tuy nhiên, vấn đề nằm ở chỗ gói tin mã hóa chứa khoảng 48 trường thông tin khác trong device_info và 12 "mini-envelopes" riêng biệt. ATT chỉ làm mất hiệu lực một định danh (IDFA). Nó không chạm đến các dữ liệu như:

• Mã mô hình phần cứng và phiên bản hệ điều hành.
• Kích thước màn hình và vùng an toàn (notch).
• Tổng dung lượng RAM và dung lượng đĩa trống.
• Mức pin, âm lượng, trạng thái nút tắt âm.
• Thời gian khởi động thiết bị.
• IDFV (Identifier for Vendor).

Tác giả nghiên cứu đã tạo một bản băm SHA-256 từ chín trường thông tin chính (mã máy, hệ điều hành, RAM, màn hình, bàn phím, ngôn ngữ, múi giờ...). Kết quả cho thấy 10 thiết bị iPhone vật lý khác nhau tạo ra 10 vân tay hoàn toàn riêng biệt. Thậm chí, một người dùng từ chối ATT xuất hiện trên ba ứng dụng khác nhau của ba nhà xuất bản khác nhau vẫn có cùng một bản băm vân tay 321d60c4d72ddf2a trên cả ba ứng dụng.

Kết luận

ATT của Apple thực chất chỉ là một công cụ kiểm soát mã định dạng cross-app do Apple cấp cấp (IDFA). Nó được tôn trọng trên đường truyền, nhưng giao thức mà AppLovin và khoảng 12 mạng lưới quảng cáo hạ nguồn sử dụng lại hoạt động ở tầng vân tay thiết bị—một tầng mà iOS không kiểm soát cơ học và ATT không thể chạm tới.

Mỗi yêu cầu quảng cáo mang theo hàng chục trường dữ liệu thiết bị đến AppLovin và hàng chục đối tác khác, cho phép họ liên kết lại cùng một chiếc iPhone vật lý qua các nhà xuất bản và phiên bản sử dụng khác nhau, bất kể sự lựa chọn riêng tư của người dùng.