How Google saw the DDoS attack against Github and GreatFire

The recent DDoS attacks aimed at GreatFire, a website that exposes China’s internet censorship efforts and helps users get access to their mirror-sites, and GitHub, the world’s largest code hosting service, have been linked to the Great Cannon, an attack tool co-located with the Great Firewall of China.

“A report released by GreatFire.org fingered malicious Javascript returned by Baidu servers as the source of the attack. Baidu denied that their servers were compromised,” Citizen Lab researchers noted, then explained: “The Great Cannon is not simply an extension of the Great Firewall, but a distinct attack tool that hijacks traffic to (or presumably from) individual IP addresses, and can arbitrarily replace unencrypted content as a man-in-the-middle.”

GreatFire says that the attack against their servers started on March 17, and Citizen Lab pinpoints their end to April 8, 2015. A blog post published on Friday by Niels Provos, an engineer with Google’s Security Team, shows this information is correct, as its Safe Browsing infrastructure picked up this attack, too.

“While Safe Browsing does not observe traffic at the network level, it affords good visibility at the HTTP protocol level. Using Safe Browsing data, we can provide a more complete timeline of the attack and shed light on what injections occurred when,” he noted.

The data shows that content injections against baidu.com domains on March 3, 2015, and ended on April 7. Also, that the attack was carried out in multiple phases:

Phase 1: March 3 – March 6. Target: 114.113.156.119:56789. This was a testing stage.
Phase 2: March 10 – March 13. Targets: Hosts under the sinajs.cn and cloudfront.net domains.
Phase 3: March 14 – March 17. Target: Another host under the cloudfront.net domain.
Phase 4: March 18 – March 25. Targets: Additional Five cloudfront hosts. “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.”
Phase 5: March 25 – April 7. Targets: github.com/greatfire/wiki/wiki/nyt/, github.com/greatfire/, github.com/greatfire/wiki/wiki/dw/, and github.com/cn-nytimes/.

All in all, eight baidu.com domains and corresponding IP addresses were injected with Javascript replacement payloads and HTML injections.

Apart from giving more insight in the attacks, this report shows that hiding such attacks from detailed analysis after the fact is difficult. Even though this data can’t be used to identify the attackers, it is Provos’ hope that “external visibility of this attack will serve as a deterrent in the future.”

“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,” he noted. “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.”