'Google' Hackers Had Ability to Alter Source Code

Hackers who breached Google and other companies in January targeted source-code management systems, security firm McAfee asserted Wednesday. They manipulated a little-known trove of security flaws that would allow easy unauthorized access to the intellectual property the system is meant to protect. The software-management systems, widely used at businesses unaware that the holes exist, were […]

macafee_whitepaper

Hackers who breached Google and other companies in January targeted source-code management systems, security firm McAfee asserted Wednesday. They manipulated a little-known trove of security flaws that would allow easy unauthorized access to the intellectual property the system is meant to protect.

The software-management systems, widely used at businesses unaware that the holes exist, were exploited by the Aurora hackers in a way that would have enabled them to siphon source code, as well as modify it to make customers of the software vulnerable to attack. It's akin to making yourself a set of keys in advance for locks that are going to be sold far and wide.

A white paper released by security firm McAfee during this week's RSA security conference in San Francisco provides a couple of new details about the Operation Aurora attacks (.pdf) that affected 34 U.S. companies, including Google and Adobe, beginning last July. McAfee helped Adobe investigate the attack on its system and provided information to Google about malware used in the attacks.

According to the paper, the hackers gained access to software-configuration management systems (SCM), which could have allowed them to steal proprietary source code or surreptitiously make changes to the code that could seep undetected into commercial versions of the company's product. Stealing the code would allow attackers to examine the source code for vulnerabilities, in order to develop exploits to attack customers who use the software, such as Adobe Reader, for example.

"[The SCMs] were wide open," says Dmitri Alperovitch, McAfee's vice president for threat research. "No one ever thought about securing them, yet these were the crown jewels of most of these companies in many ways — much more valuable than any financial or personally identifiable data that they may have and spend so much time and effort protecting."

Many of the companies that were attacked used the same source-code management system made by Perforce, a California-based company that makes products used by many large companies. McAfee's white paper focuses on the insecurities in the Perforce system and provides suggestions for securing it, but McAfee said it will look at other source-code management systems in the future. The paper doesn't indicate which companies were using Perforce or had vulnerable configurations installed.

As previously reported, the attackers gained initial access by conducting a spear-phishing attack against specific targets within the company. The targets received an e-mail or instant message that appeared to come from someone they knew and trusted. The communication contained a link to a website hosted in Taiwan that downloaded and executed a malicious JavaScript, with a zero-day exploit that attacked a vulnerability in the user's Internet Explorer browser.

A binary disguised as a JPEG file then downloaded to the user's system and opened a backdoor onto the computer and set up a connection to the attackers' command-and-control servers, also hosted in Taiwan.

From that initial access point, the attackers obtained access to the source-code management system or burrowed deeper into the corporate network to gain a persistent hold.

According to the paper, many SCMs are not secured out of the box and also do not maintain sufficient logs to help forensic investigators examining an attack. McAfee says it discovered numerous design and implementation flaws in SCMs.

"Additionally, due to the open nature of most SCM systems today, much of the source code it is built to protect can be copied and managed on the endpoint developer system," the paper states. "It is quite common to have developers copy source code files to their local systems, edit them locally, and then check them back into the source code tree.... As a result, attackers often don’t even need to target and hack the backend SCM systems; they can simply target the individual developer systems to harvest large amounts of source code rather quickly."

Alperovitch told Threat Level his company has seen no evidence yet to indicate that source code at any of the hacked companies had been altered. But he said the only way to determine this would be to compare the software against backup versions saved over the last six months to when the attacks are believed to have begun.

"That's an extremely laborious process, particularly when you are dealing with massive projects with millions of lines of code," Alperovitch said.

Among the vulnerabilities found in Perforce:

  • Perforce runs its software as "system" under Windows, giving malware the ability to inject itself into system-level processes and providing an attacker access to all administrative functions on the system. Although the Perforce documentation for UNIX tells the reader not to run the server service as root, it doesn't suggest making the same alteration to the Windows service. As a result, the default installation on Windows runs as a local system, or as root.
  • By default, unauthenticated anonymous users are allowed to create users in Perforce, and no user password is required to create a user.
  • All information, including source code, that is communicated between the client system and the Perforce server is unencrypted and therefore easily sniffed and compromised by someone on the network.
  • The Perforce tools use weak authentication, allowing any user to replay a request with a cookie value that is easy to guess and obtain authenticated access to the system to perform "powerful operations" on the Perforce server.
  • The Perforce client and server store all files in cleartext, allowing easy compromise of all the code in the local cache or on the server.

The paper lists a number of additional vulnerabilities.