移动客户端程序安全

app程序安全

文章目录

1.安装包签名和证书

漏洞说明：

检测客户端是否经过正确签名（正常情况下应用都应该是签名的，否则无法安装）。检测app移动客户端安装包是否正确签名，通过签名，可以检测出安装包在签名后是否被修改过。

危险等级：

低

漏洞危害：

若使用debug证书签名，则APP中一部分signature级别的权限控制会失效，攻击者甚至可以编写安装是能直接替换掉这些客户端的恶意APP。

安全建议：

建议移动客户端使用从属方证书进行签名后进行发布而不是使用第三方开发商的证书进行签名，以防开发商内部监管异常，证书滥用的情况出现。

测试步骤：

利用java/jdk/bin下的jarsigner.exe工具，对签名进行校验、

jarsigner.exe -verify xxx.apk    -verbose -certs

关注最后的结果，显示jar已验证则表示签名正常（下面的警告是因为签名密钥不在本地密钥库中）。同时标注了加密算法

结果分析：

可以看到目标使用了SHA256withRSA算法，2048位RSA密钥，算法为安全算法；同时签名正常，均为官方签名（geekBang）

2.应用程序数据可备份

漏洞说明：

Android 2.1以上的系统可为App提供应用程序数据的备份和恢复功能，该由AndroidMainfest.xml文件中的allowBackup属性值控制，其默认值为true。当该属性没有显式设置为false时,攻击者可通过adb backup和adb restore对App的应用数据进行备份和恢复,从而可能获取明文存储的用户敏感信息。

危险等级：

中

漏洞危害：

当allowBackup标志值为true时，即可通过adb backup和adb restore来备份和恢复应用程序数据；

安全建议：

将allowBackup的属性显式设置为false，以关闭应用数据备份功能；或者使用具有本地数据加密功能的APP安全加固方案具有本地数据加密功能，避免本地数据泄露。

测试步骤：

解压当前安装apk，在解压后的文件中找到AndroidManifest.xml

利用AXMLPrinter2.jar，将该xml文件转换为可读的txt文件

java -jar AXMLPrinter2.jar AndroidManifest.xml >> AndroidManifest.txt

打开AndroidManifest.txt，寻找属性allowBackup，查看是否设置为false

结果分析：

可以看到allowBackup的值为false，测试结果安全。

3.debug模式

漏洞说明：

客户端软件AndroidManifest.xml中的android:debuggable="true"标记如果开启，可被Java调试工具例如jdb进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑，我们经常使用android.util.Log来打印日志。软件发布后调试日志被其他开发者看到，容易被反编译破解。

危险等级：

高

漏洞危害：

当应用可调试时，攻击者可利用动态调试的方式理解应用逻辑，便于对应用的关键功能进行破解。

安全建议：

建议app移动客户端在上线之前关闭Debug模式，保证在移动客户端在正常进行所有业务逻辑时中不会打印任何有关用户和服务器的敏感信息。

测试步骤：

检查AndroidManifest.xml文件中的debuggable属性

解压当前安装apk，在解压后的文件中找到AndroidManifest.xml

利用AXMLPrinter2.jar，将该xml文件转换为可读的txt文件

java -jar AXMLPrinter2.jar AndroidManifest.xml >> AndroidManifest.txt

打开AndroidManifest.txt，寻找debuggable属性

结果分析：

发现未设置android:debuggable属性，该属性默认为false，不存在漏洞

4.移动客户端程序保护

漏洞说明：

app代码未保护，可能面临被反编译的风险。反编译是将二进制程序转换成易读的一种描述语言的形式。反编译的结果是应用程序的代码，这样就暴露了客户端的所有逻辑，比如与服务端的通讯方式，加解密算法、密钥，转账业务流程、软键盘技术实现等等。攻击者可以利用这些信息窃取客户端的敏感数据，包括手机号、密码；截获与服务器之间的通信数据；绕过业务安全认证流程，直接篡改用户账号信息；对服务器接口发起攻击等。

