跟着大神学App安全测试,事半功倍

发表于:2020-12-18 10:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:book4yi    来源:简书

  App渗透我几乎没有了解过,于是找了几个相关的app安全检测的pdf文件来学习学习
  APP渗透测试要点:
  APK文件结构:
  1、Assets目录:用来存放需要打包到 Android 应用程序的静态资源文件,例如图片资源文件、JSON 配置文件、渠道配置文件、二进制数据文件、HTML5离线资源文件等。与res/raw 目录不同的是,assets 目录支持任意深度的子目录,同时该目录下面的文件不会生成资源ID。
  2、Lib目录:存放的是当前app所用得到的so动态链接库文件,so文件就是利用底层的c、c++代码实现的。
  3、META-INF目录:存放的是所用到的证书签名文件,包括:MANIFEST.MF(摘要文件)、CERT.SF和CERT.RSA。其中MANIFEST.MF文件是对每个文件的SHA-256-Digest;CERT.SF是对每个文件的头3行进行SHA-256-Digest;CERT.RSA这个文件保存了签名和公钥证书。
  4、Res目录:放应用的资源文件,包括图片资源、字符串资源、颜色资源、尺寸资源等,这个目录下面的资源都会出现在资源清单文件 R.java 的索引中。
  5、AndroidManifest.xml:Android项目的系统清单文件,Android应用的四大组件(Activity、Service、BroadcastReceiver和 ContentProvider )均在此配置和声明。
  6、classes.dex:应用程序的可执行文件。若APP有多个dex,是因为当前的方法数超过65535,进行了分包处理。如果未超过,则只有一个dex。Android的所有代码都集中在此。可以通过反编译工具dex2jar转化成jar包,再通过jd-gui查看其代码。
  7、resources.arsc:资源索引表,用来描述具有ID值的资源的配置信息。
  客户端程序安全:
  1、安装包签名:
  在 Android 中,包名相同的两个 APK 会被认为是同一个应用。当新版本覆盖旧版本时,签名证书必须一致,否则会被拒绝。(即使开启了“允许未知来源的应用”)。如果 APK 没有使用自己的证书进行签名,将会失去对版本管理的主动权。本项检测是检测客户端是否经过恰当签名(正常情况下应用都应该是签名的,否则无法安装),签名是否符合规范使用Jdk自带的jarsigner.exe对app的签名进行检查:
jarsigner.exe -verify C:\Users\sws123\Desktop\apk\huazhu_7.9.9993_guanwang.apk
  当输出结果为“jar 已验证”时,表示签名正常。
  这时还需检测签名的 CN 及其他字段是否正确标识客户端程序的来源和发布者身份:
  注意:只有在使用直接客户的证书签名时,才认为安全。Debug 证书、第三方(如开发方)证书等等均认为风险。
  如下图就认为存在风险:
  威胁等级:
  若客户端安装包签名有异常(例如签名证书为第三方开发商而不是客户端发布方),此时高风险;若无异常则无风险。
  2、反编译检测:
  测试客户端安装程序,判断是否能反编译为源代码,java 代码和 so 文件是否存在代码混淆等保护措施。未作保护的 java 代码,可以轻易分析其运行逻辑,并针对代码中的缺陷对客户端或服务器端进行攻击。
  成功的反编译将使得攻击者能够完整地分析 APP 的运行逻辑,尤其是相关业务接口协议、和通信加密的实现。
  把 apk 当成 zip 并解压,得到 classes.dex 文件(有时可能不止一个 dex 文件,但文件名大多类似):
  这里利用到dex2jar,dex2jar是用于将Android的.dex格式转换为Java的.class格式的工具。
  项目地址:https://github.com/pxb1988/dex2jar
  使用指南:https://github.com/pxb1988/dex2jar/wiki/UserGuide
  利用jdk版本:jdk1.7.0_80:
d2j-dex2jar.bat C:\Users\sws123\Desktop\apk\com.cjia.pms.apk
  然后再换成jdk1.8版本,使用 jd-gui 打开 jar 文件,即可得到 JAVA 代码:
  如上图,逆向后发现是没混淆的情况,是不安全的。
  如果代码经过混淆,或者有加壳措施,不能完整恢复源代码的,都可以认为此项安全,混淆后的代码样例,除了覆写和接口以外的字段都是无意义的名称。如下图已加密混淆,除了覆写和接口以外的字段都是无意义的名称:
  威胁等级:
  若客户端进行加壳保护,此时认为无风险。
  若大部分代码(包括核心代码)经过混淆,此时低风险。
  若部分代码混淆,关键代码(加密或通信等)可以获知其关键代码,此时中风险。
  防御措施:客户端程序可以把关键代码以 JNI 方式放在 so 库里。so 库中是经过编译的 arm 汇编代码,可以对其进行加壳保护,以防止逆向分析。
  注意:有时用 apktool 能够解包并查看 smali,但 dex2jar 却不行。如果 dex2jar 反编译失败,可以试试看能不能恢复 smali 代码。
  3、应用完整性校检:
  这里得提一下APK的签名机制:
  Apk中的每个文件会做一次算法(数据SHA1摘要+Base64编码),保存到MANIFEST.MF文件中,具体作法可以理解为程序遍历APK包中的所有文件,对非目录、非签名文件的文件,逐个用SHA1生成摘要信息,再用Base64进行编码后保存。基于此文件的安全机制可以进行文件完整性校验:如果APK包的文件被修改,在APK安装校验时,被修改的文件与MANIFEST.MF的校验信息不同,程序将无法正常安装,同理CERT.SF和CERT.RSA文件同样应用于apk的完整性校验。
  风险点:
  测试客户端程序是否对自身完整性进行校验。攻击者能够通过反编译的方法在客户端程序中植入自己的木马,客户端程序如果没有自校验机制的话,攻击者可能会通过篡改客户端程序窃取手机用户的隐私信息。
  项目地址:https://github.com/iBotPeaches/Apktool
  用 ApkTool 将目标 APK 文件解包:
