While Safe Browsing does not observe traffic at the network level, it affords good visibility at the HTTP protocol level. As such our infrastructure picked up this attack, too. Using Safe Browsing data, we can provide a more complete timeline of the attack and shed light on what injections occurred when.
For this blog post, we analyzed data from March 1st to April 15th 2015. Safe Browsing first noticed injected content against baidu.com domains on March 3rd, 2015. The last time we observed injections during our measurement period was on April 7th, 2015. This is visible in the graph below, which plots the number of injections over time as a percentage of all injections observed:
We noticed that the attack was carried out in multiple phases. The first phase appeared to be a testing stage and was conducted from March 3rd to March 6th. The initial test target was 126.96.36.199:56789 and the number of requests was artificially limited. From March 4rd to March 6th, the request limitations were removed.
The next phase was conducted between March 10th and 13th and targeted the following IP address at first: 188.8.131.52. Passive DNS places hosts under the sinajs.cn domain at this IP address. On March 13th, the attack was extended to include d1gztyvw1gvkdq.cloudfront.net. At first, requests were made over HTTP and then upgraded to to use HTTPS. On March 14th, the attack started for real and targeted d3rkfw22xppori.cloudfront.net both via HTTP as well as HTTPS. Attacks against this specific host were carried out until March 17th.
<meta name=”referrer” content=”never”/>
<iframe src=”http://pan.baidu.com/s/1i3[…]?t=Zmh4cXpXJApHIDFMcjZa” style=”position:absolute; left:0; top:0; height:100%; width:100%; border:0px;” scrolling=”yes”></iframe>
In this technique, the web browser fetches the same HTML page twice but due to the presence of the query parameter t, no injection happens on the second request. The attacked domains also changed and now consisted of: dyzem5oho3umy.cloudfront.net, d25wg9b8djob8m.cloudfront.net and d28d0hakfq6b4n.cloudfront.net. About 10 hours after this new phase started, we see 302 redirects to a different domain served from the targeted servers.
The attack against the cloudfront hosts stops on March 25th. Instead, resources hosted on github.com were now under attack. The first new target was github.com/greatfire/wiki/wiki/nyt/ and was quickly followed by github.com/greatfire/ as well as github.com/greatfire/wiki/wiki/dw/.
Our systems saw injected content on the following eight baidu.com domains and corresponding IP addresses:
- cbjs.baidu.com (184.108.40.206)
- eclick.baidu.com (220.127.116.11)
- hm.baidu.com (18.104.22.168)
- pos.baidu.com (22.214.171.124)
- cpro.baidu.com (126.96.36.199)
- bdimg.share.baidu.com (188.8.131.52)
- pan.baidu.com (184.108.40.206)
- wapbaike.baidu.com (220.127.116.11)
We hope this report helps to round out the overall facts known about this attack. It also demonstrates that collectively there is a lot of visibility into what happens on the web. At the HTTP level seen by Safe Browsing, we cannot confidently attribute this attack to anyone. However, it makes it clear that hiding such attacks from detailed analysis after the fact is difficult.