Using components with known vulnerabilities is one of the vulnerability categories on OWASP‘s list of the ten most common vulnerabilities. A proof of concept video follows this article. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their Top 10 list one by one in our OWASP Top 10 blog series.
It is very common for web services to include a component with a known security vulnerability. When that happens it falls under this category, independently of what kind of component is vulnerable, making this a very frequent finding.
The component with a known vulnerability could be the operating system itself, the CMS used, the web server, some plugin installed or even a library used by one of these plugins.
It is one of the most common vulnerability types, with one of the reasons being that it is hard to find. The attack surface is wide as any layer could be vulnerable. As stated above any used component, everything between the core of the OS to libraries used by plugins, could have known vulnerabilities making the site vulnerable.
Developers usually focus on securing their own code and often forget about the code they have imported from others. In many cases developers are not even aware of all the code that is running. This is mainly due to plugins which in turn import libraries which in turn have their own dependencies etc.
The potential impact is impossible to grade for this as it completely depends on the vulnerable component and what vulnerability it suffers from. The vulnerability could be an XSS on some unimportant subdomain, but it could just as well lead to a full system takeover.
When a vulnerability is published on the internet, someone often uploads a ready to use payload which an attacker could simply download and use against the target. This means that an attacker can use it towards the site without even knowing how and why it works. Even when a PoC is not available, documentation about the vulnerability is easy to access, so all the attacker would need to know is how to follow instructions.
However, there are of course also exceptions to this. Some vulnerabilities require existing knowledge about the system, and if the component that is vulnerable is not directly exposed to the internet, the attacker would need to figure out a solution to that as well.
In short, this is often really easy to exploit, but can be as hard as any other vulnerability.
Over the last few years about 4500 CVEs have been published every single year, and there are of course even more vulnerabilities. It is thus hardly surprising that it is impossible for most developers to keep up-to-date with all this information.
A few years ago Reuters got hacked and someone was able to take over their Twitter account to spread false news. Reuters is one of the biggest news agencies and the possible impact of such attack should be obvious.
According to Wall Street Journal they used an outdated version of WordPress when the attack happened, making it likely that was the way attackers were able to comprise the site. It is, however, possible the attack was carried out in some other way as well.
How to discover
The first step is to identify all components that are being used and could possibly be vulnerable, i.e. the ones that somehow process user data. This includes CMS solutions, web servers, operating systems, plugins and everything in between.
The next step is to look up every component for vulnerabilities and exploits. The first step would be to use Google to search for this, and then proceed to look into different vulnerabilities and exploit databases.
To increase the likelihood of hearing about vulnerabilities before someone else uses them for malicious purposes, mailing lists, forums and word of mouth are examples of means that would be necessary to take advantage of.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable »
Example of a vulnerable application
One of many examples would be running a WordPress installation with the plugin Jetpack with a version lower than 4.0.3 as stated in our blog post about that specific vulnerability.
There are thousands more ways this vulnerability can occur, so one concrete example does not necessarily say much. However, the Jetpack case might help illustrate how vulnerabilities can be found in popular plugins, affecting a wide range of users.
The first step to get rid of vulnerabilities in the components you are using would be to always keep everything up to date. Build the system in a way that allows security patches to be installed in a timely manner.
Be careful when external components, plugins, softwares or even the dependencies of those plugins are used. Make sure that everything fulfils the requirements that have been set for custom code regarding regularly maintenance, passing security tests, etc.
Slim down the system as much as possible. Delete plugins that are not used, disable features that are of no use, block ports that are not in use.
Regularly scan the site with a security scanner that updates with new vulnerabilities. When using our own service the default is to scan once a week as we constantly update it with more vulnerabilities, and we would recommend something similar if another service was used as well.
As always in life, the following rule applies: do not use anything that sounds too good to be true.
Using Components with Known Vulnerabilities Proof of Concept video:
Just leave a comment or contact email@example.com if there are any questions, we are happy to help!