APP安全检测手册

随着运营商新技术新业务的发展，运营商层面对安全的要求有所变化，渗透测试工作将会面临内容安全、计费安全、业务逻辑及APP等方面的挑战。随着运营商自主开发的移动APP越来越多，这些APP可能并不会通过应用市场审核及发布，其中的安全性将面临越来越多的挑战。

在海量的APP应用中，可能会遇到各种各样的威胁：木马、病毒、篡改、破解、钓鱼、二次打包、信息泄露、资源篡改、信息劫持等。

为有效的针对上述各种威胁进行有效防范，保障运营商和客户的业务安全，本手册将着重从下表所列项目针对APP应用（安卓）安全进行检测。

表1  APP应用安全测试要点

Java JDK 1.8.0_151，Android SDK。

MobSF框架，GameGuardian（内存DUMP），夜神模拟器（运行环境模拟），Android Killer（反编译集成）,改之理（反编译集成），7zip，dex2jar（文件转换），jd-gui，apktool，activity 劫持测试工具等，详细清单请参照附录。

2.1.1描述

在Android中，包名相同的两个APK会被认为是同一个应用。当新版本覆盖旧版本时，签名证书必须一致，否则会被拒绝安装（即使开启了“允许未知来源的应用”）。如果APK没有使用自己的证书进行签名，将会失去对版本管理的主动权。本项检测是检测客户端是否经过恰当签名（正常情况下应用都应该是签名的，否则无法安装），签名是否符合规范。

2.1.2测试步骤

打开cmd，进入到JDK的安装路径，C:\Program Files\Java\jdk1.8.0_111\bin，输入命令:

测试结果如下：

图1 签名验证

如上图，如果证书指纹与客户一致，说明测试结果为安全。

检测签名的字段是否正确标示客户端程序的来源和发布者身份，输入命令：

若各个字段与预期的一致，则测试通过

要说明的是，只有在使用直接客户的证书签名时，才认为安全。Debug证书、第三方（如开发方）证书等均认为存在风险。

2.1.3威胁等级

安装包签名的威胁等级判断一般如下：

若客户端安装包签名有异常（例如签名证书为第三方开发商而不是客户端发布方），此时高风险；若无异常则无风险。

2.1.4安全建议

将安装包进行签名并检测安装包签名的异常。

2.2.1描述

测试客户端安装程序，判断是否能反编译为源代码，java 代码和so 文件是否存在代码混淆等保护措施。未作保护的 java 代码，可以轻易分析其运行逻辑，并针对代码中的缺陷对客户端或服务器端进行攻击。

成功的反编译将使得攻击者能够完整地分析APP的运行逻辑，尤其是相关业务接口协议、和通信加密的实现。

2.2.2 名词解释

smali语言是一种Android系统特有的中间代码语言。Android系统使用Dalvik指令（可执行文件为*.dex）代替了通常的JVM中间代码（可执行文件为*.class、*.jar）。对应Dalvik指令的“汇编语言”便是smali。因此，从*.dex中恢复smali代码比恢复JAVA代码要容易，成功率更高。如果APK经过花指令处理，会导致无法恢复smali代码（表现为apktool解包失败）。

花指令：由设计者特别构思，希望使反汇编的时候出错，让破解者无法清楚正确地反汇编程序的内容，迷失方向。经典的应用，目标位置是另一条指令的中间，这样在反汇编的时候便会出现混乱。

2.2.3 测试步骤

把apk当成zip并解压（后缀改为zip），得到classes.dex文件（有时可能不止一个dex文件，文件名均以classes***开头），如下图：

图2      APK文件结构

使用dex2jar执行如下命令：

得到classes.dex.jar，然后使用jd-gui打开jar文件，即可得到JAVA代码。或者直接使用smali2java打开apk文件，也可反编译回Java代码。

图3 反编译后的APK

有时用apktool能够解包并查看smali，但dex2jar却不行。如果dex2jar反编译失败，可以试试看能不能恢复smali代码。

如上图，逆向后发现是没混淆的情况，是不安全的。

