The Vulnerability Researcher's Handbook E-Book

Benjamin Strout

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 363

Veröffentlichungsjahr: 2023

Beschreibung

Vulnerability researchers are in increasingly high demand as the number of security incidents related to crime continues to rise with the adoption and use of technology. To begin your journey of becoming a security researcher, you need more than just the technical skills to find vulnerabilities; you’ll need to learn how to adopt research strategies and navigate the complex and frustrating process of sharing your findings. This book provides an easy-to-follow approach that will help you understand the process of discovering, disclosing, and publishing your first zero-day vulnerability through a collection of examples and an in-depth review of the process.
You’ll begin by learning the fundamentals of vulnerabilities, exploits, and what makes something a zero-day vulnerability. Then, you'll take a deep dive into the details of planning winning research strategies, navigating the complexities of vulnerability disclosure, and publishing your research with sometimes-less-than-receptive vendors.
By the end of the book, you'll be well versed in how researchers discover, disclose, and publish vulnerabilities, navigate complex vendor relationships, receive credit for their work, and ultimately protect users from exploitation. With this knowledge, you’ll be prepared to conduct your own research and publish vulnerabilities.

Leseprobe

The Vulnerability Researcher’s Handbook

A comprehensive guide to discovering, reporting, and publishing security vulnerabilities

Benjamin Strout

BIRMINGHAM—MUMBAI

The Vulnerability Researcher’s Handbook

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Mohd Riyan Khan

Publishing Product Manager: Khushboo Samkaria

Senior Editor: Runcil Rebello

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Manju Arasan

Production Designer: Alishon Mendonca

Senior Marketing Coordinator: Marylou De Mello

First published: February 2023

Production reference:1200123

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-887-6

www.packtpub.com

To my dearest and oldest friend, Linda Mehlhorn. Thank you for your friendship and support over the years. It’s meant the world to me.

– Benjamin Strout

Contributors

About the author

Benjamin Strout is a veteran of the technology industry and a passionate technology communicator. His experience in the healthcare, biotech, pharmaceutical, and fintech industries has led him to a role as a lead penetration tester at one of the largest healthcare conglomerates in the United States. The founder and point of contact of Maine’s local DEF CON group (DC207), he has been featured as a guest speaker at various conferences. He has contributed to works as a technical reviewer and published 30+ CVEs for technologies in use worldwide. When not teaching others or tinkering with some technological curiosity, he’s busy learning bluegrass licks on his banjo and playing with his cats, Dionysius and Louis Thanksgiving.

I could not have imagined writing this book without the support of my husband. Alex, thank you for reading my drafts, putting up with the late nights, and encouraging me to do this. In my career, I have immense gratitude for these awesome people for helping me on my path: David Freedman, Taylor Shain, Scott Allen, and the brilliant information security researcher Ryan Boutot. Many thanks to everyone at the DC207 group that keeps showing up monthly, keeping the hacking community alive in Maine. Finally, this book wouldn’t be possible without the help of the ever-evolving SANS ICS HyperEncabulatation research.

About the reviewers

Avinash Sinha is a cybersecurity expert with 12+ years of experience and has worked with many global business unicorns, such as IBM, GE HealthCare, Schneider Electric, Airtel, Target, Aujas Networks, and UIDAI Aadhaar, securing them from next-generation threats.

He has managed and led teams for the successful execution of OT/IT/cloud security projects entailing security operations, enterprise security architecture, penetration testing, HIPAA, GDPR, threat intelligence, IR, red teaming, and cloud security assessment for O365, Azure, Citrix, and AWS.

He has a degree in computer technology, majoring in artificial intelligence and a postgraduate degree in international business from Symbiosis. He holds GICSP, GCFA, and SEC 541-Cloud Attacks and Monitoring certifications from SANS.

I’d like to thank my father, Rajendra Sinha, for constantly inspiring me, and my mother, for her love and blessings. Also, thanks to my lovely wife, Tanu, for taking care of me and keeping me healthy while my passion for cybersecurity extends beyond unusual times.

Every one of us has the responsibility to protect the world from constantly evolving threats. Special thanks to Jaykishan Nirmal, Vikram Dhar, and Anil Kumar PV for their guidance.

Vaibhav Kushwaha is a lead security engineer with a specialization in cybersecurity products architecture and R&D and has led teams for ASM, pentesting automation, network and web vulnerability scanners, and much more.

He started his career with pentesting but later gathered interest in security software R&D to innovate cybersecurity products and industry and also to automate boring and repetitive tasks.

