逻辑漏洞初探之任意密码重置

2019-10-09 14:20:01 admin

网络安全发展到今天,最初常见的注入、跨站、上传等Web安全问题基本得到大多数人的重视,日益强大的Web扫描器也能帮助我们发现此类漏洞,业务安全延伸出来的逻辑缺陷测试逐渐成为白帽子漏洞挖掘中的重要手段。本文着重挑选任意密码重置相关的安全案例供大家参考,并对其常见的设计缺陷进行汇总。

1.验证码可爆破

成因:

  • 验证码时效过长或不失效

  • 验证码过于简易(一般为纯数字4-8位)

  • 验证接口未做限制

相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0203274.html

2.验证码回传(重置凭证泄露)

常见场景:重置密码时,凭证为发送到手机上的验证码,但是通过拦截发送验证码请求对应的Response包时,发现验证码在Response包中。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0190497.html

  • http://www.anquan.us/static/bugs/wooyun-2016-0174249.html

  • http://www.anquan.us/static/bugs/wooyun-2016-0207468.html

3.验证码未绑定用户

成因:输入手机号和验证码进行重置密码的时候,仅对验证码是否正确进行了判断,未对该验证码是否与手机号匹配做验证。
测试方法:在提交手机号和验证码的时候,替换手机号为他人手机号进行测试。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0190525.html

4.用户混淆

成因:密码找回逻辑含有用户标识(用户名、用户 ID、cookie)、接收端(手机、邮箱)、凭证(验证码、token)、当前步骤等四个要素,若这几个要素没有完整关联,则可能导致任意密码重置漏洞。
参考链接:https://www.freebuf.com/articles/web/162152.html
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0189606.html

  • http://www.anquan.us/static/bugs/wooyun-2016-0206958.html

  • http://www.anquan.us/static/bugs/wooyun-2016-0206447.html

  • http://www.anquan.us/static/bugs/wooyun-2016-0190935.html

5.接收端可篡改

成因:重置密码时,凭证会发送到手机上,通过替换手机号,可以使用自己的手机号接受验证码。
还有一种情况比较特殊,也是手机接受验证码,但是重置密码的整个流程中并没有输入过手机号之类的,说明后台程序很可能是通过用户名来查询的电话号码。
整个重置流程中,一般第一步是绑定用户名的地方,但是如果后面几个流程中还会发送用户名这个参数(这个时候发送的参数可能是单独用于在数据库中查询手机号的,同时说明这个地方可能存在sql注入),可以修改尝试一下。
参考链接:https://www.freebuf.com/articles/database/161495.html

6.本地验证绕过

成因:客户端在本地进行验证码是否正确的判断,而该判断结果也可以在本地修改,最终导致欺骗客户端,误以为我们已经输入了正确的验证码。
测试方法:重置目标用户,输入错误验证码,修改返回包,把错误改为正确,即可绕过验证步骤,最终重置用户密码。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0207115.html

7.跳过验证步骤

成因:对修改密码的步骤,没有做校验,导致可以输入最终修改密码的网址,直接跳转到该页面,然后输入新密码达到重置密码的目的。
测试方法:首先使用自己的账号走一次流程,获取每个步骤的页面链接,然后记录输入新密码的对应链接。重置他人用户时,获取验证码后,直接进入输入新密码对应链接到新密码的界面,输入密码重置成功。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0211505.html

8.token可预测

使用邮件接受重置密码的链接时,一般都会带有一个token用于判断链接是否被修改过。如果token可以预测,那么攻击者可以通过构造链接来重置任意用户的密码。

8.1 基于时间戳生成的Token

成因:部分程序使用当前时间戳MD5加密后的值作为token。
测试方法:使用我们自己的账号先走一遍流程,再用admin的账号走一次流程,再用自己的账号再走一次流程。由于第一次和第三次是我们自己的账号,可以收到邮件,我们取出两邮件中重置密码链接中的时间戳,那么admin的重置密码链接中的时间戳应该时介于之前两个时间戳之间的,使用burp爆破,找出正确的时间戳,构造链接即可。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0188088.html

8.2 找回密码的凭证脆弱

测试方法:多获取几次重置密码的链接,发现参数的加密方式以及一定的生成规律。比如说base64编码的用户名+id。

9.同时向多个账户发送凭证

测试方法:攻击者可以通过发送一组电子邮件地址而不是单个电子邮件地址向任意电子邮件发送密码重置链接。
相关案例:

  • https://hackerone.com/reports/322985

10.万能验证码

这是可遇不可求的奇葩场景,某些开发在未上线前为了方便测试加了888888、000000这样的万能验证码但是上线后没去删除测试的内容导致被恶意利用。
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0195518.html

11.重置凭证未校验

参考链接:https://www.freebuf.com/articles/web/164090.html
相关案例:

  • http://www.anquan.us/static/bugs/wooyun-2016-0189300.html

Tips:有些重置密码的模块可以通过回答密保问题来重置密码。

但是有部分用户并没有设置密保问题,那么就有可能我们提交任意的密保答案都可以重置这些用户的密码。

怎样确认这些用户是否存在密保呢?

一般通过密保重置密码的场景,第一步都会让我们先输入用户名,发送请求包后我们可以拦截response包,很多时候,我们可以发现用户存在且有密保、用户存在但没有密保、用户不存在这三种情况返回包都不一样,我们可以使用burp进行爆破找出存在但没有密保的用户名。


此外,也可以参考SiteServer这个老洞:

  • http://0day5.com/archives/1043/

写在结尾

以上案例仅供思路参考,并不能覆盖所有的业务场景。
逻辑漏洞的挖掘考验的是另类的思维,对于逻辑漏洞我们不能满足于1:1的学习,而要善于变通。
打开你的黑盒测试思维,任何点你都只能猜测,所以为什么不多猜猜?
黑盒测试的精华是什么?Fuzzing.(key大佬说的)

更多的密码重置姿势可能上文并未涉及到,欢迎留言区评论交流~
点一波关注叭

服务热线

17884544032

公司地址

安徽省合肥市蜀山区鑫鹏大厦

作息时间

周一至周五 9:00-18:00