Last Saturday I was excited to speak at the recent Codemotion Rome 2018 conference to talk about how important (and critical!) it is to keep the open source libraries of your software up-to-date to minimise your risk to vulnerabilities.

After introducing the problem of vulnerabilities due to live dependencies on open source software libraries, I gave a live demo of how just one well-known open source vulnerability in jackson-databind (CVE- 2017-7525) can be exploited to take control of the targeted system.

It’s incredibly easy to exploit the vulnerability by simply using a JSON message. If you are a software developer or a technical person I encourage you to have a look at this technical explanation, which allows you to reproduce the same experiment I demonstrated.

Some famous victims…

During my presentation, I spoke of three companies that unfortunately suffered from data breaches:

• The San Francisco Metropolitan Transit Agency’s ransomware attack
• The Canada Revenue Agency apache struts hack, and
• Equifax’s massive data breach

All three are from completely different industries and their systems were targets of a cybersecurity attack exploiting a vulnerability in a third-party open source library.  Two of these vulnerabilities were not newly discovered security holes.  On the contrary, the attack on San Francisco MTA exploited a one-year old vulnerability, and Equifax was hacked using a two-month old vulnerability.  In the case of Canada Revenue Agency,  the attack used a zero-day vulnerability.

In two of the three cases, such attacks would have been avoided if some basic software security maintenance had been in place. Even a fully manual process would have probably avoided a successful attack.

If we look at the situation today, examining three of the most common open source libraries used in modern applications, we can see that the scenario is far from ideal:

• vert.x 3.5.1 (latest version) incorporates three major vulnerabilities
• struts 2.5.16 (latest version) also incorporates three major vulnerabilities
• spring-boot 1.5.9 (released on 09/2017) incorporates four major vulnerabilities

Interestingly so, the supporting technical explanation shows an exploit of a vulnerability actually very similar to the one available in vert.x 3.5.1, which in the library is still unpatched.

Why are we using open source libraries then?

At this point, you may ask, “Why are we using these open source libraries if they are potentially so dangerous?” If you want to deliver code quickly then it’s a real time saver if you can use pre-built software components ready to solve all or most of your problems. Why rewrite everything on your own? Unless you see a competitive advantage to do so, most likely you do not want to use your engineering resources to reinvent the wheel but rather accelerate development for faster time to market. Furthermore, if you need access to state-of-the-art algorithms, using open source may be your only option, as you do not want to implement one of those again.

All this contributes to the hard fact that nowadays applications use external libraries and frameworks.

Preventive measures

As this is a very well understood problem, it’s possible to put in place simple preventive measures while also complying with the OWASP Top Ten Application Security Risks. Recently, the risk of using components with known vulnerabilities was added to OWASP and includes these common reasons why you are likely vulnerable:

• if you don’t know the versions of all your software components,
• if your software is vulnerable, unsupported, or out of date,
• if you don’t scan for vulnerabilities regularly, and
• if you don’t update and fix vulnerabilities in timely fashion

To improve upon the quality of your software, it is essential to build in security into your development workflow. Find out exactly which components and versions you have and get an assessment of your code’s vulnerabilities by using our continuous security platform Meterian. When integrated into your CI/CD pipeline or used as a manual scan, Meterian immediately highlights vulnerabilities your software is potentially exposed to in an assessment report. You can see a sample report here with clear information and indications of how to resolve each vulnerability.

This is a very basic and straightforward action to take in order to not end up in the news like other unfortunate companies have. Are you using a vulnerability assessment tool on your software projects?

Just one vulnerability is enough for an adversary to exploit.

I encourage you to try our Meterian client and get in touch if you need any further information.