Apart from this, Vaibhav also likes reverse engineering and working on cloud services and has worked on cloud connectors for multiple cloud services.

Disclaimer

The information within this book is intended to be used only in an ethical manner. Do not use any information from the book if you do not have written permission from the owner of the equipment. If you perform illegal actions, you are likely to be arrested and prosecuted to the full extent of the law. Packt Publishing does not take any responsibility if you misuse any of the information contained within the book. The information herein must only be used while testing environments with properly written authorizations from the appropriate persons responsible.

Table of Contents

Preface

Part 1– Vulnerability Research Fundamentals

1

An Introduction to Vulnerabilities

Introducing software vulnerabilities

The CIA Triad

Organizing impacts

Getting familiar with software vulnerability scanners

Common vulnerability scanning tools

Exploring common types of software vulnerabilities

Web applications

Client-server applications

Inspecting the software vulnerability life cycle

Inception

Discovery

Exploitation and remediation

Deprecation

Summary

Further reading

2

Exploring Real-World Impacts of Zero-Days

Zero-days – what are they?

Zero-day vulnerability

Zero-day attack

An analogy of zero-day terminology

Exploring zero-day case studies

Pulse – CVE-2019-11510

Confluence – CVE-2021-26084

Microsoft .NET CVE-2017-8759

Citrix – CVE-2019-19781

Considering zero-day ethics

Researcher responsibility

Vendor responsibility

Summary

Further reading

3

Vulnerability Research – Getting Started with Successful Strategies

Technical requirements

What is vulnerability research?

Conducting research

Selecting research targets

Finding targets that interest you

Likely vulnerable and downloadable software

Exploring vulnerabilities with test cases

Test cases – a primer

Building effective test suites

Writing your own test cases

Introducing common research tools

Note-taking, screenshot, and screen recording tools

Hypervisors and virtual machines

Web application proxies

Debuggers and decompilers

Summary

Further reading

Part 2 – Vulnerability Disclosure, Publishing, and Reporting

4

Vulnerability Disclosure – Communicating Security Findings

Vulnerability disclosure – what and why

What is vulnerability disclosure?

Why is vulnerability disclosure important?

Different types of disclosures

Bug bounties and coordinated disclosure

Initiating disclosure

What happens after disclosure?

Sample disclosure template

Approaching common challenges

Duplication of efforts

Unresponsive vendors

Uncooperative vendors

Failed vendors

Hostile vendors

Summary

Further reading

5

Vulnerability Publishing –Getting Your Work Published in Databases

Demystifying vulnerability publishing

Why publish vulnerabilities?

What are some of the risks involved in vulnerability publishing?

Selecting the right vulnerability publishing method

CVE

CVE CNA intermediates

Ineligible application publication options

Exploitation databases

Practical vulnerability publishing examples

A CNA-sponsored CVE

A CNA-LR-sponsored CVE

CNA intermediate sponsored CVE

Summary

Further reading

6

Vulnerability Mediation – When Things Go Wrong and Who Can Help

The basics of vulnerability mediation

What is vulnerability mediation?

Types of mediators

When to consider mediation services

Benefits of vulnerability mediation

Resolving disputes through vulnerability mediation

The vulnerability mediation process

Mediator resources

The CERT/CC

The US-CERT

The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)

Other CERT organizations

Bug bounty programs

Legal support

Other mediation options

Summary

7

Independent Vulnerability Publishing

Independent disclosures and their place in a vulnerability life cycle

The benefits of independent publishing

Risks of independent publishing

How to independently publish while avoiding risks

Avoiding the common risks in publishing

How to independently publish a vulnerability

A before-you-publish checklist

Summary

Additional reading

Part 3 – Case Studies, Researcher Resources, and Vendor Resources

8

Real-World Case Studies – Digging into Successful (and Unsuccessful) Research Reporting

Case study 1 – are we there yet?

Lessons learned

Possible improvements

Case study 2 – contract clause

Lessons learned

Possible improvements

Case study 3 – tough customers

Lessons learned

Possible improvements

Case study 4 – large corporations and you

Lessons learned

Possible improvements

Case study 5 – I’d like to speak to your manager

Lessons learned

Possible improvements

Summary

9

Working with Security Researchers – A Vendor’s Guide

What is a security researcher?

The characteristics of a researcher

The skillset of a researcher

The motivations of a researcher

Harnessing researcher resources

Building trust and collaboration with researchers

Avoiding common relationship missteps

Building positive vendor-researcher relations

Crafting a responsible disclosure policy

