CustomPermission

发表于 | 分类于

《Resolving the predicament of Android custom permissions》
来源：NDSS 2018 (CCF B)
关键词：Android, Custom Permission

1.针对问题：

自定义权限的不安全性

2.Contribution

（1） 提出Android现有的自定义权限存在的漏洞以及根据漏洞实施了两大攻击

  • 恶意app可绕过用户交互需求直接获取危险权限，窃取高危险级的系统资源（Android6.0及以上）
  • 恶意app可提升自己的权限以访问其他app受保护的组件
    （2） 建立了第一套Android下运行时权限模型，提出了Cusper，解决上述存在的漏洞

3.Inroduction

Android权限模型：Normal，Signature，Dangerous
Android 6.0之前：安装时权限
Android 6.0之后：运行时权限（仅针对dangerous权限）
Android不允许两个同名权限同时存在于一个设备上。
系统权限：保护系统资源
自定义权限：第三方应用程序可自己定义新的权限。 保护不同app之间或者系统组件间的IPC资源
然而！
（1）安卓对待自定义权限和系统权限没有区别
（2）没有对自定义权限的命名规则约束，可以随便取自定义权限名称

自定义权限的使用情况如图所示：
title

4.Attack

利用自定义权限获取未授权的平台和app资源

两种攻击：custom permission upgrade，confused deputy
攻击前准备：
抓取应用市场（例如Google Play Store）下载感兴趣的目标应用，并进行逆向，分析Android Manifest文件和源代码，以观察自定义权限用于保护应用程序组件的情况。
攻击者可以在应用市场上构建和分发一系列恶意应用，利用Android的自定义权限漏洞对被攻击应用和平台发起攻击。

A legacy application (legacy app) is a software program that is outdated or obsolete. Although a legacy app still works, it may be unstable because of compatibility issues with current operating systems (OSes), browsers and information technology (IT) infrastructures.

1.custom permission upgrade attack
原理：系统权限和自定义权限没有隔离
效果：攻击者可在未经过用户交互的情况下，直接获取dangerous级别的系统权限。
概述：
（1）首先攻击者创建一个app，声明一个自定义权限，级别为normal或signature，并且将自定义权限设置为系统权限组的一部分（如存储，或照相机）
（2）更新此自定义权限的定义，将保护级别更改为dangerous，并继续在相应的应用市场上推送其应用的更新，此时攻击者app将自动获取授权，同时自动获取同组其他危险权限，而不会告知用户
title
左边：已获取该system permission group的权限
右边：可获取该dangerous权限及该权限组的所有权限

分析：
（1）Android处理自定义权限的方式与系统权限相同
（2）normal和signature权限在安装时授予。对于传统应用程序（SDK<23），dangerous权限也在安装时授予;而对于新应用程序，则在运行时被授予。

当system权限从安装时授予变成运行时授予，意味着 这个app升级到了SDK 23以上
当custom 权限升级，暗示着 这个app有可能升级了，也有可能权限级别从normal/signature变成了dangerous
但是系统并不具备区分这两种情况的能力

如果传统应用程序升级到SDK 23或更高，则系统还将授予的危险权限从安装时 “升级”到运行时权限，并在用户未通过权限设置手动撤销它们时自动授予它们（由FLAG_PERMISSION REVOKE_ON_UPGRADE标志被设置为允许）。
PackageManager.FLAG_PERMISSION_REVOKE_ON_UPGRADE：如果permission被标记了这个flag，那么表示，app升级后被deny的permission,会依然是deny的状态。这个flag会在下面的情况中用到。适用于L以前版本的app,安装得到M的device上，如果它的dangerous permission被撤销了，比如通过settings里面的permission管理撤销或者device policy中设定，那么该APP升级到适用于M新的permission模式后，那么升级后这个permission依然是撤销的状态。也就是dangerous permission如果在升级之前被撤销过，升级后依然是撤销的状态。

2.confused deputy attack
原理：利用自定义权限不严格的命名约定
效果：使操作系统向攻击应用授予被攻击应用的签名级自定义权限（俩应用为不同证书签名），以此获取对被攻击应用组件的未经授权的访问。
概述：
假定被攻击应用自定义权限名为N

  1. 攻击者创建两个app，definer app A自定义一个名称为N的权限，但将保护级别设置为dangerous，attack app仅在清单中请求该权限N
  2. Definer app需要先由用户安装，然后安装attack app。在运行时将definer app的欺骗权限授予attack app后，definer app可由用户卸载或由应用程序开发人员更新，以便事后安装被攻击应用。
  3. 安装被攻击app后，attack app能够向受害者发起攻击，以便自由访问被攻击app的受到签名保护的组件，即使它未使用与被攻击app相同的应用程序证书进行签名。
    title
    Google承认这是高度严重的攻击，因为它绕过了隔离应用程序数据与其他应用程序的操作系统保护。

分析：
（1）在更新或卸载app时，系统并不立即更新原有的自定义权限，而是在重新声明具有相同名称的新权限时撤销。
（2）由于Android在权限执行期间仅使用权限名称，因此无法区分具有相同声明名称的两个不同权限。因此，持有“暂时休眠”危险权限的应用程序会以未授权的方式访问受同名signature权限保护的组件。

目标app：
（1）CareZone
所有的隐私数据都存在一个被signature级别的自定义权限保护的content provider中

1
2
3
<permission android:label="@string/permission_access_provider_label" android:name="com.carezone.caredroid.careapp.permission.CZ_CONTENT_PROVIDER" android:protectionLevel="signature|signatureOrSystem" android:description="@string/permission_access_provider_desc" />

<provider android:name="com.carezone.caredroid.careapp.content.provider.CareAppProvider" android:permission="com.carezone.caredroid.careapp.permission.CZ_CONTENT_PROVIDER" android:exported="true" android:authorities="@string/cz_authority_content" android:syncable="true" />

（2）Skype
有一个被signature级别的权限保护的Activity，该Activity的功能是拨打电话

5.Cusper

修改Android源码BasePermission等class文件

A. 隔离系统权限和自定义权限

  • sourcePackage（权限的始发包名）无法可靠的标记权限是系统还是自定义
  • 使用额外的成员变量来扩展权限的对象表示，以指示此权限是否为自定义权限
  • 应用程序声明自定义权限组时，禁止使用系统权限组前缀（android.permission-group）
  • 区分系统和自定义权限后，设置FLAG_PERMISSION_REVOKE_ON_UPGRADE标志位，攻击者将应用更新为dangerous权限时，系统不会自动授予

B.系统级的自定义权限命名约束
设想解决：
1.将app包名作为源id，强制所有自定义权限名称都内部添加声明它的app的id为前缀：source_id:permission_name，以此解决不同app的同名权限欺骗攻击
2.系统只允许签名相同的app申请同名自定义权限

但是存在两个问题：
1.恶意应用刻意伪造包名与被攻击者包名一致？
2.同一开发者开发的多个应用之间若要互相申请使用权限？
解决：使用app的signature作为source_id

6.Android Permissions Alloy Model

Alloy：一种轻量级的formal语言

（1）构建权限，applications，组件，设备的相关数据结构体
Permissions {name, package, protection level, permission group}
Applications {packageName, signature, declaredPerms, usesPerms, guard, components, targetSDK, permissionState}
Components {app, guard} //guard是指protected permission
Device {apps, builtinPerms, customPerms, platform PackageName, platformSignature, builtinPermGroups}
（2）与权限相关的系统操作 {install, uninstall, update}
（3）实现效果：可以防止以上提出来的两种攻击