技术讨论 | 看我如何突破iOS APP双向证书认证防护

这几天我实验室成员都在集中测试某些酒店APP，本来已经发现某酒店支付部分存在金额可篡改漏洞。于是想试试，那么预定酒店客房部分，能否也能绕过，进而做到1元支付了？于是开始截取报文，尝试修改。

修改完以后，发现出现了400 No required SSL certificate was sent的报错信息而APP端，同样出现了类似的错误 于是，尝试分析原因上网搜索了一下，发现该错误是指服务器端启用了证书双向认证。当服务器启用了双向认证之后，除了客户端去验证服务器端的证书外，服务器也同时需要验证客户端的证书，也就是会要求客户端提供自己的证书，如果没有通过验证，则会拒绝连接，如果通过验证，服务器获得用户的公钥。

正是因为如此，双向认证以来都是企业内部或者证券、银行等这类用户使用，而如何保证证书的合法和保密性，就不可能通过一个公开接口去提供给访问者下载，所以一般都是放入usb-key中，或者是提供一个身份认证接口，认证通过后，可以下载安装，但是一般不会如此使用，这样的话，使用者多个电脑都安装的话，其他人也就可以使用了，所以保证唯一性，大部分都会采用usb-key的方式，所以也就限制了双向认证的使用，但是这几年手机端应用的推广，和安全的推进，很多企业在app中直接封装了客户端的证书，使得我们想对app基于行为的安全检测，无法成功。所以相比于单项的认证，其实也就是多了一个服务器端验证客户端证书的过程，而在以往的用代理 工具 如burp和fiddler这一类工具，抓取https的包时，除了浏览器获取的是代理工具的证书外，默认是不发送证书给服务器端的，而其实代理工具也提供了双向认证的证书发送而burp在抓取https报文的过程中，我们是使用了burp提供的证书文件，也就是CA证书。 相信很多人，都使用burp，配置的第一步就是安装这个CA证书。

那么既然我们app的服务端不认证这个burp提供的CA证书，那么我们就需要拿到匹配的证书，以其对服务端进行匹配。这也解释了，为什么是双向认证。

所以，我决定对app本身进行二进制层面的分析，也就是俗称的逆向或者反编译。

我通过旧版本iTunes下载得到ipa包，对其进行解压

进入目录，找到我们的payload

接下来的步骤，我们应该很熟悉，之前两篇文章有说过我们进入payload寻找，有无证书文件

我发现确实有好几个证书文件，发现有.pfx结尾的文件应该是我们想要的那个服务器端认证的证书文件。这类文件一般有安装密码

果然需要密码

于是我决定在二进制文件中，寻找密码。

当然我们在使用反编译工具之前需要对其砸壳，当然你也可以从某助手直接下载越狱版的ipa，免去砸壳

打开反编译工具，尝试寻找秘钥在寻找以前，我试想了一下，app解密的代码逻辑

应该是发送报文以后，需要去从app包中读取这个证书文件，那么密码应该是以硬编码形式发在了代码中，利用这个代码中的密码字段去解密证书文件，从中读取以后，再进行解密并回传给服务器端进行确认。

所以我们只需要尝试，寻找我们的证书名称应该就可以拿到安装密码。因为objective-c读取文件需要根据文件名称和文件路径。果然，我们在文件名附近拿到了安装密码。

那么我们去尝试安装试试

发现我们已经安装成功

既然有了安装密码，那么证书文件我们如何在burp中进行使用了？我们需要如下操作

安装时，我们host填写这个酒店app服务端的主域名即可

随后选择我们的pfx文件，输入安装密码

一旦安装密码正确，即可导入成功

我们勾选它即可以使用

我们尝试是否可以绕过防护了