An example policy – Acme Logistics’ responsible disclosure policy

Summary

10

Templates, Resources, and Final Guidance

Research test case templates

Vendor communication email templates

An introduction email for a company with no security disclosure policy

Sample disclosure template with security policy

Attempting to reinitialize communication

Notification of pending publication with an unresponsive vendor

CVE templates

CVE reservation template

CVE disclosure template

Organizational templates

Workspace

Research to disclosure

Summary and final words

Further reading

Index

Other Books You May Enjoy

Preface

Hello, intrepid explorer!

Vulnerability research is the practice of searching for security flaws in technical systems and then sharing that information with people who can fix these flaws. It’s a fascinating process that helps improve the security and privacy of user data throughout the ever-growing technological world we find ourselves inhabiting. The Vulnerability Researcher’s Handbook is a book that aims to explore, in depth, the process of what someone does with a new, never-before-observed information security vulnerability after it’s discovered. For example, you might work in software development, operations, or information security roles. In such a case, you might wonder how vulnerabilities in publicly released software become known and ultimately addressed for the greater good of end users. The answer is that it takes coordinated effort, friction between parties, and grit from security researchers to overcome many of the challenges these scenarios introduce.

In this book, we’ll introduce you to the world of vulnerability research for publicly released software by ensuring you understand the fundamentals around vulnerabilities and how they become dangerous. After that, we’ll cover ways to begin selecting compelling research targets and then subject those targets to a methodology built on proven techniques that yield results. Finally, you’ll be able to build plans to find security vulnerabilities.

We’ll then cover the most complex step in this process: navigating the murky waters of working with vendors as you share your research and publish it to the world. We’ll do this by learning about enthralling examples of vulnerability research and the many challenges security researchers like yourself need to overcome. Finally, as you work through the last chapters, you’ll be armed with knowledge, various helpful templates to organize and standardize your research, and strategies to implement better vendor-research relations that you can begin to share or employ with software vendors.

I developed this book because it’s the one I wish I had before I started working with vendors on disclosing vulnerabilities and persuading them to fix security problems in their products. Adopting technology systems and software to solve problems is (and has been) expanding into every niche that humans do. The entire software and hardware industry needs people more than ever who know how to share research in a way that benefits users and holds the right people accountable for fixing problems when they’re found.

Ideally, I would expect you, the reader, to have strong technical skills that you can then apply to the soft skills you’ll learn in this book. We don’t teach you how to execute the latest in vulnerability research – several books, courses, and web content are released each year on this. We expect you’ll be coming to the table or referring to these resources. Instead, this book aims to help you understand how publicly disclosed vulnerabilities are disclosed in the CVE system (or not) and how to find research targets and develop methods for organizing the arduous process of disclosing and publishing your findings in a responsible way that improves the world around us. Even if you don’t possess highly technical skills, with this book, you’ll find this entire process approachable, engaging, and very rewarding – so much so that you’ll seek to grow that knowledge even more.

Who this book is for

This book is for security analysts, researchers, penetration testers, software developers, technology engineers, and anyone in leadership roles who wants to learn how vulnerabilities are found and then disclosed to the public. Before you start, we’re expecting intermediate knowledge of operating systems, software, and interconnected systems. Prior experience with finding and disclosing vulnerabilities is optional. Nevertheless, some exposure to vulnerability scanners and other information security tools will help accelerate your journey to exploring research targets and finding and disclosing your first vulnerability.

What this book covers

Chapter 1, An Introduction to Vulnerabilities, includes a primer on what vulnerabilities are and how they’re classified and organized. Then, you’ll learn how security analysts find known vulnerabilities and what software they use.

Chapter 2, Exploring Real-World Impacts of Zero-Days, discusses the vulnerability life cycle and introduces zero-days, their exploitation, and their various dangers. Most importantly, you’ll learn important terminology and how security research directly or indirectly creates these dangers, and the dilemmas of how to disclose such research.

Chapter 3, Vulnerability Research – Getting Started with Successful Strategies, defines security research, the strategies used, how to select targets and use test suites, and the tools that are commonly used for research.

Chapter 4, Vulnerability Disclosure – Communicating Security Findings, informs you of and defines the types of vulnerability disclosures you can use, and what strategies you can use to navigate the various challenges you’ll face in making disclosures.

Chapter 5, Vulnerability Publishing – Getting Your Work Published in Databases, demystifies vulnerability publishing and the methods used to publish and provides practical examples and best practices that will help you confidently share your research with the world.

Chapter 6, Vulnerability Mediation – When Things Go Wrong and Who Can Help, defines what mediators are and how to find and utilize them best when things go wrong with vendor relationships.

Chapter 7, Independent Vulnerability Publishing, discusses what an independent disclosure is, the risks of using them, and how to avoid legal problems researchers commonly face from hostile vendors.

Chapter 8, Real-World Case Studies – Digging into Successful (and Unsuccessful) Research Reporting, uncovers real stories from vulnerability researchers, showing you how scenarios can unfold and how challenges were addressed by the researchers.

Chapter 9, Working with Security Researchers – A Vendor’s Guide, turns the tables and speaks to vendors about the people reading this book, aiming to give researchers and technology leaders tools and information that they can use to foster good relationships in the unavoidable contact they’ll have with researchers.

Chapter 10, Templates, Resources, and Final Guidance, shares test case templates and methods for using them, vendor communication templates, CVE disclosure templates, organizational templates, and finally, words of encouragement to those of you who use this information to improve the world of technology by researching and disclosing vulnerabilities.

To get the most out of this book

To get the most out of this book, we expect a beginner to intermediate knowledge of various techniques used, maintained, and developed by users and businesses. However, to apply the strategies and conduct research that will be reported, we expect advanced and possibly specialized knowledge on discovering security vulnerabilities using techniques defined in the frameworks covered in this book.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/1iZ9q.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read The Vulnerability Researcher’s Handbook, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781803238876

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1– Vulnerability Research Fundamentals

In this section, you will learn about the basics of vulnerabilities and vulnerability research. You will learn about different types of vulnerabilities and various exploits. You will also learn about the tools and techniques used by security researchers to find and analyze vulnerabilities. Armed with this knowledge, you will be well on your way to becoming a security researcher yourself.

This section comprises the following chapters:

Chapter 1, An Introduction to VulnerabilitiesChapter 2, Exploring Real-World Impacts of Zero-DaysChapter 3, Vulnerability Research – Getting Started with Successful Strategies

1

An Introduction to Vulnerabilities

A vulnerability is a characteristic of something that makes that thing susceptible to hazards or damage. Technology is certainly not immune to vulnerabilities. For example, during the 1960s in the United States, AT&T observed one of the first widespread exploitations of vulnerabilities in technology. People found they could subvert telephone systems and avoid paying for services if they played certain tones into telephone receivers. These technology hackers learned that if they understood how the systems worked and what flaws might be present in these systems, they could take advantage of weaknesses in ways that could directly benefit them. Today, the same spirit and enterprising ways of challenging technology by using it in unintended ways are present and thriving.

Throughout our world, people are discovering and exploiting vulnerabilities found in software. Software drives the modern world in almost everything we do. Security researchers can find software and subsequent vulnerabilities in the simple applications you use on your phone, business applications that drive commerce, devices used in hospitals to save lives, and industrial controls that help ensure societal needs. These vulnerabilities can be used for cybercrime, to violate your privacy, disrupt infrastructure, and create national security risks. Unfortunately, the exploitation of these security vulnerabilities can be difficult to detect, especially in undisclosed vulnerabilities.

Despite the growing number of reported and unreported vulnerabilities, people continue to be victimized by these threats, which incur increasingly high financial and privacy costs.. So, what is being done about this? In this chapter, we’ll explore how these threats are addressed by covering some fundamental concepts.

We’ll go over the following:

Software vulnerabilities and the CIA TriadHow software vulnerabilities are classified and organizedThe vulnerability scanners that professionals often use to detect and fix flaws in softwareSome common security vulnerability types usually found in softwareThe vulnerability life cycle and its impact on software

By the end of this chapter, you should understand what vulnerabilities are, how they get introduced to software, how vulnerabilities are organized and ranked, how to search for vulnerable software components, and the software vulnerability life cycle. Let’s get started.

Introducing software vulnerabilities

Criminals want your data. One of the many ways they can obtain this data is by finding and exploiting vulnerabilities in software products that store your data. Since the adoption of the internet, there have been many such instances where criminals have exploited vulnerabilities, resulting in stolen banking information, health information, and corporate and state secrets.

Before we examine vulnerabilities, let’s get a good idea of what software is. It’s best to think about software as instructions that tell a computer what to do. Software can include any instructions or programs written for a device or machine. These instructions enable and empower users to do work such as word processing, sending emails, browsing the internet, and using social media sites such as Facebook and Twitter. Software isn’t necessarily limited to just user-facing components in the form of applications. Software is built to power hardware components and microcontroller devices. Think about modern cars and consumer electronics – if you’ve bought anything with any semblance of computing technology in the 21st century, it’s likely software has been written and is running these devices.

