SRC高危漏洞实战——破解加密流程发现的大量信息泄漏

上篇文章[SRC漏洞挖掘——常见数据加密传输方式解析]分析了一下目前常见的WEB端传输加解密流程，下面分享一个我之前实战的一个某SRC高危例子，就是通过分析加密方式篡改了请求包，进而拿到了大量用户敏感数据。

分析过程

尝试

首先是过了一下全站的功能，没发现什么切入点，而且有WAF，就没有尝试去搞常规漏洞了。主要还是以逻辑为主，但是大部分的接口连参数都少，连改ID的尝试越权的机会都没有。原本打算放弃了。

但是在一个比较深的页面发现了一个功能，允许查询他人的订单信息，但是需要验证手机。

这里就有点搞头了，拿另一个手机号试一下，看看验证成功后请求的接口是啥，有没有可能绕过这部分。

抓包后有点抓瞎，全是密文！梳理了一下，在输入手机号和验证码之后，点击查询，主要请求了两个接口：

1. 使用手机号加验证码请求接口A，返回一个加密的数据

2. 使用接口A返回的加密的数据访问接口B，返回一串加密的数据

这时候作为一个开发，第一个反应是接口A返回的数据是一个临时的token，对应了这个手机号的订单信息，使用这个token去访问接口B即可获取用户订单信息。

那如果是这样的话，又没得搞，因为token需要使用手机验证码随机临时生成，没办法绕过。为了验证是不是随机生成的，又尝试获取了几次，发现果然每次接口A返回的数据都不一样，这时候已经有点想放弃了。

峰回路转

这个站搞了挺久了，又有点不甘心，又多尝试了一次这个功能，仔细分析请求包，发现一个问题，在请求接口A的时候，有一个名称为AuthXXX请求头也在一直变！根据之前分享的加密流程猜测，这个请求头应该是通过RSA加密AES密钥的密文，那是不是意味着AES密钥也在变？ 那接口A每次请求返回不一样的数据，那还有极低的概率是接口A返回的数据并不一定是随机的，只是因为密钥变了，所以密文也变了。

破解加密算法

要确认这个问题，就需要解密数据，知道它的数据到底是什么。

通过之前的文章，我们知道要解密，先要知道它是怎么加密的，是不是RSA+AES的方式，如果是的话，那么需要知道以下数据：

• RSA公钥

•  他生成AES密钥（16位或32位）的逻辑

•  加密模式（ECB或CBC）

•  IV值（如果是CBC模式的话）

直接Chrome浏览器内F12搜索JS文件或者将JS文件下载下来（我是下载到本地处理的）：

1. 通过AuthXXX这个请求头搜索，找到它的生成逻辑，发现果然是通过RSA加密AES密钥，并且RSA的公钥是写死在代码里面的（PublicKey即RSA公钥）：

2. 搜索AES关键字，找到AES相关的方法，可以看到它的密钥是随机生成的16位字符串（也就是AES128），使用的CBC，IV是写死在在代码里面的：

那我们知道上面的逻辑后，就可以随便修改或解密数据了。

1.  密钥我们直接生成一个简单的16位字符串K作为AES密钥

2.  使用JS源码中的RSA公钥加密这个字符串，得到密文R

3.  在请求接口A时，拦截请求包，替换AuthXXX请求头为我们生成的密文R

4.  使用我们生成密钥K解密接口A返回的密文数据即可得到原文

高危到手

通过上面的方法解密之后，发现它果真不是随机字符串，而是一个6位数的整数：

而且同一个手机号每次返回都是一样的。这可不巧了，难道是用户ID？直接尝试遍历一下！遍历方式也很简单，使用上面的加密逻辑生成请求头，然后使用密钥K加密用户ID后请求接口B即可。

写个Python脚本从返回的6位ID开始往后遍历，直接返回了其它用户的订单信息：

Bingo!! 虽然订单信息也是密文，但是我们都已经知道密钥了，这部分数据可以直接解密出来了，这部分就不再细说了。

最后

要发现这个洞一个比较重要的点是要了解数据的加解密流程，如果对这块不了解话，很难去找到切入点。而且也需要对JS代码有一定的了解，前端JS代码都是混淆过的，即使我们对它进行反混淆，可读性也很差，就需要善于去发现关键代码。总的来说，基础还是十分重要的。最后祝大家天天高危，日日严重。