Hmm, I wonder if this could backfire. If it's an <iframe>, couldn't GitHub insert code that framebusts? If it's some other mechanism, couldn't they block by referrer? If it's CORS, couldn't GitHub deny CORS requests? If it's a <script> tag, couldn't GitHub do some nasty XSS?
"script": Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, "_=[TIMESTAMP]", to the URL unless the cache option is set to true. Note: This will turn POSTs into GETs for remote-domain requests.
Oh dear. If GitHub can detect this, GitHub can basically XSS all sites using Baidu's analytics.
Edit 2: Oh, the insight-labs article says the attack has stopped.
Assuming this is the Chinese government, what's their end game here? They must believe that GitHub will bow to their will and remove Greatfire or block it from China. Permanently? That seems incredibly naive. Also, have they not considered the Streisand effect? Also, assuming they see Baidu as effectively a state asset, why poison that brand for such a temporary gain? It doesn't make sense.
They must believe that GitHub will bow to their will and remove Greatfire or block it from China. Permanently?
Well, yes? Extraterritorial law enforcement works fine for the US, they're quite happy to shut down gambling, copyright infringement, and so on regardless of where you are in the world.
In this case, it's git. It's inherently distributed. It's fairly easy to force Chinese users onto a local equivalent and block all those suspicious outgoing https/ssh connections to github.
Github has been known to remove files and repositories simply because employees don't like them, despite them not actually breaking any ToS. They've also been known to block access to files/repos to users in certain countries. I wouldn't be surprised if attacks on those repos would cause it to get removed.
The US's tech prestige was damaged by the revelations that of mass US spying. One could ask "Why did the US poison their branch for such temporary gain?"
GitHub was blocked completely by GFW. But many developers in China complained, because GitHub is too important. Now it becomes available again.
I think they choose Baidu just because its scripts are widely used.
The US government should prohibit US companies from complying with censorship demands from China. It already does something like that to prevent US companies from complying with the Arab League boycott of Israel.[1]
Very interesting to look at the original content of https://github.com/greatfire/ and https://github.com/cn-nytimes. One appears to be a collection of resources for proxying around the Great Firewall [1] and the other has a number of clones of the New York Times translated in Mandarin [2][3].
I didn't realize until now that part of the NYT's strategy in having a Mandarin version may be due in part to it's being blocked in China -- a reply to China's censors, of sorts.
The only thing the average web user would take away from such a popup is that github.com is annoying or spying on them, and then proceed to bombard github with messages to knock it off (reminds me of when a blog temporarily became the #1 search term for "facebook login", oh the hate that blog received for "breaking my Facebooks")
alert("The site you are visiting contains malicious JavaScript. It uses your machine as part of a cyber attack. You must immediately alert owners of this website to remove Baidu analytics which distributes the malware.")
Or perhaps use it to advertise a Baidu competitor.
Okay, I'm guessing this isn't on Baidu so much as the Chinese governments, but incentivizing Chinese corporations to object to government attacks isn't a terrible idea.
From what I've read about Chinese leadership, it's incorrect to label Xi as "in charge", at least if you mean in a dictatorial fashion. The CCP seems to run by the consensus of top party leaders. Xi certainly has more authority/sway than the rest, but I doubt he's making all of the decisions alone.
This is a very clever attack. I wonder if the same attack can be used on other sites or if it exploits something about Github.
Github's data is difficult to cache and many pages load piecemeal using turbolinks which itself creates lots of un-cacheable requests (cacheable only until someone pushes a new commit).
So it would appear to be next to impossible to stop a distributed attack.
> I wonder if the same attack can be used on other sites or if it exploits something about Github.
It doesn't exploit anything GitHub-specific! The way it's done is applicable to any site. The reason is that it uses the <script> loophole around the Same Origin Policy (<script> can be loaded cross-domain, thanks Eich...). They basically just inject this every two seconds:
The browser will request that page expecting a script. And it'll get HTML, but that's not valid JS and just ignore it, but the DDOS is successful.
However, this also makes all sites with the malicious JS vulnerable to an XSS attack by GitHub, like GitHub is currently doing. If you visit that URL, you get this:
alert("WARNING: malicious javascript detected on this domain")
Though I think the same trick could be done with, say, <img> or <style>, and those wouldn't allow XSS (though <style> could fuck with the page, certainly). Sloppy coding, Chinese Government employee...
Github's website is very easy to cache: read heavy, non-realtime. Especially if you consider they can go into a cache-friendly mode where they disable push notifications ("you just pushed to this branch", etc).
They look real time now, but that is best effort: they don't have to be. Nobody will lament Github suddenly saying "we're under heavy load, changes will take a minute to propagate and real time notifications are turned off".
Note that this attack is read-only; there's no creating new issues or PRs or any other write operation (that would be different).
It's comparable to Wikipedia, which has close to 100% cache hits on popular pages. (sorry can't find the source for this right now)
The git repositories are another story, but that's not so easily attacked through JS.
Still, with an attack of this magnitude, no matter how cacheable, you're going to feel it.
PS: I forgot about one thing; their HTTP interface to diffs. That's a huge surface of fresh data to request which will have to go to the backend. Like you could do with Wikipedia history diffs. Perhaps they would have to cut that off for users who do not have a cookie set from a project or user home page... Okay, I spoke too soon. Github has a huge amount of fresh data to request and a targeted attack on things like git diffs (let every user request a different diff) can't just be solved by HTTP caches.
The JavaScript code instructs Visitors browsers to Request the Github Pages of Anti-censorship group Greatfire and the Chinese Language Edition of the New York Times . These groups turned to a developer source code control tool to host their information with the knowledge that China was unable to block Github because of the huge cost to its technology industry.
Seems like these groups hosted content that the Chinese government didn't approve of, and tried to put it on github to avoid it being blocked. The Chinese government responded by DDoS-ing the two repositories to bend github itself into removing/blocking the content.
I suspect at the time one or the other puts their foot in the sand, that it will escalate to a conventional war.
Let us hope that day never ever happens. It would be awful for both sides no matter the "winner". As I learned from spending a year as a UAV Pilot in Iraq from 2003-2004, in war, as soon as a single person on either side is injured, both sides permanently lose. There is no real "winner". Just one side that loses less.
Unless you can make the case that risking commercial relations with the current largest economy in the world over these attacks makes sense... I would say never.
I agree. It would be nice to see the president or some government official at least publicly acknowledge that a US-based company is currently under attack by the Chinese government.
GitHub should cut China off from all services until the attack stops. It is clearly something the Chinese government doesn't want, or they'd just block GitHub in the Great Firewall themselves.
You seem to think China (or the folks running the great firewall) would be unhappy losing GitHub. I don't think they'd care as long as those two repos were effectively invisible to users.
If I understand correctly, there is almost no way to stop this attack because it uses client side JavaScript code. If Baidu doesn't remove this malicious js from its http response, github will continue to suffer.
In hindsight, GitHub moving away from GitHub Pages from the github.com domain to github.io makes this whole situation less severe. Imagine all the GitHub-Pages-powered sites that would have been down at the moment.
That's why websites should stop including javascript from third party sources. For my analytics, I use liveinternet.ru because it runs the javascript locally on my website but passes the browser information via an image embed. Liveinternet has no ability to execute malicious code and yet I can still use them as a fully functioning analytics.
How much more difficult is using liveinternet.ru, out of curiosity? Google analytics got popular because all you had to do was paste a single line to the bottom of your site and google would handle the rest.
[+] [-] TazeTSchnitzel|11 years ago|reply
Edit: ooh, take a look at the more detailed look from insight-labs: http://insight-labs.org/?p=1682
It's XMLHttpRequest ($.ajax), but with dataType: "script". Looking at the jQuery docs (http://api.jquery.com/jquery.ajax/):
"script": Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, "_=[TIMESTAMP]", to the URL unless the cache option is set to true. Note: This will turn POSTs into GETs for remote-domain requests.
Oh dear. If GitHub can detect this, GitHub can basically XSS all sites using Baidu's analytics.
Edit 2: Oh, the insight-labs article says the attack has stopped.
[+] [-] Pirate-of-SV|11 years ago|reply
Timeline of the attack looks something like this:
1. The Chinese firewall hijacks requests to http://hm.baidu.com/h.js and sends back a script that attacks GH instead.
2. Github notices that a huge amount of people are trying to reach https://github.com/greatfire/ and https://github.com/cn-nytimes/
3. GH figures out what's happening and starts replying with the alert javascript snippet.
4. Users are now getting noticed by the alert every time their browser runs the hijacked javascript.
5. The person that wrote this article writes this article after investigating what the alert message is about.
[+] [-] fyarebox|11 years ago|reply
What would be much more interesting is replacing <body> with a multi-lingual message explaining what's happening and how to block the Baidu script.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] TazeTSchnitzel|11 years ago|reply
Edit: Google cached it here: http://webcache.googleusercontent.com/search?q=cache:CeVJaTq...
Edit 2: Here's an archive.today of Google's cache: https://archive.today/KtgpS
[+] [-] dang|11 years ago|reply
[+] [-] cvuletich|11 years ago|reply
[+] [-] RA_Fisher|11 years ago|reply
[+] [-] michaelt|11 years ago|reply
The only way to find out if Github is such a company is a few months of successful attacks.
[+] [-] pjc50|11 years ago|reply
Well, yes? Extraterritorial law enforcement works fine for the US, they're quite happy to shut down gambling, copyright infringement, and so on regardless of where you are in the world.
In this case, it's git. It's inherently distributed. It's fairly easy to force Chinese users onto a local equivalent and block all those suspicious outgoing https/ssh connections to github.
[+] [-] Liru|11 years ago|reply
[+] [-] rmc|11 years ago|reply
Countries are different beasts.
[+] [-] vinceyuan|11 years ago|reply
[+] [-] dragontamer|11 years ago|reply
An American concept. Foreign to Chinese Legalism. Do note that "Free Speech" doesn't exist over there as a concept.
[+] [-] Animats|11 years ago|reply
[1] https://www.bis.doc.gov/index.php/enforcement/oac#whatsprohi...
[+] [-] seanherron|11 years ago|reply
[1]: http://webcache.googleusercontent.com/search?q=cache:X_4LmyL...
[2]: https://github.com/cn-nytimes/mirrors [3]: https://dtl1al4e74u07.cloudfront.net/
[+] [-] allochthon|11 years ago|reply
[+] [-] akx|11 years ago|reply
[+] [-] Rezo|11 years ago|reply
[+] [-] zupa-hu|11 years ago|reply
alert("The site you are visiting contains malicious JavaScript. It uses your machine as part of a cyber attack. You must immediately alert owners of this website to remove Baidu analytics which distributes the malware.")
[+] [-] lkbm|11 years ago|reply
Okay, I'm guessing this isn't on Baidu so much as the Chinese governments, but incentivizing Chinese corporations to object to government attacks isn't a terrible idea.
[+] [-] arcatek|11 years ago|reply
"[...] Github.com, and more specifically the tools allowing to easily bypass the chinese government censorship."
I wonder what would happen with such a message.
[+] [-] ElijahLynn|11 years ago|reply
https://www.google.com/search?q=xi%20jinping
[+] [-] kinghajj|11 years ago|reply
[+] [-] ssunstruck|11 years ago|reply
[+] [-] grandalf|11 years ago|reply
Github's data is difficult to cache and many pages load piecemeal using turbolinks which itself creates lots of un-cacheable requests (cacheable only until someone pushes a new commit).
So it would appear to be next to impossible to stop a distributed attack.
[+] [-] TazeTSchnitzel|11 years ago|reply
It doesn't exploit anything GitHub-specific! The way it's done is applicable to any site. The reason is that it uses the <script> loophole around the Same Origin Policy (<script> can be loaded cross-domain, thanks Eich...). They basically just inject this every two seconds:
The browser will request that page expecting a script. And it'll get HTML, but that's not valid JS and just ignore it, but the DDOS is successful.However, this also makes all sites with the malicious JS vulnerable to an XSS attack by GitHub, like GitHub is currently doing. If you visit that URL, you get this:
Though I think the same trick could be done with, say, <img> or <style>, and those wouldn't allow XSS (though <style> could fuck with the page, certainly). Sloppy coding, Chinese Government employee...[+] [-] nothrabannosir|11 years ago|reply
They look real time now, but that is best effort: they don't have to be. Nobody will lament Github suddenly saying "we're under heavy load, changes will take a minute to propagate and real time notifications are turned off".
Note that this attack is read-only; there's no creating new issues or PRs or any other write operation (that would be different).
It's comparable to Wikipedia, which has close to 100% cache hits on popular pages. (sorry can't find the source for this right now)
The git repositories are another story, but that's not so easily attacked through JS.
Still, with an attack of this magnitude, no matter how cacheable, you're going to feel it.
PS: I forgot about one thing; their HTTP interface to diffs. That's a huge surface of fresh data to request which will have to go to the backend. Like you could do with Wikipedia history diffs. Perhaps they would have to cut that off for users who do not have a cookie set from a project or user home page... Okay, I spoke too soon. Github has a huge amount of fresh data to request and a targeted attack on things like git diffs (let every user request a different diff) can't just be solved by HTTP caches.
[+] [-] dtech|11 years ago|reply
[+] [-] phaza|11 years ago|reply
Seems like these groups hosted content that the Chinese government didn't approve of, and tried to put it on github to avoid it being blocked. The Chinese government responded by DDoS-ing the two repositories to bend github itself into removing/blocking the content.
[+] [-] yincrash|11 years ago|reply
[+] [-] TazeTSchnitzel|11 years ago|reply
[+] [-] SEJeff|11 years ago|reply
Let us hope that day never ever happens. It would be awful for both sides no matter the "winner". As I learned from spending a year as a UAV Pilot in Iraq from 2003-2004, in war, as soon as a single person on either side is injured, both sides permanently lose. There is no real "winner". Just one side that loses less.
[+] [-] ukigumo|11 years ago|reply
[+] [-] rmc|11 years ago|reply
[+] [-] camhenlin|11 years ago|reply
[+] [-] justaman|11 years ago|reply
[+] [-] eggnet|11 years ago|reply
[+] [-] r00fus|11 years ago|reply
[+] [-] smcl|11 years ago|reply
[+] [-] bstream|11 years ago|reply
[+] [-] roylez|11 years ago|reply
[+] [-] itsmrwave|11 years ago|reply
https://github.com/blog/1452-new-github-pages-domain-github-...
Obviously the link above might not work at the moment.
[+] [-] invisible|11 years ago|reply
[+] [-] chwahoo|11 years ago|reply
[+] [-] Dorian-Marie|11 years ago|reply
[+] [-] LLWM|11 years ago|reply
[+] [-] brador|11 years ago|reply
Could that be the real aim here?
[+] [-] undefined0|11 years ago|reply
[+] [-] Sanddancer|11 years ago|reply