一次简单的SRC漏洞挖掘

本文记录在一次SRC挖掘过程中发现的用户枚举导致了敏感信息泄露以及水平越权。难度不大，分享一些漏洞挖掘的思路。

挖掘过程

在翻阅资产的过程中，发现了一个某销售系统，并且没有验证码，感觉有戏。

用户枚举

首先便是尝试弱口令admin/123456，admin，admin123，不出意外，无果。

于是便尝试bp抓包进行爆破，爆破了top1000，没有结果，便尝试万能密码admin' or 1=1-- ，密码任意，惊喜的发现提示页面和刚刚的不一样

提示账号不存在，这也就说明了账号存在的情况显示的是账号或密码错误，而不存在的情况则是提示账号不存在，说明admin账户是存在的，但是刚刚我们爆破了弱口令没有结果，所以我们可以换一种思路--枚举用户，我们把密码设为弱口令，对账号处进行枚举，看看是否有收获。

用户名字典先用top500进行尝试，在爆破结果发现了不一样的响应包长度

从图可以看出，响应包长度有三种，这里猜测分别对应的登录成功会跳转到后台，账号存在和账号不存在。四个状态码为302的，用liyan这个账号尝试进行登录，结果意料之中，成功进入到后台！

敏感信息泄露

在后台功能点中，客户池页面以及公海池处泄露大量敏感信息

李艳的客户池比较少，我们登录刚刚拿到的其他三个账号看看。

在公海池处发现泄露大量敏感信息，这里不放完了，放其中一个账号的图，泄露了上百万条数据

水平越权

在客户池页面进行抓包，发现了3个数据包，其中一个数据包是这样的

从数据包以及对比可以发现，该数据包（liyan的客户池，只有7个客户数据）返回的数据就是客户池页面所对应的数据，id即为编号。在请求包中发现有个71，我们对该数值进行修改。

把71改成70，可以发现第一个id为1894275，这个id并不是liyan的客户，这也就成功越权查看其他业务员的客户信息，中文显示的为unicode编码，可通过在线网站解码

可以发送到intruder模块进行大量遍历，这里只遍历30个作为测试

在浏览器中进行查看

12条数据刚好对应着一页显示12个客户信息。这里尝试了未授权访问并没有成功，会自动跳转到登录界面，还是做了鉴权的。

结语

本次挖掘主要是由于系统的缺陷导致了用户枚举因此有了后续的挖掘，或许没有那个提示我也不会尝试弱口令枚举用户进行登录。所以说大家以后在挖掘过程中，不要因为前端显示账号或密码错误就限制了思路。带有点运气成分吧，这个系统的销售员很多都使用了弱口令123456，安全意识较低，从而导致了大量信息泄露+水平越权。以上漏洞已提交并修复。

原文来自: freebuf.com