A9: Using Components with Known Vulnerabilities 2017 OWASP

What are Components With Known Vulnerabilities?

Top 10 OWASP describes the term components as a very broad term. It can either be a full piece of software that our target relies on from a third party such as "It's me" which is an identity confirmation service or it can be a small dependency in a script that is hidden somewhere far away.

If we talk about A9: Using Components with Known Vulnerabilities we are often talking about either outdated pieces of software or software that is not actively maintained anymore. Usually well maintained software will attempt to fix any issues as they arise but often pushing out those updates can be cumbersome and users of that component can be reluctant to update. 

These issues are very hard to fix as they often rely on the human psyche to be lazy and careless. They have to be fixed at the source of the issue and they have to be fixed properly but often finding a root cause and implementing a proper update strategy can be expensive which is why many companies opt to skip on what they perceive as a money sink, instead opting to update only when things break if they do not.

We can implement a strategy as a provider of these components to force our users to update but that practice is not considered very user friendly and is often avoided which is good news for ethical hackers and penetration testers as it gives us material to report.

How to identify known vulnerabilities?

If the client in case of pentesting or target in case of bug bounties has a poor understanding of the dependencies they use and any nested dependency they are much more likely to be vulnerable to A9: Using Components with Known Vulnerabilities. This may be hard to gauge at first but anything is, it really matters to spend time on your application under test and with passing time will come solidifying knowledge. 

These dependencies do include more than just what you might think of in the first place. We are of course talking about things that are included in any configuration file of the software but also of things like any database system, API security and even the operating system itself. 

To find these A9: Using Components with Known Vulnerabilities vulnerabilities we can use automated scanners but we should be very careful not to outstep our boundaries when we do so. I always prefer to just do passive scanning with no spidering or any requests to speak of. This means that I only analyse the things that I find while I test manually.  Automated scanners need to be talked over with the client and agreed upon as they can cause serious damage to the infrastructure of the client.

I am on the lookout for any version number of software that I can find. Jquery versions, database versions, operating system banners, anything i can find. I will look these version numbers up manually but while I hack I also use a MiTM proxy such as burp to automatically scan the source code of the websites i am visiting. There are several plugins available to look for outdated software of which my favourite is retireJS.

How to prevent exposure to known vulnerabilities

Developers need to be fully aware of all the dependencies they are using and they need to think of the consequences of using dependencies. Furthermore all dependencies should be entered into an inventory system which can give an easy overview of all the dependencies being used. All of these actions are best done automatically but developers should not lose sight of which automatic actions are performed.

A vulnerability scanner will also need to be implemented to ensure the versions of the dependencies are up-to-date as they can scour the internet for the latest CVE's and automatically scan your infrastructure and dependencies for A9: Using Components with Known Vulnerabilities. 

These scans should be done periodically and preferably automatically so that they can't be forgotten. These scans are best to be executed by an external system as that is how the customer faces the web application or program. This will also ensure that the resources needed for these scans will not slow down any other servers. 

We should also ensure we only use dependencies from trusted sources and that we never use third party modifications like forks of open source dependencies for example. We need to monitor which dependencies are being used very strictly and apply risk-based analysis on whether or not we should include any third party or external component and we should carefully consider our update strategy as well to not only update when required but at least on every security patch. 

All of this needs to be described into a plan which is clear, concise and approved and carried by everyone in the organisation that is a stakeholder.

• MANUAL UPDATES

Updating our systems and components manually is an option but it can be quite cumbersome to manage and the complexity is only growing with time as things like microservices arise. To adopt a manual update technique we have to make sure to set up a proper inventory management system where we keep an eye out for any outdated vulnerabilities.

This requires a good understanding of the infrastructure as sometimes updates in one place can break things in a totally different spot. We need to be aware that we do not update to a point where the system breaks and allow the developers to fix and the testers to fully test any possible compatibility issues that arise from updating.

• USE HDIV

HDIV provides us with a useful set of tools for Web and API security. Their tools integrate with the software development lifecycle to detect vulnerable bits of code or dependencies early so they can be updated as required. This has the advantage of protecting all of the development lifecycle and flag vulnerabilities early. All of these vulnerabilities are managed in a useful dashboard that contains the results of all the scans it executes in a centralized repository, making it easier to manage.

‍

Examples of Using Components with Known Vulnerabilities in the world

To explain the severity of one of these vulnerabilities we need to look at this from all angles. After all, you want to fix things that are found by your internal scanner. Best practice would have you fix all outdated dependencies but logic dictates that when a bug bounty report comes in with no proveable impact on our infrastructures that we are hesitant to pay out.

After all, what's the harm in keeping an outdated dependency, right? Well rest assured that it can definitely harm your company greatly and opens them up to A9: Using Components with Known Vulnerabilities! After all, what one hacker was not able to exploit might still be exploitable to another hacker. 

One example that is often seen in real life targets would be outdated versions of JS being vulnerable to XSS for example. So should you report this? Well it depends. In an ideal world I would want these reports to always be accepted no matter the impact because what might not hurt now might become a giant eyesore later on when new functionality is added.

That being said, if a risk analysis points to the issue being no direct danger in the future it can be understood why sometimes these reports are denied. If there is no impact and there never will be, there is no point in spending money to fix something that hurts nobody. 

Another example we can think of is an outdated version of linux, again it really depends on the exploitability here. If the exploit in question would require us to use a port that was not even open on our target and never would be there is no real impact and the reporting should be held off until further impact can be proven.

A hacktivity report I would also like to draw your attention to is coming from none other than slack. They were using an outdated version of javascript which led to the attacker being able to load forms from domains not owned by slack. 

https://hackerone.com/reports/335339

How to classify a vulnerability

In this topic I wanted to bring up the idea of where to classify an issue because at first it might seem obvious but when learning about this issue type, you can see how things can get complicated. For example, what if you found an XSS from 2015 in your target because they used a dependency? Or how about SQLi from 2019 due to their sanitisation library? One could argue that these vulnerabilities belong to either one of their respective classes (XSS, Injections) or to this vulnerability type (being a component with known vulnerabilities). I think the case can be made of even classifying these issues under both vulnerability types instead of just one.

The issues discussed in the top 10 OWASP vulnerabilities such XSS, XXE and injections will usually eventually evolve into a component with known vulnerabilities if the component that is being built is re-used. This might not be as obvious as the examples give above, it can be as obfuscated using a JQuery library with a known XSS issue in it but then not using the affected functionality. Later on though, we might decide to add functionality that does rely on the vulnerable code but we might forget to update our JQuery component. This can also be classified as both XSS and using a component with known vulnerabilities. 
‍

‍

Conclusion

In short, finding these vulnerabilities should ideally be automated but one should never overlook the importance of a manual audit every now and again. As for hackers themselves, I always recommend we judge our impact extremely carefully and that we do not report any vulnerability like this in bug bounties until impact is clear. For pentesters it is always advised to at least report these issues as informative but ideally they should be exploited further if possible and at least investigated carefully.

Watch the video: