[公开漏洞]腾讯微博可能会被用作于DDOS他人服务器

来源：WooYun　浏览：585次　时间：2014-06-16
做网站找雨过天晴工作室
腾讯微博可能会被用作于DDOS他人服务器 相关厂商： 腾讯 漏洞作者：imlonghao 提交时间：2014-05-02 17:39 公开时间：2014-06-16 17:40 漏洞类型：设计缺陷/逻辑错误 危害等级：中 自评Rank：10 漏洞状态： 厂商已经确认 漏洞来源：http://www.wooyun.org Tags标签： 逻辑错误 设计不当 漏洞详情 披露状态：

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

厂商回复：

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

最新状态：

暂无