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
m (Added some comments in Wiki source code of the SummaryTable Header (SummaryTableRowStyleTemplates))
(OWASP Top 10-2017 RC1: A9-Using Components with Known Vulnerabilities)
Line 15: Line 15:
  
 
{{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:SummaryTableTemplate|exploitability=2|prevalence=2|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 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Line 21: Line 21:
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
−
<!--- Attack Vectors --->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.
+
<!--- Attack Vectors --->Attackers identify a weak component through scanning or manual analysis. They customize the exploit as needed and execute the attack. It gets more difficult if the used component is deep in the application.
−
 
 
 
</td>
 
</td>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
−
<!--- Security Weakness --->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.
+
<!--- Security Weakness --->Many applications and APIs have these issues because their development teams don’t focus on ensuring their components and libraries are up to date. In some cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse. Tools are becoming commonly available to help detect components with known vulnerabilities.
−
 
 
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Technical Impacts --->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.
 
<!--- Technical Impacts --->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>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Business Impacts  --->Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.
 
<!--- Business Impacts  --->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>
 
</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|year=2017|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=9|year=2017|language=en}}
−
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.
+
The challenge is to continuously monitor the components (both client-side and server-side) you are using for new vulnerability reports. This monitoring can be very difficult because vulnerability reports are not standardized, making them hard to find and search for the details you need (e.g., the exact component in a product family that has the vulnerability). Worst of all, many vulnerabilities never get reported to central clearinghouses like <u>[https://cve.mitre.org/ CVE]</u> and <u>[https://nvd.nist.gov/]</u>.
  
−
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.
+
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. This process can be done manually, or with automated tools. If a vulnerability in a component is discovered, carefully evaluate whether you are actually vulnerable. Check to see if your code uses the vulnerable part of the component and whether the flaw could result in an impact you care about. Both checks can be difficult to perform as vulnerability reports can be deliberately vague.
  
 
{{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=howPrevent|position=right|risk=9|year=2017|language=en}}
−
One option is not to use components that you didn’t write. But that’s not very realistic.
+
Most component projects do not create vulnerability patches for old versions. So the only way to fix the problem is to upgrade to the next version, which can require other code changes. Software projects should have a process in place to:
 +
# Continuously inventory the versions of both client-side and server-side components 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 [https://nvd.nist.gov NVD] for vulnerabilities in your components. Use software composition analysis tools to automate the process.
 +
# Analyze libraries to be sure they are actually invoked at runtime before making changes, as the majority of components are never loaded or invoked.
 +
# Decide whether to upgrade component (and rewrite application to match if needed) or deploy a [Virtual_Patching_Best_Practices#What_is_a_Virtual_Patch.3F virtual patch]] that analyzes HTTP traffic, data flow, or code execution and prevents vulnerabilities from being exploited.
  
−
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=example|position=left|risk=9|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).
+
Components almost always run with the full privilege of the application, 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:
−
# Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
 
−
# Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.  
 
−
# Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
 
  
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=9|year=2017|language=en}}
+
* [https://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.)
−
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.
+
* [https://nvd.nist.gov/vuln/detail/CVE-2017-5638 Struts 2 Remote Code Execution] – Sending an attack in the Content-Type header causes the content of that header to be evaluated as an OGNL expression, which enables execution of arbitrary code on the server.
−
* [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.
+
Applications using a vulnerable version of either component are susceptible to attack as both 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:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=9|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
−
 
+
* <u>[[OWASP_Dependency_Check|OWASP Dependency Check (for Java and .NET libraries)]]</u>
−
* [[OWASP Dependency Check|OWASP Dependency Check (for Java libraries)]]
+
* <u>[[Virtual_Patching_Best_Practices|OWASP Virtual Patching Best Practices]]</u>
−
* [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>[http://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-insecure-libraries|The Unfortunate Reality of Insecure Libraries]</u>
−
* [http://en.wikipedia.org/wiki/Open_source_software_security  Open Source Software Security]
+
* <u>[[Virtual_Patching_Best_Practices|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

Revision as of 00:13, 22 April 2017

← A8-Insecure Deserialization
2017 Table of Contents

PDF version

A10-Insufficient Logging&Monitoring →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability
AVERAGE		 Prevalence
COMMON		 Detectability
AVERAGE		 Impact
MODERATE		 Business ?

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.

Attackers identify a weak component through scanning or manual analysis. They customize the exploit as needed and execute the attack. It gets more difficult if the used component is deep in the application.

Many applications and APIs have these issues because their development teams don’t focus on ensuring their components and libraries are up to date. In some cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse. Tools are becoming commonly available to help detect components with known vulnerabilities.

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.

Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.

Am I Vulnerable To 'Using Components with Known Vulnerabilities'?

The challenge is to continuously monitor the components (both client-side and server-side) you are using for new vulnerability reports. This monitoring can be very difficult because vulnerability reports are not standardized, making them hard to find and search for the details you need (e.g., the exact component in a product family that has the vulnerability). Worst of all, many vulnerabilities never get reported to central clearinghouses like CVE and [1].

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. This process can be done manually, or with automated tools. If a vulnerability in a component is discovered, carefully evaluate whether you are actually vulnerable. Check to see if your code uses the vulnerable part of the component and whether the flaw could result in an impact you care about. Both checks can be difficult to perform as vulnerability reports can be deliberately vague.

How Do I Prevent 'Using Components with Known Vulnerabilities'?

Most component projects do not create vulnerability patches for old versions. So the only way to fix the problem is to upgrade to the next version, which can require other code changes. Software projects should have a process in place to:

  1. Continuously inventory the versions of both client-side and server-side components and their dependencies using tools like versions, DependencyCheck, retire.js, etc.
  2. Continuously monitor sources like NVD for vulnerabilities in your components. Use software composition analysis tools to automate the process.
  3. Analyze libraries to be sure they are actually invoked at runtime before making changes, as the majority of components are never loaded or invoked.
  4. Decide whether to upgrade component (and rewrite application to match if needed) or deploy a [Virtual_Patching_Best_Practices#What_is_a_Virtual_Patch.3F virtual patch]] that analyzes HTTP traffic, data flow, or code execution and prevents vulnerabilities from being exploited.
Example Attack Scenarios

Components almost always run with the full privilege of the application, 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:

  • 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.)
  • Struts 2 Remote Code Execution – Sending an attack in the Content-Type header causes the content of that header to be evaluated as an OGNL expression, which enables execution of arbitrary code on the server.

Applications using a vulnerable version of either component are susceptible to attack as both components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.

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=228949"