Vulnerability Assessment 🐖

This content was extracted from HTB Academy

Security Assessments

Every organization must perform different types of Security assessments on their networks, computers, and applications at least every so often. The primary purpose of most types of security assessments is to find and confirm vulnerabilities are present, so we can work to patch, mitigate, or remove them. There are different ways and methodologies to test how secure a computer system is. Some types of security assessments are more appropriate for certain networks than others. But they all serve a purpose in improving cybersecurity. All organizations have different compliance requirements and risk tolerance, face different threats, and have different business models that determine the types of systems they run externally and internally. Some organizations have a much more mature security posture than their peers and can focus on advanced red team simulations conducted by third parties, while others are still working to establish baseline security. Regardless, all organizations must stay on top of both legacy and recent vulnerabilities and have a system for detecting and mitigating risks to their systems and data.

Vulnerability Assessment

Vulnerability assessments are appropriate for all organizations and networks. A vulnerability assessment is based on a particular security standard, and compliance with these standards is analyzed (e.g., going through a checklist).

A vulnerability assessment can be based on various security standards. Which standards apply to a particular network will depend on many factors. These factors can include industry-specific and regional data security regulations, the size and form of a company’s network, which types of applications they use or develop, and their security maturity level.

Vulnerability assessments may be performed independently or alongside other security assessments depending on an organization’s situation.

Penetration Test

Here at Hack The Box, we love penetration tests, otherwise known as pentests. Our labs and many of our other Academy courses focus on pentesting.

They’re called penetration tests because testers conduct them to determine if and how they can penetrate a network. A pentest is a type of simulated cyber attack, and pentesters conduct actions that a threat actor may perform to see if certain kinds of exploits are possible. The key difference between a pentest and an actual cyber attack is that the former is done with the full legal consent of the entity being pentested. Whether a pentester is an employee or a third-party contractor, they will need to sign a lengthy legal document with the target company that describes what they’re allowed to do and what they’re not allowed to do.

As with a vulnerability assessment, an effective pentest will result in a detailed report full of information that can be used to improve a network’s security. All kinds of pentests can be performed according to an organization’s specific needs.

Black box pentesting is done with no knowledge of a network’s configuration or applications. Typically a tester will either be given network access (or an ethernet port and have to bypass Network Access Control NAC) and nothing else (requiring them to perform their own discovery for IP addresses) if the pentest is internal, or nothing more than the company name if the pentest is from an external standpoint. This type of pentesting is usually conducted by third parties from the perspective of an external attacker. Often the customer will ask the pentester to show them discovered internal/external IP addresses/network ranges so they can confirm ownership and note down any hosts that should be considered out-of-scope.

Grey box pentesting is done with a little bit of knowledge of the network they’re testing, from a perspective equivalent to an employee who doesn’t work in the IT department, such as a receptionist or customer service agent. The customer will typically give the tester in-scope network ranges or individual IP addresses in a grey box situation.

White box pentesting is typically conducted by giving the penetration tester full access to all systems, configurations, build documents, etc., and source code if web applications are in-scope. The goal here is to discover as many flaws as possible that would be difficult or impossible to discover blindly in a reasonable amount of time.

Often, pentesters specialize in a particular area. Penetration testers must have knowledge of many different technologies but still will usually have a specialty.

Application pentesters assess web applications, thick-client applications, APIs, and mobile applications. They will often be well-versed in source code review and able to assess a given web application from a black box or white box standpoint (typically a secure code review).

Network or infrastructure pentesters assess all aspects of a computer network, including its networking devices such as routers and firewalls, workstations, servers, and applications. These types of penetration testers typically must have a strong understanding of networking, Windows, Linux, Active Directory, and at least one scripting language. Network vulnerability scanners, such as Nessus, can be used alongside other tools during network pentesting, but network vulnerability scanning is only a part of a proper pentest. It’s important to note that there are different types of pentests (evasive, non-evasive, hybrid evasive). A scanner such as Nessus would only be used during a non-evasive pentest whose goal is to find as many flaws in the network as possible. Also, vulnerability scanning would only be a small part of this type of penetration test. Vulnerability scanners are helpful but limited and cannot replace the human touch and other tools and techniques.

Physical pentesters try to leverage physical security weaknesses and breakdowns in processes to gain access to a facility such as a data center or office building.

• Can you open a door in an unintended way?
• Can you tailgate someone into the data center?
• Can you crawl through a vent?

Social engineering pentesters test human beings.

• Can employees be fooled by phishing, vishing (phishing over the phone), or other scams?
• Can a social engineering pentester walk up to a receptionist and say, “yes, I work here?”

Pentesting is most appropriate for organizations with a medium or high security maturity level. Security maturity measures how well developed a company’s cybersecurity program is, and security maturity takes years to build. It involves hiring knowledgeable cybersecurity professionals, having well-designed security policies and enforcement (such as configuration, patch, and vulnerability management), baseline hardening standards for all device types in the network, strong regulatory compliance, well-executed cyber incident response plans, a seasoned CSIRT (computer security incident response team), an established change control process, a CISO (chief information security officer), a CTO (chief technical officer), frequent security testing performed over the years, and strong security culture. Security culture is all about the attitude and habits employees have toward cybersecurity. Part of this can be taught through security awareness training programs and part by building security into the company’s culture. Everyone, from secretaries to sysadmins to C-level staff, should be security conscious, understand how to avoid risky practices, and be educated on recognizing suspicious activity that should be reported to security staff.

Organizations with a lower security maturity level may want to focus on vulnerability assessments because a pentest could find too many vulnerabilities to be useful and could overwhelm staff tasked with remediation. Before penetration testing is considered, there should be a track record of vulnerability assessments and actions taken in response to vulnerability assessments.

Vulnerability Assessments vs. Penetration Tests

Vulnerability Assessments and Penetration Tests are two completely different assessments. Vulnerability assessments look for vulnerabilities in networks without simulating cyber attacks. All companies should perform vulnerability assessments every so often. A wide variety of security standards could be used for a vulnerability assessment, such as GDPR compliance or OWASP web application security standards. A vulnerability assessment goes through a checklist.

• Do we meet this standard?
• Do we have this configuration?

During a vulnerability assessment, the assessor will typically run a vulnerability scan and then perform validation on critical, high, and medium-risk vulnerabilities. This means that they will show evidence that the vulnerability exists and is not a false positive, often using other tools, but will not seek to perform privilege escalation, lateral movement, post-exploitation, etc., if they validate, for example, a remote code execution vulnerability.

Penetration tests, depending on their type, evaluate the security of different assets and the impact of the issues present in the environment. Penetration tests can include manual and automated tactics to assess an organization’s security posture. They also often give a better idea of how secure a company’s assets are from a testing perspective. A pentest is a simulated cyber attack to see if and how the network can be penetrated. Regardless of a company’s size, industry, or network design, pentests should only be performed after some vulnerability assessments have been conducted successfully and with fixes. A business can do vulnerability assessments and pentests in the same year. They can complement each other. But they are very different sorts of security tests used in different situations, and one isn’t “better” than the other.

Adapted from the original graphic found here.

