Hackers Attack Apps While Still in Development

Everybody's talking about the need to write more secure applications. But what if the bad guys sabotage the code during the development process?

Researchers long have known about the potential for infection or a breach during the software-build process using open-source tools -- there were cases in 2002 of hackers infecting OpenSSH, Sendmail, and IRC client IRSSI. But the recent generation of automated tools for compiling code and managing software builds -- namely Apache "Ant," "Maven," and "Ivy" -- have exacerbated the risk, says Brian Chess, founder and chief scientist for Fortify Software.

"This isn't a brand-new risk. People have been forever downloading and running code," Chess says. "But with these new 'build' systems that automate the process... That extra bit of automation does hurt you."

Chess and his fellow researchers at Fortify recently dubbed this class of vulnerabilities as "cross-build injection." Attackers insert vulnerabilities and malware into code during the software development process, rather than the more common approach of finding holes after the software is operational.

The problem is not in the open-source software itself, but in the way it gets distributed automatically and repeatedly during the software development process, Chess says. This practice leaves the developer and his or her application vulnerable to infection or attack.

Chris Wysopal, CTO at Veracode, says the problem extends to commercial software library components as well, not just open source. "I'm glad they [Fortify] are raising awareness of the problem of potentially malicious code getting into your organization -- not because you wrote a vulnerability [into an app], but a backdoor in a library or component" got in, he says.

Although these types of attacks are more sophisticated and difficult to launch, they can be more lucrative for the bad guys. "The payoff is so much higher than compromising just one site. You essentially get your code installed in places you wouldn't normally be able to get into because they would otherwise be untouchable," Wysopal says.

An attacker could replace source code with malware such as Trojans or backdoors, or even take control of the "build" machine, Fortify's Chess explains. At the extreme, this could be an inside job, where a malicious developer writes the malware into his company's app. "That would require a very dedicated bad guy... Quite a few attackers are not that dedicated."

A more realistic threat might be an attacker in Eastern Europe inserting malware into your software build system, he says. "That's an easy way for them to go," he says. He could do so via the build software's server, rendering the site malicious, or via a more targeted attack on a specific organization.

Wysopal says he's seeing more attacks that put backdoors into Web applications. WordPress experienced the most high-profile case of this type of attack earlier this year.

A targeted attack, meanwhile, would work like this: The attacker could do some simple reconnaissance and then target the victim company's open-source provider. "They can figure out that this bank is using particular pieces of software, and if they can compromise any of the open-source Websites the bank is using, they can compromise the [bank] in a targeted attack," Chess says.

The best way to protect software during the development phase is for the ISV or enterprise to use its own centralized repository, security experts say, rather than blindly and automatically pulling code from a tool site. That entails manually inspecting the code on a repository system each time you upgrade to a new DLL library, for instance, Wysopal says. "You do an inspection of it, and if it's OK, then let your internal developers link to it."

"You should vet that code like you're vetting the code you're writing," Wysopal says -- even if it's a commercial tool. (See CERT Advances Secure Coding Standards.)

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.