Detecting Vulnerabilities With Vulnture
Introducing a new open source tool for more quickly identifying security vulnerabilities across your assets.
Introduction
Securing assets and data is a challenging and important task, regardless of your industry or company size. On Airbnb’s InfoSec team, we are constantly thinking about how to quickly and effectively detect and remediate known security vulnerabilities that impact our assets.
To address this challenge, we created a tool called Vulnture, which we are happy to open source and share with the software community!
Vulnture vastly simplifies the otherwise laborious process of collecting your known assets in one place and identifying security vulnerabilities in a timely manner. Before we share how Vulnture works, let’s take a deeper look at the challenges we’re addressing.
Background
In 1999, MITRE and the broader security community launched the Common Vulnerabilities and Exposures (CVE) List. This list was developed to reduce gaps in security coverage, to enable interoperability between vulnerability databases and tools, and to provide a standardized basis for evaluating vulnerabilities across tools.
Several years later, in 2005, the National Institute of Standards and Technology (NIST) launched the U.S. National Vulnerability Database (NVD). The NVD is populated with vulnerability data from the CVE List along with additional information associated with each vulnerability such as fix information, severity scores, and impact ratings in an effort to make the CVE information more useful and actionable. The NVD also provides more granular search capabilities such that vulnerabilities can be queried based on which product name and/or version they affect, how recently they were created, their severity, and more.
In short, the CVE List provides a list of all known, publicly disclosed security vulnerabilities while the NVD provides more detailed and easily queryable information related to those vulnerabilities. Airbnb saw a great opportunity in these resources. Let’s see how we made use of this data!
The Problem
For the past twenty or so years these data sources have grown vastly, as have the consumers of the data. However, the data is not easy to ingest. To make use of it, you have to have a good way to compare all of your assets against the vulnerable products listed in the NVD. Additionally, the NVD is updated hourly according to the NVD FAQ, so you need to check back often, particularly if you’re on the hunt for critical severity vulnerabilities. Prerequisites for effectively utilizing data from the NVD include:
- Having a record of all of your assets (e.g., operating systems, applications, services, executables, hardware models, versions of each of these, associated IP addresses, owners)
- Having the ability to query often in order to pick up all updates, while preferably not reviewing the same vulnerabilities more than once (unless they’ve been modified) to avoid duplicating work
Solving for these challenges starts to get even more complex when we look at the actual turnaround time for NVD updates. The NVD FAQ mentions that it can take 1–3 days for information to be published depending on the volume of new CVEs. According to a report from threat intelligence company Recorded Future, in 2017 there was a median lag time of 7 days before vulnerabilities were populated within the NVD. Obviously, waiting up to a week just to be notified about a known vulnerability is far from ideal.
This means that in addition to searching the NVD, you probably want to consider searching other sources of vulnerability data as well, such as vendor sites of the products potentially affected. This way you’re more likely to find critical vulnerabilities that impact you before several days pass, thereby no longer granting attackers precious time to exploit those vulnerabilities.
The challenge here, of course, is that you now have to:
- Seek out all possible vulnerability feeds from your vendors
- Craft a suitable query to sift out unwanted data
- Parse out the non-standardized results
The latter of these two steps needs to be repeated for each separate vulnerability feed meaning exponentially more work for each vulnerability source you want to get data from.
Considering the above, it may come as no surprise that, according to the 2020 Verizon Data Breach Investigations Report, nearly 85% of security breaches and 99% of security incidents are discovered by an external or partner source, such as a third-party monitoring service, security researcher, or customer report. That means most security breaches, and practically all security incidents, are detected by somebody other than the company experiencing the security incident or breach!
Not all security incidents or breaches are caused by a known vulnerability, but the key point here is that overwhelmingly companies are relying on third parties to tell them that they have a security issue rather than being able to identify it themselves.
Introducing Vulnture
Vulnture is a completely serverless solution that ingests all of your known assets, searches for vulnerabilities that impact them, and then notifies you of all discovered vulnerabilities that you should know about. Let’s briefly go over how it works.
In the currently released version, Vulnture has the ability to pull asset information from an AWS DynamoDB table and then query the NVD, as well as Cisco Security Advisories publications, for vulnerabilities. For notifications, it sends emails to the recipient(s) configured in the configuration file:
Vulnture is set to query its vulnerability data sources once per day to ensure that you’re never missing critical information related to vulnerabilities impacting your assets. If you don’t already have some type of asset management or inventory solution, you can start building one in a DynamoDB table which you can then have Vulnture reference. If you do have one, you can either export that data to a DynamoDB table or update Vulnture so that it is capable of querying your existing asset data (if you do make an update for your specific tech stack, consider making a pull request to make this a native feature of Vulnture!)
Vulnture is written entirely in Python and deployed via Terraform using the included Terraform modules (.tf files). This makes it quick and easy to deploy without having to worry about manually managing various pieces of infrastructure or making code changes in multiple languages.
We’re planning some exciting updates to Vulnture which are pending public release. These include an additional notification option (JSON files uploaded to an AWS S3 bucket) and support for more detailed asset information from a DynamoDB table (e.g., IP, FQDN, source).e have many more updates in the pipeline for future releases, including leveraging the relatively new NVD API to speed up and narrow down vulnerability queries. We’re also planning to support more sources of vulnerability data directly from vendors (e.g., Amazon, Microsoft, Ubuntu, Red Hat) to find vulnerabilities sooner.
We aim to make Vulnture easily extensible with a plugin model to allow it to work seamlessly with various asset, vulnerability, and notification channels that can be quickly selected via straightforward configuration changes.
Conclusion
Although securing your assets is no simple task, you can feel more at ease knowing that you have a tool working for you by regularly querying industry standard vulnerability data repositories, comparing that data against your known asset information, and notifying you of vulnerabilities discovered.
We’ve used Vulnture at Airbnb to replace some of our previous, less efficient methods of vulnerability identification and notification and hope that others find benefit in this tool as well. Beyond that, we would love to work with the community to continue to augment Vulnture so that it can become a more robust and feature-rich tool that’s simple to use and adaptable to various company environments and toolsets.
Try out Vulnture today, you may be surprised at what you’re missing!
Interested in helping protect people and data? Airbnb InfoSec is hiring! Check out our open positions and apply today!
Appendix
All trademarks are the property of their registered owners; Airbnb claims no responsibility for nor proprietary interest in them.
Amazon Web Services, the “Powered by AWS” logo, AWS, AWS Lambda, and DynamoDB are trademarks of Amazon.com, Inc. or its affiliates in the United States and/or other countries.
Cisco is a registered trademark or trademark of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
Terraform is a trademark of HashiCorp.
