Why The GitHub DDoS Attack Should Concern Everyone

UPDATE:  (Note: this is a bit geeky) Again according to Steve Gibson, the way this malware that attacked Github and GreatFire worked is that it modified the local hosts file using vulnerabilities that were fixed but that users had not yet patched and changed the local hosts file.  It created entries for connect.facebook.net and google-analytics.com and pointed them to the attackers server so that when your browser asked Google or Facebook for the code it needed, it got malicious code.  Another reason to keep your patches up to date!  For systems that were up to date on their patches, this attack would not work.

Steve Gibson in his Security Now podcast talked about the details of the attack against GreatFire and GitHub.

In both of these attacks, presumed to be orchestrated by China, hackers flooded these web sites with millions of requests per hour, overwhelming the servers and denying legitimate users access.  There are two other far scarier things about the attack to concern you.

While that is a problem,  bigger problem number one is this.  GreatFire runs on the Amazon cloud.  As such, they pay as they go for compute resources.  Millions of businesses do that.  The problem is that when they are seeing a customer load of 2500 times their normal load and Amazon scales up to support that, GreatFire gets the bill.

In GreatFire’s case, that bill is $30,000 A DAY.  Probably more than they would normally spend in a year.  What this means is that if you are an attacker, one attack method would be, if your target is renting their infrastructure from a pay as you go cloud service provider, to slowly ramp up their traffic – not enough to shut them down, but enough, over time, to affect them in the pocketbook.  Likely if they are not shut down but their Amazon bill goes up by a factor of 10, you deliver an interesting financial hit.  Even at $3,000 a day, never mind $30,000 a day, that is a $1 mil a year compute bill.  Pick a number between $3,000 and $30,000 a day, depending on the size of your target.  You have just caused your target to spend a lot more money to deliver his service.

Bigger problem number two is a security problem vs. a financial problem.  Apparently, the way this attack worked is that someone, presumed to be the Chinese government or one of their agents, slipped in the middle of unencrypted traffic between Chinese web hosting service Baidu (think Chinese, Google-like web services – map, cloud, news, search, etc.) and sometimes, but not always, when a client went to a Baidu hosted service, instead of getting the javascript they were supposed to get, they got a malicious script which just banged on GreatFire and later GitHub.  The user’s machine was not technically infected because when they closed the browser the script went away and Baidu was not infected – in fact, they never saw that request for the script.

Be evil and logically extend this.  You could compromise any non-SSL site and either have it serve up occasional malicious code that could do anything, or create a man in the middle attack that returns malicious code before the web site can.  They could attack any web site and when the browser closes, the evidence is gone (minor detail, it might be in a local cache but you can tell the browser not to do that or wipe it before you leave).  The user’s anti virus software won’t detect the malware because either it doesn’t persist or the software does not check scripts in browser cache.

You may have to tune the attack, but still, pretty interesting.

by