如果代码经过混淆，或者有加壳措施，不能完整恢复源代码的，都可以认为此项安全。

下图为混淆后的代码样例：

图4 有混淆的代码

2.2.4威胁等级

若客户端进行加固保护，此时认为无风险。

若大部分代码（包括核心代码）经过混淆，此时低风险。

若部分代码混淆，关键代码（加密或通信等）可以获知其关键代码，此时中风险。

2.2.5安全建议

建议客户端程序可以把关键代码以 JNI 方式放在 so 库里。so 库中是经过编译的arm 汇编代码，可以对其进行加壳保护，以防止逆向分析。

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

用ApkTool将目标APK文件解包，命令如下；

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

图5 解包后的APK资源目录

随便找一个解包目录里的资源文件进行修改，推荐找到splash.png进行修改（容易确认结果）；将APK拖入Androidkiller,搜索splash.png，修改替换，，然后签名打包回APK。

将签了名的APK安装、运行、确认是否存在自校验；需要注意的是，如果之前安装的APK和修改后的APK签名不同，就不能直接覆盖安装，一般来说，先卸载之前安装的APP即可。

注：APK必须进行签名后，方可安装和运行。如果开启了“允许未知来源的应用”，那么Debug证书、自签名证书、过期证书的签名都是可以的，但是不可以不签名。

将客户端程序文件反编译，修改源码或资源文件后重新打包安装运行如果可运行，说明文件完整。

若应用完整性校验不使用MANIFEST.MF 中的数据，且核心代码通过 JNI 技术写入.so库，同时于服务端进行相关校验，此时无风险。

若应用完整性于本地进行验证而不存在其他问题或使用 MANIFEST.MF 中的数据作为验证凭证（有新文件时提示应用完整性验证失败），此时低风险；

若在本地进行验证的基础上只通过MANIFEST.MF 对客户端原有文件进行校验而忽略新增文件的检验，此时中风险；若未进行应用完整性校验此时高风险。

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

本项主要测试客户端是否包含后台服务、Content Provider、第三方调用和广播等组件，Intent 权限的设置是否安全。应用不同组成部分之间的机密数据传递是否安全。检查客户端是否存在组件劫持风险，查看客户端程序具有导出哪些应用信息的权限。反编译APK文件后，检查AndroidManifest文件中是否有多余的android:export声明，客户端是否存在导出其他应用信息的权限等。

1.组件:安卓APP以组件为单位进行权限声明和生命周期管理；

2.组件的作用：安卓系统的组件共有四种，其主要用途分别为：

Activity：呈现可供用户交互的界面，是最常见的组件；

Service：长时间执行后台作业，常见于监控类应用；

Content Provider：在多个APP间共享数据，比如通讯录数据；

Broadcast Receiver：注册特定事件，并在其发生时被激活；

3.权限声明：安卓系统定义了许多权限声明项，分别对应一些操作系统功能；

4.权限声明的作用：如果一个APP或组件在没有声明权限的情况下就调用相关API，会被拒绝访问；但如果声明了相关权限，安装的时候就会有提示；

5.组件导出：简而言之，就是别的APP也可以访问这个组件。

6.组件导出的作用：有些APP的功能需要提供一些接口给其它APP访问，就需要把相关的接口功能放在一个导出的组件上。

7.组件导出的危害：因为权限声明是以组件为单位的，A组件调用B组件的功能来访问操作系统API时，适用于B组件的权限声明。

如果B作为导出组件，没有进行严格的访问控制，那么A就可以通过调用B来访问原本没有声明权限的功能，构成本地权限提升。

4.3.3方案一：

使用ApkTool解包，打开解包目录中AndroidManifest.xml，对其中声明的各个组件，根据以下规则判断是否可导出：

1.显示声明了android:exported="true"，则可导出；

2.显示声明了android:exported="false"，则不可导出；

3.未显示声明android:exported：

    a) 若组件不是Content Provider：

i.       若组件包含则可导出，反之不可；

    b) 若组件是Content Provider：

      i.  若SDK版本