Google Provides Detailed Analysis of GitHub Attack Traffic

The high-profile DDoS attack against GitHub that went on for several days last month was the end result of an operation that included several phases and extensive testing and optimization by the attackers. Researchers at Google analyzed the attack traffic over several weeks and found that the attackers used both Javascript replacement and HTML injections.

The early stages of the attack started in early March, and Google’s researchers said that seemed to be a test as the attackers figured out the techniques they were going to use. There was only one target at that time, from March 3 to March 6, and the attackers then moved on.

“The initial test target was 114.113.156.119:56789 and the number of requests was artificially limited. From March 4rd to March 6th, the request limitations were removed,” Niels Provos from Google’s security team said in a blog post. 

“The next phase was conducted between March 10th and 13th and targeted the following IP address at first: 203.90.242.126. Passive DNS places hosts under the sinajs.cn domain at this IP address. On March 13th, the attack was extended to include d1gztyvw1gvkdq.cloudfront.net. At first, requests were made over HTTP and then upgraded to to use HTTPS. On March 14th, the attack started for real and targeted d3rkfw22xppori.cloudfront.net both via HTTP as well as HTTPS. Attacks against this specific host were carried out until March 17th.”

 The next day, the attackers, who are widely believed to be affiliated with the Chinese government, added several more hosts to the target list, all of them hosted by Amazon’s CloudFront service. The attackers changed tactics during this phase of the operation.

“At some point during this phase of the attack, the cloudfront hosts started serving 302 redirects to greatfire.org as well as other domains. Substitution of Javascript ceased completely on March 20th but injections into HTML pages continued. Whereas Javascript replacement breaks the functionality of the original content, injection into HTML does not,” Provos said. 

It wasn’t until March 26 that the attackers actually began targeting two separate resources on GitHub, one of which housed content from GreatFire.org, a censorship monitoring organization in China. The other resource was Chinese language content from the New York Times. The attack on those resources lasted until April 7 and Provos said that the attack wouldn’t have been possible if all of the Web’s links were encrypted.

“Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible. This provides further motivation for transitioning the web to encrypted and integrity-protected communication,” Provos said.

“Unfortunately, defending against such an attack is not easy for website operators. In this case, the attack Javascript requests web resources sequentially and slowing down responses might have helped with reducing the overall attack traffic. Another hope is that the external visibility of this attack will serve as a deterrent in the future.”

Suggested articles

Discussion

  • Larry West on

    I don't buy the assertion that using TLS would have made this impossible. Given a state actor that has control over some CAs, including those used by very popular sites, decrypting the traffic to inject into HTML seems perfectly possible. It may not be the optimal DDoS strategy, and perhaps the attackers would need to scale up their systems and energy budget, but, again, for a large state actor, these are minor points. Attributability might be more of a concern, but there is still plausible deniability as far as the public is concerned. (PS: these captchas seem almost illegible, and the audio nearly undecipherable. Is this seriously necessary for posting comments?)

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.