身份认证逻辑缺陷漏洞挖掘思路

身份认证逻辑缺陷漏洞挖掘思路

背景

在渗透测试项目中,很多时候横在我们渗透路上的第一个拦路虎就是后台登录界面,有时可以通过找弱密码的方式直接获取登录后的权限,有时也可以通过钓鱼或者在其他业务系统中拿到的账户密码来登录目标系统获取更多权限,有时也可以通过未授权访问漏洞来获取本应登录后才能拿到的数据,但是如果没有以上渠道,想要获取一个靶标系统的访问权限就比较难了,因此下文总结身份认证逻辑缺陷相关漏洞挖掘思路。

密码重置逻辑漏洞

1、任意验证码重置密码

  • 无验证码验证

这种漏洞多出现于边缘业务系统(Bug较多,开发人员编码能力差),或者是新上线的系统(逻辑不完善),修改密码时可以不需要验证码或输入任意验证码,真实场景应该比较少见。

  • 验证码校验逻辑写在前端代码中

有的业务系统可能将验证码验证的逻辑写在js中,这时找到返回的验证码信息,可能进行加加密,按照代码逻辑还原出原始验证码再输入对应验证码或者通过浏览器调试功能跳过验证逻辑即可。

2、验证码验证逻辑错误

  • 未校验验证码与用户的关系

这个例子比较简单,即攻击者向服务器提交修改密码的请求,服务器向攻击者返回用于修改密码的验证码,但攻击者在修改密码的包中将目标用户从攻击者改为受害者,而服务器并没有校验验证码是否属于目标用户,导致攻击者使用自己的验证码修改了受害者的密码。

此漏洞在实现较为完善的系统上应该不会出现,而且利用此漏洞需要攻击者拥有一个目标系统的普通账号,如果攻击者没有普通账号权限且无法进行用户注册则无法利用此漏洞。

  • 修改密码的包可由用户控制且服务器未校验

对着某系统修改密码逻辑进行抓包时发现在找回密码时,系统会在第一个包中校验用户名与手机号是否匹配,不匹配就无法在浏览器中进行下一步,但是在BurpSuite中可以绕过页面本身的限制,在发送验证码时客户端向服务端发送了用户名和手机号,这一步服务器并没有根据用户ID直接根据存储的手机号信息发送验证码,因此我们可以篡改这一步的手机号信息,将受害者的手机号修改为自己指定的手机号:

图中手机号为某在线短信接收网站中的手机号码

image.png

从自己指定的手机号中获取验证码之后下一步则是验证验证码是否有效,数据包如下,客户端向服务器发送了手机号与验证码,并没有发送用户ID信息,因此这一步并没有校验手机号与用户是否匹配,因为开发人员人为这一步在找回密码的第一步已经校验过了,下图为篡改的手机号与收到的验证码通过服务器认证的步骤:

image.png

验证码验证成功之后就是修改密码的数据包,这一过程客户端发送的数据包含用户ID、用户手机号、手机验证码、修改的新密码,由于上一个包已经校验了验证码的有效性,因此可以大胆猜测这一步不会再校验验证码是否正确,且这一步需要正确填写受害者的手机号,验证码可以随意填写,密码填写为自己指定的密码,进行发包,果不其然,这一步服务器并没有检查验证码的有效性,密码修改成功。

image-20210106150254745.png

导致此问题的根本原因是业务系统在实现的过程中为了降低耦合性或者是为了减少性能开销(如修改密码过程中一次性校验多组数据可能会耗费较多系统资源),将验证步骤进行了分解,正常用户在浏览器中进行操作时这些多步骤验证操作确实可以形成完整的校验逻辑,即用户有任何一步输入错误都会导致密码修改失败,但是攻击者通过BurpSuite等工具可以绕过这些验证逻辑的统一性导致密码认证逻辑漏洞。

将此攻击过程拓展到通用场景即为:当目标程序在修改密码时没有将所有需要绑定的数据进行一次性(单个数据包)绑定认证时,就有可能存在这样的漏洞。

3、验证码爆破

利用爆破的方式来完成任意用户密码重置的前提是验证码验证这一过程可以短时间内重复多次,如果重复几次服务器就限制访问的情况下显然无法采用爆破的方式来突破验证码,以下为验证码可爆破的利用场景。

  • 验证码有效期较长(超过规定的有效期但实际还是可用)

手机或短信的验证码一般情况下会存在有效期,多为5分钟或10分钟,在某些实现相对不完善的业务系统中,点击忘记密码获取验证码时验证码显示的有效时长为5分钟,但业务系统可能并没有及时清除超时的验证码,因此验证码真实有效时间比标注的有效时间更长,甚至多次点击忘记密码之后系统会生成较多有效验证码同时存在于系统验证逻辑中,可以大大增加验证码爆破成功的概率。

  • 验证码长度短

验证码长度较短时,一般长度为4,当验证码为数字组成时则验证码生成区间为00009999共10000种可能性,假设验证码有效期为5分钟,则5分钟内爆破10000次平均每秒发10000 / 5 / 60 ~= 33个包,对于服务器压力较大,尤其是在有代理存在的情况下网络延迟较高可能无法达到这样的发包速度,因此可以只爆破一半如爆破00004999的验证码,发包频率就是原来的一半,但是此时如果验证码生成的区间为5000~9999时则无法成功爆破出验证码,因此可以多爆破几轮,按照概率是可较快爆破出目标验证码完成密码篡改的。

Cookie通用问题

最近遇到的比较多的还有撞库问题,即A目标单位部署了某X业务系统,在B非目标单位中找到与A单位相同的X业务系统,B单位的X系统存在弱密码,因此可以直接获取access_token,将B单位X系统的Token用在A单位的X业务系统中可以直接登录A单位的X系统,这种情况是因为同一个业务系统的Token生成流程完全一致,举个例子,B单位的管理员账号名为admin,其access_token生成逻辑为md5(“username”),当A单位的管理员用户名也为admin时则md5()函数的返回值与B单位业务系统代码的返回值完全一致,因此导致Cookie信息可以“一次获取,多系统登录”。

个人感觉这样的漏洞在认证环节复杂的系统上更容易出现,尤其是免密登录的SSO场景,其生成的Token为了保证减少服务器负担,可能只有一次校验逻辑,即校验用户名与Token是否匹配,而不会校验用户名和密码的组合与Token是否匹配,因为这里存在一个惯性逻辑问题即用户拿着Token来进行认证的时候服务器假定用户已经通过了用户名+密码的验证逻辑,因此在SSO登录时就不校验密码了,导致Token生成算法一致的两个系统中存在相同用户名的用户认证信息完全一致的情况。

在实际攻击场景中,如果某业务系统迟迟拿不下来可以通过fofa搜索相同的系统,即使这个系统的Cookie无法复用也可以找一些未授权访问的接口来做进一步的信息收集,不过这种方法严格意义上不符合渗透规范,容易被请去喝茶,所以还是慎用。

其他

验证码发送过程中也有较大概率存在短信轰炸的问题,攻击者可以不断请求短信发送接口,受害者就会被短信轰炸。

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×