0x01 APK应用程序是否签名异常的检测方法
要在Android上安装APK必须要进行数字签名,数字签名用于验证应用程序更新的所有者身份,验证的目的是为了防止APK应用程序被篡改或修改APK来包含恶意代码
对 APK 进行签名时,会附加一个公钥证书,这个证书是将 APK 应用程序与开发者和开发者的私钥进行关联
注:在调试模式下构建应用时,Android SDK 会使用专门为调试目的创建的调试密钥对我们要打包的APK应用程序进行签名,需要注意使用调试密钥签名的应用并不会在大多数APK应用商店中被接受和允许上架
应用程序的最终发布版本(上线生产版本)必须使用有效的发布版本的密钥进行签名。在 Android Studio 中,APK可手动或通过创建分配给发布构建类型的签名配置来对应用进行APK的签名
Android 9(API 级别 28)之前的 Android 上,所有的应用程序更新都需要使用相同的证书进行签名,所以开发者可以考虑使用 25 年或更长的有效期
注:需要注意,如果在 Google Play 上发布的应用必须使用有效期在 2033 年 10 月 22 日之后结束的密钥进行签名
三种 APK 签名方案:
v1 方案:JAR 签名
v2 方案:APK 签名方案 v2
v3 方案:APK 签名方案 v3
与 v1 方案相比,Android 7.0(API 级别 24)及更高版本支持的 v2 签名,且提供了更高的安全性和性能。Android 9(API 级别 28)及以上版本支持的 V3 签名,使应用程序能够更改其签名密钥,作为APK 更新的一部分,此功能通过允许同时使用新/旧密钥,保证了兼容性和应用程序的持续可用性。需要注意对于每个签名方案,发布APK版本也应该始终通过之前内部评估好的方案进行签名
在做静态分析(当然动态分析时跟这个一样,将APK导出来用jarsigner或apksigner工具来验证APK的签名是否异常)APK时,我们要确认几个重要的信息,比如APK的发布版本是 Android 7.0(API 级别 24)及更高版本的 v1 和 v2 方案以及 Android 9(API 级别 28)及更高版本的所有三个方案进行签名,且 APK 应用程序中的签名证书是属于开发者的
我们可以使用 Android SDK 构建工具的修订版 24.0.3 及更高版本中提供的 apksigner 工具为 APK 签名,并确保 APK 的签名能够在 APK 支持的所有版本的 Android 平台上成功通过验证,此处我们是主要是利用apksigner 工具来验证APK的签名是否是属于正确的开发者的,apksigner 工具它的位置在[SDK-Path] /build-tools/[版本]
。它位于[SDKPath]/build-tools/[version]
,更多详情请前往:https://developer.android.com/studio/command-line/apksigner?hl=zh-cn#usage
我们可以使用apksigner工具来验证 APK的 签名,apksigner 默认安装位置位于:C:\Users\xxx\AppData\Local\Android\Sdk\build-tools\33.0.0\lib
下,随后执行如下命令:
$ java -jar C:\Users\xxx\AppData\Local\Android\Sdk\build-tools\33.0.0\lib\apksigner.jar verify --verbose vuls.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
当然,我们也可以使用 jarsigner 工具来检查APK的签名证书的内容,但需要注意在调试证书时,Common Name (CN)属性要设置为 "Android Debug"
使用调试证书签名的 APK 的输出,这里我们使用JAVA自带的jarsigner工具来做签名,如何签名的命令如下:
$ jarsigner -verify -verbose -certs vuls.apksm 14112 Fri Nov 30 00:00:00 CST 1979 AndroidManifest.xml >>> 签名者
X.509, C=US, O=Android, CN=Android Debug [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]sm 6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.core_runtime.version >>> 签名者
X.509, C=US, O=Android, CN=Android Debug [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]sm 6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.lifecycle_livedata-core.version(... ...此处省略一堆内容) >>> 签名者
X.509, C=US, O=Android, CN=Android Debug [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]s = 已验证签名
m = 在清单中列出条目
k = 在密钥库中至少找到了一个证书
i = 在身份作用域内至少找到了一个证书- 由 "C=US, O=Android, CN=Android Debug" 签名
摘要算法: SHA1 (弱)
签名算法: SHA1withRSA (弱), 1024 位密钥 (弱)jar 已验证。警告: 此 jar 包含其证书链无效的条目。原因: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
此 jar 包含其签名者证书为自签名证书的条目。
SHA1 摘要算法被视为存在安全风险。此算法将在未来的更新中被禁用。
SHA1withRSA 签名算法被视为存在安全风险。此算法将在未来的更新中被禁用。
RSA 签名密钥的密钥大小 1024 被视为存在安全风险。此密钥大小将在未来的更新中被禁用。
此 jar 包含的签名没有时间戳。如果没有时间戳, 则在其中任一签名者证书到期 (最早为 2048-05-29) 之后, 用户可能无法验证此 jar。签名者证书将于 2048-05-29 到期。
上面可以看到出现了许多"CertPath not validated"错误,这个错误在 Java SDK 7 及以上版本才有,如果想忽略这个错误,我们可以使用 Android SDK 构建工具的修订版 24.0.3 及更高版本中提供的 apksigner 工具为 APK 签名来代替JAVA JDK自带的 jarsigner 工具来验证APK的证书链,如下:
检查 APK 的签名是否可在 APK 支持的所有 Android 平台上被确认为有效:
$ apksigner verify vuls.apk
检查 APK 的签名是否可在 Android 4.0.3(API 级别 15)及更高版本上被确认为有效:
$ apksigner verify --min-sdk-version 15 vuls.apk
另外签名配置可以通过 Android Studio
或 build.gradle
中的 signingConfig 块进行管理。要同时激活 v1和 v2 以及 v3 方案,必须设置以下值:
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true
在官方的 Android 开发者文档中,提供了几种配置应用发布的最佳实践
Android Studio Signature Version V1/ V2
:
V1 (jar Signature)
V1: Jar Signature 来自 JDK,可对签名后的文件,作适当修改,并重新压缩
V1 签名不保护 APK 的某些部分,例如 ZIP 元数据。APK 验证程序需要处理大量不可信(尚未经过验证)的数据结构,然后会舍弃不受签名保护的数据。这会导致相当大的受攻击面。此外,APK 验证程序必须解压所有已压缩的条目,而这需要花费更多时间和内存。为了解决这些问题,Android 7.0 中引入了 APK 签名方案 v2
V2 (Full APK Signature
)
V2: Android 7.0 (Nougat) 引入的一项新的签名方案,不能对签名后的 APK作任何修改,包括重新解压。因为它是针对字节进行的签名,所以任何改动都会影响最终结果
V3
V3:在 Android 9 中,v2 方案已更新为 v3 方案(也称为v2+),以便在签名分块中包含其他信息,但在其他方面保持相同的工作方式,该方案会对 APK 的内容进行哈希处理和签名,然后将生成的“APK 签名分块”插入到 APK 中
APK 签名方案详情,请移步Android 官网的介绍:https://source.android.com/docs/security/apksigning?hl=zh-cn
只勾选v1签名所有机型都能用,如果只勾选V2签名7.0以下机型会在直接安装完后显示未安装,7.0及以上机型使用V2的方式验证成功安装,同时勾选V1和V2对所有机型成功安装,或者在Gradle 文件中修改,如下:
signingConfigs {
debug {
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true }
release {
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true } } <p data-line="170" class="sync-line" style="margin:0;"></p>
来说说为什么我们要推荐使用v1和v2共同使用呢?因为在2020年的时候Google公布的“Janus”漏洞,可使攻击者将Dex附加到原有的apk之上,绕过签名认证,在执行时优先执行附加的dex文件,这个漏洞直接影响Android 5.0~8.0
上所有基于signature scheme V1
签名的APK。这里说哈,对应APK应用程序来说签名确是唯一的,是用来证明是谁开发的是否是盗版或恶意APK,那么假如正版应用被恶意修改,其签名也会随之被破坏,需要重新签名才能安装到Android上,而且市面上各种APK应用商店和手机应用助手类的工具,往往通过包名和签名来判断一个APK应用程序是否是盗版或恶意APK应用程序
注:在官方的 Android 开发者文档中,官方提供了几种配置应用发布的方式,详情请移步:https://developer.android.com/studio/publish/preparing#publishing-configure
参考链接:
https://www.cnblogs.com/daemon369/p/3227309.html
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md
https://support.google.com/googleplay/android-developer/answer/9848633?hl=zh-Hans
https://blog.csdn.net/beyond702/article/details/56281068
https://www.jianshu.com/p/271474cd1d91
推荐阅读