Insecure Code: TechBeacon Talks Dangerous Code & Programming Missteps

This week, Erik Sherman of TechBeacon mentioned Jeff Williams, Contrast Security CTO and Co-Founder, in an article on the consequences of insecure code "21 Dangerous Pieces of Code and Programming Mishaps". He points out that software is powerful enough to be the lifeblood of social networks, control supply chains, and get astronauts to the moon and back. 

Click here to read Erik's "salutes" to the truly terrible choices developers have made and, sadly, will continue to make.

In this TechBeacon article, Jeff Williams, Co-Founder and CTO of Contrast Security, is quoted under the section "Deliberate Sabotage" from a paper he published at the 2009 Black Hat conference: 

"Someone might bribe a developer to insert code snippets to cause damage."

From the Black Hat abstract noted in Erik's article:

"Enterprise Java Rootkits: Hardly anyone watches the developers"
by Jeff Williams

In a world with layoffs, outsourcing, and organized crime, the risk from malicious developers should be considered seriously. In "Byte Wars: The Impact of September 11 on Information Technology," Ed Yourdon cautions us to "remember that hardly anyone watches the programmers."

How much would it cost to convince a developer to insert a few special lines of Java in your application? Would you detect the attack before it went live? How much damage could it do? In many ways malicious developers are the ultimate insiders. With a very small number of lines of Java, they can steal all your data, corrupt systems, install system level attacks, and cover their tracks. What's really scary is that a trojaned Struts or Log4j library could affect most of the financial industry all at once.

In this paper, we examine the techniques that malicious programmers can use to insert and hide these attacks in an enterprise Java application. We examine techniques for bootstrapping external attacks, avoiding code review, avoiding static analysis, trojaning libraries, and trojaning an enterprise build server. The point here is not to show how complex these attacks are, but rather how many opportunities there are and how simple and obvious they are to most developers.

The paper also presents several strategies for minimizing the risk to organizations from malicious Java developers. We evaluate the benefits and limitations of procedural controls, technical controls, and detection. In particular we focus on techniques for limiting the trust you grant developers through restricting API's, establishing a trustworthy build process, and limiting trust in operation with the Java SecurityManager. We'll also discuss improving detection techniques such as code review and static analysis tools.

Businesses should be aware of these risks so that they can make informed decisions about their software supply chain, and even whether to automate certain business functions at all.

Click here to read Jeff's full report from BlackHat USA.