We want to and are creating fantastic tools that accomplish various tasks, for which our apps no matter their tongue (language c++, JS etc.) or technology use various packages or tools made by other developers from various sources we trust (sometimes arbitrary …simply put dont ) this is very true in case of startups or tight schedule features/products. Maximum priority is given to delivery of the product ( sometimes security ) but we tend to offload securing the dependencies to their sources overlooking the fact that we not only inherit their feature but also their vulnerabilities.
Enter OWASP A9-Using Components with Known Vulnerabilities this is by far the easiest and the most prevalent strategy to exploit application and can be used from simple reconnaissance to a root shell , the end result of using components from third parties that have a established vulnerability in them and there are plenty across every technology in use. A little stat shows most of the breaches are caused because of using components that had a vulnerability in them.
Exploits are plenty:
We all at this point know about a few breaches over the last year alone.. I am gonna focus strictly on the technical aspects hence no names. A company vulnerable.corp say is a major java-web user and they had a bunch of vulnerable dependencies. A malicious agent lets call her Eve uses various tools to find out they are using Apache struts 2 (finding this is beginner level stuff). Given that mere googling shows a list of vulnerabilities
All that remains is to craft an exploit but Eve is new to java and does not have any clue what a struts is, from the CVE it is clear that this is a mature and old vulnerability Eve seldom needs the knowledge of the internals to craft an exploit. Eve googles or refers to git or Exploits database to fetch a exploit and readme to use it. Eve then uses the exploit with vulnerable.corp to get an Root shell. Voila ! a root shell in under 4 hours of work PWNED!(mostly takes more effort but for a few cases surprisingly lesser depends on the case)
As serious and prevalent as this vulnerability category is its a bit easier to protect against proactively:
- Keep all the dependencies updated (duh!)
- Before using a dependency check if it has any known vulnerabilities https://cve.mitre.org is a good place to start
- Keep track or use a tool to keep track of Zero day exploits and take precautions for your product.
- Continuously scan your repositories using tools that specialize in this eg. flexera , snyk.io, blackduck etc. and fix any find immediately
- Spread the knowledge to developers and make a clear process in place for using dependencies.
- And finally when in doubt.. always ask the security team.
stay safe ….
will cover more ways to keep track of dependencies through solid CI/CD processes in Dependency management — 2