Software vulnerabilities, simply defined, are the defects and shortcomings of software. Think of vulnerabilities as logical errors or loopholes in the instructions we give to our computers. These errors or loopholes can impact three critical areas concerning vulnerabilities in software. In the information security industry, this is commonly referred to as the CIA Triad. CIA is an acronym for confidentiality, integrity, and availability, as illustrated in the following figure:

Figure 1.1 – The CIA Triad

Let’s discuss these factors because they’ll be essential to understanding how vulnerabilities are organized by severity.

The CIA Triad

Confidentiality is the extent to which data is kept private and hidden. Vulnerabilities that can impact this vector often manifest in ways that allow unauthorized users to view or export data they should not have access to. Exploits that impact this vector often disclose data that should not otherwise be disclosed.

Integrity refers to whether data is the same as when it was originally inserted into the software. Vulnerabilities that impact integrity often result in the changing of data. Consider the importance of information related to your banking or health information and how the integrity of those values is important. Exploits to this vector often include changing values from their original sets in a way that benefits the goals of an attacker.

Availability relates to whether the data can be accessed. Vulnerabilities in availability often result in downtime of the application or the disablement of certain features. Bad actors exploiting these vulnerabilities aim to disrupt the access or use of data and systems. Exploits here often result in legitimate users not being able to access data.

When thinking about vulnerabilities, it’s important to know that they impact one or more of these factors in a way that is detrimental to the software. So, now that we understand what the three core concepts are in weighing and measuring vulnerabilities in software, how do they get organized and prioritized?

Organizing impacts

To help us organize and prioritize vulnerabilities, security researchers have developed methods and systems for scoring the impact of vulnerabilities. The most common scoring method you’ll come across is the Common Vulnerability Scoring System (CVSS). The CVSS is an open source specification acting as an equalizing language that helps explore the severity of vulnerabilities and the impacts on the CIA Triad. In addition, the scoring system can be used as a sort of calculator that defines key base metrics about how bad vulnerabilities are. The calculation considers the following factors:

Impact on confidentialityImpact on integrityImpact on availabilityHow the vulnerability is exploitedComplexity of the exploitAccess needed to exploit the vulnerabilityWhether user interaction is required for exploitation

This set of data is calculated with a CVSS calculator (see Figure 1.2) and is usually attached to vulnerabilities in a vulnerability database:

Figure 1.2 – An example of a CVSS score calculator

While we’ll dig into different databases in future chapters, it’s important to be aware of the most common vulnerability dataset, the MITRE Common Vulnerabilities and Exposures (CVE) list. Vulnerable software that has been publicly disclosed is assigned ID numbers through the CVE list. The CVE list feeds into large security vulnerability databases such as the US National Vulnerability Database (NVD) and many others. Each vulnerability in the list is simply called a CVE. Each vulnerability is assigned a CVE ID number, a CVSS score, and details relating to the vulnerability such as exploitation, research, a brief description of the vulnerability, and any other related information. A typical CVE record will look like this:

Figure 1.3 – An example of a CVE record, CVE-2021-2021

Every year, thousands of CVEs are added to the MITRE CVE list, then reported to the NVD. These vulnerabilities can impact various software, services, hardware, and more.

Note

The CVE list, CVE records, and subsequent datasets do not track vulnerabilities for software as a service (SaaS) products. For a vulnerability in this list and dataset, the software in question must be a customer-controlled product. So, for example, Google Docs is an office productivity solution that primarily operates as a web application that does not consist of installed elements under user control. Therefore, Google Docs is not eligible for CVE assignments and registration in vulnerability databases that house CVEs. Similarly, office productivity applications such as Microsoft Office now have similar cloud-based services – but they also provide thick-client installs of applications like Microsoft Word. In this example, the version of Microsoft Word that is installed on a computer is eligible for publishing on the CVE list, but not the cloud-based version.

Now we know how to find information on vulnerabilities and how that research is organized. So, how can security professionals leverage these resources?

Getting familiar with software vulnerability scanners

Many of the exploited vulnerabilities used today are known vulnerabilities registered in the CVE list and have an associated vulnerability score, CVE ID, and details about the vulnerabilities. As of writing this sentence, over 20 million vulnerabilities have been registered in this list. While it’s entirely possible to gather information about the software used and then cross-reference it by searching through a CVE list, the practice would be relatively inefficient and impractical to do regularly.

