【重磅！】看我如何在APP中getshell
说起APP上的渗透测试，很多朋友在拿到一个APP的时候，往往会将客户端的检测与服务端的检测分得很开，越来越多的测试人员客户端检测仅仅局限于静态工具扫描，不注重客户端审计与服务端渗透的结合，以至于APP的安全审计报告中服务端的漏洞占比较少。
我们接下来会通过一次网安渗透测试项目，来跟大家聊聊怎么样通过APP与服务端的结合，getshell。希望通过这个案例，能给大家在app渗透测试过程中起到一个抛砖引玉的作用，见招拆招，百步穿扬。
由于客户给了我们明确的测试范围，且重点要求获取服务网权限，所以我们前期做了各种信息收集。其中有一点较为重要，就是发现了内部员工使用的一个邮件类的app，我们也希望以此为突破口，最终拿到服务器的权限。
流程分析
1
绕过SSL Pinning抓包
拿到这个APP后，我们首先做出了一个大胆的假设：其内部使用的客户端在安全防护上是否较弱呢？
于是我们当机立断，打算直接使用Burp抓包，找到利用点后攻击服务端，利用相关漏洞一步到位，Get Shell。
然而，经过尝试发现，客户端对证书进行了校验，burp竟然没法抓包。起步就遇到了阻碍，所以，我们先得解决抓包问题。
证书验证主要有两种方式，分别为双向校验、单向校验。而双向校验一般存在于银行、金融等app中，所以为了提高攻击效率，我们假定其为单向校验，并尝试绕过。
该案例我们借助了JustTrustMe，非常幸运的是通过该插件，我们绕过了证书校验。但是在这里又遇到一个问题：我们抓到的包都是加密的。如下：
由于请求和响应数据包都进行了加密，并且使用同样的数据进行请求的时候，每次密文都不一样，很显然，数据加密密钥是动态变化的。此处的阻碍让我有点方了。
如果客户端实现了OTP加密原理的话，客户端是需要存有非对称算法如RSA 的公钥的。服务端存有非对称算法的私钥，客户端采用自身生成的对称加密密钥如AES来加密信息内容，然后将此对称密钥用服务端的公开密钥来加密之后，将它和加密后的信息一起发送给服务端。服务端先用相应的私有密钥打开数字信封，得到对称密钥，然后使用对称密钥解开加密信息。
但是，抓包过程中发现，它首先有一个从服务端获取密钥的过程。发现每次请求前，客户端都要向服务端发送请求，获取Key。从加密数据本身看，貌似是RSA。由此推测它的一次一密不是数字信封的方式。那么接下来，破解它的加密逻辑就迫在眉睫了。
以上步骤是绕过证书校验进行数据抓包。我们可是站在正义的角度看看客户端客户端证书校验威胁噢。
如果客户端在与服务端通信的过程中没有对传输的数据进行保护与完整性校验，并且未做任何的证书校验，这将直接导致中间人攻击，可重复发送截取到的请求报文，并观察和分析服务端的反应，实现进一步的攻击。
常用的工具有Wireshark、Burpsuite、Fiddler和Charles等。
我们通过反编译APK文件，尝试去定位加密函数，看能否破解上述网络请求中的加解密逻辑。 但是我们反编译后发现APK被加了壳。
那么我们见招拆招，使用FRIDA-DEXDump进行脱壳，且成功的拿到dex文件。
通过对脱壳拿到的dex文件进行反编译，定位getkey请求进行分析对应的加密逻辑。
分析定位加密到函数如下：
经过缜密分析，发现这个APK加密逻辑是这样的：
