{ "id": "06fbb978-b5a1-4761-b0ae-a5d27d24828b", "created_at": "2026-04-06T00:20:53.830404Z", "updated_at": "2026-04-10T03:20:55.240208Z", "deleted_at": null, "sha1_hash": "0c4aa0404e853aeab46bc9c348a412baae0cfb6f", "title": "China Uses Unencrypted Websites to Hijack Browsers in GitHub Attack", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 52546, "plain_text": "China Uses Unencrypted Websites to Hijack Browsers in GitHub\r\nAttack\r\nBy Bill Budington\r\nPublished: 2015-04-01 ยท Archived: 2026-04-05 18:50:29 UTC\r\nUpdate 2015-04-02: Robert Graham over at Errata Security has published some excellent research pinpointing\r\nthe routers responsible for the attack, which seems to confirm their location within the Great Firewall of China.\r\nOver the past few weeks, China has been using its country's Internet infrastructure to attack political opponents by\r\nturning normal users' web browsers into Denial of Service tools. These attacks were a deep violation of the basic\r\ntrust that allows the Internet to function smoothly, and an disquieting and unprecedented development in the\r\nhistory of state-orchestrated denial-of-service attacks. They exploited the fact that many enormous sites still use\r\ninsecure HTTP rather than HTTPS, allowing the Great Firewall to modify those sites, and the fact that our web\r\nbrowsers are willing to run JavaScript code on an extremely liberal basis. These facts allowed China to marshal an\r\nincredible number of \"zombie\" systems both inside and outside of China, making billions of requests in an attempt\r\nto overwhelm the targets' servers.\r\nThe attack targets code-hosting platform GitHub, and URLs used in the attack point to two repositories, greatfire\r\nand cn-nytimes, which mirror GreatFire.org and the Chinese New York Times. As an analysis published by\r\nresearchers at Netressec explains, this Man-on-the-Side attack modifies the Baidu Analytics JavaScript included\r\nby many sites to inject a malicious copy. The malicious version of the JavaScript instructs browsers to make\r\nfrequent requests to the two GitHub URLs. As long as a browser remained on the Baidu Analytics-including site,\r\nit would continue generating traffic at a regular interval. It is important to note that although China is using its\r\nprivileged access to backbone routers within its borders to modify the Baidu resources, it is ultimately end users\r\nanywhere in the world who run the malicious code who are having their browsers hijacked.\r\nGitHub has announced that this is the largest DDoS that they have ever dealt with. Despite the scale of the attack,\r\nneither GitHub nor the individual repositories have been forced offline. In fact, due to GitHub's wide deployment\r\nof HTTPS, it would be quite hard for China to censor these specific endpoints without censoring the entirety of\r\nGitHub. One of the advantages that HTTPS provides is that it not only encrypts the contents of a web page, but\r\nalso the specific URL of the page being requested. Unless you have access to the private keys for a given site, it is\r\ndifficult for an attacker to determine exactly which URL within a site is being accessed in a secure browsing\r\nsession. And if the attacker can't determine which requests are for pages they want to block, they are forced to\r\nblock the entire site if they want to prevent access to certain pages.\r\nThis is a big advantage for citizens who wish to access information freely within a censorship regime. In order to\r\nmitigate the risk of critical information being censored, content creators can mirror their data on a secure domain\r\nthat the censors may be reluctant to block for fear of political or financial consequences. It seems that that is\r\nexactly what has happened in this situation. Before the GitHub attack started on March 26th, GreatFire.org\r\nreported an attack on their own servers starting March 17th. And indeed, blocking GitHub would have injurious\r\nhttps://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack\r\nPage 1 of 2\n\neffects on Chinese coders and thus the Chinese economy. When China previously blocked the site for days at a\r\ntime in January 2013, the former head of Google's China operations Kai-Fu Lee posted on the micro-blogging site\r\nSina Weibo that the act was \"unjustifiable,\" and that it \"will only derail the nation's programmers from the world,\r\nwhile bringing about a loss in competitiveness and insight.\" This time, they've gone a step further and actually\r\nweaponized Chinese Internet businesses in order to censor critical voices.\r\nWe know that China injected the payload at some point between Baidu's servers and when the traffic exited the\r\ncountry. This was only possible due to the fact that the Baidu Analytics script included on sites is not using\r\nencryption by default. Without HTTPS, anyone sitting between the web server and the end user can modify\r\ncontent arbitrarily. This is part of the reason we need 100% deployment of HTTPS for the entire web. At the same\r\ntime, It's important to note that HTTPS isn't a complete inoculation against malicious state action. The\r\ngovernment of China could easily have leaned on Baidu to provide their encryption keys to the censors to\r\nincorporate in their Man-on-the-Side attack. Alternatively, they could have forced Baidu to deliver the malicious\r\ncode directly from their servers. And as we have pointed out before, when governments can force web services to\r\nfork over their crypto keys or suffer the consequences, an enormous amount of information about end users\r\nactivities is divulged. In this case, it's worse: governments can turn people across the world into unwitting partners\r\nin assisting censorship regimes to stifle free speech.\r\nChina isn't unique in its technical capacity to inject traffic. Most national governments could apply this same\r\ntechnique, if they host popular JavaScript within their borders and have the tools to modify Internet traffic leaving\r\ntheir country. It has become increasingly common for websites to include utility libraries and ad networks hosted\r\non a diaspora of servers across the globe. Any one of these third party resources can modify page content, divulge\r\nbrowsing habits, or initiate an attack like the one we've described.\r\nThe solution is twofold: technical and political. As a site maintainer, you can host utility libraries locally. That\r\nway, a compromise of one remote resource will not result in malicious JavaScript being executed by your users. In\r\nthis instance, using open alternatives for analytics would have averted users loading remote attack code.\r\nSysadmins can deploy HTTPS, making it harder for malicious agents to modify traffic in-transit. And citizens can\r\nsupport initiatives such as the Manila Principles, which seeks to establish a clear legal framework around content\r\nrestriction, one that respects human rights and is grounded in due process and backed by international law. Only a\r\ncombination of sane policy and technical measures can limit governments' power to hijack our browsers and use\r\nthem to censor the Internet worldwide.\r\n2015-04-01: updated first paragraph for a slightly less technical introduction.\r\nSource: https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack\r\nhttps://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack\r\nPage 2 of 2", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack" ], "report_names": [ "china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack" ], "threat_actors": [], "ts_created_at": 1775434853, "ts_updated_at": 1775791255, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0c4aa0404e853aeab46bc9c348a412baae0cfb6f.pdf", "text": "https://archive.orkl.eu/0c4aa0404e853aeab46bc9c348a412baae0cfb6f.txt", "img": "https://archive.orkl.eu/0c4aa0404e853aeab46bc9c348a412baae0cfb6f.jpg" } }