Application security, and the open source vulnerabilities that can threaten it, were front of mind for many in the software world this year, especially in the wake of the Equifax fiasco.
For as surreal as that incident was, seeing the personal details for 145 million people snatched out from under the noses of the Equifax team, let’s remember that a whole host of other vulnerabilities hit the industry over the course of the past year, causing plenty of headaches and long nights filled with updating and patching.
The Mend team has poured over our reports from the past year and compiled a list of the ten most common vulnerabilities in 2017. Some of these may have been first uncovered in 2016, but really came into their own during this year.
We have pulled together data not only from the National Vulnerability Database (NVD) that most developers and security personnel are familiar with, but also from our own database that is updated daily from a number of open source publicly available, peer-reviewed security advisories.
While every developer cares most about the vulnerabilities that affect their projects, we have ordered the list according to how many organizations were affected by the vulnerability. This group includes only vulnerabilities that were we have classified as Medium or High, but the order does not reflect how much damage was caused, like in the Equifax case that gained so much attention.
If we can think of one optimistic takeaway from the year’s vulnerability events, let it be this. Our hope is that more than one CEO saw the congressional hearings and sent out an urgent email to their development leads, asking for a report on which open source components are being used in their products.
More than one C-level decision maker was probably shocked to hear that their developers are building apps that contain on average between 70-80% open source components, if their team was able to get back to them with an answer at all.
We strongly recommend that your team look through their projects to see if they are using one of the versions listed below, and patch accordingly as quickly as possible.
Topping our list for 2017 is the Spring Framework.
Spring is one of the most popular Java application development frameworks because of its modularity and lightweight-ness. It is loved by many programmers since it allows them to develop more powerful applications with greater ease.
This framework is often depended on to provide an interface between your application and a database, which is essential for having an API that makes use of data from a backend. It is widely known for its inversion of the control design principle which incorporates layering, a lightweight container, and the ability to program on an interface.
Unfortunately for the good folks at Spring, they had two separate and painful vulnerabilities uncovered affect their Security project over the past year. In both cases, each CVE received a score of 5.0 with a severity of Medium.
The first was CVE-2016-9879 which was discovered in the Pivotal Spring Security and allowed attackers to bypass an important security constraint. This flaw hit 264 organizations that we were following, leading to plenty of red alerts.
According to researchers, the flaw that led to this vulnerability was a lack of clarity concerning the handling of path parameters in the Servlet Specification as not all Servlet containers actually contain path parameters when the getPathInfo() command is used to ask for a value. This is important because Spring Security depends on this value for mapping requests to security constraints. An attacker that was able to exploit this vulnerability could in theory bypass authentication to gain access to sensitive data. While luckily no stories of breaches were reported due to this vulnerability, it has the potential to lead to the same kind of exposure like we saw in the Equifax story over the flaw in Apache Struts2.
The second vulnerability that was found in Spring Security was CVE-2016-5007. This little doozie, which hit a whopping 554 organizations, also had issues of being too lax in how it allowed for mapping certain paths to the controllers, leaving some resources open wide to hackers.
Thankfully, both of these vulnerabilities have had patches put out for plugging the holes, with Spring offering updated versions.
Coming in for the silver medal is an old favorite that affected 354 organizations.
Often referred to as the “best JSON parser for Java”, the Jackson Databind component is a crowd favorite due to its ability to translate between the popular data exchange converter JSON and Java. This is an essential tool if you want to run an API and keep the lights on for your users, so we can safely say that a lot of folks suffered some grief over this one.
This beloved project was found to have a deserialization flaw that scored a 7.8 on the CVE scale, and a High on severity. The harsh verdict came down due to the vulnerability allowing attackers to perform code execution when given maliciously-crafted input to the readValue method of ObjectMapper.
Take a look here at this page from RedHat for more information on how to deal with this vulnerability.
It is well liked because once you structure it, it makes it very easy to manipulate the elements in your client-side environment. It is used for basically everything from the client side, providing validation for fields, creating buttons, and performing data manipulation like sorting and calculations.
Essentially, this component gives the user almost everything they need from a logic perspective to do whatever they would otherwise do on a server but on the web page itself.
Where it ran into trouble was with v2.2.4 and below when a lowercasing logic was used on the attribute names. This led to boolean attributes whose names were not all in lowercase causing infinite recursion, and will exceed the stack call limit, thus breaking the functionality and potentially causing a denial of service (DOS). It is unknown if this vulnerability led to any major issues or breaches.
Not listed in the NVD, Mend has labeled this vulnerability as WS-2017-0195 in our database where we saw it hit 288 organizations.
View the fix here on GitHub.
Like the name implies, this project tries to keep all of the beasts in order and not eating each other.
Zookeeper essentially helps developers configure, synchronize, and organize large distributed systems like intra or internets. So this was a big one when it was discovered that the vulnerability could lead to a denial of service attack. We saw it running wild in 212 different organizations, far more projects than would have otherwise been expected, leaving plenty for the clean up crew of developers to pick up after.
It was given a severity of Medium but a score of 6.9, making this one to watch for.
The fix turned to creating a whitelist of four letter word commands that otherwise would cause the DOS attack. We’re sure that the organizations that were hit with this one had plenty of choice four letter words of their own.
Oh Apache Tomcat, why do you hurt us so? Your logo is so cute and capabilities so useful but your vulnerabilities so bad.
Tomcat is an implementation of one of the most commonly used application server specifications, namely Java EE, making it a very popular project.
This is why it was so frustrating when CVE-2017-12617 was uncovered, putting 151 organizations at risk according to our records.
Allowing a potential remote execution attack, this CVE put many organizations at risk of some serious danger. Hackers can use this vulnerability to carry out unauthorized operations within your system like self-executing commands for publishing or stealing information like we saw in the Equifax example.
Due to its potential for causing significant damage, this vulnerability received a High severity and a score of 8.1.
The next pill that Tomcat users had to swallow was CVE-2016-6794, which allowed attackers to bypass the SecurityManager.
When a SecurityManager is configured, a web application’s ability to read system properties should be controlled by the SecurityManager.
In Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70, 6.0.0 to 6.0.45, the system property replacement feature for configuration files could be used by a malicious web application to make it past the SecurityManager and read system properties that should not be visible.
The issue with seeing properties that would otherwise not be vulnerable is that it can reveal important info. What kind of info? Well, how about your passwords.
While this was a bad one, affecting 213 organizations, it wasn’t as bad as CVE-2017-12617’s sins, and received a more moderate score of 5.1 and a severity of Medium.
According to our researchers, this vulnerability could cause denial of service to the target when exploited. The threat posed by this vulnerable walibrary s sufficient to warrant a score of 7.5 and a severity of High.
The fix is available here on GitHub.
Also a DOS attack, we decided that it makes the list due to the fact that 127 organizations were using it.
If exploited, this vulnerability allows an attacker to use a regular expression to trick the regex interpreter into a highly inefficient loop, enough to prevent the service from working properly.
The fix can be viewed here on GitHub.
Another popular one, Angular is one of the most widely used front end development frameworks. It is used for working with NPM, js, and CDNJS.
Unfortunately, there was a failure to include the proper sanitize of xlink:href attribute interpolation, which made it vulnerable to cross-site scripting attacks where attackers try tricking the server into giving them access to other parts of the site that they aren’t supposed to reach.
Keep the baddies from reaching your good stuff with this fix from GitHub.
If you spent 2017 under a rock and missed this vulnerability, here is your TL;DR.
This remote code execution attack exploited a vulnerability in the very popular Apache Struts2 project where the parser mishandled the file uploads, causing a world of hurt for the team at Equifax and ending a number of careers.
The only reason that we didn’t rank it higher up on the list was because fewer organizations had it in their inventories. However, this example proves how a single vulnerability can cause so much damage if attackers are given the opportunity.
Of course this one received a severity of High and a score of 10.
If for some reason you have not yet patched this one and still have your job, here is a link to the fix from Apache.
If the vulnerabilities listed above, excluding #9 because of the Equifax breach, were headaches only for developers, this series of CVEs affected anyone using a Wi-Fi device. So basically everyone.
The attack targeted the WPA2 encryption protocol that has become standard on all Wi-Fi systems, undermining the essential security that we have come to depend on for keeping data like our credit cards and other info safe. Hackers managed to go and perform key reinstallation attacks (shortened to Krack) and sending users of all systems from Apple to Linux into a tizzy.
It is not clear that this attack ever made it out of the theoretical research space and into the wild, but none the less we have given the series of attacks a score of 8.1 and designation of High due to its potential for wreaking havoc.