China’s Great Cannon

China’s Great Cannon

citizenlab 

April 10, 2015

This post describes our analysis of China’s “Great Cannon,” our term for an attack tool that we identify as separate from, but co-located with, the Great Firewall of China. The first known usage of the Great Cannon is in the recent large-scale novel DDoS attack on both GitHub and servers used by GreatFire.org.
Authors: Bill Marczak^1,2,3 (Lead), Nicholas Weaver^2,3 (Lead), Jakub Dalek,¹ Roya Ensafi,⁴ David Fifield,² Sarah McKune,¹ Arn Rey, John Scott-Railton,¹ Ronald Deibert,¹ Vern Paxson.^2,3
Affiliations: (1) Citizen Lab, Munk School of Global Affairs, University of Toronto; (2) International Computer Science Institute; (3) University of California, Berkeley; (4) Princeton University

Section 1: Introduction, Key Findings

On March 16, GreatFire.org observed that servers they had rented to make blocked websites accessible in China were being targeted by a Distributed Denial of Service (DDoS) attack.  On March 26, two GitHub pages run by GreatFire.org also came under the same type of attack.  Both attacks appear targeted at services designed to circumvent Chinese censorship.  A report released by GreatFire.org fingered malicious Javascript returned by Baidu servers as the source of the attack.¹  Baidu denied that their servers were compromised.²
Several previous technical reports³ have suggested that the Great Firewall of China orchestrated these attacks by injecting malicious Javascript into Baidu connections.  This post describes our analysis of the attack, which we were able to observe until April 8, 2015.
We show that, while the attack infrastructure is co-located with the Great Firewall, the attack was carried out by a separate offensive system, with different capabilities and design, that we term the “Great Cannon.”  The Great Cannon is not simply an extension of the Great Firewall, but a distinct attack tool that hijacks traffic to (or presumably from) individual IP addresses, and can arbitrarily replace unencrypted content as a man-in-the-middle.
The operational deployment of the Great Cannon represents a significant escalation in state-level information control: the normalization of widespread use of an attack tool to enforce censorship by weaponizing users. Specifically, the Cannon manipulates the traffic of “bystander” systems outside China, silently programming their browsers to create a massive DDoS attack.  While employed for a highly visible attack in this case, the Great Cannon clearly has the capability for use in a manner similar to the NSA’s QUANTUM system,⁴ affording China the opportunity to deliver exploits targeting any foreign computer that communicates with any China-based website not fully utilizing HTTPS.

Report Structure

We organize our Report as follows:
Section 2 locates and characterizes the Great Cannon as a separate system;
Section 3 analyzes DDoS logs and characterizes the distribution of affected systems;
Section 4 presents our attribution of the Great Cannon to the Government of China;
Section 5 addresses the policy context and implications;
Section 6 addresses the possibility of using the Great Cannon for targeted exploitation of individual users.

Section 2: The Firewall & The Cannon: Separate Systems, Significant Similarities

Figure 1. Simplified logical topology of the Great Cannon and Great Firewall

