Bài báo này là một công trình nghiên cứu về việc các ứng dụng Android có khả năng rò rỉ thông tin được bảo mật mà không cần được cấp quyền để truy cập các dữ liệu đó. Kết quả của bài báo này đã được cung cấp cho Google, tuy nhiên các bản sửa lỗi sẽ chỉ hoạt động trên các thiết bị chạy Android Q.

Phương pháp tiếp cận trong bài báo bao gồm 4 bước chính:

  • Tạo môi trường test chạy các ứng dụng trong một honeypot và tìm ra các ứng dụng nào đang rò rỉ thông tin mà không được cấp phép.
  • Reverse engineering được sử dụng để tìm ra cơ chế hoạt động của các ứng dụng này.
  • Tạo ra các fingerprints dựa trên phân tích trên để áp dụng lên các ứng dụng có sử dụng cơ chế tương tự.
  • Phân tích kết quả để tìm ra cơ chế được sử dụng trong thực tế và mức độ thịnh hành của chúng

1. Tìm ra các ứng dụng rò rỉ dữ liệu

Sử dụng bộ scraper dựng sẵn của Google Play, nhóm nghiên cứu đã tải về 252,864 phiên bản của 88,113 ứng dụng Android khác nhau. Mỗi ứng dụng được chạy trên một thiết bị với với network monitor và một OS tuỳ chỉnh. Các ứng dụng được điều khiển sử dụng Application Exerciser Monkey của Android nhằm truyền một luồng mô phỏng input event của người dùng.
Thiết bị thiết bị điện thoại thử nghiệm sử dụng phiên bản Android Marshmallow trên một nhân Linux tùy chỉnh có thể ghi lại các tệp tin I/O. Network traffic cũng đã được điều chỉnh, bao gồm toàn bộ kết nối được bảo mật bằng TLS. Sau khi ứng dụng đã được khởi chạy, network traffic do ứng dụng tạo ra được kiểm tra phân tích để tìm ra thông tin bị rò rỉ. Thông tin được tìm thấy sẽ đem đối chiếu với các permission mà ứng dụng đã yêu cầu cấp phép.

Một ứng dụng để lộ dữ liệu mà nó không được cấp phép đồng nghĩa với việc nó bằng một cách nào đó đã nhận được những thông tin một cách không hợp lệ. Việc xác định thông tin cá nhân trong một hệ thống truyền tải mạng đòi hỏi một nỗ lực đáng kể bởi các ứng dụng và SDK nhúng của bên thứ ba thường sử dụng các phương thức mã hoá khác nhau để truyền dữ liệu.

2. Tìm ra cách thức các ứng dụng rò rỉ dữ liệu

Với việc có trong tay network traffic kèm với những thông tin đã được giải mã, nhóm nghiên cứu phân nhóm thông tin dựa trên đặc điểm và địa chỉ network được gửi đến, sau đó lại tiếp tục sử dụng reverse engineer lên từng ứng dụng trong mỗi nhóm để tìm ra cách thức ứng dụng đấy sử dụng để thu thập dữ liệu.

3. Xác định mức độ thông dụng của từng phương thức sử dụng

Bước cuối cùng trong quá trình nghiên cứu này đó là tạo một fingerprint để xác định sự tồn tại của một lỗ hổng bị khai thác của một SDK (một hằng số string ứng với một encryption key cố định), sau đó decompile toàn bộ ứng dụng và tìm kiếm các string đó.

Kết quả cuối cùng cho thấy, một covert channel được sử dụng hết sức đơn giản: ghi vào thẻ SD. Một ứng dụng với một số quyền nhất định ghi dữ liệu mà nó được cấp phép truy cập vào một tệp trong thẻ SD, và các ứng dụng khác có thể đọc dữ liệu (mà nó không có quyền truy cập) từ tệp đó. Salmonads - một third-party platform sử dụng kỹ thuật này để ghi IMEI vào file /sdcard/.googlex9/.xamdeco0962. Các ứng dụng khác sử dụng SDK mà không có quyền để lấy thông tin này vẫn có thể đọc được nó từ tệp tin trên.

Theo dữ liệu của Google Play, số lần tải về của các ứng dụng không được cấp quyền sử dụng channel này để thu thập IMEI rơi vào khoảng ít nhất 17.6 triệu lượt tải.

Maps SDK của Baidu cũng sử dụng kỹ thuật này để tiết lộ IMEI, các ứng dụng tận dụng SDK bị rò rỉ này bao gồm các ứng dụng của công viên giải trí Disney ở Hồng Kông và Thượng Hải, cũng như các ứng dụng và trình duyệt của Samsung Health. Số liệu cho thấy có ít nhất 2.6 tỷ lượt cài đặt cho các ứng dụng mà được xác định là có chứa SDK này.