To solve this problem, software developers have built solutions to detect these vulnerabilities. These kinds of applications are typically referred to as vulnerability scanners. Despite what you might be told by an enthusiastic vendor on the latest security features of their vulnerability scanner, these scanners are typically passive and do not discover otherwise unknown vulnerabilities. Instead, they only identify known flaws by running scripts that search for information about software. The scanners then compare versions of software to the published list of vulnerabilities to determine whether there are known vulnerabilities in the software installed.

Software development teams have been able to get these tools to work with detecting hardware, software versions, and even vulnerable networking equipment such as firewalls. In addition, vulnerability scanning systems let system administrators know what software needs security fixes to avoid the exploitation of vulnerable software. Modern systems usually do this in well-organized ways that prioritize the highest risk and provide reports and dashboards that various audiences can consume.

Vulnerability scanners allow cybersecurity professionals to identify, classify, and prioritize risks. There are many vulnerability scanning tools available to help identify these vulnerabilities. So, what are these common vulnerability scanning tools?

Common vulnerability scanning tools

This section introduces some of the common vulnerability scanning tools that are used by security practitioners. The list is not exhaustive, but it should give you a solid introduction to the basics of these tools and help with your understanding of the common tooling you’ll likely find when you begin researching and using these tools.

Nmap

Nmap or Network Mapper is a free, open source network scanning tool created by the software developer Gordon Lyon. Take a look at the type of output Nmap typically generates when a user runs a scan:

Figure 1.4 – A screenshot of Nmap output using the Nmap-vulners script

The tool can scan for a range of different services on a target host. It can be used to scan a single host or multiple hosts on a local area network or the internet. To say it’s a vulnerability scanning tool is a bit reductive to the complexity of Nmap, but it’s often used with scripts that specifically probe for vulnerabilities. Command-line inputs drive it, and scripts must be specifically requested to determine whether something is vulnerable.

OpenVAS

The Open Vulnerability Assessment System, more commonly known as OpenVAS, is a free, open source tool spun off the commercial product Nessus. OpenVAS’s interface is pictured in the following figure with the Greenbone Security Assistant interface:

Figure 1.5 – The OpenVAS Greenbone Security Assistant dashboard

OpenVAS can help system administrators scan for well-known vulnerabilities against various operating systems and platforms. While it’s open source, it’s a well-supported tool. However, critics or detractors of OpenVAS often point out that the support for enterprises is poor, and extracting data out of the system can be difficult.

Nikto

Nikto is an open source command-line tool that can scan a webserver for vulnerabilities. Its usage is strictly limited to web servers and will require open web services to be of use. The output and interfaces are similar to Nmap, as seen in the following figure:

Figure 1.6 – A screenshot of Nikto output from the command line

Nevertheless, it’s a great tool to use to check in on websites to get a better idea of what they might have for vulnerabilities. Much like Nmap, the output is limited, and detractors anecdotally point out that the rate of false positives is high.

Nessus

Nessus is one of the most deployed vulnerability assessment solutions across the information security industry. The easy-to-use interface and dashboard looks like this:

Figure 1.7 – Nessus scan example

Nessus works much like OpenVAS, allowing an operator to detect and audit the configuration and vulnerabilities on client computers, web servers, and more. This commercially available product also offers easy-to-export reports on the data it finds and various plugins that extend the scanning tools’ functions.

Rapid7 Nexpose

Rapid7 Nexpose is a vulnerability scanner that can scan various targets for a wide range of vulnerabilities and misconfigurations. Take a look at the dashboard to compare and contrast it with Nessus in the following figure:

Figure 1.8 – Rapid7 Nexpose dashboard

It provides operators with a dashboard of results and tie-ins with other Rapid7 tooling used by penetration testers.

Qualys Vulnerability Management

Qualys Vulnerability Management is a commercial vulnerability scanner. Security analysts use this tool much like the other scanners previously mentioned. This aids in assessing the severity of the vulnerabilities so that they can be prioritized and corrected. It works much like OpenVAS, Nessus, and Nexpose.

Note

However powerful security vulnerability scanners are, they are strictly limited in their ability to search through their databases for known vulnerabilities. If there’s not a scripted check for the vulnerability, it cannot be detected.

Now that we’ve talked about vulnerability scanners, let’s get up to speed on the common kinds of software vulnerabilities you’ll see in the wild.

Exploring common types of software vulnerabilities

While an exhaustive list of common software vulnerabilities is out of scope for this book, we should cover some of the most common software vulnerabilities that are being found and exploited. We’ll split this up into two separate groups, web applications and client-server applications.

Web applications

Web applications are one of the most common entry points where organizations get breached. One of the most notable breaches of all time is the Equifax data breach in 2017. This breach occurred because Equifax had a vulnerable website that got exploited. This exploitation of vulnerable software was chained together with other vulnerabilities and exploits to ultimately result in the theft of confidential data. Organizations commonly have websites that feature tools and applications that help them conduct business with their customers and other organizations. These are just some of the common kinds of vulnerabilities found in these popular and widely adopted technologies.

Broken authentication and authorization

Broken authentication and authorization are one of the more common issues found in modern web applications. As a result of the vulnerability, attackers can access data they shouldn’t be allowed to access through a valid account to the website or no account at all. A good example of broken authentication would be if an attacker could bypass the login page for the website to access and or manipulate data that doesn’t belong to them. In contrast, broken authorization might result in an attacker logging in to that website with their own account, but when they access their account information, they could manipulate the application session to access the account information of another user.

Cross-site scripting

Cross-site scripting (XSS) is a technique used to inject malicious content into a website that can be used to run arbitrary JavaScript on a user’s browser session. Attackers do this by finding poor input validation in code. This can be accomplished by finding places on websites that reflect information back to the users either through persistent storage or reflected values that can be present in a URL. There are three widely accepted variants of this vulnerability we’ll briefly discuss:

Persistent XSS: This vulnerability is exploited when users load websites that contain stored values with malicious JavaScript. To exploit this, attackers find places to submit data into the application in a way that saves those values as valid JavaScript, which is then, in turn, reflected back to a user.Reflected XSS: This variation of the XSS vulnerability allows attackers to exploit vulnerable inputs by giving victims URLs that contain malicious JavaScript. Typically, this kind of vulnerability is commonly present in search functions of websites.DOM-based XSS: This vulnerability exists when there is poor input handling in JavaScript, which exploits controls in something called the Document Object Model (DOM). The DOM is a representation of windows and elements on a website and how data flows through these objects. To exploit these vulnerabilities, attackers need to insert malicious JavaScript, which can take advantage of how the objects are processed.

SQL and NoSQL injection

SQL/NoSQL injection is a type of vulnerability that exploits queries made to a connected database. Attackers exploit this kind of vulnerability by manipulating how data is queried in forms and/or requests to the server. When used, the vulnerability results in the disclosure of data such as passwords and personal information. In some cases, these vulnerabilities can be exploited in a way that allows an attacker to take over the underlying server that hosts the database. A variant of this vulnerability referred to as NoSQL injection is related to similar methods used to exploit non-tabular database systems that are connected to applications. The techniques have similar results but are executed in very different ways.

Command injection

Command injection is a type of vulnerability that is a lot like SQL injection. In command injection, though, attackers attempt to insert values into fields or processes in the web application that, if exploited, can run arbitrary commands on the server. This can give an attacker the ability to take complete control over the server and provide them with a foothold into networks they may otherwise not have access to.

Cross-site request forgery

Cross-site request forgery (CSRF) is a vulnerability that, when exploited, can cause users to perform actions for attackers. Standard exploitation techniques involve attackers sending users malicious links that serve requests if used by a user. One of the expected outcomes of distributing these malicious links to victims is actions that change the victim’s password, email address, or other account information to initiate an account takeover.

Server-side request forgery

Server-side request forgery (SSRF) is a type of attack that exploits the trust that a server has in its client. It’s very similar to the CSRF vulnerability type, but the specific focus of this vulnerability is the server and the trust it has with clients and other servers instead of the end user. Exploiting this type of vulnerability can result in the server making authenticated elevated privilege requests to itself or other internally accessible endpoints.

Business logic flaws

Business logic flaws are vulnerabilities introduced by failing to anticipate unexpected behavior or input in routine business processes. There’s never a typical way to exploit these vulnerabilities. These vulnerabilities don’t always follow similar patterns because the application developers always design the logic that dictates how an application ought to be used, and any attack patterns that emerge from the design must be considered on a case-by-case basis. Software developers often introduce these vulnerabilities by not handling the unexpected inputs and states that users may encounter.

Note

What’s prevalent in web application security has changed significantly over the last decade. For the most up-to-date list of common security flaws found in web applications, please refer to the OWASP Top 10 list, which is updated frequently at the following link: https://www.owasp.org/www-project-top-ten.

Client-server applications

