The problem here is external, somehow. There are libraries with vulnerabilities that can be identified and exploited using automated tools. In this way, the threat agent can be expanded beyond well-known forms of attacks, to include an unknown factor of risk.
The official definition defines A9, stating that:
"Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts."
At first, it seems easy to find out whether a commercial or open source component has known vulnerabilities. However, different versions pose a factor of risk, especially the latest ones, which are supposed to be more secure and fix old problems on the one hand, but on the other hand, they might introduce new flaws. Not to mention that not all vulnerabilities are reported to the control sites.
There are places such as CVE (Common Vulnerabilities and Exposures), found at https://cve.mitre.org/, or National Vulnerability Database (NVD), which can be accessed at https://web.nvd.nist.gov/view/vuln/search, in which you can search for these kind of problems.
The question here is that vulnerabilities in components can potentially cause all types of trouble from the most simple to the most sophisticated ones, with attacks exclusively thought of for some type of component.
Examples are many, but let's just think of a few common problems:
- For many years, Adobe Flash has been the most preferred extension for browsers that companies used in order to reproduce videos, insert advertising, play audio, and so on. Actually, there were so many that Adobe would release periodic updates to deal with the security problems.
- The situation got to a critical point when in 2010, Steve Jobs declared that no Apple mobile device would use Adobe Flash anymore. He published a letter explaining the six main reasons to do that (http://www.apple.com/hotnews/thoughts-on-flash/) and recommending the use of standards such as HTML5, instead.
- In the Windows world, there are many examples, but in order to give you an idea, let's think of a simple desktop application that uses some components of the control panel (which, on the other hand, is the recommended approach instead of reinventing the wheel).
- Now, imagine that we have a simple options menu that allows the user to select the configuration before printing a report. In .NET, we have several components available, which map the corresponding dialog boxes of the operating system: Print Dialog, Print Preview, Print Document, and so on.
- If we don't delimit the input values, we might end up in trouble. Let's say that the user is allowed to give any value in the font size (or even worse, any value in the number of copies). The user can establish a font size of, say, 900 pt and a number of copies of 32564 for some configurations. The system can collapse or the printing server in the network can start using virtual memory to hold the huge amount of information sent. Here, we have a very simple way to build a DoS (Denial of Service) attack.
We have to consider that often, components run with the complete privileges of the application, and we usually don't have the source code to prevent these attacks.
Officially, we should do the following:
- Identify all components and the versions you are using, including all dependencies (for example, the versions plugin).
- 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 the component in use, such as requiring certain software development practices, passing security tests, and having acceptable licenses.
- Where appropriate, consider adding security wrappers around components in order to disable unused functionalities and/or secure weak or vulnerable aspects of the component.
In .NET, a new document was created in OWASP in relation to this vulnerability: OWASP SafeNuGet, which is available at https://www.owasp.org/index.php/OWASP_SafeNuGet. However, if you need to test a given component, the code required is at your disposal in a GitHub project of the same name (https://github.com/OWASP/SafeNuGet), where you'll find an MSBuild project that can help you in the task, along with instructions and details.