An organization may benefit more from a vulnerability assessment over a penetration test if they want to receive a view of commonly known issues monthly or quarterly from a third-party vendor. However, an organization would benefit more from a penetration test if they are looking for an approach that utilizes manual and automated techniques to identify issues outside of what a vulnerability scanner would identify during a vulnerability assessment. A penetration test could also illustrate a real-life attack chain that an attacker could utilize to access an organization’s environment. Individuals performing penetration tests have specialized expertise in network testing, wireless testing, social engineering, web applications, and other areas.

For organizations that receive penetration testing assessments on an annual or semi-annual basis, it is still crucial for those organizations to regularly evaluate their environment with internal vulnerability scans to identify new vulnerabilities as they are released to the public from vendors.

Other Types of Security Assessments

Vulnerability assessments and penetration tests are not the only types of security assessments that an organization can perform to protect its assets. Other types of assessments may also be necessary, depending on the type of the organization.

Security Audits

Vulnerability assessments are performed because an organization chooses to conduct them, and they can control how and when they’re assessed. Security audits are different. Security audits are typically requirements from outside the organization, and they’re typically mandated by government agencies or industry associations to assure that an organization is compliant with specific security regulations.

For example, all online and offline retailers, restaurants, and service providers who accept major credit cards (Visa, MasterCard, AMEX, etc.) must comply with the PCI-DSS “Payment Card Industry Data Security Standard”. PCI DSS is a regulation enforced by the Payment Card Industry Security Standards Council, an organization run by credit card companies and financial service industry entities. A company that accepts credit and debit card payments may be audited for PCI DSS compliance, and noncompliance could result in fines and not being allowed to accept those payment methods anymore.

Regardless of which regulations an organization may be audited for, it’s their responsibility to perform vulnerability assessments to assure that they’re compliant before they’re subject to a surprise security audit.

Bug Bounties

Bug bounty programs are implemented by all kinds of organizations. They invite members of the general public, with some restrictions (usually no automated scanning), to find security vulnerabilities in their applications. Bug bounty hunters can be paid anywhere from a few hundred dollars to hundreds of thousands of dollars for their findings, which is a small price to pay for a company to avoid a critical remote code execution vulnerability from falling into the wrong hands.

Larger companies with large customer bases and high security maturity are appropriate for bug bounty programs. They need to have a team dedicated to triaging and analyzing bug reports and be in a situation where they can endure outsiders looking for vulnerabilities in their products.

Companies like Microsoft and Apple are ideal for having bug bounty programs because of their millions of customers and robust security maturity.

Red Team Assessment

Companies with larger budgets and more resources can hire their own dedicated red teams or use the services of third-party consulting firms to perform red team assessments. A red team consists of offensive security professionals who have considerable experience with penetration testing. A red team plays a vital role in an organization’s security posture.

A red team is a type of evasive black box pentesting, simulating all kinds of cyber attacks from the perspective of an external threat actor. These assessments typically have an end goal (i.e., reaching a critical server or database, etc.). The assessors only report the vulnerabilities that led to the completion of the goal, not as many vulnerabilities as possible as with a penetration test.

If a company has its own internal red team, its job is to perform more targeted penetration tests with an insider’s knowledge of its network. A red team should constantly be engaged in red teaming campaigns. Campaigns could be based on new cyber exploits discovered through the actions of advanced persistent threat groups (APTs), for example. Other campaigns could target specific types of vulnerabilities to explore them in great detail once an organization has been made aware of them.

Ideally, if a company can afford it and has been building up its security maturity, it should conduct regular vulnerability assessments on its own, contract third parties to perform penetration tests or red team assessments, and, if appropriate, build an internal red team to perform grey and white box pentesting with more specific parameters and scopes.

Purple Team Assessment

A blue team consists of defensive security specialists. These are often people who work in a SOC (security operations center) or a CSIRT (computer security incident response team). Often, they have experience with digital forensics too. So if blue teams are defensive and red teams are offensive, red mixed with blue is purple.

What's a purple team?

Purple teams are formed when offensive and defensive security specialists work together with a common goal, to improve the security of their network. Red teams find security problems, and blue teams learn about those problems from their red teams and work to fix them. A purple team assessment is like a red team assessment, but the blue team is also involved at every step. The blue team may even play a role in designing campaigns. “We need to improve our PCI DSS compliance. So let’s watch the red team pentest our point-of-sale systems and provide active input and feedback during their work.”

Vulnerability Assessment

A Vulnerability Assessment aims to identify and categorize risks for security weaknesses related to assets within an environment. It is important to note that there is little to no manual exploitation during a vulnerability assessment. A vulnerability assessment also provides remediation steps to fix the issues.

The purpose of a Vulnerability Assessment is to understand, identify, and categorize the risk for the more apparent issues present in an environment without actually exploiting them to gain further access. Depending on the scope of the assessment, some customers may ask us to validate as many vulnerabilities as possible by performing minimally invasive exploitation to confirm the scanner findings and rule out false positives. Other customers will ask for a report of all findings identified by the scanner. As with any assessment, it is essential to clarify the scope and intent of the vulnerability assessment before starting. Vulnerability management is vital to help organizations identify the weak points in their assets, understand the risk level, and calculate and prioritize remediation efforts.

It is also important to note that organizations should always test substantial patches before pushing them out into their environment to prevent disruptions.

Methodology

Below is a sample vulnerability assessment methodology that most organizations could follow and find success with. Methodologies may vary slightly from organization to organization, but this chart covers the main steps, from identifying assets to creating a remediation plan.

Adapted from the original graphic found here.

Understanding Key Terms

Before we go any further, let’s identify some key terms that any IT or Infosec professional should understand and be able to explain clearly.

Vulnerability

A Vulnerability is a weakness or bug in an organization’s environment, including applications, networks, and infrastructure, that opens up the possibility of threats from external actors. Vulnerabilities can be registered through MITRE’s Common Vulnerability Exposure database and receive a Common Vulnerability Scoring System (CVSS) score to determine severity. This scoring system is frequently used as a standard for companies and governments looking to calculate accurate and consistent severity scores for their systems’ vulnerabilities. Scoring vulnerabilities in this way helps prioritize resources and determine how to respond to a given threat. Scores are calculated using metrics such as the type of attack vector (network, adjacent, local, physical), the attack complexity, privileges required, whether or not the attack requires user interaction, and the impact of successful exploitation on an organization’s confidentiality, integrity, and availability of data. Scores can range from 0 to 10, depending on these metrics.

For example, SQL injection is considered a vulnerability since an attacker could leverage queries to extract data from an organization’s database. This attack would have a higher CVSS score rating if it could be performed without authentication over the internet than if an attacker needed authenticated access to the internal network and separate authentication to the target application. These types of things must be considered for all vulnerabilities we encounter.

Threat

A Threat is a process that amplifies the potential of an adverse event, such as a threat actor exploiting a vulnerability. Some vulnerabilities raise more threat concerns over others due to the probability of the vulnerability being exploited. For example, the higher the reward of the outcome and ease of exploitation, the more likely the issue would be exploited by threat actors.

Exploit

An Exploit is any code or resources that can be used to take advantage of an asset’s weakness. Many exploits are available through open-source platforms such as Exploit-db or the Rapid7 Vulnerability and Exploit Database. We will often see exploit code hosted on sites such as GitHub and GitLab as well.

Risk

Risk is the possibility of assets or data being harmed or destroyed by threat actors.

