|
任意用户密码重置 转载于： 池羽 [url=]Tide安全团队[/url] 2022-08-05 17:03 发表于山东 0x01 等保测评项GBT 22239-2019《信息安全技术 网络安全等级保护基本要求》中，8.1.4.2安全计算环境—访问控制项中要求包括：a）应对登录的用户分配账户和权限；b）应重命名或删除默认账户，修改默认账户的默认口令；c）应及时删除或停用多余的、过期的账户，避免共享账户的存在；d）应授予管理用户所需的最小权限，实现管理用户的权限分离；e）应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；f）访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；g）应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问。任意用户密码重置对应访问控制项中要求d），所以安全控制点为访问控制d。 GBT 28448-2019《信息安全技术 网络安全等级保护测评要求》中，测评单元（L3-CES1-09） 该测评单元包括以下要求: a）测评指标：应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则。b）测评对象：终端和服务器等设备中的操作系统（包括宿主机和虚拟机操作系统）、网络设备（包括虚拟网络设备）、安全设备（包括虚拟安全设备）、移动终端、移动终端管理系统、移动终端管理客户端、业务应用系统、数据库管理系统、中间件和系统附案例软件及系统设计文档等。c）测评实施包括以下内容：1）应核查是否由授权主体（如管理用户）负责配置访问控制策略；2）应核查授权主体是否一句安全策略配置了主体对客体的访问规则；3）应测试验证用户是否由可越权访问情形。d）单元判定：如果1）～3）均为肯定，则符合本测评单元指标要求，否则不符合或部分符合本测评单元指标要求。任意用户密码重置属于测评单元（L3-CES1-09）中测评实施的第3项，故定测评单元为L3-CES1-09.3。 0x02 测试内容测试系统找回密码等功能处是否存在验证缺陷，可进行任意用户密码重置。 0x03 漏洞原理什么是任意用户密码重置？未经用户本身授权，在未知他人的重置密码链接或手机验证码的情况下，通过构造重置密码链接或穷举验证码等方法直接重置他人密码的一种攻击方式。任意用户密码重置影响系统的稳定性，可由此作为攻击入口，进行持续攻击。 任意用户密码重置漏洞在渗透测试中属于逻辑漏洞的一种，形成原因是开发者在开发时没有对各项参数进行准确的校验从而导致漏洞的诞生。密码重置漏洞在生活中很是普遍，在各类网络安全事件中，占比也非常高，影响十分恶劣。 在逻辑漏洞中，任意用户密码重置最为常见，可能出现在新用户注册页面，也可能是用户登录后重置密码页面，或者用户忘记密码时的密码找回页面中。其中，密码找回功能是任意用户密码重置漏洞的重灾区。 0x04 代码示例以下代码使用ID标识用户，且未做权限划分，攻击者可通过修改ID值重置他人密码。
0x05常见任意用户密码重置分类密码找回逻辑含有用户标识（用户名、用户 ID、cookie）、接收端（手机、邮箱）、凭证（验证码、token）、当前步骤等四个要素，若这几个要素没有完整关联，则可能导致任意密码重置漏洞。（为方便理解会尽量都带图示、案例，如果没有，那说明我既没有库存也找不到合适的案例了????♀️????♂️...） 1. 验证码无时间限制 产生原因：系统对验证码缺少时间限制，仅判断了验证码是否正确，未判断验证码是否过期。测试方法：输入受害者手机号，点击获取验证码，随意输入验证码，比如1234，提交，截取数据包进行验证码爆破，通过枚举找到真实正确的验证码，输入并完成验证。
2. 验证码在Response包中回显 产生原因：验证码在客户端生成，并直接返回在Response包中。测试方法：输入受害者手机号，点击获取验证码，并观察返回包，在返回包中直接可得到验证码，进而完成验证，成功重置密码。
3. 验证码为固定值 产生原因：开发者失误，上线前未修改为正确的验证码机制。测试方法：开发在系统上线前为了方便测试等原因，将验证码设置为固定值，比如0000、1111、123456等，攻击者可尝试常见的固定值当作验证码进行验证。 4. 密码重置步骤未进行校验 产生原因：系统对修改密码的步骤、流程没有做校验，导致可直接输入最终修改密码的URL进行跳转，直接重置密码。测试方法：这种情况一般发生在多个步骤重置的过程中，比如重置步骤为“1.填写用户名 2.填写手机号码获取验证码 3.填写短信验证码 4.填写新密码”。攻击者先使用自己的账号走一遍流程，获取每个步骤的URL，记录最后一步设置新密码的URL。重置受害者密码时，在获取验证码时直接输入记录的URL跳转到设置新密码的界面进行重置。 5. 未校验Cookie信息（适用于当修改密码的数据包中无ID等值，只有Cookie值） 产生原因：重置密码的最后一步仅判断唯一的用户标识Cookie是否存在，未判断该Cookie是否通过之前过程的验证，导致可直接替换Cookie重置他人密码，测试方法：第一步，先使用攻击者身份进行密码重置，直到流程最后一步设置新密码时截取数据包。第二步，再使用受害者身份进行重置密码，获取受害者的Cookie。将受害者的Cookie替换到第一步截取的数据包中，替换完成后发送报文，即可成功重置受害者的密码。 6. 验证码与手机/邮箱号未进行匹配性验证 产生原因：系统仅对验证码是否正确进行了判断，未进行验证码与注册手机/邮箱号的匹配性验证。测试方法：重置密码时先使用攻击者的手机/邮箱号进行验证，直到攻击者接收到验证码，在提交验证码时截取数据包，将数据包中的手机/邮箱号替换为受害者的手机/邮箱号，即可绕过对验证码正确性的检测，接着再去修改受害者的密码完成密码重置。 7. 用户名、手机/邮箱号、验证码三者未进行匹配性验证 产生原因：用户名、手机号/邮箱号、验证码三者没有进行统一验证，仅判断了三者中的手机/邮箱号与验证码是否匹配和正确，如果正确则判断成功并进入下一流程。测试方法：先使用受害者的用户名获取验证码，提交时截取数据包，将数据包中接收验证码的手机/邮箱号改为攻击者的手机/邮箱号，再使用攻击者手机接收到的验证码进行提交验证，进入下一流程。 8. 在本地客户端进行验证码校验 产生原因：客户端在本地进行验证码是否正确的判断，而判断结果也可在本地修改，造成欺骗客户端，误以为用户输入了正确的验证码。测试方法：输入受害者身份信息完成第一步，再随意输入验证码，截取数据包，修改返回包中的状态码（或者其他验证的地方），即可绕过验证步骤，重置用户密码。验证码校验成功的Response：
验证码校验失败的Response： 替换后的Response：
9. 修改密码处ID可替换 产生原因：修改密码时，系统未对原密码进行判断，且仅根据ID的值来修改用户名的密码，类似于SQL语句：uodate user set password="123456" where ID="1"，修改ID的值即可修改他人密码。** 测试方法：** 攻击者先使用自己的用户信息进行修改密码，抓取数据包，将数据包中用户对应的ID替换为受害者的ID值，即可重置他人密码。 10. 修改信息时替换、添加字段值 产生原因：在执行修改信息的SQL语句的时候，用户的密码也当字段执行了，而且是根据隐藏参数执行的，这样就导致了可以通过修改、添加隐藏参数的值去修改他人密码。测试方法：攻击方在重置密码的时候截取数据包，修改数据包中的参数和相对应的值，参数名可在其他地方找到（页面源代码、其他数据包等），替换或者添加隐藏参数就可修改他人的密码等信息，此漏洞不仅适用于密码重置页面也适用于修改资料等页面。 0x06 测试过程大多数密码重置的流程：
重置密码过程一般是先验证注册的邮箱或者手机号或者用户名，获取重置密码的链接或者验证码，然后访问重置密码链接或者输入验证码，最后输入新密码。 繁琐的步骤核心目的是确认当前的操作者是该用户本人。那么就有四个因素特别重要，分别是：操作者、用户账号、用户凭证、当前步骤。这四个因素需要相互验证，在重置流程中，任何因素缺失都有可能被利用。 测试案例1要求重置17101304128用户的登录密码。
根据提示得知我的手机号是18868345809。根据页面提示，依次填入手机号、新密码、图片验证码，单击【点击获取】后得到验证码RmD6Rv 。
重新打开一个页面进入密码重置界面，输入手机号17101304128，依次输入新密码等信息，获取验证码，系统提示已经发送验证码。由于不是自己的手机号，所以不知道验证码。
将自己手机号获取的验证码输入到171的验证码处，点击重置密码，系统显示重置成功。
单页面密码重置，只在一个页面完成密码重置、短信验证，短信验证不会跳转到另一个页面重置密码。这种方式现在很少采用，并不安全 这种漏洞实际基本不会遇到，只能在靶场练习一下。现在一般都采用多界面跳转验证重置密码，并且在服务端也有验证防范措施。 测试案例2用户登录处，点击找回密码。
密码找回页面显示需要通过手机号码找回，手机号码、校验码（图形验证码+短信验证码）、密码、再次输入密码是必填项。输入通过信息收集收集到的受害者手机号，点击【获取校验码】会先让用户输入图形验证码，这个验证码就只是为了验证是否是真人操作。正常输入图形验证码，点击【确认】时进行抓包，通过Response包能够直接看到短信验证码。
输入获取的短信验证码和新的密码即可重置密码。
使用新密码就可成功登录受害者的个人中心。登录后发现该网站与其他21个知名网站进行了绑定端口账号，也就是可以获取该用户已绑定网站的密码，能够扩大战果继续登录其他网站发现相关漏洞。
0x07 风险分析● 重置他人密码；● 利用他人账号进行恶意操作，如任意读取、修改、删除用户信息、转移资金等； 0x08 加固建议一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求； 对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断； 不应该将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端； 对原始密码进行了验证的情况下，限制输入原始密码的错误次数，以及有效的限制，防止攻击者暴力破解原始密码； 重置密码链接中的关键信息应随计划，不可预测（例如token机制），且禁止将关键信息返回到客户端。
代码端： 如果是使用第三方的库，请参考第三方的安全配置； 如果是自研代码，请按照修复思路对代码进行调整。
参考： https://cloud.tencent.com/developer/news/232143https://blog.csdn.net/sycamorelg ... tm_relevant_index=5[/url]
| 
发表于 2022-8-7 11:23:20
