Facebook Notes allows users to include <img> tags. Whenever a <img> tag is used, Facebook crawls the image from the external server and caches it. Facebook will only cache the image once however using random get parameters the cache can be by-passed and the feature can be abused to cause a huge HTTP GET flood.
Steps to re-create the bug as reported to Facebook Bug Bounty on March 03, 2014.
Step 1. Create a list of unique img tags as one tag is crawled only once
<img src=http://targetname/file?r=1></img> <img src=http://targetname/file?r=1></img> .. <img src=http://targetname/file?r=1000></img>
Step 2. Use m.facebook.com to create the notes. It silently truncates the notes to a fixed length.
Step 3. Create several notes from the same user or different user. Each note is now responsible for 1000+ http request.
Step 4. View all the notes at the same time. The target server is observed to have massive http get flood. Thousands of get request are sent to a single server in a couple of seconds. Total number of facebook servers accessing in parallel is 100+.
Initial Response: Bug was denied as they misinterpreted the bug would only cause a 404 request and is not capable of causing high impact.
After exchanging few emails I was asked to prove if the impact would be high. I fired up a target VM on the cloud and using only browsers from three laptops I was able to achieve 400+ Mbps outbound traffic for 2-3 hours.
Number of Facebook Servers: 127
Of course, the impact could be more than 400 Mbps as I was only using browser for this test and was limited by the number of browser thread per domain that would fetch the images. I created a proof-of-concept script that could cause even greater impact and sent the script along with the graph to Facebook.
On April 11, I got a reply that said
Thank you for being patient and I apologize for the long delay here. This issue was discussed, bumped to another team, discussed some more, etc.
In the end, the conclusion is that there’s no real way to us fix this that would stop “attacks” against small consumer grade sites without also significantly degrading the overall functionality.
Unfortunately, so-called “won’t fix” items aren’t eligible under the bug bounty program, so there won’t be a reward for this issue. I want to acknowledge, however, both that I think your proposed attack is interesting/creative and that you clearly put a lot of work into researching and reporting the issue last month. That IS appreciated and we do hope that you’ll continue to submit any future security issues you find to the Facebook bug bounty program.
I’m not sure why they are not fixing this. Supporting dynamic links in image tags could be a problem and I’m not a big fan of it. I think a manual upload would satisfy the need of users if they want to have dynamically generated image on the notes.
I also see a couple of other problems with this type of abuse:
- A scenario of traffic amplification: when the image is replaced by a pdf or video of larger size, Facebook would crawl a huge file but the user gets nothing.
- Each Note supports 1000+ links and Facebook blocks a user after creating around 100 Notes in a short span. Since there is no captcha for note creation, all of this can be automated and an attacker could easily prepare hundreds of notes using multiple users until the time of attack when all of them is viewed at once.
Although a sustained 400 Mbps could be dangerous, I wanted to test this one last time to see if it can indeed have a larger impact.
Getting rid of the browser and using the poc script I was able to get ~900 Mbps outbound traffic.
I was using an ordinary 13 MB PDF file which was fetched by Facebook 180,000+ times, number of Facebook servers involved was 112.
We can see the traffic graph is almost constant at 895 Mbps. This might be because of the maximum traffic imposed on my VM on the cloud which is using a shared Gbps ethernet port. It seems there is no restriction put on Facebook servers and with so many servers crawling at once we can only imagine how high this traffic can get.
After finding and reporting this issue, I found similar issues with Google which I blogged here. Combining Google and Facebook, it seems we can easily get multiple Gbps of GET Flood.
Facebook crawler shows itself as facebookexternalhit. Right now it seems there is no other choice than to block it in order to avoid this nuisance.
乌云吐槽:
Using Facebook Notes to DDoS any website
瞌睡龙 (drops) | 2014-04-25 18:35
利用facebook Notes服务进行DDos。
Notes允许插入img标签并且服务器会自动爬行抓取。
各甲方想想自己是否有相关的服务能被利用呢 :)
http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/
1#
小乐天 (Web安全只能当兴趣) | 2014-04-25 18:48
龙哥,我来帮你顶帖的
2#
erevus (我的乌云币都在小号上,小号不是绑定我QQ,别盗我号) | 2014-04-25 18:51
Facebook 的服务器的流量能进来国内么
3#
超级大菜鸟 | 2014-04-25 18:54
可以利用来搞岛国和美国的政府站
4#
VIP (Fatal error: Call to undefined function getwb() in /data1/www/htdocs/106/wzone/1/index.php on line 10|@齐迹@小胖子@z7y@nauscript|昨晚做梦梦见了一个ecshop注射0day,醒来后忘记在哪了。|预留广告位) | 2014-04-25 18:54
@erevus 亮了
5#
p.z (一回头 青春都喂了狗) | 2014-04-25 19:21
@erevus 可以的 我已经在打乌云了
6#
摄影会长 | 2014-04-25 20:03
@p.z 还不够
用图片种子打 加倍流量!
7#
霸气帝王攻 | 2014-04-25 20:17
有作用?
8#
123 (v2ex) | 2014-04-25 20:18
这帮老外是没见过用迅雷打的吧....
9#
Mujj (Krypt VPS特价www.80host.com) | 2014-04-25 21:11
我记得当初帮一个客户分析过类似的,有种子+迅雷+腾讯+贴吧+微博,我了个去
10#
whirlwind (息壤最大代理商,北京/香港不限内容云服务器,五线BGP/10兆独享/4千兆硬防,备案/可信,QQ493633628,海外服务器请联系Mujj-------------------------------------------------------无损音乐网 http://wusunyinyue.cn----------------------月色仍如昔,江上有归帆!-----------------------------) | 2014-04-26 01:34
谷歌表格也可以,,可是测试浏览器崩溃
11#
小忆 | 2014-04-26 08:47
@Mujj 求图片
12#
核攻击 (统治全球,奴役全人类!毁灭任何胆敢阻拦的有机生物!) | 2014-04-26 10:30
目测比较鸡肋……
你在贴吧高访问量的帖子插入外链图片到目标服务器……
相关内容:
Bitcoin startup BIPS loses $1 million after DDoS heist
超级短信DDOS 女生一天收上万条10086短信 还有近50万条等着她
迅雷云你伤不起啊,利用迅雷云资源绑架用户,发起大型DDOS攻击
US-CERT:DNS服务器配置不当是上周300G DDoS的元凶
【CSRF】基于图片方式(<img)的 DDOS、CC、会话劫持以及刺探用户信息
电磁风暴超暴力 PHP DDOS 攻击工具 & PHP DDOS 攻击 - 编年史
美国热炒解放军网络战能力 国产神器!军工级暴力DDOS攻击系统!
男子转嫁黑客攻击致金盾网瘫痪 被DDOS请勿乱指域名到政府网