‘Google’ Hackers Had Ability to Alter Source Code
- By Kim Zetter
- March 3, 2010
- 11:05 pm
The hackers who targeted Google and other companies in January targeted the source code management systems of companies, allowing them to siphon source code as well as modify it, according to a new report.
More importantly, systems that the companies used to develop and manage their source code have numerous security flaws that would allow easy compromise of a company’s intellectual property. The same systems are used by numerous other companies who may not realize that their source code is open to attack.
The white paper (.pdf), released by security firm McAfee during this week’s RSA security conference in San Francisco, provides a couple of new details about the attacks, dubbed Operation Aurora, that affected some 34 U.S. companies, including Google and Adobe, beginning last July. McAfee helped Adobe investigate the attack on its system and also provided information to Google about malware that was 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 software product. Stealing the code would also 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 whose products are used by many large companies. McAfee’s white paper focuses on the insecurities in the Perforce system and provides suggestions for securing it, but the company said it also would be looking at other source code management systems in the future. The paper doesn’t indicate exactly 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 web site 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 that 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 the all the code in the local cache or on the server.
The paper lists a number of additional vulnerabilities.
沒有留言:
張貼留言