To differentiate the three, we can think of it as follows:

• Risk: something bad that could happen
• Threat: something bad that is happening
• Vulnerabilities: weaknesses that could lead to a threat

Vulnerabilities, Threats, and Exploits all play a part in measuring the level of risk in weaknesses by determining the likelihood and impact. For example, vulnerabilities that have reliable exploit code and are likely to be used to gain access to an organization’s network would significantly raise the risk of an issue due to the impact. If an attacker had access to the internal network, they could potentially view, edit, or delete sensitive documents crucial for business operations. We can use a qualitative risk matrix to measure risk based on likelihood and impact with the table shown below.

In this example, we can see that a vulnerability with a low likelihood of occurring and low impact would be the lowest risk level, while a vulnerability with a high likelihood of being exploited and the highest impact on an organization would represent the highest risk and would want to be prioritized for remediation.

Asset Management

When an organization of any kind, in any industry, and of any size needs to plan their cybersecurity strategy, they should start by creating an inventory of their data assets. If you want to protect something, you must first know what you are protecting! Once assets have been inventoried, then you can start the process of asset management. This is a key concept in defensive security.

Asset Inventory

Asset inventory is a critical component of vulnerability management. An organization needs to understand what assets are in its network to provide the proper protection and set up appropriate defenses. The asset inventory should include information technology, operational technology, physical, software, mobile, and development assets. Organizations can utilize asset management tools to keep track of assets. The assets should have data classifications to ensure adequate security and access controls.

Application and System Inventory

An organization should create a thorough and complete inventory of data assets for proper asset management for defensive security. Data assets include:

• All data stored on-premises. HDDs and SSDs in endpoints (PCs and mobile devices), HDDs & SSDs in servers, external drives in the local network, optical media (DVDs, Blu-ray discs, CDs), flash media (USB sticks, SD cards). Legacy technology may include floppy disks, ZIP drives (a relic from the 1990s), and tape drives.

• All of the data storage that their cloud provider possesses. Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure are some of the most popular cloud providers, but there are many more. Sometimes corporate networks are “multi-cloud,” meaning they have more than one cloud provider. A company’s cloud provider will provide tools that can be used to inventory all of the data stored by that particular cloud provider.

• All data stored within various Software-as-a-Service (SaaS) applications. This data is also “in the cloud” but might not all be within the scope of a corporate cloud provider account. These are often consumer services or the “business” version of those services. Think of online services such as Google Drive, Dropbox, Microsoft Teams, Apple iCloud, Adobe Creative Suite, Microsoft Office 365, Google Docs, and the list goes on.

• All of the applications a company needs to use to conduct their usual operation and business. Including applications that are deployed locally and applications that are deployed through the cloud or are otherwise Software-as-a-Service.

• All of a company’s on-premises computer networking devices. These include but aren’t limited to routers, firewalls, hubs, switches, dedicated intrusion detection and prevention systems (IDS/IPS), data loss prevention (DLP) systems, and so on.

All of these assets are very important. A threat actor or any other sort of risk to any of these assets can do significant damage to a company’s information security and ability to operate day by day. An organization needs to take its time to assess everything and be careful not to miss a single data asset, or they won’t be able to protect it.

Organizations frequently add or remove computers, data storage, cloud server capacity, or other data assets. Whenever data assets are added or removed, this must be thoroughly noted in the data asset inventory.

Assessment Standards

Both penetration tests and vulnerability assessments should comply with specific standards to be accredited and accepted by governments and legal authorities. Such standards help ensure that the assessment is carried out thoroughly in a generally agreed-upon manner to increase the efficiency of these assessments and reduce the likelihood of an attack on the organization.

Compliance Standards

Each regulatory compliance body has its own information security standards that organizations must adhere to maintain their accreditation. The big compliance players in information security are PCI, HIPAA, FISMA, and ISO 27001.

These accreditations are necessary because it certifies that an organization has had a third-party vendor evaluate its environment. Organizations also rely on these accreditations for business operations since some companies won’t do business without specific accreditations from organizations.

Payment Card Industry Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS) is a commonly known standard in information security that implements requirements for organizations that handle credit cards. While not a government regulation, organizations that store, process, or transmit cardholder data must still implement PCI DSS guidelines. This would include banks or online stores that handle their own payment solutions (e.g., Amazon).

PCI DSS requirements include internal and external scanning of assets. For example, any credit card data that is being processed or transmitted must be done in a Cardholder Data Environment (CDE). The CDE environment must be adequately segmented from normal assets. CDE environments are segmented off from an organization’s regular environment to protect any cardholder data from being compromised during an attack and limit internal access to data.

Source

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA is the Health Insurance Portability and Accountability Act, which is used to protect patients’ data. HIPAA does not necessarily require vulnerability scans or assessments; however, a risk assessment and vulnerability identification are required to maintain HIPAA accreditation.

Federal Information Security Management Act (FISMA)

The Federal Information Security Management Act (FISMA) is a set of standards and guidelines used to safeguard government operations and information. The act requires an organization to provide documentation and proof of a vulnerability management program to maintain information technology systems’ proper availability, confidentiality, and integrity.

ISO 27001

ISO 27001 is a standard used worldwide to manage information security. ISO 27001 requires organizations to perform quarterly external and internal scans.

Although compliance is essential, it should not drive a vulnerability management program. Vulnerability management should consider the uniqueness of an environment and the associated risk appetite to an organization.

The International Organization for Standardization (ISO) maintains technical standards for pretty much anything you can imagine. The ISO 27001 standard deals with information security. ISO 27001 compliance depends upon maintaining an effective Information Security Management System. To ensure compliance, organizations can perform penetration tests in a carefully designed way.

Penetration Testing Standards

Penetration tests should not be performed without any rules or guidelines. There must always be a specifically defined scope for a pentest, and the owner of a network must have a signed legal contract with pentesters outlining what they’re allowed to do and what they’re not allowed to do. Pentesting should also be conducted in such a way that minimal harm is done to a company’s computers and networks. Penetration testers should avoid making changes wherever possible (such as changing an account password) and limit the amount of data removed from a client’s network. For example, instead of removing sensitive documents from a file share, a screenshot of the folder names should suffice to prove the risk.

In addition to scope and legalities, there are also various pentesting standards, depending on what kind of computer system is being assessed. Here are some of the more common standards you may use as a pentester.

PTES

The Penetration Testing Execution Standard (PTES) can be applied to all types of penetration tests. It outlines the phases of a penetration test and how they should be conducted. These are the sections in the PTES:

• Pre-engagement Interactions
• Intelligence Gathering
• Threat Modeling
• Vulnerability Analysis
• Exploitation
• Post Exploitation
• Reporting

OSSTMM

OSSTMM is the Open Source Security Testing Methodology Manual, another set of guidelines pentesters can use to ensure they’re doing their jobs properly. It can be used alongside other pentest standards.

OSSTMM is divided into five different channels for five different areas of pentesting:

1. Human Security (human beings are subject to social engineering exploits)
2. Physical Security
3. Wireless Communications (including but not limited to technologies like WiFi and Bluetooth)
4. Telecommunications
5. Data Networks

NIST

The NIST (National Institute of Standards and Technology) is well known for their NIST Cybersecurity Framework, a system for designing incident response policies and procedures. NIST also has a Penetration Testing Framework. The phases of the NIST framework include:

• Planning
• Discovery
• Attack
• Reporting

OWASP

OWASP stands for the Open Web Application Security Project. They’re typically the go-to organization for defining testing standards and classifying risks to web applications.

OWASP maintains a few different standards and helpful guides for assessing various technologies:

• Web Security Testing Guide (WSTG)
• Mobile Security Testing Guide (MSTG)
• Firmware Security Testing Methodology

Common Vulnerability Scoring System (CVSS)

There are various ways to score or calculate severity ratings of vulnerabilities. The Common Vulnerability Scoring System (CVSS) is an industry standard for performing these calculations. Many scanning tools will apply these scores to each finding as a part of the scan results, but it’s important that we understand how these scores are derived in case we ever need to calculate one by hand or justify the score applied to a given vulnerability. The CVSS is often used together with the so-called Microsoft DREAD. DREAD is a risk assessment system developed by Microsoft to help IT security professionals evaluate the severity of security threats and vulnerabilities. It is used to perform a risk analysis by using a scale of 10 points to assess the severity of security threats and vulnerabilities. With this, we calculate the risk of a threat or vulnerability based on five main factors:

• Damage Potential
• Reproducibility
• Exploitability
• Affected Users
• Discoverability

The model is essential to Microsoft’s security strategy and is used to monitor, assess and respond to security threats and vulnerabilities in Microsoft products. It also serves as a reference for IT security professionals and managers to perform their risk assessment and prioritization of security threats and vulnerabilities.

Severity Scoring

The CVSS system helps categorize the severity associated with an issue and allows organizations to prioritize issues based on the rating. The CVSS scoring consists of the exploitability and impact of an issue. The exploitability measurements consist of access vector, access complexity, and authentication. The impact metrics consist of the CIA triad, including confidentiality, integrity, and availability.

Adapted from the original graphic found here.

Base Metric Group

The CVSS base metric group represents the vulnerability characteristics and consists of exploitability metrics and impact metrics.

Exploitability Metrics

The Exploitability metrics are a way to evaluate the technical means needed to exploit the issue using the metrics below:

• Attack Vector
• Attack Complexity
• Privileges Required
• User Interaction

Impact Metrics

The Impact metrics represent the repercussions of successfully exploiting an issue and what is impacted in an environment, and it is based on the CIA triad. The CIA triad is an acronym for Confidentiality, Integrity, and Availability.

Confidentiality Impact relates to securing information and ensuring only authorized individuals have access. For example, a high severity value would be in the case of an attacker stealing passwords or encryption keys. A low severity value would relate to an attacker taking information that may not be a vital asset to an organization.

Integrity Impact relates to information not being changed or tampered with to maintain accuracy. For example, a high severity would be if an attacker modified crucial business files in an organization’s environment. A low severity value would be if an attacker could not specifically control the number of changed or modified files.

Availability Impact relates to having information readily attainable for business requirements. For example, a high value would be if an attacker caused an environment to be completely unavailable for business. A low value would be if an attacker could not entirely deny access to business assets and users could still access some organization assets.

Temporal Metric Group

The Temporal Metric Group details the availability of exploits or patches regarding the issue.

Exploit Code Maturity

The Exploit Code Maturity metric represents the probability of an issue being exploited based on ease of exploitation techniques. There are various metric values associated with this metric, including Not Defined, High, Functional, Proof-of-Concept, and Unproven.

A ‘Not Defined’ value relates to skipping this particular metric. A ‘High’ value represents an exploit consistently working for the issue and is easily identifiable with automated tools. A Functional value indicates there is exploit code available to the public. A Proof-of-Concept demonstrates that a PoC exploit code is available but would require changes for an attacker to exploit the issue successfully.

Remediation Level

The Remediation level is used to identify the prioritization of a vulnerability. The metric values associated with this metric include Not Defined, Unavailable, Workaround, Temporary Fix, and Official Fix.

A ‘Not Defined’ value relates to skipping this particular metric. An ‘Unavailable’ value indicates there is no patch available for the vulnerability. A ‘Workaround’ value indicates an unofficial solution released until an official patch by the vendor. A ‘Temporary Fix’ means an official vendor has provided a temporary solution but has not released a patch yet for the issue. An ‘Official Fix’ indicates a vendor has released an official patch for the issue for the public.

Report Confidence

Report Confidence represents the validation of the vulnerability and how accurate the technical details of the issue are. The metric values associated with this metric include Not Defined, Confirmed, Reasonable, and Unknown.

A ‘Not Defined’ value relates to skipping this particular metric. A ‘Confirmed’ value indicates there are various sources with detailed information confirming the vulnerability. A ‘Reasonable’ value indicates sources have published information about the vulnerability. However, there is no complete confidence that someone would achieve the same result due to missing details of reproducing the exploit for the issue.

Environmental Metric Group

The Environmental metric group represents the significance of the vulnerability of an organization, taking into account the CIA triad.

Modified Base Metrics

The Modified Base metrics represent the metrics that can be altered if the affected organization deems a more significant risk in Confidentiality, Integrity, and Availability to their organization. The values associated with this metric are Not Defined, High, Medium, and Low.

A ‘Not Defined’ value would indicate skipping this metric. A ‘High’ value would mean one of the elements of the CIA triad would have astronomical effects on the overall organization and customers. A ‘Medium’ value would indicate one of the elements of the CIA triad would have significant effects on the overall organization and customers. A ‘Low’ value would mean one of the elements of the CIA triad would have minimal effects on the overall organization and customers.

Calculating CVSS Severity

The calculation of a CVSS v3.1 score takes into account all the metrics discussed in this section. The National Vulnerability Database has a calculator available to the public here.

CVSS Calculation Example

For example, for the Windows Print Spooler Remote Code Execution Vulnerability, CVSS Base Metrics is 8.8. You can reference the values of each metric value here.

Common Vulnerabilities and Exposures (CVE)

Open Vulnerability Assessment Language (OVAL)

Open Vulnerability Assessment Language (OVAL) is a publicly available information security international standard used to evaluate and detail the system’s current state and issues. OVAL is also co-supported by the office of Cybersecurity and Communications from the U.S. Department of Homeland Security. OVAL provides a language to understand encoding system attributes and various content repositories shared within the security community. The OVAL repository has over 7000+ definitions for public use. Additionally, OVAL is also used by the U.S. National Institute of Standards and Technology’s (NIST) Security Content Automation Protocol (SCAP) which brings together community ideas for automating vulnerability management, measurement, and ensuring systems meet policy compliance.

OVAL Process

Adapted from the original graphic found here.

The goal of the OVAL language is to have a three-step structure during the assessment process that consists of:

• Identifying a system’s configurations for testing
• Evaluating the current system’s state
• Disclosing the information in a report

The information can be described in various types of states, including: Vulnerable, Non-compliant, Installed Asset, and Patched.

OVAL Definitions

The OVAL definitions are recorded in an XML format to discover any software vulnerabilities, misconfigurations, programs, and additional system information taking out the need to exploit a system. By having the ability to identify issues without directly exploiting the issue, an organization can correlate which systems need to be patched in a network.

The four main classes of OVAL definitions consist of:

