对内容管理系统的开发来说,一个重要和关键的步骤就是账户的身份认证实现。身份认证功能可以管理用户登录行为和会话,作出有效的登录访问控制。通常,这种认证功能一般由用户名和密码来实现,但在实际应用场景中,某些重要的内容管理系统仍然存在严重的身份认证漏洞。比如我测试的雅虎小企业平台Luminate

Luminate:前身为图片广告公司,后被雅虎于2014年9月收购,与雅虎小企业服务平台整合,共同推动雅虎广告和小企业客户业务。

忘记密码功能

在我晚间例行参与的漏洞众测项目中,我决定研究研究Luminate的密码忘记处理功能。果然,他们还有一个重置用户密码的方法:

forgot.png

该方法的基本流程如下:

首先,用户向雅虎服务器提交邮箱地址,告知服务器自己忘记密码:

POST /forgotpassword HTTP/1.1 Host: login.luminate.com ontent-Type: application/x-www-form-urlencoded Content-Length: 861 Connection: close Upgrade-Insecure-Requests: 1 email=example@example.com

服务器将根据提交请求的用户创建一个一次性令牌,并发往用户邮箱:

https://login.luminate.com/passwordreset?sign=TMaJJnAjigfnprxqbcfnuBK8eJmJL2PHFByAA8OblfyHdZvxhXkeTmo5G_V1TNabJHUmSR9OSeYAnzm-yAlKbUfCYLsCQtrZnZF2IxCotLh_VEn7Px6nVTA3Sm_fF9t490t_x9-t1xKcVqRPLOgQGSHb3wXYBevsypDblPoO1c4

用户将使用这个一次性令牌验证自己身份,并进行密码重置操作:

 

POST /passwordreset HTTP/1.1

Host: login.luminate.com

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Content-Type: application/x-www-form-urlencoded

Content-Length: 463

onnection: close

Upgrade-Insecure-Requests: 1

password=password&cpassword=password&uuid=6491c80b-2850-4d9c-9061-73a6122b3dca&sign=TMaJJnAjigfnprxqbcfnuBK8eJmJL2PHFByAA8OblfyHdZvxhXkeTmo5G_V1TNabJHUmSR9OSeYAnzm-yAlKbUfCYLsCQtrZnZF2IxCotLh_VEn7Px6nVTA3Sm_fF9t490t_x9-t1xKcVqRPLOgQGTiD-OCPPqBlpAWpi4yXgz0&email=example@example.com

实验

这个密码重置方法非常有趣,因为它包含了其它一些没必要的额外参数。在以上流程第二步中,为了排除利用数据猜测发起的密码重置攻击,服务器根据用户邮箱地址生成了一串安全密钥的sign参数。严格意义上来说,该sign参数是密码重置的唯一必要参数,其它参数只是系统辅助数据。

在以上流程第三步中,可以看到,在实际的密码重置要求中,用户竟然可以修改“email”和“uuid”参数,这是非常有意思的地方,因为它可能与用户身份认证相关。

随着一点点的研究深入,我发现修改email参数根本无济于事,它只是起到了一个直观的提示作用。

yo.png

那么,“uuid”参数是什么呢?再次勾起了我的兴趣。如果sign参数是必须的,那么这个独特的用户uuid参数又是什么作用呢?从编程开发的角度来看,我觉得开发者在超出常人想像设计系统时,可能会利用sign参数识别并获取数据,把这些数据存储在hidden隐藏字段中,之后,再对这些数据进行进一步的解析验证。

<input name="uuid" value="6491c80b-2850-4d9c-9061-73a6122b3dca" type="hidden">

利用发现的问题进行攻击测试

根据以上的假设和实验可知,uuid是与用户账户ID关联的参数。如果该参数可以利用的话,我想那么不需要与sign参数配对,就能用其它人的用户ID进行密码重置。

为了验证这种攻击猜测,我利用测试账号“attacker@attacker.com”进行密码重置信息提交,其产生了一个UUID:1231c32b-2850-4e9c-9061-42k3022b3dcd;另一个测试账号为我自己的samwcurry@gmail.com,产生的UUID为:6491c80b-2850-4d9c-9061-73a6122b3dca。

当把“attacker@attacker.com”产生的UUID替换成我自己账号samwcurry@gmail.com生成的UUID后,按照以上重置流程操作,利用BurpSuite向服务器提交修改后的POST请求,最终samwcurry@gmail.com账号对应的密码竟然以账号attacker@attacker.com身份被成功重置了,GOD:

frgt.png

问题总结起来是这样的:uuid是与每个用户账户关联的认证参数,在密码重置请求提交时可以被修改,密码重置操作时与sign参数无关。

漏洞利用思路

回到文章一开始,用户名密码是身份验证的重要方式,当然,掌握了密码就能控制账户。而uuid又与账户密码重置相关,当然,换句话说,如果知晓uuid,也就能控制账户。假设的攻击场景如下:

下载.png

虽然uuid值获取存在难度,但这种攻击场景也能说明雅虎小企业平台存在的身份认证漏洞。一旦攻击者获取了uuid,就可以利用这种攻击进行反复密码重置攻击,直到完全接管控制账户。

漏洞报送时间表

2017年6月14日 – 向雅虎漏洞初报

2017年6月14日 – 雅虎方面进行漏洞验证分类

2017年6月15日 – 漏洞修复

2017年6月25日 – 公布漏洞,等待赏金。

该漏洞利用存在一定前提,文中表达思路仅供测试参考。

*参考来源:samcurry,freebuf小编clouds编译