您的位置:首页 > 其它

挖洞经验|雅虎小企业服务平台Luminate身份认证漏洞

2017-07-03 16:18 465 查看
对内容管理系统的开发来说,一个重要和关键的步骤就是账户的身份认证实现。身份认证功能可以管理用户登录行为和会话,作出有效的登录访问控制。通常,这种认证功能一般由用户名和密码来实现,但在实际应用场景中,某些重要的内容管理系统仍然存在严重的身份认证漏洞。比如我测试的雅虎小企业平台LuminateLuminate:前身为图片广告公司,后被雅虎于2014年9月收购,与雅虎小企业服务平台整合,共同推动雅虎广告和小企业客户业务。

忘记密码功能

在我晚间例行参与的漏洞众测项目中,我决定研究研究Luminate的密码忘记处理功能。果然,他们还有一个重置用户密码的方法:该方法的基本流程如下:首先,用户向雅虎服务器提交邮箱地址,告知服务器自己忘记密码:
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.1Host: login.luminate.comAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Content-Type: application/x-www-form-urlencodedContent-Length: 463onnection: closeUpgrade-Insecure-Requests: 1password=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参数根本无济于事,它只是起到了一个直观的提示作用。那么,“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:问题总结起来是这样的:uuid是与每个用户账户关联的认证参数,在密码重置请求提交时可以被修改,密码重置操作时与sign参数无关。

漏洞利用思路

回到文章一开始,用户名密码是身份验证的重要方式,当然,掌握了密码就能控制账户。而uuid又与账户密码重置相关,当然,换句话说,如果知晓uuid,也就能控制账户。假设的攻击场景如下:虽然uuid值获取存在难度,但这种攻击场景也能说明雅虎小企业平台存在的身份认证漏洞。一旦攻击者获取了uuid,就可以利用这种攻击进行反复密码重置攻击,直到完全接管控制账户。

漏洞报送时间表

2017年6月14日 – 向雅虎漏洞初报2017年6月14日 – 雅虎方面进行漏洞验证分类2017年6月15日 – 漏洞修复2017年6月25日 – 公布漏洞,等待赏金。该漏洞利用存在一定前提,文中表达思路仅供测试参考。*参考来源:samcurry,freebuf小编clouds编译,转载请注明来自FreeBuf.COMclouds150 篇文章 等级:8级||上一篇:使用Python检测并绕过Web应用程序防火墙下一篇:通过服务器日志溯源web应用攻击路径发表评论

已有 7 条评论

wyldlmu (1级) 2017-07-02 回复1楼思路清晰意图明确,老铁你真厉害亮了(1)softbug (7级)011101000110100001100001011011...  2017-07-02回复2楼不错!分析联想到位!亮了(2)憶楓  2017-07-02回复3楼以前优酷 来疯 和土豆都给我这样玩过亮了(1)hwtct (1级) 1 = everythings 2017-07-02 回复4楼思路很清晰亮了(1)放开那个大婶 (1级) 2017-07-03 回复5楼那么问题来了。怎么获取到别人的uuid。感觉还是太鸡肋亮了(1)leveluo (1级) 这家伙太勤快了,竟然填写了个人描述! 2017-07-03 回复6楼我都看懂了亮了(1)super外特 (1级) 你还安全吗? 2017-07-03 回复7楼类似以前挖的51的一个洞亮了(0)
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: