맞춤 권한

OWASP 카테고리: MASVS-CODE: 코드 품질

개요

맞춤 권한과 관련된 위험은 맞춤 권한 정의가 누락되거나 철자가 틀리거나 매니페스트 내에서 해당 android:protectionLevel 속성이 잘못 사용된 경우에 발생합니다.

예를 들어 이러한 위험은 이름은 같지만 악성 앱에 의해 정의되고 다른 보호 수준이 적용된 맞춤 권한을 만들어 악용될 수 있습니다.

맞춤 권한은 다른 앱과 리소스 및 기능을 공유할 수 있도록 설계되었습니다. 맞춤 권한의 합법적인 사용 사례는 다음과 같습니다.

  • 두 개 이상의 앱 간 프로세스 간 통신 (IPC) 제어
  • 서드 파티 서비스 액세스
  • 앱의 공유 데이터에 대한 액세스 제한

영향

이 취약점을 악용하면 악성 앱이 원래 보호되도록 설계된 리소스에 액세스할 수 있습니다. 취약점의 영향은 보호되는 리소스와 원래 애플리케이션 서비스의 연결된 권한에 따라 달라집니다.

위험: 맞춤 권한 오타

맞춤 권한이 매니페스트에 선언되었지만 오타로 인해 내보낸 Android 구성요소를 보호하는 데 다른 맞춤 권한이 사용됩니다. 악성 애플리케이션은 다음과 같은 방법으로 권한의 철자를 잘못 입력한 애플리케이션을 악용할 수 있습니다.

  • 해당 권한을 먼저 등록합니다.
  • 후속 애플리케이션에서 맞춤법 예측

이를 통해 애플리케이션이 리소스에 무단으로 액세스하거나 피해자 애플리케이션을 제어할 수 있습니다.

예를 들어 취약한 앱이 권한 READ_CONTACTS를 사용하여 구성요소를 보호하려고 하지만 실수로 권한을 READ_CONACTS로 잘못 입력합니다. 악성 앱은 애플리케이션(또는 시스템)이 소유하지 않으므로 READ_CONACTS를 요청하여 보호된 구성요소에 액세스할 수 있습니다. 이 취약점의 또 다른 일반적인 변형은 android:permission=True입니다. true 및 false과 같은 값은 대소문자와 관계없이 권한 선언에 유효하지 않은 입력이며 다른 맞춤 권한 선언 오타와 유사하게 처리됩니다. 이 문제를 해결하려면 android:permission 속성 값을 유효한 권한 문자열로 변경해야 합니다. 예를 들어 앱이 사용자의 연락처에 액세스해야 하는 경우 android:permission 속성 값은 android.permission.READ_CONTACTS이어야 합니다.

완화 조치

Android 린트 검사

맞춤 권한을 선언할 때는 Android 린트 검사를 사용하여 코드의 오타와 기타 잠재적 오류를 찾으세요.

이름 지정 규칙

일관된 이름 지정 규칙을 사용하여 오타를 더 눈에 띄게 만드세요. 앱의 매니페스트에서 맞춤 권한 선언에 오타가 있는지 주의 깊게 확인하세요.

위험: 고아 권한

권한은 앱의 리소스를 보호하는 데 사용됩니다. 앱이 리소스 액세스에 필요한 권한을 선언할 수 있는 위치는 두 가지입니다.

하지만 이러한 권한은 기기의 APK 매니페스트에 있는 해당 <permission> 태그로 정의되지 않는 경우가 있습니다. 이 경우 고아 권한이라고 합니다. 이러한 상황은 다음과 같은 여러 가지 이유로 발생할 수 있습니다.

  • 매니페스트의 업데이트와 권한 확인이 있는 코드 간에 동기화가 해제될 수 있습니다.
  • 권한이 있는 APK가 빌드에 포함되지 않았거나 잘못된 버전이 포함되었을 수 있습니다.
  • 확인 또는 매니페스트의 권한 이름의 맞춤법이 잘못되었을 수 있습니다.

악성 앱이 고아 권한을 정의하고 획득할 수 있습니다. 이 경우 구성요소를 보호하기 위해 고아 권한을 신뢰하는 권한 있는 애플리케이션이 손상될 수 있습니다.

