Web渗透从App寻找攻击面的几个方法

声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测以及文章作者不为此承担任何责任。

雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

No.1

抓包

App抓包已经是一个老生常谈的话题了，但不得不说抓包才是真正的开始，这里推荐两个个人常用的抓包方法：

1、模拟器+Proxifier

如果App可以在模拟器里正常使用，首选该方法，方便快捷！

Proxifier抓模拟器进程的包，即可让模拟器上的流量上代理，然后过Burp Suite即可。以夜神为例：

首先开启Burp Suite代理（127.0.0.1：8080），然后在Proxifier添加代理服务器（127.0.0.1：8080），再添加一条通行规则：

启动模拟器，可观察到流量情况（导入证书）：

抓微信小程序：

2、Frida+SSL Bypass

上述方法遇到失败的情况，就需要掏出 Frida (https://github.com/frida) 神器了，通过Hook掉关键校验点（需逆向分析）来达到抓包的目的，不过已经有很多完善好的bypass脚本，无需再去逆向直接拿来用就行（大部分情况），也推荐两个：

(1)frida-codeshare的热门脚本：universal-Android-ssl-pinning-bypass-with-frida(https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/)

(2)瘦蛟舞大佬的DroidSSLUnpinning

(https://github.com/WooyunDota/DroidSSLUnpinning)

覆盖场景非常全面，个人比较推荐，比frida仓库那个效果好。

/*

hook list:

1.SSLcontext

2.okhttp

3.webview

4.XUtils

5.httpclientandroidlib

6.JSSE

7.network_security_config (android 7.0+)

8.Apache Http client (support partly)

9.OpenSSLSocketImpl

10.TrustKit

11.Cronet

*/

举个案例

只导入Burpsuite证书，设置代理，打开App，提示证书不可信，无法抓到流量：

不要使用WIFI处的高级代理（App会检测当前网络环境），开启ProxyDroid，也会出现同样的问题。

开启proxydroid，frida注入ssl-pinning脚本：

成功在burpsuite抓到流量。

其他

JustTrustMe：了解Xposed的同学应该都知道这个，正常安装、启用插件即可。

No.2

接口挖掘

除了抓包可以看到一些请求外，还可以主动通过代码文件寻找隐蔽接口，主要用到的工具是grep。

前提是拿到无壳/已脱壳dex文件，无壳App的dex文件直接在反编译工具（如jadx）打开就可以读JAVA源码，或者使用更方便的grep来查找字符串：

查找所有HTTP服务地址（扩展其他服务、ftp等）：

提取所有IP地址：

可以做一个去重，然后整理到资产表里，进行下一步工作。Tips：分析App之前adb logcat开启日志输出，操作完之后对日志做一次grep过滤，或者其他感兴趣字符串比如password、token等等，也会有意外收获。

No.3

双端差异

目标业务既有Web端，也有App，往往在App一侧会“忽视”参数加密的问题，或者是套用Web的前端加密算法过来，列举几个案例：

1、同一登录接口，Web端做了复杂加密，爆破等操作遇到困难，然而抓包App登录请求发现未加密，或者是用户名未加密。同一系统不同“端”加密：

2、同样是登录接口，Web端有图形验证码校验，App登录无需图形验证码，用App的包爆破之。同一系统的不同“端”登录：

关于前端加密的处理方式有很多，比如burpsuite的jsEncrypter插件等，如果是App自己实现了一套加密方法，就需要跟进代码去分析。

No.4

历史版本

由于App版本更新迭代的缘故，或许某个版本没加壳、报文未加密、使用老版本加密算法等等问题，可通过找历史版本App进行分析。

豌豆荚历史版本：

No.5

其他

从Web出发，通过对App的流量、接口分析，回归到Web测试，或许会得到不错的效果。