# -f apk 文件路径 -o 解包目标文件夹
java -jar apktool_2.4.1.jar d -f C:\Users\sws123\Desktop\apk\com.cjia.tenement.apk -o C:\Users\sws123\Desktop\apk\123
  这里同时也能够得到 smali 代码。
  这里随便找一个解包目录里的资源文件进行修改,推荐找到 logo 之类的图进行修改,这样容易确定结果:
  将APK拖入Androidkiller 进行反编译,获取图标的文件名:
  打开res(资源存放目录)目录文件夹,点击右键,选择”打开方式“,再点击”打开文件路径“:
  根据icon文件名进行搜索:
  刚好最近在完糖豆人,换张我吃鸡的照片~图片分辨率不变:
  将待打包的文件夹进行APK编译并签名:
  如果我们不使用 Android Killer,可以通过 Apktool 将解包目录重新打包成未签名的 APK 文件:
java -jar apktool_2.4.1.jar b -f 待打包的文件夹 -o 输出 apk 路径
  再用 SignApk,对未签名的 APK 文件进行签名:
java -jar signapk.jar testkey.x509.pem testkey.pk8 待签名 apk 文件路径 签名后输出 apk 路径
  将签了名的 APK 安装、运行、确认是否存在自校验;
  需要注意的是,如果之前安装的 APK 和修改后的 APK 签名不同,就不能直接覆盖安装,一般来说,先卸载之前安装的 APP 即可。
  推荐修改 apk 中 assets 目录下或 res/raw 目录下的文件。将修改后的 apk 文件导入到/data/app 目录下,覆盖原文件,然后重启客户端,观察客户端是否会提示被篡改。
  注意:APK 必须进行签名后,方可安装和运行。如果开启了“允许未知来源的应用”,那么 Debug 证书、自签名证书、过期证书的签名都是可以的,但是不可以不签名。
  在模拟器里下载原版apk进行安装:
  卸载重新安装以后:
  安卓手机成功安装:
  说明上述apk没有经过自校验的情况,若经过自校检的情况,则修改后无法正常启动。
  威胁等级:
  1、若应用完整性校验不使用 MANIFEST.MF 中的数据,且核心代码通过 JNI 技术写入.so库,同时于服务端进行相关校验,此时无风险。
  2、若应用完整性于本地进行验证而不存在其他问题或使用 MANIFEST.MF 中的数据作为验证凭证(有新文件时提示应用完整性验证失败),此时低风险。
  3、若在本地进行验证的基础上只通过 MANIFEST.MF 对客户端原有文件进行校验而忽略新增文件的检验,此时中风险;若未进行应用完整性校验此时高风险。
  防御措施:客户端在每次开机启动时进行客户端自身的应用完整性校验,在验证逻辑中不使用 MANIFEST.MF 中的数据作为验证凭证,同时需验证是否有不属于该客户端版本的新文件添加,验证过程于服务器端完成。
  AndoridManifest.xml风险点:
  debug模式
  客户端软件 AndroidManifest.xml 中的 android:debuggable="true"标记如果开启,可被Java 调试工具例如 jdb 进行调试,获取和篡改用户敏感信息,甚至分析并且修改代码实现的业务逻辑。
  检查方法:
  检查 AndroidManifest.xml 文件中的 debuggable 属性(MobSF) -- 检查是否能被调试(或者我们可以直接使用MobSF的静态检测)。
  应用程序数据可备份:
  Android 2.1 以上的系统可为 App 提供应用程序数据的备份和恢复功能,该由AndroidMainfest.xml 文件中的 allowBackup 属性值控制,其默认值为 true。当该属性没有显式设置为 false 时,攻击者可通过 adb backup 和 adb restore 对 App 的应用数据进行备份和恢复,从而可能获取明文存储的用户敏感信息。
  检查方法:
  检查应用 AndoridManifest.xml 文件中的配置是否为:android:allowBackup="true",即为 allowBackup 开启,记录漏洞,停止测试。
  应用权限测试:
  检查应用 AndoridManifest.xml 文件,将应用权限和业务功能需要权限做对比,检查申请应用权限是否大于业务需要权限,有即存在安全隐患或者我们也可以使用MobSF进行静态检测,它列举了被检测App在AndroidManifest.xml文件中申请的所有权限,并标出了每个权限的危险指数,对于有安全隐患的权限标记为危险再或者利用github上的项目:
python manitree.py -f AndroidManifest.xml
  篇幅有限,暂且写到这~

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号