Android 15 bảo vệ chống nhìn trộm màn hình như thế nào?

Hệ thống mới, tính năng bảo mật mới

Mã nguồn cho Android 15 đã được phát hành vào ngày 3 tháng 9, như thông báo trên Android Developers Blog, và Google bắt đầu triển khai Android 15 cho các thiết bị Pixel từ ngày 15 tháng 10.

Các cải tiến về tính năng bảo mật và quyền riêng tư được công bố và đánh giá trong nhiều bài viết [security.googleblog.com,android-developers.googleblog.com,

androidauthority.com,kaspersky.com]. Hai trong số các tính năng mới tập trung vào việc bảo vệ chống nhìn trộm màn hình. Giờ đây, với vai trò là nhà phát triển, bạn có thể thêm một callback để ứng dụng nhận biết khi màn hình đang được ghi lại. Hơn nữa, hệ thống sẽ tự động bảo vệ các cửa sổ chứa mật khẩu để chúng không xuất hiện trong quá trình ghi hoặc chia sẻ màn hình.

Trong bài viết này, chúng tôi thảo luận về những lợi ích mà Android 15 mang lại với các tính năng chống nhìn trộm màn hình mới, cũng như các hạn chế của chúng. Chúng tôi sẽ giải thích và minh họa cách các vấn đề bảo mật có thể xảy ra dù có các cải tiến về bảo mật của Android 15 và và tại sao các đề xuất bảo vệ trước đây của chúng tôi [secu secure_flag, bàn phím an toàn trong ứng dụng] vẫn là biện pháp bảo vệ tốt nhất để chống lại nhìn trộm màn hình không mong muốn. Bạn có thể tìm thấy hướng dẫn và các đoạn mã cần thiết trong Trung tâm Nghiên cứu Bảo mật của chúng tôi để điều chỉnh các biện pháp bảo vệ cho phù hợp.

FLAG_SECURE trên Android 15 có còn cần thiết?

Lợi ích của các tính năng bảo mật mới

1. Xác định khi bắt đầu và dừng quay màn hình

Trạng thái ghi có thể được sử dụng để xác định xem màn hình có đang được ghi hay không. Hệ thống cung cấp hai trạng thái có thể xảy ra: đang ghi hoặc không ghi.

Bạn có thể đăng ký một callback (trình gọi lại), được kích hoạt mỗi khi trạng thái ghi có sự thay đổi. Để sử dụng tính năng này, trước tiên cần khai báo quyền trong tệp kê khai Android:

<uses-permission android:name="android.permission.DETECT_SCREEN_RECORDING" />

Sau đó, chúng ta có thể triển khai callback, screenRecordingCallback, và đăng ký nó bằng cách gọi phương thức addScreenRecordingCallback như sau:

Executor executor = Executors.newSingleThreadExecutor();

Consumer screenRecordingCallback = state -> {
     if (state == WindowManager.SCREEN_RECORDING_STATE_VISIBLE) {       
          Toast.makeText(this, "[!] Screen recording started!",
               Toast.LENGTH_SHORT).show());

     } else if (state == WindowManager.SCREEN_RECORDING_STATE_NOT_VISIBLE) {
          Toast.makeText(this, "[!] Screen recording stopped!",
               Toast.LENGTH_SHORT).show());

     }
};

windowManager.addScreenRecordingCallback(executor, screenRecordingCallback);

Kết quả có thể được quan sát trong hình ảnh động dưới đây:

Tính năng này là một cải tiến đáng kể, vì ứng dụng giờ đây có thể phát hiện khi nào màn hình đang bị ghi lại và phản ứng phù hợp. Điều này bổ sung thêm cho tính năng phát hiện ảnh chụp màn hình đã có trên Android 14 [developer.android.com, medium.com]. Ngoài ra, callback ghi màn hình cũng sẽ phát hiện bất kỳ ứng dụng nào sử dụng API MediaProjection để chụp ảnh màn hình. Tuy nhiên, ảnh chụp màn hình qua nút bấm không thể bị phát hiện qua callback ghi màn hình, nhưng có thể được phát hiện qua callback chụp màn hình trên Android 14.

2. Mật khẩu được bảo vệ khỏi con mắt tò mò

