Login Papers Register

Need an account to vote? Register to attend at gsec.hitb.org/sg2018/
Deadline is 30th June 2018!

<< previous next >>

Exploiting Vulnerabilities in Open Source Libraries: A Primer

Bruno Bossola

1 vote(s)

September 2017, Equifax: how did hackers manage to steal the data of almost 200 million users? Equifax simply fell victim to a vulnerability on a seasoned framework, Struts, which is still widely used in the industry. But even the newest ones, used in modern microservices architectures, are affected by vulnerabilities. After an introduction to the problem we will perform live exploits together, and then take a look at prevention strategies.

You will learn:
- how external vulnerabilities can affect your product
- how can be exploited to gain access
- how can you prevent being exposed


In the recent past three companies that unfortunately suffered from data breaches:

- the San Francisco Metropolitan Transit Agency’s ransomware attack [1]
- the Canada Revenue Agency apache struts hack [2], and
- Equifax’s massive data breach [3]

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 months old vulnerability. In the case of Canada Revenue Agency, the attack used a zero-day vulnerability, but 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, where the library is still unpatched.


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, and roughly 80% of the code in your application is not usually your code.


How difficult is to exploit a vulnerability in a common Java library in order to remotely execute Java code on a remote server and successfully taking control over it? Not much, really. During the presentation we will demonstrate how to do that using CVE-2017-7525 [4], a well-known vulnerability in jackson-databind [5], a widely used library to serialize and deserialize JSON, also part of the spring-boot [6] stack.A full description of the exploit is available at my personal blog [7] and the full working code you can run on your own machine, can be found on GitHub [8]

We will also show another exploit of a new vulnerability, but as this at the moment of the writing in the work and it will be disclosed at the conference.


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 [9]. 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 a 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 a vulnerability scanner into your CI/CD pipeline 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?

Several options are available on the market, and few good open-source solutions are available for integration, such as dependency-check[10] and retirejs[11]: we will have a look of how these tools can be integrated into your pipelines in order to avoid nasty surprises.


Just one vulnerability is enough for an adversary to exploit: as you use open source libraries to produce your software, you have to put in place the correct preventive measures.


[1] https://arstechnica.co.uk/information-technology/2016/11/san-francisco-transit-ransomware-attacker-likely-used-year-old-java-exploit/

[2] https://securityaffairs.co/wordpress/57130/hacking/cra-apache-struts-hack.html

[3] https://www.wired.com/story/equifax-breach-no-excuse/

[4] https://nvd.nist.gov/vuln/detail/CVE-2017-7525

[5] https://github.com/FasterXML/jackson-databind/issues/1599

[6] https://github.com/spring-projects/spring-boot

[7] https://bbossola.wordpress.com/2018/04/14/remotely-execute-java-code-using-json/

[8] https://github.com/bbossola/vulnerability-java-samples

[9] https://www.owasp.org/index.php/Top_10-2017_Top_10

[10] https://www.owasp.org/index.php/OWASP_Dependency_Check

[11] https://retirejs.github.io/retire.js/


Bruno has 30 years of solid experience in building enterprise applications with various technologies and infrastructures, with extensive knowledge of the Java platform and an immense curiosity on what's new in the sector. He's an Agile Coach, passionate about agile processes, software engineering, trained in XP and Scrum, with 15+ years of agile work from the trenches. He developed distributed objects and large-scale application for the enterprise using RMI, CORBA, and J2EE. In 1999 he coaches one of the first group that adopts XP (eXtreme Programming) method in Italy. In 2002 he has co-founder of Java User Group Torino, in 2005 he's recognized as international Java Champion, He has been promoting Java technologies as a speaker in Italy at developer conferences like Webbit, AgileDay, JavaConference, Javaday and in Europe at Devoxx, Jazoon, and Geecon. Since 2009 he lives in London, where he set up and ran a startup company which brought cutting-edge open source niche solutions to the enterprise ALM Software. He's now working in leadership positions in engineering and recently co-founded a new startup in the cybersecurity space.