In general, a firewall serves as an in-path barrier between two networks: all traffic between the networks must flow through the firewall.  In contrast, an on-path system like the Chinese “Great Firewall” (GFW) sits off to the side: it eavesdrops on traffic between China and the rest of the world (TAP in Figure 1), and terminates requests for banned content (for example, upon seeing a request for “http://www.google.com/?falun”,⁵ regardless of actual destination server) by injecting a series of forged TCP Reset (RST) packets that tell both the requester and the destination to stop communicating (INJECT RST in Figure 1).⁶  On-path systems have architectural advantages for censorship, but are less flexible and stealthy than in-path systems as attack tools, because while they can inject additional packets, they cannot prevent in-flight packets (packets that have already been sent) from reaching their destination.⁷  Thus, one generally can identify the presence of an on-path system by observing anomalies resulting from the presence of both injected and legitimate traffic.⁸
The GFW keeps track of connections and reassembles the packets (“TCP bytestream reassembly”)  to determine if it should block traffic.  This reassembly process requires additional computational resources, as opposed to considering each packet in isolation, but allows better accuracy in blocking.  While a web request often fits within a single packet, web replies may be split across several packets, and the GFW needs to reassemble these packets to understand whether a web reply contains banned content.
On any given physical link (e.g., a fiber optic cable), the GFW runs its reassembly and censorship logic in multiple parallel processes⁹ (perhaps running on a cluster of many different computers).  Each process handles a subset of the link’s connections, with all packets on a connection going to the same process.  This load-balanced architecture reflects a common design decision when a physical link carries more traffic than a single computer can track.  Each GFW process also exhibits a highly distinctive side-channel — it maintains a counter, and numbers the forged TCP Reset packets it injects (via the value of the IP TTL field).
The Great Cannon (GC) differs from the GFW: as we will show, the GC is an in-path system, capable of not only injecting traffic but also directly suppressing traffic, acting as a full “man-in-the-middle” for targeted flows.  The GC does not actively examine all traffic on the link, but only intercepts traffic to (or presumably from) a set of targeted addresses.  It is plausible that this reduction of the full traffic stream to just a (likely small) set of addresses significantly aids with enabling the system to keep up with the very high volume of traffic: the GC’s full processing pipeline only has to operate on the much smaller stream of traffic to or from the targeted addresses.  In addition, in contrast to the GFW, the GC only examines individual packets in determining whether to take action, which avoids the computational costs of TCP bytestream reassembly.  The GC also maintains a flow cache of connections that it uses to ignore recent connections it has deemed no longer requiring examination.
The GC however also shares several features with the GFW.  Like the GFW, the GC is also a multi-process cluster, with different source IP addresses handled by distinct processes.  The packets injected by the GC also have the same peculiar TTL side-channel as those injected by the GFW, suggesting that both the GFW and the GC likely share some common code.  Taken together, this suggests that although the GC and GFW are independent systems with different functionality, there are significant structural relationships between the two.
In the attack on GitHub and GreatFire.org, the GC intercepted traffic sent to Baidu infrastructure servers that host commonly used analytics, social, or advertising scripts.  If the GC saw a request for certain Javascript files on one of these servers, it appeared to probabilistically take one of two actions: it either passed the request onto Baidu’s servers unmolested (roughly 98.25% of the time), or it dropped the request before it reached Baidu and instead sent a malicious script back to the requesting user (roughly 1.75% of the time).  In this case, the requesting user is an individual outside China browsing a website making use of a Baidu infrastructure server (e.g., a website with ads served by Baidu’s ad network).  The malicious script enlisted the requesting user as an unwitting participant in the DDoS attack against GreatFire.org and GitHub.

Localizing the Cannon

The GFW continues to operate as normal: on-path and statefully

We began our investigation by confirming the continued normal operation of the GFW’s censorship features.  We did so employing measurements between our test system outside of China and a Baidu server that we observed returning the malicious Javascript.  We sent the Baidu server a request that the GFW would process as a query for “http://www.google.com/?falun”, a URL long known¹⁰ to trigger the GFW to inject forged TCP Resets to terminate the connection.  This packet capture shows the results of our experiment, which confirmed that the normal, well-understood operation of the GFW continues.  Note that the capture includes both the injected TCP Reset and, later, the legitimate response (an HTTP 403 reply) from the Baidu server.  This occurs because the GFW operates as an on-path system, and, as discussed earlier, on-path systems cannot prevent in-flight packets from reaching their destination.

Figure 2. How the Great Cannon was deployed in the GitHub and GreatFire.org attacks

Localizing the GFW

We then localized where (with respect to our measurement system) in the network topology the GFW operates, as follows.  For a given measurement packet, we can control how far into the network it transits from our measurement system to its destination by controlling the packet’s TTL value.  The TTL value determines after how many intermediate hops a packet will be discarded by the Internet’s internal routers.  We sent the “Falun” queries from our test system to the Baidu server with TTL values increasing from 1 on up.  We observed that the GFW’s TCP Reset injection only occurred when we sent packets with TTL values >= 18, suggesting that the GFW acts on traffic flowing between the 17th and 18th hop along the path from our test system to the Baidu server (which was itself 24 hops away from our test system).  This packet capture shows our localization results.¹¹

The GC operates as a separate, in-path system

As noted previously, our traces of GFW operation showed both the injected TCP Reset, as well as the legitimate server reply.  In contrast, no legitimate server reply accompanied the injected malicious reply from the GC.  We ran further testing, where we retransmitted our request to Baidu over the same connection, and with the same sequence numbers, after we received a malicious response.  We observed Baidu responding as normal to the retransmitted request.  Thus, we conclude¹² that the GC dropped our request before it reached Baidu, a capability not present in the GFW.¹³
We also checked whether the GFW and GC might share the same injector device,¹⁴ but found no evidence that they do.  In particular, from a given TCP source port, we sent one request designed to trigger GC injection, followed by a request designed to trigger GFW injection.  We repeated the experiment from a number of source ports.  While packets injected by both the GFW and GC exhibited a similar (peculiar) TTL side-channel indicative of shared code between the two systems, we found no apparent correlation between the GFW and GC TTL values themselves.

The GC appears to be co-located with the GFW

We used the same TTL technique to localize the GC on the path between our test system and the Baidu server.  We found that for our path, the GC acted on traffic between hop 17 and hop 18, the same link we observed as responsible for the GFW.  We also observed that unlike the GFW, we could trigger the GC using “naked” requests (i.e., requests sent in isolation, with no previous TCP SYN as required for standard communication).  Acting on “naked” requests implies that the GC’s content analysis is more primitive (and easily manipulated), but does offer significant performance advantages, as the GC no longer needs to maintain complex state concerning connection status and TCP bytestream reassembly.
We also checked two separate servers in China whose traffic the GC targets to observe whether the GC existed along with the Great Firewall on multiple network paths.  From our measurement system outside of China, we examined the path to both 115.239.210.141 and 123.125.65.120.  For 115.239.210.141, the GFW and the GC both exist between hop 12 and 13, on the link between 144.232.12.211 and 202.97.33.37, as the traffic enters China Telecom.  For 123.125.65.120, the GFW and GC both exist between hop 17 and 18, on the link between 219.158.101.61 and 219.158.101.49, belonging to China Unicom.  A previous report by Robert Graham used the same TTL technique to conclude that on one link, the GC was located “inside China Unicom infrastructure.”¹⁵

The GC is currently aimed only at specific destination IP addresses

When we probed an IP address adjacent to the Baidu server (123.125.65.121), the GC ignored the requests completely, although the GFW acted on censorable requests to this host.

Unlike the GFW, the GC only acts on the first data packet of a connection

For a given source IP address and port, the GC only examines the first data packet sent when deciding whether to inject a reply.  To avoid examining subsequent packets requires remembering which connections it has examined in a flow cache.  Unlike the GFW, the GC does not reassemble packets, a significant implementation difference.  In addition, the GC will process invalid HTTP requests, while the GFW will not, also indicating differing implementations.
We confirmed these behaviors by sending a number of probes to the Baidu server, requesting resources that trigger the GC’s injection.  Each probe had a different source port.  We sent 500 probes, each with the request split across three packets (so 1,500 packets total).  The GC ignored each probe.  We then sent 500 probes where the first packet’s data is an invalid HTTP request, and the second packet’s data is a complete, valid request for a targeted resource.  The GC ignored each probe.  We then sent a final 500 single-packet probes, each containing a complete, valid request for a targeted resource, to confirm normal GC operation.  As expected, the GC injected malicious content in some cases, seemingly based on its probabilistic decision-making process.

How big is the GC flow cache?

We attempted to completely fill the GC flow cache by sending packets to the Baidu server with different source IP addresses and ports, while probing to see whether the entries that we previously added had now expired.  Our attempt suggests that at least in some cases, the GC flow cache between our test system and the Baidu server supports up to around 16,000 entries for a single sending IP address.

Unlike the GFW, the GC appears to act probabilistically

Censorship systems generally operate in a deterministic fashion: they aim to block all content that matches the target criteria.  The GC, on the other hand — at least for this particular attack — appears to act probabilistically, and ignores most of the traffic it could act on.  In one test, it completely ignored all traffic from one of four measurement IP addresses, and on the three other measurement IP addresses it only responded to 526 requests out of an initial 30,000 from the three (1.75%).
The cache capacity test also provides evidence that the GC’s probabilistic choice occurs on the decision to act on a particular flow, and not as some sort of pre-filter for reducing analysis load.  When we succeeded in completely filling the flow cache, subsequently injected packets occurred for different source ports than in the initial test.  If the GC only intercepted a subset of flows to the target IP address, we would expect subsequent injections to appear for the same flows, since most schemes to probabilistically select flows for interception (such as hashing the connection 4-tuple) would select the same set of flows the second time around.

Does the GC have a load-balanced architecture?

We determined that the GC uses a separate flow cache for different source IP addresses, and that packets injected from different source IP addresses have distinct TTL side-channels.  This finding suggests a load-balanced architecture similar to the GFW, where packets are routed to GC nodes based on source IP address.  We then sent traffic alternating from four measurement IP addresses in an attempt to fill a 16,000 entry cache.  This attempt did not manage to fill the cache, suggesting that the GC not only processed the different source IP addresses with different injection elements, but did so using different flow caches.  As stated before, one of the four source IP addresses never received any injected replies.

Section 3: Analysis of the DDoS Logs from the attack against GreatFire

The staff of GreatFire.org provided the authors with server logs covering the period of March 18 to 28.¹⁶  (A report previously published by Great Fire uses a different sample.¹⁷) This period appears to capture the end of the DDoS attack on GreatFire.org’s services, as shown by the size of server log files over this period:
To keep our analysis tractable, we examined a sample of the data from March 18th 11:00 GMT to March 19th 7:00 GMT, as seen from two of the three most commonly seen backend servers.  For each hour, we selected 30MB of compressed logs for each server.¹⁸  The total sample includes 16,611,840 web requests, with 13,183 unique source IP addresses.  We used the MaxMind GeoIP2 Lite database¹⁹ from March 3rd, 2015 to assign a country of origin to each source IP address.  For any IP address that did not result in a definite geolocation using this tool (31 addresses), we looked up the address manually using the iplocation.net service.
The figure below summarizes the top countries of origin, with China added for comparison.

Figure 3. Number of Unique IP addresses seen in DDoS log sample showing the top 5 countries/regions, with Chinese traffic included for comparison.

Note that 8,827 (66.9%) of the IP addresses originate from Taiwan and Hong Kong, two regions where Chinese is the official language. China, however, accounted for only 18 requests.  This is consistent with malicious code injected into China-hosted websites at the border of the Chinese Internet.
To determine which websites have their responses altered by the injection of malicious code, we extracted the domain names of the 25 most frequently seen referrers in our dataset,²⁰  finding that these domains account for 55% of the total requests in the sample.

Figure 4. Top 25 referrers found in the DDoS logs, grouped by domain. The top bar reflects domains directly in the baidu.com DNS space. Manual verification confirms that all top 25 referrers use Baidu services such as advertising or analytics.

The most commonly seen domain is pos.baidu.com (37.7% of total requests in the sample), a part of Baidu’s ad network.  Many non-Baidu sites display ads served through Baidu’s ad network, indicating that visitors to non-Baidu sites displaying ads also became targeted.²¹
We examined the top 25 domains, and linked each one to Baidu: in each case, the site is either a Baidu property or uses Baidu analytics, advertisements, or static resources.²² This finding indicates that Baidu was a major injection target for this attack. According to Alexa statistics, Baidu itself is the fourth-most visited site globally, the highest ranking China-based site on the global list,²³ and has received an estimated 4.99 million unique visitors from the US alone in the past 30 days.²⁴
We speculate that Baidu was chosen as an injection target because it is a simple way to target many users.

Section 4: Attributing the Great Cannon to the Chinese Government

We believe there is compelling evidence that the Chinese government operates the GC.  In recent public statements, China has deflected questions regarding whether they are behind the attack, instead emphasizing that China is often itself a victim of cyber attacks.²⁵

Where is the GC Located?

We tested two international Internet links into China belonging to two different Chinese ISPs, and found that in both cases the GC was co-located with the GFW.  This co-location across different ISPs strongly suggests a governmental actor.

Who built the Great Cannon?

That the GFW and GC have the same type of TTL side-channel suggests that they share some source code.  We are unaware of any public software library for crafting packets that introduces this type of TTL side-channel.

What is the Great Cannon’s Function?

Our observations indicate that the GC’s design does not reflect technology well-suited for performing traffic censorship.  Its operation only examines the first data packet of a given connection, which provides a weak censorship mechanism compared to the GFW.  More generally, the GC’s design does not, in practice, enable it to censor any traffic not already censorable by the GFW.  Thus, the evidence indicates that the GC’s role is to inject traffic under specific targeted circumstances, not to censor traffic.

Who is the Great Cannon attacking?

The DDoS attack launched by the GC using “bystander” machines directly aligns with known political concerns of the Chinese government.  The Cyberspace Administration of China has previously referred to GreatFire as a “foreign anti-Chinese organization” (境外反华组).²⁶  The particular GreatFire service targeted in this attack provides proxies to bypass the GFW using encrypted connections to Amazon’s CloudFront cloud service.
GreatFire also hosts two GitHub repositories, https://gitub.com/greatfire and https://github.com/cn-nytimes, that provide technology for users who wish to circumvent Chinese government censorship.  The attack on GitHub specifically targeted these repositories, possibly in an attempt to compel GitHub to remove these resources.  GitHub encrypts all traffic using TLS, preventing a censor from only blocking access to specific GitHub pages.  In the past, China attempted to block Github, but the block was lifted within two days, following significant negative reaction from local programmers.²⁷

Section 5: Policy Context and Implications

This section describes some policy implications of deploying the Great Cannon, addresses the impact of targeting Baidu traffic specifically, and discusses the Chinese authorities that may be involved in operation of the GC.

Implications of the GC for Chinese Policy

Deploying the Great Cannon is a major shift in tactics, and has a highly visible impact. It is likely that this attack, with its potential for political backlash,²⁸ would require the approval of high-level authorities within the Chinese government. These authorities may include the State Internet Information Office (SIIO),²⁹ which is responsible for Internet censorship. It is also possible that the top body for cybersecurity coordination in China, the Cybersecurity and Informatization Leading Group (CILG),³⁰ would have been involved. The CILG is chaired by Xi Jinping and includes as members senior leaders from across the government; its administrative office is housed within the SIIO.³¹
The government’s reasoning for deploying the GC here is unclear, but it may wish to confront the threat presented to the Communist Party of China’s (CPC) ideological control by the “collateral freedom” strategy advanced by GreatFire.org³² and others. The attack was exceptionally costly to GreatFire, according to their public statements,³³ as well as disruptive to the companies that hosted GreatFire content. Such a disruption could be both an attempt to block the operations of an undesirable resource, and a signal sent to other organizations of the potential price tag for this kind of activity. Deployment of the GC may also reflect a desire to counter what the Chinese government perceives as US hegemony in cyberspace.
This approach would be consistent with the CPC’s paramount focus on protecting “domestic stability” (and its own authority) against entities it has identified as “foreign hostile forces,” including not only governments but also Western media outlets (such as the New York Times) and NGOs or other civil society actors (such as GreatFire.org).³⁴ According to such a world view, the collateral freedom strategy is a provocative, hostile act that threatens China’s security.

Implications of Using Traffic to Baidu Services

The incorporation of Baidu in this attack suggests that the Chinese authorities are willing to pursue domestic stability and security aims at the expense of other goals, including fostering economic growth in the tech sector. Selecting Baidu’s international traffic may appear counterproductive given the importance of Baidu to the Chinese economy: the company enjoys stature as one of China’s “big three” Internet firms, alongside Alibaba and Tencent,³⁵ and currently ranks as the top site in China.³⁶ While its shares came under pressure after the February release of its Q4 and fiscal year 2014 reports,³⁷ its total revenue in 2014 was USD $7.906 billion, with online marketing revenues for that period valued at USD $7.816 billion.³⁸

“Service interruptions could reduce our revenues and profits and damage our brand if our systems are perceived to be unreliable.”³⁹

Baidu has denied involvement in the attack and asserted its internal security was not compromised.⁴⁰ Yet the targeting of international visitors trying to reach sites that are Baidu properties, or that use Baidu analytics, advertisements, or static resources, could undermine the company’s reputation and its appeal to overseas users and advertisers.
Baidu writes in its SEC filings that it was the target of legal action in the United States in 2011⁴¹ for complying with Chinese censorship. Baidu explicitly notes that cooperation and coordination with Chinese censorship authorities could be costly in terms of brand image, profit, and stockholder confidence.

“our compliance with PRC regulations governing internet access and distribution of news and other information over the internet may subject us to negative publicity or even legal actions outside of China.”⁴²

Moreover, exploiting Baidu’s international reach as a means for conducting digital attacks belies the government’s recent commitment to enhance the global presence of Internet companies. At the meeting of the National People’s Congress on March 5, 2015, Premier Li Keqiang (who is also Vice-Chair of the CILG) announced:

We will develop the “Internet Plus” action plan to integrate the mobile Internet, cloud computing, big data, and the Internet of Things with modern manufacturing, to encourage the healthy development of e-commerce, industrial networks, and Internet banking, and to guide Internet-based companies to increase their presence in the international market.⁴³

This goal – which closely echoes that contained in a draft declaration presented (but not passed) at the November 2014 Wuzhen World Internet Conference⁴⁴ – may not come to fruition if Chinese domestic companies appear unreliable, their business objectives secondary to other objectives of the Chinese Government.
Chinese authorities may, however, be betting that their use of Baidu traffic to mount this DDoS attack will ultimately be perceived as an isolated occurrence, a sort of “force majeure,” with limited impact on Baidu’s long-term economic prospects – particularly given Baidu’s apparent status as unwitting victim and its strong market position.
Additionally, Baidu’s CEO Robin Li is a member of the Chinese People’s Political Consultative Conference⁴⁵ and well-positioned for lucrative government contracts going forward — such as his artificial intelligence project “China Brain,” for which he has sought military support.⁴⁶ He may have little personal incentive (let alone opportunity, given the existing legal and regulatory framework applicable to Internet companies in China⁴⁷) to challenge this action by the government.

Thinking About Authorities Who May Be Responsible for Implementing The Great Cannon

Even for the GFW, it is difficult to pinpoint the precise authorities behind its deployment, or its operators and origins. This makes understanding the origins of the GC equally challenging.  However, some clues are available. For example, the shared source code and co-location between the GFW and GC suggest that the GC could have been developed within the same institutional framework as the GFW. We might therefore draw further insight into the GC by assessing what we know about the GFW.
Some reports characterize the GFW as an element of China’s “Golden Shield” project,⁴⁸ under the authority of the Ministry of Public Security. However, unverified insider information ‘leaked’ online suggests that the GFW was developed within a separate entity: the “National Computer Network and Information Security Management Center” (国家计算机网络与信息安全管理中心) (hereafter, “the Center”).⁴⁹ Little is publicly known about the Center. It appears to bear close relationship⁵⁰ to the National Computer Network Emergency Response Technical Team/Coordination Center of China (CNCERT/CC) run by the Ministry of Industry and Information Technology (MIIT) — indeed, the listed address for CNCERT/CC is the same as that of the Center as indicated on its patent applications — and the former National Network and Information Security Coordination Team,⁵¹ a subcommittee of the State Informatization Leading Group subsumed by the CILG in 2014.⁵² Notably, “MIIT also regulates China’s six Internet service providers (ISPs), which in turn are expected to monitor and filter content on their networks according to censorship guidelines established by the State Council Information Office and the SIIO.”⁵³ Those ISPs include China Telecom and China Unicom, on the links of which we co-located the GFW and GC (see above).
It is unknown whether the GFW and/or the GC are in fact maintained (or may have been developed in whole or in part) by the National Computer Network and Information Security Management Center.  However, patent applications filed by this entity, taken together, appear to indicate a mandate for large scale network surveillance, filtering, and defense. The Center has filed nearly 100 patent applications,⁵⁴ for designs such as “Method for detecting unexpected hot topics in Chinese microblogs;” “Method and system for recognizing Tibetan dialects;” “Website classifying method;” “Method and system for intelligent monitoring and analyzing under cloud computing;” “Method and device for managing global indexes of mass structured log data;” “Method, device and system for traffic monitoring and switching;” “Image searching/matching method and system for the same;” and “Internet basic information management system” (this last “comprises a national-level management sub-system, a provincial management sub-system and an enterprise management sub-system” that “can perform effective supervision on the Internet basic information throughout the country”). Moreover, according to state media, during the time of the GFW’s development the so-called “father of the Great Firewall,” Fang Binxing, was employed at CNCERT/CC,⁵⁵ an entity that appears closely tied to the Center.⁵⁶ Fang is likewise listed as an inventor on a 2008 patent application by the Center, indicating some collaboration with the Center prior to that point.
While we cannot determine the exact role played by the Center, the patent documentation and the Center itself require further research and analysis to determine whether they are relevant to operation of the GC, or present other human rights-related concerns.

Section 6: Concluding Remarks: The Capability for Targeted Exploitation by China

We conclude with some remarks about the precedent set by China in the use of the GC and outline further implications for targeted exploitation.
The attack launched by the Great Cannon appears relatively obvious and coarse: a denial-of-service attack on services objectionable to the Chinese government.  Yet the attack itself indicates a far more significant capability: an ability to “exploit by IP address”. This possibility, not yet observed but a feature of its architecture, represents a potent cyberattack capability.
A technically simple change in the Great Cannon’s configuration, switching to operating on traffic from a specific IP address rather than to a specific address, would allow its operator to deliver malware to targeted individuals who communicates with any Chinese server not employing cryptographic protections.  The GC operator first needs to discover the target’s IP address and identify a suitable exploit.  The operator then tasks the GC to intercept traffic from the target’s IP address, and replace certain responses with malicious content.  If the target ever made a single request to a server inside China not employing encryption (e.g., Baidu’s ad network), the GC could deliver a malicious payload to the target.  A target might not necessarily realize that their computer was communicating with a Chinese server, as a non-Chinese website located outside China could (for example) serve ads ultimately sourced from Chinese servers.
Since the GC operates as a full man-in-the-middle, it would also be straightforward to have it intercept unencrypted email to or from a target IP address and undetectably replace any legitimate attachments with malicious payloads, manipulating email sent from China to outside destinations.  Even email transmission protected by standard encryption (STARTTLS) can be undermined because the GC is in a position to launch a “downgrade” attack, steering the transmission to only use legacy, unencrypted communication.
Our findings in China add another documented case to at least two other known instances of governments tampering with unencrypted Internet traffic to control information or launch attacks — the other two being the use of QUANTUM by the US NSA and UK’s GCHQ.  In addition, product literature from two companies, FinFisher and Hacking Team, indicate that they sell similar “attack from the Internet” tools to governments around the world.⁵⁷  These latest findings emphasize the urgency of replacing legacy web protocols, like HTTP, with their cryptographically strong versions, like HTTPS.
We remain puzzled as to why the GC’s operator chose to first employ its capabilities in such a publicly visible fashion.  Conducting such a widespread attack clearly demonstrates the weaponization of the Chinese Internet to co-opt arbitrary computers across the web and outside of China to achieve China’s policy ends.  The repurposing of the devices of unwitting users in foreign jurisdictions for covert attacks in the interests of one country’s national priorities is a dangerous precedent — contrary to international norms and in violation of widespread domestic laws prohibiting the unauthorized use of computing and networked systems.

................................................................................
3c.ltn自由時報

不讓你連還攻擊你！中國網路長城將升級為網路砲兵！

3C 科技頻道／綜合報導／2015-04-13 10:43

 

去過中國的人都知道，中國針對國外網站所設立的國家級防火牆「網路長城」相當厲害，到了中國想要上臉書、傳 LINE，都得要透過不易的「翻牆」手法才能完成，但是現在中國政府預計把這項「網路安全」設施再升級，不僅具有被動的阻擋手法，還能主動的攻擊特定目標網站。

全球網站注意！中國網路大砲要來襲啦！圖片來源：法新社

上個月就有一個網站疑似遭到這種攻擊，專門提供中國國內網友連上國外網站的鏡像服務 Greatfire.org，在  3 月份遭到不明的 DDoS 阻斷攻擊，疑似由中國最大搜尋引擎百度伺服器所傳出的大量要求，癱瘓了 Greatfire.org 的服務，即便中國官方網路監管機構已經對此作出否認，但是上週五由加拿大多倫多大學提出的報告中指出，大多數的可疑連線都來自於中國境內的伺服器。

目前中國網路長城與網路大砲的可能運作方式分析，採用阻擋與攻擊的兩種並行模式，畫面擷取自 citizenlab.org 網站。

報導中指出，這種被稱為量子（ Quantum）的大量攻擊技術，不僅中國正在研發，包括美國與英國，也使用這種技術進行網路資料審查與監控，或許在無法察覺的網際網路中，爾虞我詐的激烈攻防正進行中。