登陆框系列最后一篇,半年的准全职赏金猎人的生涯,算是水到渠成的一篇,这一篇每一个类型都将配一个这半年来我所发现的漏洞当作案例。
0x00 文章内容结构图
0x01 管理后台隐藏的注册接口
很多系统的后台会用一些本身存在注册功能,但是在后续正式使用的时候,开发人员为了图省事,仅仅删除前端显示的操作。也就是说该系统注册接口仍然存在,只是你在客户端无法找到而已。
案例
这是某系统的管理后台,除了我们所看到的以及HTML源码,js代码均为发现其他有效接口。
此时,我手动将login修改为reg,没想到中奖了。
很简单的尝试,最终让我获得了2500元的赏金。
一般来说我会尝试像reg、register、sign字段,这些字段直接记住手动测试即可,都没必要用字典跑了。
再来看另一个案例:
这个时候我们就要灵活变通了,根据开发人员的命名规则来进行测试,此时我们应该尝试的便是:Reg、Register、Sign。
0x02 目录遍历
当资产仅仅只有一个登陆框时,一定要花费两秒钟的时间来测试这个目录遍历漏洞,讲真,真的只需要两秒钟。
案例
第一秒:直接按快捷键 Ctrl+U(查看页面源代码),讲真,不要再右键点击了,太慢。
第二秒:直接访问https://domain/static/,不要问我为什么直接访问static目录。这个漏洞的确认没必要用路径扫描器去扫。
此时只需要了两秒钟,一个目录遍历漏洞便确认了。后续的则是想办法找敏感文件来扩大危害了。
最后,找到了该系统的备份文件,很常规的一个备份文件的目录,backup。
不过这里有趣的时,遇到了其他困难。
找到数据库配置文件apiappconfigdatabase.php
可以看到加密了,使用了网上的phpjm加密,解密比较费劲,不过过了一会我想到,根本没必要解密。
通过封装的数据库文件可以知道database.php文件使用变量$db来存放配置信息。
我只需要新建一个文件,然后包含database.php文件,再打印出配置信息来即可。
除去后面代码审计出来的漏洞以外,这个漏洞获得了4000元的赏金。
0x03 三端逻辑处理不一致导致的问题
这里的三端只是一个虚词,并不是非得三端,可能是两端,也可能是四端,只是这里我的案例是三端的原因:web端、app端、小程序端。
就像是木桶原理,你的站点web端做的安全系数可能很高,但是你的app端、小程序端如果很烂的话,依旧可以让人突破进去。
案例
首先这个站点我先发现的是web端,其次是app端,最后则是小程序端。
我在web端跟app端用了很多时间,最后突破点是小程序端,发现小程序端以后,则用了很短的时间。
Web端安全系数最高,在登陆时,用了rsa加密,没法直接爆破,并且用了token校验。我手动试了一下,没法确定用户名,只能得到一个【用户名或密码错误的提示】。
后来我发现了app端,发现app端有图形验证码,并且是有效的图形验证码,我试图通过该apk文件包含的js代码来入手,无果。
最终我发现了微信小程序端,在登陆时由于图形验证码是客户端刷新,因此可以直接进行数据包重放。
确认用户名是否存在非常重要,这个时候我一般会先输入一个一定不存在的用户名进行尝试,可以看到,竟然提示了【账号不存在】,最终我通过该处枚举出了多个用户名。
然后我进行了简单的爆破尝试,未果,此时我拿着正确的用户名去尝试app端时,发现了另一个问题。
当输入正确的用户名时,竟然会将该用户的基本信息返回过来,包括但不限于姓名,部门,密码的md5值。
我用拿到的账号密码登陆成功了web端、app端、小程序端。
最终获得了1400元的漏洞赏金。
0x04 从系统帮助文档进行突破
当资产只有一个登陆框时,确认用户名信息则显得至关重要,通过系统的帮助文档,可以快速的帮我们确定用户名的规则及密码的规则。从而可以有针对性的进行爆破。
案例
如下图所时,这个系统我放弃了一次又一次,在登陆时会先校验公司名是否存在,但是我却连公司名都不知道,更不要说用户名了。
我发现这个系统用的是非自研的系统,因此我通过蛛丝马迹(恕我直言,我不能说),结合google语法,intitle:XXXX,发现了该系统的一个测试系统,该测试系统使用了另一个域名,于是我通过site该域名,发现了该系统的一个帮助文档。
通过下图,我获得了,公司名的命名规则。
通过下图,我获得了密码的规则,至少6位,2/3原则。
使用了正确的公司名后发现了,发现存在用户名枚举漏洞,然后我写了一个脚本,原理就是三重循环。
公司名 – 用户名 – 生成的该用户符合规则的社工型字典。
很快,大约30秒,第一个用户的密码就出来了。
我使用的是用户名+123456的形式,既符合规则,又好用。
登陆系统后发现了很多漏洞。最终也是获得了6000元的赏金。
0x05 从js文件进行突破
讲真,我是真的很喜欢读js文件,因为它经常给我带来惊喜,接口信息、命名规则等频率是极高的。
案例
如下图,看到下图的时候,我小心_脏噗通一跳,哇咔咔,竟然没有校验旧密码。
于是我构造数据包。对了,有一个技巧,其实不用构造数据包,直接将我红框标记的区域复制出来,粘贴到开发者工具,js的控制台里,然后替换userCode变量跟password变量回车抓包即可。
我推测存在admin用户,果然推测成功。
最终顺利登陆后台,赚的2000元的赏金。
0x06 其他
当然还有很多其他类型的,如apk重编译突破登陆限制、图型验证码dos攻击、历史漏洞、Http Request Smuggling等。
我便不再说了,网上很多资料。打算完结了,也不会再写啦。
0x07 综合
说一个综合的吧。我这个漏洞是利用了web端跟pc端处理逻辑不一样,然后通过pc端js文件发现了密码规则(这不是一个单纯的名命规则)及可用来枚举用户名的接口来进行突破的。
案例
Web端非常安全,我通过fuzz目录,xxxx.jsp,发现了该站点的一个app下载地址download.jsp。
这个PC端跟web一样存在图型验证码,只不过web端的图形验证码无法绕过,但是pc端的图形验证码可以通过删除该字段的值进行绕过。
但是,不管用户名是否存在,反馈都是一样:账号不存在或密码错误。
这个站点我放弃了很多天,因为js文件实在是太太太太大了,除了大还有别的障碍,总之就是一句话,读起来费劲。
最终我还是一段代码一段代码的读了。
如下图,原始功能是,用户改变自己的在线/离线状态。
这个接口导致我可以在未登陆状态下,通过账户名加在线(1)离线(0)来根据响应包判断出用户是否存在。
如果用户名存在,那么res的值为1(即切换状态成功),如果不存在那么值为-1
通过下图,可以得知密码的名命规则,字母+数字+特殊字符,最短8位。
这样的密码规则,确实难爆破,我心中一凉。
但是峰回路转的是,我看到了以下代码。
于是我推测,可能是因为后台的某些功能,导致会存在不符合规则的密码存在,使用这些不符合规则的密码进行登陆时,依旧可以登陆成功。
window.loation.href= main_url;
于是我用枚举出来的几千个账号,尝试123456的密码。最终成功登陆了PC端跟web端,结合其他福利获得了2300元的赏金。
对了,再补充一下,通过删除图形验证码的值绕过校验的截图。
0x08 临别
最后分享我师傅送我的一句话:在路上点滴挪步,不骄不躁。
原文始发于微信公众号(迪哥讲事):一个登陆框引起的血案
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论