What do Heartbleed, Shellshock and Poodle all have in common? Well apart from being software vulnerabilities discovered in 2014, they were all found in pre-built software components, used by developers to speed-up the development of their own bespoke programs.
Heartbleed was in OpenSSL (an open source toolkit for implementing secure access to web sites), Shellshock was in the UNIX Bash shell (which enables the running of UNIX operating system commands from programs), whilst Poodle was another SSL vulnerability.
Also common to all three is that they were given fancy names and well publicised. This is not a bad thing; it gives the press something to hang its hat on and gets the message out to software developers that a bug needs fixing.
The time lag between zero day, when a vulnerability is first identified, and the bug being patched is the window of opportunity for hackers to exploit it. With Heartbleed in particular, there was also advice for the general public, to change their passwords for certain web sites that used the vulnerable version of OpenSSL.
However, these widely publicized bugs are just the tip of the iceberg, as data from HP’s Security Research (HPSR) team reveals. HPSR uncovers software security flaws on behalf of its customers and the boarder community.
Unlike the discoverers of Heartbleed, Shellshock and Poodle, HPSR does not seek publicity for all the flaws it hunts down via its Zero Day Initiative (ZDI) program; not least because there are so many of them.
HPSR has a number of ways of seeking vulnerabilities out. Some it simply buys from white hat hackers (those who look for ways to hack software code, but not to exploit the flaws they find).
It also sponsors an annual competition to find flaws called Pwn2Own; the 2014 event uncovered 33 in software from Adobe, Apple, Google, Microsoft and Mozilla. On top of this HPSR does its own research. In total in 2014, ZDI has uncovered over 500 bugs, two thirds of which have been patched, it estimate 50-75% of these were in software components. HPSR claims ZDI is the number one finder of bugs in deployed versions of Microsoft software.
As an HPSR rep points out ‘these days most software is composed not written,’ meaning that software is largely built from pre-constructed components. In fact, not using components would be highly inefficient, as it would mean constantly re-inventing the wheel, especially when many components are cheap or free via open source.
However, the number of bugs in software components means that users need more effective ways to monitor their use and fix problems that arise. This is especially true of open source components, as anyone can contribute to them. HPSR contends that commercial software vendors could strengthen the open source movement by investing more resources to ensure open source components are well-tested and secure.
Of course, the broader HP has an interest in all this for two reasons. First, as a builder and supplier of software, HP is a big user of components. Second, it also helps its customers build and deploy safer software through its Fortify product range. In February 2014 HP announced its Fortify Open Review Project to identify and report on security vulnerabilities in widely used open-source software components.
HP also announced improved component checking support for its on-demand scanning service by partnering with Sonatype to use its Component Lifecycle Management analysis technology.
Software Composition Analysis
HP is not alone in recognizing the need for safer component use. Veracode, another software security vendor, estimates that components constitute up to 90% of the code in some in-house developed applications.
In September 2014 Veracode added a ‘software composition analysis’ into its static software scanning service to protect customers more rapidly from zero day vulnerabilities discovered in components.
With the introduction of software composition analysis Veracode can now create an inventory of all the components used by a given customer, detailing the programs in which each is embedded. When a new vulnerability is identified in a component, Veracode can take rapid and pervasive action; either applying fixes immediately or isolating already deployed applications until patches are available.
This further enhances its ability to protect customers from newly discovered vulnerabilities. Its dynamic scanning service, which tests deployed executables, would pick many of these up too. However, it focusses on common paths through applications and may miss obscure parts that are rarely or never used, but a hacker may focus exactly on these areas once a vulnerability becomes public knowledge.
As Veracode points out, most IT departments are managing software code that was largely not built in-house. The only control, security teams have over software is to maintain effective scanning capabilities with an awareness of components to help understand inherited risk. Software components are not going to disappear; their value to business is too great, security teams need to learn how to live with them.