OWASP A9 Using Components with Known Vulnerabilities

The use of 3^rd party frameworks and libraries in application development has become a very common practice but unfortunately most of the time, proper security policies aren’t implemented to mitigate the risks associated with the practice.

Start by finding the vulnerability with Free Website Security Scan.

Open source components have become a rich attack vector because of their pervasive reuse. Reuse makes it easier for hackers to propagate their attack across multiple applications and multiple organizations.

It should come as no surprise that using components with Known Vulnerabilities as made it to the top of the OWASP Top 10 vulnerabilities list.

Example of Attack due to ‘Using Components With Known Vulnerabilities’

Somehow, an attacker found out my bank’s website uses Apache web server version 1.3.22 on Win32. This version has a critical vulnerability that allows remote attackers to execute arbitrary commands. As, on Windows, the web server runs with SYSTEM privileges, this vulnerability can be exploited by the attacker to do what he wants (steal information, stop services…) on that server.

The attacker first stops the local firewall that blocks outbound connections from the webserver to the Internet. Then he can download a network traffic monitoring tool, install it and start it to intercept all traffic behind the Apache webserver (after SSL termination). All login requests are intercepted and relevant information (obviously, login and passcode) is extracted and uploaded to its server using a simple Batch script.

How to manage risks associated with ‘Using components with known vulnerabilities’?

• • a)  Know your application: To reduce the risk of using vulnerable components, you need to know exactly what components your application uses (directly or not) and the version of each of these components.  Have an inventory of all the components (OS, Web server, libraries with version info) that are being used by your application and also all the network components in the path before an app is hit along with its versions
  • b) Know your vulnerabilities: Vulnerability assessment is the process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system. In a simpler language, it is the search and disclosure of these weaknesses which need to be fixed and patched in order to prevent your web and mobile applications from being compromised. Have a strong Vulnerability management program in place.   Do regular (weekly or even daily) External VA to get a snapshot of system info and banner information an external user can see and associated vulnerability information of the systems from the CVE and vulnerability databases.  Do periodic complete Internal and External VA PT to get a more in-depth assessment of all the devices used in the path for application access.
  • c)Run your own security assessment tests: Even if there are no known CVE identified, the combination of different libraries and how you use these APIs could create a vulnerability. Before deploying a new major version of your application on production, consider doing full static code analysis and a manual code review. Running a penetration test is needed for very sensitive applications
  • d)  Harden your systems and strip them of libraries and services not needed for your application to reduce the surface area of attack
  • e) Educate your developers: Developer should not add a new dependency in the application without a strict validation process. First, before adding a new library, check that no existing dependency can do the same thing and help them document a very clear set of dependency and why it is needed.  This ties to point d) to also harden the system and strip it of any unneeded services not relevant and needed for the applications
  • f)  Web Application Firewalls: Deployment of WAF is the good technique to centralize the action from the Vulnerability management program in protecting from the platform and third-party specific of vulnerabilities. Make sure your WAF is managed and backed by a team who offers a strong MSS and custom ruleset to include relevant platform-specific protection rules in the rule set based on the same detected

Although we don’t discourage using open source components we strongly recommend monitoring the security of those components and run security scans from time to time for regular health check-ups of your web applications.

The core of OWASP-2013 A9 is about having policies in place to ensure that an application isn’t compromised due to negligence.

OWASP states the following:

• 1. Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
     1. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date. If you are dependent on a library or platform, these components need to be updated regularly. Internally there should be a cycle to review all components and versions and ensure that these are fully updated. A monthly cycle to review these components would be ideal.
  2. Establish security policies governing the component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
  3. Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component. It is about requiring a strong validation of input to untrusted libraries. If a library hasn’t been fully tested for security defects then data passed to this library must be validated. It is a very good security practice to do this for all input. An example of this is using an OWASP ESAPI validation routine for all input.