• OVAL Vulnerability Definitions: Identifies system vulnerabilities
• OVAL Compliance Definitions: Identifies if current system configurations meet system policy requirements
• OVAL Inventory Definitions: Evaluates a system to see if a specific software is present
• OVAL Patch Definitions: Identifies if a system has the appropriate patch

Additionally, the OVAL ID Format consist of a unique format that consists of “oval:Organization Domain Name:ID Type:ID Value”. The ID Type can fall into various categories including: definition (def), object (obj), state (ste), and variable (var). An example of a unique identifier would be oval:org.mitre.oval:obj:1116.

Scanners such as Nessus have the ability to use OVAL to configure security compliance scanning templates.

Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE) is a publicly available catalog of security issues sponsored by the United States Department of Homeland Security (DHS). Each security issue has a unique CVE ID number assigned by the CVE Numbering Authority (CNA). The purpose of creating a unique CVE ID number is to create a standardization for a vulnerability or exposure as a researcher identifies it. A CVE consists of critical information regarding a vulnerability or exposure, including a description and references about the issue. The information in a CVE allows an organization’s IT team to understand how detrimental a problem could be to their environment.

The following chart explains how a CVE ID may be assigned to a vulnerability. Any vulnerabilities assigned a CVE must be independently fixable, affect just one codebase, and be acknowledged and documented by the relevant vendor.

Adapted from the original graphic here.

Stages of Obtaining a CVE

Stage 1: Identify if CVE is Required and Relevant

Identify if the issue found is a vulnerability. According to the CVE Team, “A vulnerability in the context of the CVE Program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address.” Additionally, research should verify there is not a CVE ID already in the CVE database.

Stage 2: Reach Out to Affected Product Vendor

A researcher should ensure they have made a good faith effort to contact a vendor directly. Researchers can reference CVE’s Documents on Disclosure Practices for additional information.

Stage 3: Identify if Request Should Be For Vendor CNA or Third Party CNA

If a company is a part of participating CNA’s, they can assign a CVE ID for one of their products. If the issue is for a participating CNA, researchers can contact the appropriate CNA organization here. If the vendor is not a participating CNA, a researcher should attempt to reach out to the vendor’s third-party coordinator.

Stage 4: Requesting CVE ID Through CVE Web Form

The CVE Team has a form that can be filled out online here if the methods above do not work for CVE requests.

Stage 5: Confirmation of CVE Form

Upon submitting the CVE Web Form mentioned in Stage 4, an individual will receive a confirmation email. The CVE team will contact the requestor if any additional information is required.

Stage 6: Receival of CVE ID

Upon approval, the CVE Team will notify the requestor of a CVE ID if the affected product’s vulnerability is confirmed. Please note that the CVE ID is not public yet at this stage.

Stage 7: Public Disclosure of CVE ID

CVE IDs can be announced to the public as soon as appropriate vendors and parties are aware of the issue to prevent duplication of CVE IDs. This stage ensures that all associated parties are aware of the problem before being publicly disclosed.

Stage 8: Announcing the CVE

The CVE Team asks researchers who are sharing multiple CVEs to ensure each CVE indicates the different vulnerabilities. Additional information can be found here.

Stage 9: Providing Information to The CVE Team

At this stage, the CVE Team asks that the researcher help provide additional information to be used in the official CVE listing on the website. The U.S. National Vulnerability Database (NVD) maintains this information online in their database as well.

Responsible Disclosure

Security researchers and consultants constantly reference the CVE database since it consists of thousands of vulnerabilities that could be leveraged for exploitation. In addition, there are also times when individuals may come across an issue they have never seen in the wild or it has never disclosed while digging into a specific software or program.

Responsible disclosure is essential in the security community because it allows an organization or researcher to work directly with a vendor providing them with the issue details first to ensure a patch is available before the vulnerability announcement to the world. If an issue is not responsibly disclosed to a vendor, real threat actors may be able to leverage the issues for criminal use, also referred to as a zero day or an 0-day.

Examples

CVE-2020-5902

CVE-2020-5902 is an unauthenticated, remote code execution vulnerability in the BIG-IP Traffic Management User Interface (TMUI). The issue is exploitable when TMUI is available through the BIG-IP management port and leads to a complete system takeover since an attacker could execute code, edit files, and enable or disable services on the remote host.

CVE-2021-34527

CVE-2021-34527, also known as PrintNightmare, is a remote code execution vulnerability within the Windows Print Spooler service. The Windows Print Spooler service can be abused due to the service improperly handling privileges file operations. The issue requires a user to be authenticated but allows complete takeover of a system from remote or local code execution. The issue is extremely dangerous since it allows an attacker to fully control a domain since it exploits servers (including domain controllers) and workstations.

Vulnerability Scanning Overview

As discussed earlier, vulnerability scanning is performed to identify potential vulnerabilities in network devices such as routers, firewalls, switches, as well as servers, workstations, and applications. Scanning is automated and focuses on finding potential/known vulnerabilities on the network or at the application level. Vulnerabilities scanners typically do not exploit vulnerabilities (with some exceptions) but need a human to manually validate scan issues to determine whether or not a particular scan returned real issues that need to be fixed or false positives that can be ignored and excluded from future scans against the same target.

Vulnerability scanning is often part of a standard penetration test, but the two are not the same. A vulnerability scan can help gain additional coverage during a penetration test or speed up the project’s testing under time constraints. An actual penetration test includes much more than just a scan.

The type of scans run varies from one tool to another, but most tools run a combination of dynamic and static tests, depending on the target and the vulnerability. A static test would determine a vulnerability if the identified version of a particular asset has a public CVE. However, this is not always accurate as a patch may have been applied, or the target isn’t specifically vulnerable to that CVE. On the other hand, a dynamic test tries specific (usually benign) payloads such as weak credentials, SQL injection, or command injection on the target (i.e., a web application). If any payload returns a hit, then there’s a good chance that it is vulnerable.

Organizations should run both unauthenticated and authenticated scans on a continuous schedule to ensure that assets are patched as new vulnerabilities are discovered and that any new assets added to the network do not have missing patches or other configuration/patching issues. Vulnerability scanning should feed into an organization’s patch management program.

Nessus, Qualys, and Nexpose are well-known vulnerability scanning platforms. While Nessus and Qualys offer free community editions, Nexpose provides a 30-day trial edition, allowing users to explore its features before committing to a purchase. Additionally, there are open-source alternatives such as OpenVAS.

Nessus Overview

Nessus Essentials by Tenable is the free version of the official Nessus Vulnerability Scanner. Individuals can access Nessus Essentials to get started understanding Tenable’s vulnerability scanner. The caveat is that it can only be used for up to 16 hosts. The features in the free version are limited but are perfect for someone looking to get started with Nessus. The free scanner will attempt to identify vulnerabilities in an environment.

OpenVAS Overview

OpenVAS by Greenbone Networks is a publicly available open-source vulnerability scanner. OpenVAS can perform network scans, including authenticated and unauthenticated testing.

Getting Started with Nessus

Let’s see how we can download and set up Nessus for its first use so that we can start learning its various features. Feel free to follow along and set up a Nessus instance on your own VM. For the interactive portions of this module, we provide a lab instance of Nessus and another with OpenVAS installed.

Downloading Nessus