Unlike web applications, which seem to have incoming and outgoing trends in software flaws, traditional client-server applications, often known as thick clients or thick applications, change less frequently. These applications differ due to the fact that they are primarily used on an operating system, and the application typically needs to be installed or configured to run on that operating system. These applications often power web application components in server deployments, but they also help users accomplish tasks locally with the processing power of their workstations.

Information disclosure

This happens when applications require passwords, API keys, and personal information to be stored. Sometimes these details are stored in plain-text or encoded files, which can easily be accessed through decompiling applications or decoding the content.

Process hijacking

When applications are installed on operating systems, oftentimes, they are configured with incorrect or insecure permissions on their files, scheduled services, libraries, and more. Attackers can take advantage of these configuration problems by hijacking these components, often impersonating a legitimate application or user session.

Cleartext communications

This vulnerability refers explicitly to communications the application might be making over network protocols. Like our previous category of information disclosure, applications might be transmitting information that is unencrypted and contains sensitive values, which can be exploited if an attacker can intercept the network communication between the client and its network host.

Web application vulnerabilities

Sometimes, traditional applications install web applications that allow users to interact with components of the locally installed application. With these kinds of applications, even if the application is accessed locally, all the issues previously mentioned in the web application section can apply here.

Now that we have a good idea of what kind of vulnerabilities we might find out in the wild, let’s examine the life cycle vulnerabilities typically have.

Inspecting the software vulnerability life cycle

The life cycle of vulnerabilities isn’t always linear, but there are common themes that emerge, which we will explore through a discussion of the phases of this cycle. We’ll talk about these in four stages that often overlap and or begin their execution simultaneously, as shown in the following figure:

Figure 1.9 – The stages rarely follow a specific order, but they are consistent through the inception and depreciation of vulnerabilities

Let’s explore each stage in detail over the next few sections.

Inception

The first stage we’ll cover is inception. In the life cycle, vulnerabilities get introduced through malicious or non-malicious activities during the inception stage. For example, developers might write insecure code, system administrators could deploy weak configurations, or malicious actors may purposefully embed vulnerabilities and back doors into the software. Understanding inception at times is difficult due to the various paths that vulnerabilities take when they’re introduced.

For software and systems to be deployed securely, engineers need to know how to securely write code and deploy systems, or they should receive guidance from security practitioners. Security literacy, or rather the lack of it, may be why vulnerabilities get introduced, but it’s not usually the only contributing factor. Developing software and maintaining operations is expensive, and organizations often seek to save money through various practices meant to accelerate product deployment. As a result, software developers and operation engineers are often stretched thin on projects, and products are rushed to get features and functionality embedded to acquire new customers or satisfy current customers. This pressure combined with poor security culture and/or education in the organization can often lead to outcomes where steps are skipped or security is placed on hold to ensure the product makes it to market. Remember, security always comes at a cost, and that cost often gets cut when businesses push to get applications or features to customers quickly.

Another factor to consider is the complexity of software systems and their deployed or supported infrastructure. If a system is complex, there are more opportunities for weaknesses to be introduced into the configuration and code.

Finally, malicious actors inserting vulnerabilities into code isn’t as uncommon as one might think. It can take a few different forms. Attackers are often aided by an insider threat, such as a disgruntled employee who sells access to attackers. In other instances, sophisticated state-sponsored attacks often gain a foothold into the software of companies they seek to exploit. In 2020, such a campaign made worldwide headlines when attackers targeted the business software, SolarWinds Orion, resulting in CVE-2020-10148. This vulnerability identified highly sophisticated actors implementing a trojan in the Orion software, which was then deployed thousands of times to customers. While these types of attacks and their impact are difficult to quantify, many believe the full effects of this kind of vulnerability are often unseen and potentially have catastrophic outcomes when exploited by attackers.

Discovery

During the discovery phase, vulnerabilities are discovered through security research, where motivated actors seek to understand whether something is vulnerable. They do this by using various methods that test the software for the types of vulnerabilities mentioned in the common vulnerabilities section. The motivations for discovery can vary. Some people are simply looking to discover vulnerabilities to improve the security of software, while others seek to exploit software with other goals in mind.

Depending on the actor’s motivations, the discovery stage presents the researchers with a choice to make. First, they need to decide how and whether they’ll communicate their vulnerabilities to responsible parties. Once discovered, researchers would notify the software publisher directly in ideal circumstances. Once informed, the publisher can begin work on fixing the problems in the remediation stage. Unfortunately, disclosing and determining the next steps for vulnerabilities is rarely this simple or rewarding.