Trong Android 15, khi hệ thống phát hiện ra một phiên quay phim màn hình đang diễn ra, nó sẽ tự động bảo vệ các cửa sổ chứa mật khẩu hiển thị để chúng không xuất hiện trong bản ghi. Để minh họa cách tính năng này hoạt động, chúng tôi đã sử dụng một thiết bị giả lập, được hiển thị ở hình bên trái. Ở bên phải là màn hình của thiết bị đang được ghi lại qua Scrcpy. Hệ thống không phát hiện Scrcpy là trình ghi màn hình. Đối với phần ghi màn hình, chúng tôi đã sử dụng AZ Screen Recorder. Như bạn có thể thấy bên dưới, mặc dù Scrcpy luôn được bật, tính năng bảo vệ chỉ được kích hoạt khi chúng tôi bật AZ Screen Recorder. Khi đó, nếu có trường mật khẩu trên màn hình, bạn sẽ thấy màn hình bên phải chuyển sang màu đen.

Những rủi ro bảo mật còn lại cần lưu ý

1. Cách định nghĩa ghi màn hình của tổ chức bạn?

Như chúng ta đã thấy rằng, Scrcpy không được nhận diện là một trình ghi màn hình. Điều này cũng xảy ra đối với chương trình ghi hệ thống của Android  /system/bin/screenrecord. Có vẻ như, đối với Android 15, chỉ các phần mềm sử dụng dựa trên API MediaProjection. mới được nhận diện là trình ghi màn hình. Điều này có thể khiến một số công cụ hoặc phần mềm độc hại không qua API này tránh được sự phát hiện.

2. Bạn có chắc chắn bạn có thể phát hiện tất cả?

Như đã đề cập, screenRecordingCallback sẽ được kích hoạt khi có sự thay đổi trong trạng thái ghi màn hình. Nhưng điều gì sẽ xảy ra nếu màn hình đã được ghi lại trước khi ứng dụng khởi động? Trong trường hợp này, callback sẽ không được kích hoạt. vì nó không phát hiện bất kỳ thay đổi nào kể từ khi ứng dụng chưa chạy. Điều này có nghĩa là màn hình của ứng dụng có thể bị ghi lại mà ứng dụng không hề hay biết! Một khía cạnh tích cực là nếu ứng dụng được "thu nhỏ" và sau đó khởi động lại để tiếp tục, callback sẽdduwojc kích hoạt. Điều này phần nào giảm thiểu rủi ro.

Ngoài ra có điều tốt là, khi hệ thống nhận biết rằng việc chia sẻ màn hình đang diễn ra, các cửa sổ chứa mật khẩu vẫn sẽ được bảo vệ.

Hãy xem ví dụ! Quan sát trong hình ảnh động bên dưới: không có thông báo hay cảnh báo nào cho thấy màn hình đang được ghi lại. Tuy nhiên, màn hình đăng nhập không được chia sẻ. Thay vào đó, một thông báo xuất hiện cho biết cửa sổ đăng nhập đã bị ẩn vì nó chứa mật khẩu.

3. Khi mọi thứ trở nên nghiêm trọng

Khi xem xét các tùy chọn dành cho nhà phát triển, chúng ta có thể tìm thấy một tùy chọn để "tắt tính năng bảo vệ chia sẻ màn hình", được mô tả là "tắt bảo vệ hệ thống đối với nội dung ứng dụng nhạy cảm cho các phiên chia sẻ màn hình sắp tới ". Lưu ý từ "sắp tới", vì điều này có liên quan đến các cuộc tấn công mà chúng tôi sẽ giải thích sau.

Về cơ bản, mật khẩu và dữ liệu nhạy cảm sẽ không còn được bảo vệ. Người dùng có thể bị lừa bật tùy chọn này thông qua các thủ thuật kỹ thuật xã hội, để kích hoạt nó. Ngoài ra, tùy chọn này cũng có thể được kích hoạt bằng quyền shell (nếu người dùng bị thuyết phục bật chế độ nhà phát triển) hoặc quyền root. Ví dụ, điều này có thể đạt được bằng cách chạy các lệnh sau:

# content insert --uri content://settings/global --bind name:s:disable_screen_share_protections_for_apps_and_notifications --bind value:i:1

hoặc

# settings put global disable_screen_share_protections_for_apps_and_notifications 1

Hãy xem một cuộc tấn công có thể xảy ra như thế nào. Để tránh callback ghi màn hình, kẻ tấn công có thể bắt đầu ghi màn hình trước khi ứng dụng khởi động, theo trình tự sau:

1. Kẻ tấn công vô hiệu hóa tính năng bảo vệ chia sẻ màn hình.
2. Kẻ tấn công bắt đầu ghi lại màn hình
3. 3. Ứng dụng khởi động.
4. Callback ghi màn hình không được kích hoạt (vì trạng thái ghi không thay đổi kể từ khi ứng dụng khởi động).
5. Người dùng chuyển đến màn hình đăng nhập. Vì tính năng bảo vệ đã bị vô hiệu hóa, màn hình đăng nhập sẽ bị ghi lại và thông tin bị chia sẻ.

Một số biện pháp giảm nhẹ có thể được thực hiện giúp giảm thiểu rủi ro này. Ví dụ: người quan sát nội dung có thể được sử dụng một trình quan sát nội dung để giám sát trạng thái bảo vệ. Nhà phát triển cũng có thể thiết lập một luồng chạy ngầm để kiểm tra định kỳ trạng thái bảo vệ. Nếu phát hiện tính năng bảo vệ bị vô hiệu hóa, các cơ chế này có thể đưa ra cảnh báo, ví dụ cảnh báo cho người dùng hoặc tạm ngừng các hoạt động nhạy cảm của ứng dụng.

Hãy xem nó:

Tuy nhiên, các biện pháp này vẫn có thể bị vượt qua nếu kẻ tấn công làm theo trình tự dưới đây:

1. Tắt ứng dụng.
2. Vô hiệu hóa bảo vệ.
3. Bắt đầu phiên quay màn hình.
4. Kích hoạt lại tính năng bảo vệ.

Ở bước (1), kẻ tấn công tận dụng việc callback ghi màn hình không kích hoạt nếu màn hình đã được ghi lại trước khi ứng dụng khởi động. Bước (2) khiến hệ thống không phát hiện phiên quay màn hình bắt đầu ở bước (3). Bước (4) ngăn các cơ chế kiểm tra trạng thái bảo vệ phát hiện cuộc tấn công. Do đó, khi ứng dụng khởi động lại, nó không nhận ra rằng tính năng bảo vệ đã bị vô hiệu hóa, dẫn đến việc màn hình đăng nhập bị chia sẻ và thông tin nhạy cảm bị rò rỉ.

Cuộc tấn công được thể hiện trong hình ảnh động bên dưới. Lưu ý rằng, khi chúng ta có thể thấy màn hình đăng nhập trong phép chiếu Scrcpy (bên phải), điều đó có nghĩa là cửa sổ mật khẩu không được bảo vệ.

Một điểm sáng tích cực: nếu ứng dụng chuyển sang nền và sau đó quay trở lại nền trước, callback ghi màn hình sẽ được kích hoạt và phát hiện cuộc tấn công. Điều này giúp giảm thiểu rủi ro trong một số trường hợp cụ thể, như được minh họa trong hình ảnh động bên dưới:

Cách tiếp cận đúng đắn

Các tính năng mới để bảo vệ quyền riêng tư của ứng dụng khỏi gián điệp màn hình có hiệu quả và hữu ích trong hầu hết các tình huống.Nhờ đó, bạn có thể điều chỉnh hành vi của ứng dụng để phản ứng khi có một ứng dụng khác đang xem màn hình hoặc mật khẩu của ứng dụng. Hầu hết các trường hợp, các thông tin nhạy cảm sẽ được bảo vệ. Tuy nhiên, chúng tôi đã thấy rằng dữ liệu nhạy cảm vẫn có thể bị rò rỉ qua màn hình, đặc biệt là trên các thiết bị có bật ADB hoặc khi phần mềm độc hại có đặc quyền root. Đây là lý do tại sao một cách tiếp cận bảo mật nhiều lớp là cần thiết. Các tính năng mới do Android cung cấp nên được kết hợp với FLAG_SECURE để bảo vệ các chế độ xem nhạy cảm tốt hơn. Do đó, quay trở lại với câu hỏi ban đầu của chúng tôi, "Chúng ta có còn cần FLAG_SECURE không?" Câu trả lời là có, với các ví dụ được chia sẻ trong suốt blog này. Hơn nữa, hầu hết người dùng sẽ chưa nâng cấp lên và có thiết bị Android 15 trong vài năm tới, điều FLAG_SECURE trở nên rất quan trọng đối với các thiết bị cũ.

Bạn đã sẵn sàng để bắt đầu? Kiểm tra các bản cập nhật mới nhất từ Trung tâm Nghiên cứu Bảo mật của chúng tôi để tìm hiểu thêm về:

Gọi lại ghi màn hình

Chia sẻ màn hình Cài đặt bảo mật Giám sát