Android安全开发之通用签名风险_问答-阿里云开发者社区

Android安全开发之通用签名风险

作者：伊樵、舟海、呆狐@阿里聚安全

1 通用签名风险简介

1.1 Android应用签名机制

阿里聚安全漏洞扫描器有一项检测服务是检测APP的通用签名风险。Android系统要求安装的应用必须用数字证书进行签名后才能安装，并且签名证书的私钥由应用开发者保存。签名证书的生成也由开发者自己生成。在应用安装时会校验包名（package name）和签名，如果系统中已经存在了一个相同的包名和签名的应用，将会用新安装的应用替换旧的；如果包名相同但是签名不同，则会安装失败。

为什么需要数字签名？
数字签名是防止要保护的内容被篡改，用非对称加密算法。先对要保护的内容进行消息摘要，用私钥对消息摘要进行加密，生成数字签名，将数字签名和要保护的内容一起分发出去。内容接收者用公钥对数字签名解密得到发送者给的消息摘要A，内容接收者对接收到的内容进行用相同的消息摘要算法处理得到消息摘要B，对比A和B是否相同，来判定传送的内容是否被篡改。正常的APK文件是个ZIP压缩文件，除了应用的可执行文件、资源文件，还包括这些可执行文件、资源文件的摘要信息，数字证书的公钥信息等。并且通过这些签名信息可以确定APP和其开发者的关系。

进行签名需要的工具有哪些？
对apk进行签名需要用到签名证书和签名工具。Android系统要求对APP进行签名的数字证书可以由开发者自己生成。签名工具有jarsigner和signapk。jarsigner是Java本身自带的一个工具，他也可以对jar进行签名的；而signapk是专门为了Android应用程序apk进行签名的工具。二者的区别是：jarsigner工具签名时使用的是keystore签名文件，signapk工具签名时使用的是pk8，x509.pem文件。

签名后的文件都有哪些？
应用签名完后在应用的META-INF目录下会有三个文件：
CERT.RSA、CERT.SF和MANIFEST.MF。
    MANIFEST.MF中保存了所有其他文件的SHA1摘要并base64编码后的值。
    CERT.SF文件是对MANIFEST.MF文件中的每项中的每行加上“\r\n”后，再次SHA1摘要并base64编码后的值（这是为了防止通过篡改文件和其在MANIFEST.MF中对应的SHA1摘要值来篡改APK，要对MANIFEST的内容再进行一次数字摘要）。
    CERT.RSA文件：包含了签名证书的公钥信息和发布机构信息。

对安装包的校验过程在源码的frameworks/base/core/java/android/content/pm/PackageParser.java类中可以看到，具体可看阿里聚安全博客的另外一篇文章：Android5.1.1 - APK签名校验分析和修改源码绕过签名校验。

1.2 通用签名风险

什么是通用签名？
搭建好Android开发环境后（使用Eclipse或Android Studio），对APK签名的默认密钥存在debug.keystore文件中。在linux和Mac上debug.keystore文件位置是在~/.android路径下，在windows目录下文件位置是C:\user\用户名.android路径下。

除了debug.keystore外，在AOSP发布的Android源码中，还有以下几个证书是公开的，任何人都可以获取，在源码的build/target/product/security目录中：

这几个证书的作用：
testkey
    Generic default key for packages that do not otherwise specify a key.
platform
    Test key for packages that are part of the core platform.
shared
    Test key for things that are shared in the home/contacts process.
media
    Test key for packages that are part of the media/download system.
verity
    Test Key for verifiedboot system imagein Android Lollipop. Sign boot.img,sign verity metadata in system.img.

通用签名风险：
（1）如果攻击者的应用包名与目标应用相同，又使用了相同的密钥对应用进行签名，攻击者的应用就可以替换掉目标应用；
（2）另外目标应用的自定义权限android:protectionlevel为“signature”或者“signatureOrSystem”时，保护就形同虚设；
（3）如果设备使用的是第三方ROM，而第三方ROM的系统也是用AOSP默认的签名，那么使用如果使用系统级签名文件签名过的应用，权限就得到了提升。

对于普通开发者如果自己的签名证书泄露也可能发生(1)、(2)条所提到的风险。

2 通用签名风险示例

使用通用签名的公开案例非常少，不过我们阿里聚安全漏洞扫描器还是发现了一些应用使用了通用签名，扫描结果数据库中查到曾经有819个APP使用了AOSP的签名证书（排查了几个APP的最新版，但都已经用了新的签名；也不排除应用被恶意攻击者反编译重打包后使用通用签名证书签名）。另外还有不少私有签名证书泄露、滥用的（使用通用签名证书其实就相当于泄露了签名证书）情况。

以乌云公开的WooYun-2014-67027为例，有安全研究人员发现有一个数字证书签名被很多银行的手机客户端所使用。与此同时还发现了几款个人开发者类应用也使用了此证书签名。而这种数字签名被滥用的行为存在极大的安全隐患。

解压应用安装包，可用keytool查看应用的签名证书信息：
keytool -printcert -v -file META-INF/CERT.RSA

经挖掘和分析，研究人员发现目前共有23款不同银行手机银行客户端使用该签名：

在应用市场内，目前共发现6款个人开发的应用同时使用该数字证书签名：

事情发生的原因是银行的外包开发管理不严，不同银行的APP居然用同样的数字证书签名，并且开发者还将证书用于了个人APP的开发中。如果签名证书被恶意攻击者获取，可以编写安装是能直接替换掉这些银行客户端的恶意APP。

还可以使用AOSP通用签名提升应用权限：
本人直接编译AOSP源码得到的ROM，使用AOSP的默认证书，在设置->关于手机，版本号中可查看到：

对于普通的用默认debug.keystore证书签名的App，如果在AndroidManfiest.xml的manifest节点加入android:sharedUserId=”android.uid.system”这个属性，安装时会提示错误：

如果对app-debug.apk使用AOSP提供的platform.x509.pem和platform.pk8重新签名，则可以安装成功：

查看应用的进程属性，已是system用户组。

目前有不少的第三方ROM使用的AOSP提供的默认签名（见参考[4]的论文中所提）。

3 阿里聚安全对开发者建议

（1）上线前用阿里聚安全的漏洞扫描器进行一下检查。

阿里聚安全的漏洞扫描器目前已能检查出通用签名风险，未来可能增加检测证书是否泄漏风险。还可以发现其他安全风险。

（2）生成自己专有的签名证书，证书分类使用。
使用keytool工具生成.keystore的数字证书：
    keytool -genkey -v -keystore my-release-key.keystore
    -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

使用jarsigner工具对打包好的APK进行签名：
    jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1
    -keystore my-release-key.keystore my_application.apk alias_name

使用openssl生成pk8和x509.pm的证书，参考如下：