권한 있는 앱이 권한을 사용하여 구성요소를 보호하거나 제한하는 경우 악성 앱에 해당 구성요소에 대한 액세스 권한이 부여될 수 있습니다. 예로는 권한으로 보호되는 활동 실행, 콘텐츠 제공자 액세스, 고아 권한으로 보호되는 broadcast receiver에 브로드캐스트 등이 있습니다.

또한 권한이 있는 애플리케이션이 악성 앱을 합법적인 앱으로 믿고 파일을 로드하거나 콘텐츠를 로드하는 상황이 발생할 수도 있습니다.

완화 조치

앱에서 구성요소를 보호하는 데 사용하는 모든 맞춤 권한이 매니페스트에도 정의되어 있는지 확인합니다.

앱은 콘텐츠 제공자에 대한 액세스를 보호하기 위해 맞춤 권한 my.app.provider.READ 및 my.app.provider.WRITE를 사용합니다.

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"/>

앱은 이러한 맞춤 권한을 정의하고 사용하므로 다른 악성 앱이 이를 수행하지 못하도록 합니다.

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" />

위험: android:protectionLevel 오용

이 속성은 권한의 잠재적 위험 수준을 설명하고 권한을 부여할지 여부를 결정할 때 시스템에서 따라야 하는 절차를 나타냅니다.

완화 조치

일반 또는 위험한 보호 수준 피하기

권한에 일반 또는 위험한 protectionLevel을 사용하면 대부분의 앱이 권한을 요청하고 획득할 수 있습니다.

  • 'normal'은 선언만 하면 됩니다.
  • '위험'은 많은 사용자가 승인합니다.

따라서 이러한 protectionLevels은 보안을 거의 제공하지 않습니다.

서명 권한 사용 (Android >= 10)

가능한 경우 서명 보호 수준을 사용하세요. 이 기능을 사용하면 권한을 생성한 앱과 동일한 인증서로 서명된 다른 앱만 보호된 기능에 액세스할 수 있습니다. 전용 (재사용되지 않음) 서명 인증서를 사용하고 있는지 확인하고 키 저장소에 안전하게 저장합니다.

매니페스트에서 다음과 같이 맞춤 권한을 정의합니다.

XML

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

다음과 같이 이 맞춤 권한이 부여된 앱으로만 활동에 대한 액세스를 제한합니다.

XML

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

이 맞춤 권한을 선언한 앱과 동일한 인증서로 서명된 다른 앱에는 .MyActivity 활동에 대한 액세스 권한이 부여되며 매니페스트에서 다음과 같이 선언해야 합니다.

XML

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

서명 맞춤 권한 주의 (Android 10 미만)

앱이 Android 10 미만을 타겟팅하는 경우, 제거 또는 업데이트로 인해 앱의 맞춤 권한이 삭제될 때마다 이러한 맞춤 권한을 계속 사용할 수 있어 검사를 우회하는 악성 앱이 있을 수 있습니다. 이는 Android 10에서 수정된 권한 에스컬레이션 취약점 (CVE-2019-2200) 때문입니다.

이것이 맞춤 권한보다 서명 확인이 권장되는 이유 중 하나입니다 (경합 상태 위험과 함께).

위험: 경합 상태

합법적인 앱 A가 다른 X 앱에서 사용하는 서명 맞춤 권한을 정의했지만 나중에 제거된 경우 악성 앱 B가 다른 protectionLevel(예: normal)로 동일한 맞춤 권한을 정의할 수 있습니다. 이러한 방식으로 B는 앱 A와 동일한 인증서로 서명할 필요 없이 X 앱에서 해당 맞춤 권한으로 보호되는 모든 구성요소에 액세스할 수 있습니다.

A 전에 B가 설치된 경우에도 마찬가지입니다.

완화 조치

제공하는 앱과 동일한 서명으로 서명된 앱에만 구성요소를 제공하려면 해당 구성요소에 대한 액세스를 제한하는 맞춤 권한을 정의하지 않아도 됩니다. 이 경우 서명 확인을 사용할 수 있습니다. 앱 중 하나가 다른 앱에 요청을 하면 다른 앱은 요청을 따르기 전에 서로 동일한 인증서로 서명되었는지 확인할 수 있습니다.

리소스