在APP的渗透测试中,检查这些 赏金不是简简单单?

admin 2024年2月15日17:47:58评论6 views字数 2502阅读8分20秒阅读模式

大家别嫌弃我写的乱,还是写了两天 大多数都是写的经验,想到什么写了什么,有些地方会有出入,因为我的笔记记得也很乱,都是随开随用。

前言   

常规的APP检查项目中,每个安全测试周期里,肯定是要覆盖客户APP的检查,在一些SRC里 企业里 都是必不可少的一环。

前期应该检查的风险点

SO代码注入

逆向分析(检查是否加硬壳)

Root环境检测(检查是否有ROOT环境提示,或禁止root设备运行)笑脸

界面劫持(检查是否有后台运行提示)|

越狱设备检测(IOS越狱提示,禁止运行)(对抗,xcon)

未使用安全软键盘(检查输入密码或结账密码是否使用安全键盘(如使用系统键盘为未修复))

日志信息泄露(logcat)

界面切换保护(在切换应用的时候,检查密码是否被清除)

内网地址泄漏

等等等等

因为有些漏洞很简单,在安全测试中只算一个风险等级不是很高的测试用例项,所以不过多介绍,那么可以介绍下常见的一些工具

比如测试一些越权 劫持 注入的Dz friada  GDA modsf  MT管理器 appscan(隐私合规、)AndroidKiller ApkScan-PKID.jar 等 在github 的一些开源工具。

当然,我们从一个项目的测试流程开始讲起 如何进行测试APP业务

一般我们拿到的APP要么是正式版加壳的(在外部测试中也会遇到未加壳的应用这种应用危害等级根据行业变化而变化) 要么是没壳的测试状态,使用APP查壳工具 即可识别到App是否加壳

首先通过豌豆荚获得一个App下载ApkScan-PKID.jar 工具(有时候检测不出来,多下一个查壳的) 打开或拖入该APP 查看加壳情况 ,我现在下载了个APP

通过工具查询该APP是否加壳

在APP的渗透测试中,检查这些 赏金不是简简单单?

此时提示未加壳,如果你在外网挖金融类的SRC时,发现他的重要APP未加壳 ,直接一个高危交了 一交一个不吱声。

大多数我们在APP对抗的时候,其实就是在和壳对抗,此时如果有脱壳机,或自己制作脱壳机,对APP测试起到很大的帮助,

直接右键7z打开该APP 看看有什么敏感点没,为什么这么看,因为有次手欠,这么看的,发现压缩包里存在 整个项目密码本,我直接高危起手,那个APP还是加壳的

回到豌豆荚下载的APP

在APP的渗透测试中,检查这些 赏金不是简简单单?

因为该APP 是未加壳状态,直接导入modsf 或者其他工具直接出源码审计就行 一般特殊关注 URL 资源 敏感信息泄露 KEY值 等敏感信息,或者逻辑判断处的审计任务,但是脚本小子也有脚本小子的用法。

直接上dz(Drozer)进行扫描测试 兄弟们下载直接百度就行 这个网上一堆教程,本地运行,但是需要python2 的环境 大家写个脚本就解决。 

在APP的渗透测试中,检查这些 赏金不是简简单单?

因为是python2的环境 所以代码让它独立 不污染 本地python 环境

@echo off.python2.exe .Scriptsdrozer console connect

当然 千万别忘了安装adb环境 ,然后我们需要adb进行端口转发,然后进行测试,端口转发命令如下

adb forward tcp:31415 tcp:31415  

安装agent.apk 后 打开 选择Embedded Server>Enabled

列出所有包名

run app.package.list

在APP的渗透测试中,检查这些 赏金不是简简单单?

环境解决,其中还存在一个中文乱码的问题,直接按照大佬的方式解决就行了

链接https://blog.csdn.net/qq_34594929/article/details/128873722

然后像一些注入 越权等漏洞就可以直接测试,但是我经过测试发现,使用DZ进行屏幕劫持时,方式好像是失效的,也就是说这个测试方式存在不确定性,使用ADB直接调用覆盖屏幕,可以成功劫持,命令如下

adb shell am start -n com.test.uihijack/.MainActivity

在测试中,我们尽量多方向的测试,从本身的APP测试折腾完事后,我们便可以对APP业务进行测试,比如是否有窥屏保护,使用使用scrcpy.exe对其进行远程监控,查看电脑端显示页面是否存在,如果全黑,则为安全,如果存在提示,按照低危处理,如果无影响,按照高危处理 当然我这么定级是为了方便,真实情况的定级要低。    

在反编译后 我们也可以对AndroidManifest.xml进行检查,比如allowbackup备份权限 Debuggable属性 是否正确,都可以当作检查项。

动态调试,也会是高危情况,我们下载frida-trace 通过命令对app进行so调试注入。   

业务方面  

讲话,写到这里我发现,我写的有点乱,大家可以摘着看,因为我也懒,想到什么写什么,现在做活,还是经验居多

不同系统下未脱敏导致源码保护失效,这名字是我起的,等级为高危。在这么多客户里,其他漏洞很少认可,但是这个漏洞认可率还算不错。

测试方式 检查安卓源码与IOS是否大体相同重点体现在,安卓存在的敏感信息,只能看见部分,而IOS有全部敏感数据(基本原理,这个漏洞在做一些单位的APP时,安卓铜墙铁壁, IOS源码反编译后,发现和安卓脱壳后的大部分内容相同。) 有点吹嘘,也很简单,既然安卓端点做了很严格的加壳保护,但是IOS却直接裸奔。更难过的是,我砸了半天壳 发现安卓和IOS核心源码一致。当然也有不一样的,大家根据项目来。    

等以后再写剩下的吧 我整理一份漏洞名称的表给大家

allowbackup备份权限

Debuggable属性

APP恶意木马捆绑安全检查

窥屏保护

SO代码注入(动态注入)

密码锁定策略

逆向分析

帐号登录限制(影子账号登录)

IOS反编译敏感信息检索

登录界面可绕过

本地文件读取

本地sql注入

传输通道加密传输

用户枚举

密码喷洒

密码暴力破解(或动态短信暴力破解)

短信炸弹

客户端组件安全        

组件Activity配置

webview组件安全

本地目录遍历

Root环境检测

界面劫持

日志文件泄露

越狱设备检测

未使用安全软键盘

界面切换保护

密码复杂度

不同系统下未脱敏导致源码保护失效

键盘记录

 等等

业务方面更倾向于 贴近业务 不符合逻辑和安全设计的漏洞 也有些为正常功能,但是换成另外一个角度,就变成了漏洞,看对业务的熟悉度,剩下的拿web套也可以。

写了两天了 别嫌弃我写的乱就

原文始发于微信公众号(渗透云笔记):在APP的渗透测试中,检查这些 赏金不是简简单单?

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年2月15日17:47:58
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   在APP的渗透测试中,检查这些 赏金不是简简单单?https://cn-sec.com/archives/2190251.html

发表评论

匿名网友 填写信息