To download Nessus, we can navigate to its Download Page to download the correct Nessus binary for our system. We will be downloading the Debian package for Ubuntu for this walkthrough.

Requesting Free License

Next, we can visit the Activation Code Page to request a Nessus Activation Code, which is necessary to get the free version of Nessus:

Installing Package

With both the binary and activation code in hand, we can now install the Nessus package:

gitblanc@htb[/htb]$ dpkg -i Nessus-8.15.1-ubuntu910_amd64.deb
 
Selecting previously unselected package nessus.
(Reading database ... 132030 files and directories currently installed.)
Preparing to unpack Nessus-8.15.1-ubuntu910_amd64.deb ...
Unpacking nessus (8.15.1) ...
Setting up nessus (8.15.1) ...
Unpacking Nessus Scanner Core Components...
Created symlink /etc/systemd/system/nessusd.service → /lib/systemd/system/nessusd.service.
Created symlink /etc/systemd/system/multi-user.target.wants/nessusd.service → /lib/systemd/system/nessusd.service.

Starting Nessus

Once we have Nessus installed, we can start the Nessus Service:

gitblanc@htb[/htb]$ sudo systemctl start nessusd.service

Accessing Nessus

To access Nessus, we can navigate to https://localhost:8834. Once we arrive at the setup page, we should select Nessus Essentials for the free version, and then we can enter our activation code:

Once we enter our activation code, we can set up a user with a secure password for our Nessus account. Then, the plugins will begin to compile once this step is completed:

Note

The VM provided at the Nessus Skills Assessment section has Nessus pre-installed and the targets running. You can go to that section and start the VM and use Nessus throughout the module, which can be accessed at https:// < IP >:8834. The Nessus credentials are: htb-student:HTB_@cademy_student!. You may also use these credentials to SSH into the target VM to configure Nessus.

Finally, once the setup is complete, we can start creating scans, scan policies, plugin rules, and customizing settings. The Settings page has a wealth of options such as setting up a Proxy Server or SMTP server, standard account management options, and advanced settings to customize the user interface, scanning, logging, performance, and security options.

Nessus Scan

A new Nessus scan can be configured by clicking New Scan, and selecting a scan type. Scan templates fall into three categories: Discovery, Vulnerabilities, and Compliance.

Note

The scans shown in this section have already been pre-run to save you the time of waiting for them to finish. If you re-run the scan, it’s best to go through vulnerabilities as they come, instead of waiting for the scan to finish, as they can take 1-2 hours to finish.

New Scan

Here we have options for a basic Host Discovery scan to identify live hosts/open ports or a variety of scan types such as the Basic Network Scan, Advanced Scan, Malware Scan, Web Application Tests, as well as scans targeted at specific CVEs and audit & compliance standards. A description of each scan type can be found here.

For the purposes of this exercise, we will choose the Basic Network Scan option, and we can enter our targets:

Note

For this module, the Windows target will be 172.16.16.100 and the Linux target will be 172.16.16.160.

Discovery

In the Discovery section, under Host Discovery, we’re presented with the option to enable scanning for fragile devices. Scanning devices such as network printers often result in them printing out reams of paper with garbage text, leaving the devices unusable. We can leave this setting disabled:

In Port Scanning, we can choose whether to scan common ports, all ports, or a self-defined range, depending on our requirements:

Within the Service Discovery subsection, the Probe all ports to find services option is selected by default. It’s possible that a poorly designed application or service could crash as a result of this probing, but most applications should be robust enough to handle this. Searching for SSL/TLS services is also enabled by default on a custom scan, and Nessus can additionally be instructed to identify expiring and revoked certificates.

Assessment

Under the Assessment category, web application scanning can also be enabled if required, and a custom user agent and various other web application scanning options can be specified (e.g., a URL for Remote File Inclusion (RFI) testing):

If desired, Nessus can attempt to authenticate against discovered applications and services using provided credentials (if running a credentialed scan), or else can perform a brute-force attack with the provided username and password lists:

User enumeration can also be performed using various techniques, such as RID Brute Forcing:

If we opt to perform RID Brute Forcing, we can set the starting and ending UIDs for both domain and local user accounts:

Advanced

On the Advanced tab, safe checks are enabled by default. This prevents Nessus from running checks that may negatively impact the target device or network. We can also choose to slow or throttle the scan if Nessus detects any network congestion, stop attempting to scan any hosts that become unresponsive, and even choose to have Nessus scan our target IP list in random order:

Advanced Settings

We can configure a number of advanced settings for Nessus and its scans, like scan policies, plugins, and credentials, all of which we will cover in this section.

Scan Policies

Nessus gives us the option to create scan policies. Essentially these are customized scans that allow us to define specific scan options, save the policy configuration, and have them available to us under Scan Templates when creating a new scan. This gives us the ability to create targeted scans for any number of scenarios, such as a slower, more evasive scan, a web-focused scan, or a scan for a particular client using one or several sets of credentials. Scan policies can be imported from other Nessus scanners or exported to be later imported into another Nessus scanner.

Creating a Scan Policy

To create a scan policy, we can click on the New Policy button in the top right, and we will be presented with the list of pre-configured scans. We can choose a scan, such as the Basic Network Scan, then customize it, or we can create our own. We will choose Advanced Scan to create a fully customized scan with no pre-configured recommendations built-in.

After choosing the scan type as our base, we can give the scan policy a name and a description if needed:

From here, we can configure settings, add in any necessary credentials, and specify any compliance standards to run the scan against. We can also choose to enable or disable entire plugin families or individual plugins.

Once we have finished customizing the scan, we can click on Save, and the newly created policy will appear in the polices list. From here on, when we go to create a new scan, there will be a new tab named User Defined under Scan Templates that will show all of our custom scan policies:

Nessus Plugins

Nessus works with plugins written in the Nessus Attack Scripting Language (NASL) and can target new vulnerabilities and CVEs. These plugins contain information such as the vulnerability name, impact, remediation, and a way to test for the presence of a particular issue.

Plugins are rated by severity level: Critical, High, Medium, Low, Info. At the time of this writing Tenable has published 145,973 plugins that cover 58,391 CVE IDs and 30,696 Bugtraq IDs. A searchable database of all published plugins is on the Tenable website.

The Plugins tab provides more information on a particular detection, including mitigation. When conducting recurring scans, there may be a vulnerability/detection that, upon further examination, is not considered to be an issue. For example, Microsoft DirectAccess (a technology that provides internal network connectivity to clients over the Internet) allows insecure and null cipher suites. The below scan performed with sslscan shows an example of insecure and null cipher suites:

gitblanc@htb[/htb]$ sslscan example.com
 
<SNIP>
 
Preferred TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  TLSv1.0  256 bits  AES256-SHA                   
 
<SNIP>

However, this is by design. SSL/TLS is not required in this case, and implementing it would result in a negative performance impact. To exclude this false positive from the scan results while keeping the detection active for other hosts, we can create a plugin rule:

Under the Resources section, we can select Plugin Rules. In the new plugin rule, we input the host to be excluded, along with the Plugin ID for Microsoft DirectAccess, and specify the action to be performed as Hide this result:

We may also want to exclude certain issues from our scan results, such as plugins for issues that are not directly exploitable (e.g., SSL Self-Signed Certificate). We can do this by specifying the plugin ID and host(s) to be excluded:

Scanning with Credentials

Nessus also supports credentialed scanning and provides a lot of flexibility by supporting LM/NTLM hashes, Kerberos authentication, and password authentication.

Credentials can be configured for host-based authentication via SSH with a password, public key, certificate, or Kerberos-based authentication. It can also be configured for Windows host-based authentication with a password, Kerberos, LM hash, or NTLM hash:

Nessus also supports authentication for a variety of databases types including Oracle, PostgreSQL, DB2, MySQL, SQL Server, MongoDB, and Sybase:

Note

To run a credentialed scan on the target, use the following credentials: htb-student_adm:HTB_@cademy_student! for Linux, and administrator:Academy_VA_adm1! for Windows. These scans have already been set up in the Nessus target to save you time.

In addition to that, Nessus can perform plaintext authentication to services such as FTP, HTTP, IMAP, IPMI, Telnet, and more:

Finally, we can check the Nessus output to confirm whether the authentication to the target application or service with the supplied credentials was successful:

Working with Nessus Scan Output

Nessus gives us the option to export scan results in a variety of report formats as well as the option to export raw Nessus scan results to be imported into other tools, archived, or passed to tools, such as EyeWitness, which can be used to take screenshots of all web applications identified by Nessus and greatly assist us with working through the results and finding more value in them.

Nessus Reports

Once a scan is completed we can choose to export a report in .pdf, .html, or .csv formats. The .pdf and .html reports give the option for either an Executive Summary or a custom report. The Executive Summary report provides a listing of hosts, a total number of vulnerabilities discovered per host, and a Show Details option to see the severity, CVSS score, plugin number, and name of each discovered issue. The plugin number contains a link to the full plugin writeup from the Tenable plugin database. The PDF option provides the scan results in a format that is easier to share. The CSV report option allows us to select which columns we would like to export. This is particularly useful if importing the scan results into another tool such as Splunk if a document needs to be shared with many internal stakeholders responsible for remediation of the various assets scanned or to perform analytics on the scan data.

Note

These scan reports should only be shared as either an appendix or supplementary data to a custom penetration test/vulnerability assessment report. They should not be given to a client as the final deliverable for any assessment type.

An example of the HTML report is shown below:

It is best to always make sure the vulnerabilities are grouped together for a clear understanding of each issue and the assets affected.

Exporting Nessus Scans

Nessus also gives the option to export scans into two formats Nessus (scan.nessus) or Nessus DB (scan.db). The .nessus file is an .xml file and includes a copy of the scan settings and plugin outputs. The .db file contains the .nessus file and the scan’s KB, plugin Audit Trail, and any scan attachments. More information about the KB and Audit Trail can be found here.

Scripts such as the nessus-report-downloader can be used to quickly download scan results in all available formats from the CLI using the Nessus REST API:

gitblanc@htb[/htb]$ ./nessus_downloader.rb 
 
Nessus 6 Report Downloader 1.0
 
Enter the Nessus Server IP: 127.0.0.1
Enter the Nessus Server Port [8834]: 8834
Enter your Nessus Username: admin
Enter your Nessus Password (will not echo): 
 
Getting report list...
Scan ID Name                                               Last Modified                  Status         
------- ----                                               -------------                  ------         
1     Windows_basic                                Aug 22, 2020 22:07 +00:00      completed      
         
Enter the report(s) your want to download (comma separate list) or 'all': 1
 
Choose File Type(s) to Download: 
[0] Nessus (No chapter selection)
[1] HTML
[2] PDF
[3] CSV (No chapter selection)
[4] DB (No chapter selection)
Enter the file type(s) you want to download (comma separate list) or 'all': 3
 
Path to save reports to (without trailing slash): /assessment_data/inlanefreight/scans/nessus
 
Downloading report(s). Please wait...
 
[+] Exporting scan report, scan id: 1, type: csv
[+] Checking export status...
[+] Report ready for download...
[+] Downloading report to: /assessment_data/inlanefreight/scans/nessus/inlanefreight_basic_5y3hxp.csv
 
Report Download Completed!

We can also write our own scripts to automate many Nessus features.

Scanning Issues

Nessus is a well-known and widely used vulnerability scanning platform. However, a few best practices should be taken into consideration before starting a scan. Scans can cause issues on sensitive networks and provide false positives, no results, or have an unfavorable impact on the network. It is always best to communicate with your client (or internal stakeholders if running a scan against your own network) on whether any sensitive/legacy hosts should be excluded from the scan or if any high priority/high availability hosts should be scanned separately, outside of regular business hours, or with different scan configurations to avoid potential issues.

There are also times when a scan may return unexpected results and need to be fine-tuned.

Mitigating Issues

Some firewalls will cause us to receive scan results showing either all ports open or no ports open. If this happens, a quick fix is often to configure an Advanced Scan and disable the Ping the remote host option. This will stop the scan from using ICMP to verify that the host is “live” and instead proceed with the scan. Some firewalls may return an “ICMP Unreachable” message that Nessus will interpret as a live host and provide many false-positive informational findings.

In sensitive networks, we can use rate-limiting to minimize impact. For example, we can adjust Performance Options and modify Max Concurrent Checks Per Host if the target host is often under heavy load, such as a widely used web application. This will limit the number of plugins used concurrently against the host.

We can avoid scanning legacy systems and choose the option not to scan printers, as we showed in an earlier section. If a host is of particular concern, it should be left out of the target scope or we can use the nessusd.rules file to configure Nessus scans. More information about it you can find here.

Finally, unless specifically requested, we should never perform Denial of Service checks. We can ensure that these types of plugins are not used by always enabling the “safe checks” option when performing scans to avoid any network plugins that can have a negative impact on a target, such as crashing a network daemon. Enabling the “safe checks” option does not guarantee that a Nessus vulnerability scan will have zero adverse impact but will significantly minimize potential impact and decrease scanning time.

It is always best to communicate with our clients or internal stakeholders and alert necessary personnel before starting a scan. When the scan is completed, we should keep detailed logs of the scanning activity in case an incident occurs that must be investigated.

Network Impact

It is also essential to keep in mind the potential impact of vulnerability scanning on a network, especially on low bandwidth or congested links. This can be measured using vnstat:

gitblanc@htb[/htb]$ sudo apt install vnstat
 

Let’s monitor the eth0 network adapter before running a Nessus scan:

gitblanc@htb[/htb]$ sudo vnstat -l -i eth0
 
Monitoring eth0...    (press CTRL-C to stop)
 
   rx:       332 bit/s     0 p/s          tx:       332 bit/s     0 p/s
 
   rx:         0 bit/s     0 p/s          tx:         0 bit/s     0 p/s
   rx:         0 bit/s     0 p/s          tx:         0 bit/s     0 p/s^C
 
 eth0  /  traffic statistics
 
                           rx         |       tx
--------------------------------------+------------------
  bytes                        572 B  |           392 B
--------------------------------------+------------------
          max              480 bit/s  |       332 bit/s
      average              114 bit/s  |        78 bit/s
          min                0 bit/s  |         0 bit/s
--------------------------------------+------------------
  packets                          8  |               5
--------------------------------------+------------------
          max                  1 p/s  |           0 p/s
      average                  0 p/s  |           0 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                    40 seconds

We can compare this result with the result we get when monitoring the same interface during a Nessus scan against just one host:

gitblanc@htb[/htb]$ sudo vnstat -l -i eth0
 
Monitoring eth0...    (press CTRL-C to stop)
 
   rx:   307.92 kbit/s   641 p/s          tx:   380.41 kbit/s   767 p/s^C
 
 eth0  /  traffic statistics
 
                           rx         |       tx
--------------------------------------+------------------
  bytes                     1.04 MiB  |        1.34 MiB
--------------------------------------+------------------
          max          414.81 kbit/s  |   480.59 kbit/s
      average          230.57 kbit/s  |   296.72 kbit/s
          min                0 bit/s  |         0 bit/s
--------------------------------------+------------------
  packets                      18252  |           22733
--------------------------------------+------------------
          max                864 p/s  |         969 p/s
      average                480 p/s  |         598 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                    38 seconds
 
 
real  0m38.588s
user  0m0.002s
sys 0m0.016s

When comparing the results, we can see that the number of bytes and packets transferred during a vulnerability scan is quite significant and can severely impact a network if not tuned properly or performed against fragile/sensitive devices.

Getting Started with OpenVAS

OpenVAS, by Greenbone Networks, is a publicly available vulnerability scanner. Greenbone Networks has an entire Vulnerability Manager, part of which is the OpenVAS scanner. Greenbone’s Vulnerability Manager is also open to the public and free to use. OpenVAS has the capabilities to perform network scans, including authenticated and unauthenticated testing.

We will get started with using OpenVAS by following the installation instruction below for Parrot Security. The tool is pre-installed on the host provided in a later section.

Installing Package

First, we can start by installing the tool:

gitblanc@htb[/htb]$ sudo apt-get update && apt-get -y full-upgrade
gitblanc@htb[/htb]$ sudo apt-get install gvm && openvas

Next, to begin the installation process, we can run the following command below:

gitblanc@htb[/htb]$ gvm-setup

This will begin the setup process and take up to 30 minutes.

Starting OpenVas

Finally, we can start OpenVas:

gitblanc@htb[/htb]$ gvm-start

OpenVAS Scan

The OpenVAS Greenbone Security Assistant application has various tabs that you can interact with. For this section, we will be digging into the scans. If you navigate to the Scans tab shown below, you will see the scans that have run in the past. You will also be able to see how to create a new task to run a scan. The tasks work off of the scanning configurations that the user sets up.

Note

The scans shown in this section have already been pre-run to save you the time of waiting for them to finish. If you re-run the scan, it’s best to go through vulnerabilities as they come, instead of waiting for the scan to finish, as they can take 1-2 hours to finish.

Configuration

Before setting up any scans, it is best to configure the targets for the scan. If you navigate to the Configurations tab and select Targets, you will see targets that have been already added to the application.

To add your own, click the icon highlighted below and add an individual target or a host list. You also can configure other options such as the ports, authentication, and methods of identifying if the host is reachable. For the Alive Test, the Scan Config Default option from OpenVAS leverages the NVT Ping Host in the NVT Family. You can learn about the NVT Family here.

Typically, an authenticated scan leverages a high privileged user such as root or Administrator. Depending on the permission level for the user, if it’s the highest permission level, you’ll retrieve the maximum amount of information back from the host in regards to the vulnerabilities present since you would have full access.

Once you have added your target, they will appear in the list below:

Setting Up a Scan

Multiple scan configurations leverage OpenVAS Network Vulnerability Test (NVT) Families, which consist of many different categories of vulnerabilities, such as ones for Windows, Linux, Web Applications, etc. You can see a few different types of families shown below:

OpenVAS has various scan configurations to choose from for scanning a network. We recommend only leveraging the ones below, as other options could cause system disruptions on a network:

• Base: This scan configuration is meant to enumerate information about the host’s status and operating system information. This scan configuration does not check for vulnerabilities.
• Discovery: This scan configuration is meant to enumerate information about the system. The configuration identifies the host’s services, hardware, accessible ports, and software being used on the system. This scan configuration also does not check for vulnerabilities.
• Host Discovery: This scan configuration solely tests whether the host is alive and determines what devices are active on the network. This scan configuration does not check for vulnerabilities as well. OpenVAS leverages ping to identify if the host is alive.
• System Discovery: This scan enumerates the target host further than the ‘Discovery Scan’ and attempts to identify the operating system and hardware associated with the host.
• Full and fast: This configuration is recommended by OpenVAS as the safest option and leverages intelligence to use the best NVT checks for the host(s) based on the accessible ports.

You can create your own scan by navigating to the ‘Scans’ tab and clicking the wizard icon.

Once you click the wizard icon, the panel shown below will pop up and allow you to configure your scan.

We will configure the scan with the options below, which targets 172.16.16.160 and then run our scan, which can take 30-60 minutes to finish.

Exporting The Results

OpenVAS provides the scan results in a report that can be accessed when you are on the Scans page, as shown below.

Once you click the report, you can view the scan results and operating system information, open ports, services, etc., in other tabs in the scan report.

Exporting Formats

There are various export formats for reporting purposes, including XML, CSV, PDF, ITG, and TXT. If you choose to export your report out as an XML, you can leverage various XML parsers to view the data in an easier to read format.

We will export our results in XML and use the openvasreporting tool by the TheGroundZero. The openvasreporting tool offers various options when generating output. We are using the standard option for an Excel file for this report.

gitblanc@htb[/htb]$ python3 -m openvasreporting -i report-2bf466b5-627d-4659-bea6-1758b43235b1.xml -f xlsx

This command will generate an excel document similar to the one below:

Reporting

Soft skills in information security are critical to being successful in your role. Although vulnerability scanning tools leverage automated tools, there is still a need to transfer the information to a client-ready report. The report should be readable by anyone ranging from a technical person to a non-technical person. A strong report consists of the following sections:

• Executive Summary
• Overview of Assessment
• Scope
• Vulnerabilities and Recommendations

Executive Summary

The Executive Summary of a vulnerability assessment report is intended to be readable by an executive who needs a high-level overview of the details and what is the most important items to fix immediately, depending on the severity. This section allows an executive to look at the report and prioritize remediations based on the summary.

You can also include a graphical view of the number of vulnerabilities based on the severity here, similar to the graph below:

Overview of Assessment

The Overview of the Assessment should include any methodology leveraged during the assessment. The methodology should detail the execution of the assessment during the testing period, such as discussing the process and tools used for the project (e.g., Nessus).

Scope and Duration

The Scope and Duration section of the report should include everything the client authorized for the assessment, including the target scope and the testing period.

Vulnerabilities and Recommendations

The Vulnerabilities and Recommendations section should detail the findings discovered during the vulnerability assessment once you’ve eliminated any false positives by manually testing them. It is best to group findings that relate to each other based on the type of issues or their severity.

Each issue should have the following elements:

• Vulnerability Name
• CVE
• CVSS
• Description of Issue
• References
• Remediation Steps
• Proof of Concept
• Affected Systems

Closing

The reporting portion of any assessment is the most crucial part of the project. Always make sure you are writing your reports such that any audience can read them. When discussing technical information, always reference what you describe for the reader to understand or reproduce what you are talking about in the report. Additionally, sentences should be to the point with proper grammar as well. The strongest reports are concise and clear for a reader.