危险等级：

高

漏洞危害：

该app未进行加固保护。较易被破解。可以被反编译后获取源代码。

安全建议：

建议移动客户端进行加壳处理防止攻击者反编译app客户端，同时混淆app客户端代码。

测试步骤：

尝试反编译apk – 检查是否能够正常反编译，并分析核心功能java代码

首先将apk当成zip文件进行正常解压，得到classes.dex文件

此时的dex是无法读取的，需要将其进行转换，利用dex2jar（https://github.com/pxb1988/dex2jar）

dex2jar.bat classes.dex 文件路径（默认空 当前目录即可）

然后在利用 jd-gui 打开 jar 文件，即可得到 JAVA 代码

结果分析：

经过反编译可以成功看到相关源代码，且没有做加壳和混淆，存在漏洞。

5.应用完整性校验

漏洞说明：

测试客户端程序是否对自身完整性进行校验。攻击者能够通过反编译的方法在客户端程序中植入自己的木马，客户端程序如果没有自校验机制的话，攻击者可以通过篡改客户端程序窃取手机用户的隐私信息。

危险等级：

中

漏洞危害：

攻击者可将APK反编译后插入恶意代码，然后重打包签名后发布到安卓应用市场，使用后的用户便会受到攻击。

安全建议：

建议移动客户端在每次启动时进行移动客户端自身的应用完整性校验，在验证逻辑中不使用MANIFEST.MF中的数据作为验证凭证；同时需验证是否有不属于该移动客户端版本的新文件添加，验证过程于服务器端完成。

测试步骤：

通过对目标apk进行反编译—重新打包（修改包内内容）—查看重新编译后的apk是否报错来判断是否存在漏洞

注意：工具路径不要出现中文

1）首先利用apktool.jar（https://bitbucket.org/iBotPeaches/apktool/downloads/）对目标apk进行解包

java -jar apktool.jar d -f apk apk文件路径 -o 解包目标文件夹

解压失败，提示dex加密
java -jar apktool.jar d -f apk apk文件路径 --only-main-classes -o 解包目标文件夹

踩坑记录

如果遇到解压失败，提示dex加密情况

此时需要添加–only-main-classes参数

2）将解包目录重新打包成未签名的 APK 文件，命令如下：

java -jar apktool.jar b -f 待打包的文件夹 -o 输出 apk 路径

当目标解包后的文件夹中存在/res/navigation路径时，则使用以下命令

java -jar apktool.jar b -f --use-aapt2  待打包的文件夹  -o  输出 apk 路径

打包如果失败可以尝试删除-f参数

//打包出现错误提示为：Failed to generate resource table for split ''
找到对应的xml文件进行修改，将@android改为@*android

打包出现报错，提示 Failed to generate resource table for split ‘’ ，此时需要找到对应的xml文件进行修改，将

@android

改为

@*android

3）如果上一步重新打包失败则代表无漏洞，如果成功则继续进行测试，此时将解包的资源文件进行替换，可以尝试替换logo图片（例如/res/xxxx-hdpi路径下的logo文件）

4）替换完成之后，继续尝试重新打包

java -jar apktool.jar b -f --use-aapt2  待打包的文件夹  -o  输出 apk 路径

5）打包成功后，用SignApk.jar（https://android.googlesource.com/platform/prebuilts/sdk/+/refs/heads/master/tools/lib/），对未签名的 APK 文件进行签名，命令如下（需要java8环境，同时需要引用so文件，经检测在linux下使用）：

java -Djava.library.path=. -jar signapk.jar testkey.x509.pem  testkey.pk8 待签名apk 文件路径 签名后输出apk 路径

-Djava.library.path=   后面接的是libconscrypt_openjdk_jni.so文件的路径，当前已在同级目录下（下载路径：https://android.googlesource.com/platform/prebuilts/sdk/+/refs/heads/android10-qpr1-b-release/tools/linux/lib64/）