安全矩阵

 找回密码
 立即注册
搜索
查看: 4415|回复: 0

密码重置的那些事

[复制链接]

114

主题

158

帖子

640

积分

高级会员

Rank: 4

积分
640
发表于 2020-8-20 15:42:18 | 显示全部楼层 |阅读模式
密码重置的那些事
原创:17岁的one
来自于公众号: 合天智汇
本文转自先知社区:https://xz.aliyun.com/t/8136
分享一下平时实战中密码重置的姿势
因为都是找的实战案例(尽量避免"云渗透"),可能姿势不全(水平有限,如果有缺有错,师傅们多带带)


任意密码重置姿势.jpg

1.重置凭证泄露
很好理解,短信验证码,重置链接等一系列用于重置密码过程认证的值在burp返回包响应泄露。
​以上两个案例分别泄露了短信验证码与邮箱重置链接

2.重置接收端可控
若服务端接受的手机号/邮箱是从客户端获取的话,那么就可以修改接收端,让重置信息发给自己手机或是邮箱。
输入admin账号后,服务端返回手机号给前端,获取验证码时,服务端又从前端获取手机号码

3.重置元素弱关联
一次重置过程需要哪些参数参与呢?用户标识/接收端/步骤

用户标识:cookie/username/sid
cookie混淆流程:找回密码时,未登录的cookie本地值不变,可关联多个账号,使用攻击者账号(自己注册的)走完找回密码流程,提交修改密码时截断。用一个新的账号(目标账号)发起流程,然后cookie就会关联目标账号,重放之前的包,就会修改目标账号的密码。
username/sid混淆:修改密码时若是数据包存在类似username=张三&new_pwd=123456的数据包。可替换username=admin&new_pwd=123456,类似修改密码的越权操作吧。
这两个姿势自己没在实战中遇见,就只能云了。
接收端的弱关联:之前遇见一个案例,重置密码需要账号名,身份证号,手机号同时正确才能修改密码。实际上前两个正确就行了。
步骤跳过:
这个案例遇见的特别多,当修改密码的操作被才拆分为step1,step2,step3时,我们就可以通过修改响应的状态码来欺骗前端来跳过重置的流程。(响应成功的状态码通常可以在页面的js文件中找)

4.重置凭证未校验
为了防止步骤的跳过,通常最后一步会是这样username=张三&new_pwd=123456&token=11223344,会带一个验证参数,验证参数正确。密码才会修改,这时删除cookie,删除验证参数或许有用。

5.重置凭证可爆破,可预测
可爆破:如果验证码是4位数字,有效期时间足够,而且未设置试错次数的话,可burp直接爆破。
可预测:通过观察token生成的规律,自己伪造,这里面的东西又多了.....

这里再分享两个不同的案例:
案例一:
当我正确输入用户名,身份证号时会把验证码正确和错误的页面一同返回给我。
哈哈这里还有个CSRF。

案例二:
通过在js中找到的未授权的方法,可写入任意用户的资料(改预留手机号)来实现任意用户密码重置。

案例三:
信息泄露导致密码重置,哈哈
End.....

密码重置的那些事[color=rgba(0, 0, 0, 0.3)]17岁的one [color=var(--weui-LINK)][url=]合天智汇[/url] [color=rgba(0, 0, 0, 0.3)]昨天

本文转自先知社区:https://xz.aliyun.com/t/8136
分享一下平时实战中密码重置的姿势
因为都是找的实战案例(尽量避免"云渗透"),可能姿势不全(水平有限,如果有缺有错,师傅们多带带)
任意密码重置姿势.jpg

1.重置凭证泄露
很好理解,短信验证码,重置链接等一系列用于重置密码过程认证的值在burp返回包响应泄露。
以上两个案例分别泄露了短信验证码与邮箱重置链接
2.重置接收端可控
若服务端接受的手机号/邮箱是从客户端获取的话,那么就可以修改接收端,让重置信息发给自己手机或是邮箱。
输入admin账号后,服务端返回手机号给前端,获取验证码时,服务端又从前端获取手机号码
3.重置元素弱关联
一次重置过程需要哪些参数参与呢?用户标识/接收端/步骤
用户标识:cookie/username/sid
cookie混淆流程:找回密码时,未登录的cookie本地值不变,可关联多个账号,使用攻击者账号(自己注册的)走完找回密码流程,提交修改密码时截断。用一个新的账号(目标账号)发起流程,然后cookie就会关联目标账号,重放之前的包,就会修改目标账号的密码。
username/sid混淆:修改密码时若是数据包存在类似username=张三&new_pwd=123456的数据包。可替换username=admin&new_pwd=123456,类似修改密码的越权操作吧。
这两个姿势自己没在实战中遇见,就只能云了。
接收端的弱关联:之前遇见一个案例,重置密码需要账号名,身份证号,手机号同时正确才能修改密码。实际上前两个正确就行了。

步骤跳过:这个案例遇见的特别多,当修改密码的操作被才拆分为step1,step2,step3时,我们就可以通过修改响应的状态码来欺骗前端来跳过重置的流程。(响应成功的状态码通常可以在页面的js文件中找)

4.重置凭证未校验
为了防止步骤的跳过,通常最后一步会是这样username=张三&new_pwd=123456&token=11223344,会带一个验证参数,验证参数正确。密码才会修改,这时删除cookie,删除验证参数或许有用。

5.重置凭证可爆破,可预测
可爆破:如果验证码是4位数字,有效期时间足够,而且未设置试错次数的话,可burp直接爆破。
可预测:通过观察token生成的规律,自己伪造,这里面的东西又多了.....
这里再分享两个不同的案例:
案例一:
当我正确输入用户名,身份证号时会把验证码正确和错误的页面一同返回给我。

哈哈这里还有个CSRF。
案例二:
通过在js中找到的未授权的方法,可写入任意用户的资料(改预留手机号)来实现任意用户密码重置。

案例三:
信息泄露导致密码重置,哈哈
End.....



回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|安全矩阵

GMT+8, 2024-11-28 06:44 , Processed in 0.023745 second(s), 18 queries .

Powered by Discuz! X4.0

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表