This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Top 10-2017 A9-Using Components with Known Vulnerabilities"

From OWASP
Jump to: navigation, search
(Launch the new page for Top 10 2017-A9-Using Components with Known Vulnerabilities (RC1) with content of 2013-A9 as a reference to compare changes)
 
m (Updated broken link to Mitre article: https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf)
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
−
     |usenext=2013NextLink
+
    |useprev=2017PrevLink
 +
    |prev=A8-{{Top_10_2010:ByTheNumbers
 +
        |8
 +
        |year=2017
 +
        |language=en
 +
    }}
 +
     |usenext=2017NextLink
 
     |next=A10-{{Top_10_2010:ByTheNumbers
 
     |next=A10-{{Top_10_2010:ByTheNumbers
−
              |10
+
        |10
−
              |year=2017
+
        |year=2017
−
              |language=en}}
+
        |language=en
−
     |useprev=2013PrevLink
+
     }}
−
    |prev=A8-{{Top_10_2010:ByTheNumbers
 
−
              |8
 
−
              |year=2017
 
−
              |language=en}}
 
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
−
 
+
<!--- 2017 Using Components with Known Vulnerabilities --->
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
−
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=1|detectability=3|impact=2|year=2017|language=en}}
+
{{Top_10-2017:SummaryTableTemplate|exploitability=2 |prevalence=3 |detectability=2 |impact=2 |year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
−
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
    <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors.
+
<!--- Threat Agent: --->
−
</td>
+
While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit. </td>
−
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
Attacker identifies a weak component through scanning or manual analysis. He customizes the exploit as needed and executes the attack. It gets more difficult if the used component is deep in the application.
+
<!--- Security Weakness: --->
−
 
+
Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date.<br/>Some scanners such as retire.js help in detection, but determining exploitability requires additional effort. </td>
−
</td>
+
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
    <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
<!--- Impacts: --->
−
Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.
+
While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list. </td>
−
 
 
−
</td>
 
−
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
−
The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise.
 
−
 
 
−
</td>
 
−
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
−
Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.
 
−
 
 
−
</td>
 
 
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
  
−
{{Top_10:SubsectionTableBeginTemplate|year=2017|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=9|year=2017|language=en}}
+
{{Top_10:SubsectionTableBeginTemplate|type=main}}
−
In theory, it ought to be easy to figure out if you are currently using any vulnerable components or libraries. Unfortunately, vulnerability reports for commercial or open source software do not always specify exactly which versions of a component are vulnerable in a standard, searchable way. Further, not all libraries use an understandable version numbering system. Worst of all, not all vulnerabilities are reported to a central clearinghouse that is easy to search, although sites like [http://cve.mitre.org/  CVE] and [http://nvd.nist.gov/home.cfm  NVD] are becoming easier to search.
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=isTheApplicationVulnerable|position=firstLeft|year=2017|language=en}}
 +
You are likely vulnerable:
 +
* If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
 +
* If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
 +
* If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
 +
* If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
 +
* If software developers do not test the compatibility of updated, upgraded, or patched libraries.
 +
* If you do not secure the components' configurations (see <b><u>[[{{Top_10:LanguageFile|text=documentRootTop10New|language=en|year=2017 }}_A6-{{Top_10_2010:ByTheNumbers|6|year=2017|language=en}} | A6:2017-{{Top_10_2010:ByTheNumbers|6|year=2017|language=en}}]]</u></b>).
  
−
Determining if you are vulnerable requires searching these databases, as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability. If one of your components does have a vulnerability, you should carefully evaluate whether you are actually vulnerable by checking to see if your code uses the part of the component with the vulnerability and whether the flaw could result in an impact you care about.
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howToPrevent|position=right|year=2017|language=en}}
 +
There should be a patch management process in place to:
 +
* Remove unused dependencies, unnecessary features, components, files, and documentation.
 +
* Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like <u>[http://www.mojohaus.org/versions-maven-plugin/ versions]</u>, <u>[[OWASP_Dependency_Check|DependencyCheck]]</u>, <u>[https://github.com/retirejs/retire.js/ retire.js]</u>, etc. Continuously monitor sources like <u>[https://cve.mitre.org/ CVE]</u> and <u>[https://nvd.nist.gov/ NVD]</u> for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
 +
* Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
 +
* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a <u>[[Virtual_Patching_Best_Practices#What_is_a_Virtual_Patch.3F | virtual patch]]</u> to monitor, detect, or protect against the discovered issue.
 +
Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
  
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=9|year=2017|language=en}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=en}}
−
One option is not to use components that you didn’t write. But that’s not very realistic.
+
<b>Scenario #1</b>: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:
 +
* <u>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 CVE-2017-5638]</u>, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
 +
* While <u>[https://en.wikipedia.org/wiki/Internet_of_things internet of things (IoT)]</u> are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).
 +
There are automated tools to help attackers find unpatched or misconfigured systems. For example, the <u>[https://www.shodan.io/report/89bnfUyJ Shodan IoT search engine]</u> can help you find devices that still suffer from <u>[https://en.wikipedia.org/wiki/Heartbleed Heartbleed]</u> vulnerability that was patched in April 2014.
  
−
Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical. Software projects should have a process in place to:
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2017|language=en}}
−
# Identify all components and the versions you are using, including all dependencies. (e.g., the [http://mojo.codehaus.org/versions-maven-plugin/  versions] plugin).
+
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017|language=en}}
−
# Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
+
* <u>[[ASVS_V1_Architecture|OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling]]</u>
−
# Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
+
* <u>[[OWASP_Dependency_Check|OWASP Dependency Check (for Java and .NET libraries)]]</u>
−
# Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
+
* <u>[[Map_Application_Architecture_(OTG-INFO-010)|OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)]]</u>
−
 
+
* <u>[[Virtual_Patching_Best_Practices|OWASP Virtual Patching Best Practices]]</u>
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=9|year=2017|language=en}}
 
−
Component vulnerabilities can cause almost any type of risk imaginable, ranging from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011.
 
−
* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451  Apache CXF Authentication Bypass] – By failing to provide an identity token, attackers could invoke any web service with full permission. (Apache CXF is a services framework, not to be confused with the Apache Application Server.)
 
−
* [http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/  Spring Remote Code Execution] – Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.
 
−
 
 
−
Every application using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.
 
−
 
 
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=9|year=2017|language=en}}
 
−
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
 
−
 
 
−
* [[OWASP Dependency Check|OWASP Dependency Check (for Java libraries)]]
 
−
* [https://github.com/OWASP/SafeNuGet  OWASP SafeNuGet (for .NET libraries thru NuGet)]
 
  
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
−
* [http://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-insecure-libraries  The Unfortunate Reality of Insecure Libraries]
+
* <u>[https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf The Unfortunate Reality of Insecure Libraries]</u>
−
* [http://en.wikipedia.org/wiki/Open_source_software_security  Open Source Software Security]
+
* <u>[https://www.cvedetails.com/version-search.php MITRE Common Vulnerabilities and Exposures (CVE) search]</u>
−
* [http://img.en25.com/Web/SonatypeInc/%7Bb2fa5ed8-938d-4bce-8a9c-d08ebeba826d%7D_Executive_Brief_-_Study-_Understanding_Security_Risks_in_OSS_Components-1.pdf  Addressing Security Concerns in Open Source Components]
+
* <u>[https://nvd.nist.gov/ National Vulnerability Database (NVD)]</u>
−
* [http://cve.mitre.org/ MITRE Common Vulnerabilities and Exposures]
+
* <u>[https://github.com/retirejs/retire.js/ Retire.js for detecting known vulnerable JavaScript libraries]</u>
−
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277  Example Mass Assignment Vulnerability that was fixed in ActiveRecord, a Ruby on Rails GEM]
+
* <u>[https://nodesecurity.io/advisories Node Libraries Security Advisories]</u>
 +
* <u>[https://rubysec.com/ Ruby Libraries Security Advisory Database and Tools]</u>
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate
−
     |type={{Top_10_2010:StyleTemplate}}
+
     |type=box
−
     |usenext=2013NextLink
+
    |useprev=2017PrevLink
 +
    |prev=A8-{{Top_10_2010:ByTheNumbers
 +
        |8
 +
        |year=2017
 +
        |language=en
 +
    }}
 +
     |usenext=2017NextLink
 
     |next=A10-{{Top_10_2010:ByTheNumbers
 
     |next=A10-{{Top_10_2010:ByTheNumbers
−
              |10
+
        |10
−
              |year=2017
+
        |year=2017
−
              |language=en}}
+
        |language=en
−
     |useprev=2013PrevLink
+
     }}
−
    |prev=A8-{{Top_10_2010:ByTheNumbers
 
−
              |8
 
−
              |year=2017
 
−
              |language=en}}
 
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
 +
<!-- [[Category:OWASP Top Ten Project]] -->

Latest revision as of 16:30, 5 December 2018

← A8-Insecure Deserialization
2017 Table of Contents

PDF version

A10-Insufficient Logging&Monitoring →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability: 2
 Prevalence: 3
 Detectability: 2
 Technical: 2
 Business ?
While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.  Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date.
Some scanners such as retire.js help in detection, but determining exploitability requires additional effort. 		While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.
Is the Application Vulnerable?

You are likely vulnerable:

  • If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
  • If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
  • If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
  • If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
  • If software developers do not test the compatibility of updated, upgraded, or patched libraries.
  • If you do not secure the components' configurations (see  A6:2017-Security Misconfiguration).
How to Prevent

There should be a patch management process in place to:

  • Remove unused dependencies, unnecessary features, components, files, and documentation.
  • Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
  • Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
  • Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.

Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

Example Attack Scenarios

Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

  • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
  • While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

References

OWASP

External

← A8-Insecure Deserialization
2017 Table of Contents

PDF version

A10-Insufficient Logging&Monitoring →
© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png
Retrieved from "https://wiki.owasp.org/index.php?title=Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities&oldid=245758"