Quyền tuỳ chỉnh

Danh mục OWASP: MASVS-CODE: Chất lượng mã

Tổng quan

Các rủi ro liên quan đến Quyền tuỳ chỉnh phát sinh khi định nghĩa về quyền tuỳ chỉnh bị thiếu hoặc sai chính tả, hoặc khi thuộc tính android:protectionLevel tương ứng bị sử dụng sai trong Tệp kê khai.

Ví dụ: những rủi ro này có thể bị khai thác bằng cách tạo một quyền tuỳ chỉnh có cùng tên, nhưng do một ứng dụng độc hại xác định và áp dụng các cấp độ bảo vệ khác nhau.

Quyền tuỳ chỉnh được thiết kế để cho phép chia sẻ tài nguyên và khả năng với các ứng dụng khác. Sau đây là ví dụ về trường hợp sử dụng hợp lệ đối với quyền tuỳ chỉnh:

  • Kiểm soát hoạt động giao tiếp liên quy trình (IPC) giữa hai hoặc nhiều ứng dụng
  • Truy cập vào các dịch vụ của bên thứ ba
  • Hạn chế quyền truy cập vào dữ liệu được chia sẻ của một ứng dụng

Tác động

Tác động của việc khai thác lỗ hổng này là một ứng dụng độc hại có thể truy cập vào các tài nguyên vốn được bảo vệ. Hậu quả của lỗ hổng này phụ thuộc vào tài nguyên được bảo vệ và các quyền liên kết của dịch vụ ứng dụng ban đầu.

Rủi ro: Lỗi chính tả trong quyền tuỳ chỉnh

Một quyền tuỳ chỉnh có thể được khai báo trong Tệp kê khai, nhưng một quyền tuỳ chỉnh khác được dùng để bảo vệ các thành phần Android đã xuất do lỗi chính tả. Một ứng dụng độc hại có thể lợi dụng những ứng dụng đã viết sai chính tả một quyền bằng cách:

  • Trước tiên, hãy đăng ký quyền đó
  • Dự đoán lỗi chính tả trong các ứng dụng tiếp theo

Điều này có thể cho phép một ứng dụng truy cập trái phép vào các tài nguyên hoặc kiểm soát ứng dụng mục tiêu.

Ví dụ: một ứng dụng dễ bị tấn công muốn bảo vệ một thành phần bằng cách sử dụng quyền READ_CONTACTS nhưng vô tình viết sai chính tả quyền này thành READ_CONACTS. Một ứng dụng độc hại có thể khai báo READ_CONACTS vì ứng dụng này không thuộc quyền sở hữu của bất kỳ ứng dụng nào (hoặc hệ thống) và có quyền truy cập vào thành phần được bảo vệ. Một biến thể phổ biến khác của lỗ hổng này là android:permission=True. Các giá trị như true và false, bất kể cách viết hoa, đều là thông tin đầu vào không hợp lệ cho khai báo quyền và được xử lý tương tự như các lỗi chính tả khai báo quyền tuỳ chỉnh khác. Để khắc phục vấn đề này, bạn nên thay đổi giá trị của thuộc tính android:permission thành một chuỗi quyền hợp lệ. Ví dụ: nếu ứng dụng cần truy cập vào danh bạ của người dùng, thì giá trị của thuộc tính android:permission phải là android.permission.READ_CONTACTS.

Giải pháp giảm thiểu

Kiểm tra để tìm lỗi mã nguồn trên Android

Khi khai báo các quyền tuỳ chỉnh, hãy sử dụng các quy trình kiểm tra lint của Android để giúp bạn tìm lỗi chính tả và các lỗi tiềm ẩn khác trong mã.

Quy ước đặt tên

Sử dụng quy ước đặt tên nhất quán để dễ nhận thấy lỗi chính tả hơn. Kiểm tra kỹ các nội dung khai báo quyền tuỳ chỉnh trong Tệp kê khai của ứng dụng để tránh lỗi chính tả.

Rủi ro: Quyền không còn được dùng

Quyền được dùng để bảo vệ các tài nguyên của ứng dụng. Có 2 vị trí mà ứng dụng có thể khai báo các quyền cần thiết để truy cập vào tài nguyên:

Tuy nhiên, đôi khi các quyền này không được xác định bằng thẻ <permission> tương ứng trong Tệp kê khai của một APK trên thiết bị. Trong trường hợp này, chúng được gọi là quyền bị bỏ rơi. Tình huống này có thể xảy ra vì một số lý do, chẳng hạn như:

  • Có thể xảy ra tình trạng không đồng bộ giữa các bản cập nhật trên Tệp kê khai và mã có quy trình kiểm tra quyền
  • APK có các quyền có thể không được đưa vào bản dựng hoặc có thể được đưa vào phiên bản không chính xác
  • Tên quyền trong nội dung kiểm tra hoặc Tệp kê khai có thể bị viết sai chính tả

Một ứng dụng độc hại có thể xác định một quyền không còn được dùng và giành được quyền đó. Nếu điều này xảy ra, các ứng dụng đặc quyền tin tưởng quyền không còn liên kết để bảo vệ một thành phần có thể bị xâm phạm.

Trong trường hợp ứng dụng có đặc quyền sử dụng quyền này để bảo vệ hoặc hạn chế bất kỳ thành phần nào, điều này có thể cấp cho ứng dụng độc hại quyền truy cập vào thành phần đó. Ví dụ: khởi chạy các hoạt động được bảo vệ bằng một quyền, truy cập vào một trình cung cấp nội dung hoặc truyền tin đến một bộ nhận tín hiệu truyền tin được bảo vệ bằng quyền không dùng nữa.

Điều này cũng có thể tạo ra tình huống trong đó ứng dụng đặc quyền bị lừa tin rằng ứng dụng độc hại là một ứng dụng hợp pháp và do đó tải các tệp hoặc nội dung.

Giải pháp giảm thiểu

Đảm bảo rằng tất cả các quyền tuỳ chỉnh mà ứng dụng của bạn dùng để bảo vệ các thành phần cũng được xác định trong Tệp kê khai.

Ứng dụng này sử dụng các quyền tuỳ chỉnh my.app.provider.READ và my.app.provider.WRITE để bảo vệ quyền truy cập vào một trình cung cấp nội dung:

XML

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

Ứng dụng cũng xác định và sử dụng các quyền tuỳ chỉnh này, do đó ngăn các ứng dụng độc hại khác làm như vậy:

XML

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

Rủi ro: Sử dụng sai android:protectionLevel

Thuộc tính này mô tả mức độ rủi ro tiềm ẩn trong quyền và cho biết những quy trình mà hệ thống nên tuân theo khi quyết định có cấp quyền hay không.

Giải pháp giảm thiểu

Tránh sử dụng Cấp độ bảo vệ bình thường hoặc nguy hiểm

Việc sử dụng bình thường hoặc nguy hiểm protectionLevel đối với các quyền của bạn có nghĩa là hầu hết các ứng dụng đều có thể yêu cầu và nhận được quyền này:

  • "normal" chỉ yêu cầu khai báo
  • "nguy hiểm" sẽ được nhiều người dùng phê duyệt

Do đó, những protectionLevels này không có tính bảo mật cao.

Sử dụng quyền chữ ký (Android >= 10)

Sử dụng các cấp độ bảo vệ chữ ký bất cứ khi nào có thể. Việc sử dụng khả năng này đảm bảo rằng chỉ những ứng dụng khác được ký bằng cùng một chứng chỉ với ứng dụng đã tạo quyền mới có thể truy cập vào các tính năng được bảo vệ đó. Đảm bảo bạn đang sử dụng một chứng chỉ ký chuyên dụng (không dùng lại) và lưu trữ chứng chỉ đó một cách an toàn trong kho khoá.

Xác định quyền tuỳ chỉnh như sau trong tệp kê khai:

XML

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

Hạn chế quyền truy cập vào, ví dụ: một hoạt động, chỉ cho những ứng dụng đã được cấp quyền tuỳ chỉnh này, như sau:

XML

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

Mọi ứng dụng khác được ký bằng cùng một chứng chỉ với ứng dụng đã khai báo quyền tuỳ chỉnh này sẽ được cấp quyền truy cập vào hoạt động .MyActivity và cần khai báo quyền đó như sau trong Tệp kê khai:

XML

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

Cảnh giác với Quyền tuỳ chỉnh theo chữ ký (Android < 10)

Nếu ứng dụng của bạn nhắm đến Android < 10, thì bất cứ khi nào các quyền tuỳ chỉnh của ứng dụng bị xoá do gỡ cài đặt hoặc cập nhật, có thể các ứng dụng độc hại vẫn có thể sử dụng những quyền tuỳ chỉnh đó và do đó bỏ qua các bước kiểm tra. Nguyên nhân là do lỗ hổng leo thang đặc quyền (CVE-2019-2200) đã được khắc phục trong Android 10.

Đây là một trong những lý do (cùng với nguy cơ xảy ra tình trạng xung đột dữ liệu) khiến bạn nên sử dụng quy trình kiểm tra chữ ký thay vì quyền tuỳ chỉnh.

Rủi ro: Tình huống tương tranh

Nếu một ứng dụng hợp pháp A xác định một quyền tuỳ chỉnh chữ ký mà các ứng dụng X khác sử dụng nhưng sau đó ứng dụng này bị gỡ cài đặt, thì một ứng dụng độc hại B có thể xác định cùng một quyền tuỳ chỉnh đó bằng một protectionLevel khác, ví dụ: normal. Bằng cách này, B có quyền truy cập vào tất cả các thành phần được bảo vệ bằng quyền tuỳ chỉnh đó trong các ứng dụng X mà không cần phải được ký bằng cùng một chứng chỉ như ứng dụng A.

Điều tương tự cũng xảy ra nếu B được cài đặt trước A.

Giải pháp giảm thiểu

Nếu muốn chỉ cung cấp một thành phần cho những ứng dụng được ký bằng chữ ký giống như ứng dụng cung cấp, bạn có thể tránh được việc xác định các quyền tuỳ chỉnh để hạn chế quyền truy cập vào thành phần đó. Trong trường hợp này, bạn có thể sử dụng quy trình kiểm tra chữ ký. Khi một trong những ứng dụng của bạn đưa ra yêu cầu với ứng dụng khác, ứng dụng thứ hai có thể xác minh rằng cả hai ứng dụng đều được ký với cùng một chứng chỉ trước khi tuân thủ yêu cầu đó.

Tài nguyên