The Hosts Summary (Executive) section will include the count of vulnerabilities against each critical category along with a summarized details of each vulnerability; this includes the following:

The following screenshot displays a sample report showing the host's summary:

The Vulnerabilities By Host section of the report gives a summary of the vulnerability findings per host. The Summary gives details about the scan running time, basic details about the host scanned, and the count of the number of vulnerabilities grouped together by the critical rating.

The following screenshot is a sample report showing the host's summary:

The preceding screenshot displays the Vulnerabilities By Host option with the following sections:

The following table lists the CVSS scores based on the vulnerability rating used by Nessus. As explained earlier in this chapter, the rating reported by Nessus can be analyzed further as follows:

The Vulnerabilities By Plugin section contains all the relevant details about the vulnerability. The following section displays a screenshot with the details captured for describing the vulnerability, along with a brief explanation of each field.

The following screenshot is for illustration purposes only; additional reference links and Common Vulnerability and Exposures (CVE) have been removed:

The following screenshot displays References and the CVSS Base Score in the report:

The following screenshot displays the Plugin Information section:

The vulnerability details which are captured in the preceding screenshots are as follows:

The following are the basic understandings of an organization that will aid in the false positive analysis:

In case of a large number of vulnerabilities, at least the most critical ones should be cross-verified for a false positive before being reported.

If there is access to servers/devices on which the VA scan is conducted, vulnerabilities can be crosschecked by logging in to the server or by trying to put a proof of concept against the vulnerability. For example, if the vulnerability states that a clear text File Transfer Protocol (FTP) or Telnet service is running in the server, we can either log in to the server to crosscheck if these services are actually running, or give a proof of concept by trying to connect FTP or the Telnet protocol from the testing machine.

Open source scanning tools such as Nmap can also be used to enumerate the infrastructure again for open vulnerabilities to cross-check the findings of the VA report.

As effort estimation is a time consuming activity, additional efforts and resources should be considered to include the removal of a false positive. Also, based on the size and nature of engagement, a practical call should be taken to define the extent to which this activity will be done.

The second section of this chapter details false positive analysis.

Risk severity is the severity of the risk associated with each vulnerability, depending on the environment and nature of the business. Risk severity can be quantitative or qualitative. Generally, it is preferred, and industry-wise recognized, to use risk severity as qualitative. Risk can be categorized as Critical, High, Medium, Low, and Info. A few organizations categorize them only as High, Moderate, and Low.

Most of the large-enterprise organizations that go through different security certifications, such as ISO 27001, have their risk management process defined. These risk management processes define their risk severities as well as their definitions, risk matrix, risk acceptance criteria, and so on. While performing a vulnerability assessment, you may need to recategorize the risk severity ratings if you follow the risk matrix.

For example, vulnerability on the public website of an organization that is running without SSL. This vulnerability might be declared to have a High risk rating by a vulnerability scanner, where-as, if you do a vulnerability analysis, it may declare a different risk level.

Let's take a scenario where you are doing a vulnerability assessment for a small NGO; they have no sensitive information on their website and the vulnerability of SSL is discovered. All information available on the website is public. In this scenario, you may say the vulnerability risk rating is Low or Info, whereas the scanning tool might report it as High.

In a different scenario, where you are doing vulnerability assessment for a medium-sized firm which does surveys on their website and public reports, the same vulnerability of SSL is discovered. Most of the information recorded here is confidential and should not be compromised. In this scenario, you can say that the vulnerability risk rating is Medium or High and will be rated as High by the scanning tool.

Another scenario where you are doing a vulnerability assessment for a large bank, which has net banking login on their website. Bank customers log in to use the net banking service and do their financial transactions; again, the same SSL vulnerability is discovered. In this case, if SSL is not implemented, this is a critical risk rating vulnerability, and the tool will report it as High.

It is very important for us to relook at the risk ratings given by vulnerability scanningtools if we want to treat risks based on their risk ratings.

Each vulnerability discovered by vulnerability assessment tools may not be applicable to the organization. Vulnerability applicability is used for checking if the vulnerability reported by an automated vulnerability-assessment tool is applicable to the organization or not.

For example, vulnerability such as a weak password existing in an application. This vulnerability might be declared to have a High risk rating by a vulnerability scanner, where-as, if you do vulnerability applicability analysis, it may be declared as not applicable.

Let's take a scenario where you are doing the vulnerability assessment of a small organization. The vulnerability scanner reports weak password vulnerability for an application. It is found by the tool that some of the passwords for that application were only seven-characters long, which is reported as a High risk severity vulnerability. While doing an applicability analysis, we found that the organization has approved a security password policy that considers a password as strong even if it is seven-characters long; hence, this vulnerability is not applicable to the organization.

It is important to relook at the risks and see if they are really applicable for the organization or not.

Nessus gives fix recommendations in the tool-generated report for each vulnerability. A few of them can be fixed using multiple ways, for instance, by using compensatory controls. A vulnerability can be patched or fixed in multiple ways.

Let us illustrate this through a sample vulnerability. A vulnerability such as the cleartext protocol FTP is found open on a server. The fix usually recommended is used as a secured protocol for file transfer such as Secure File Transfer Protocol (SFTP). Another solution may be to analyze the requirement of having FTP open. There might be a case where FTP was left open during testing; now even in production, FTP is open and is no longer in use. In this case, the FTP port should be closed on that server. In this scenario, we see that for the same vulnerability there are two fixes: one is to use SFTP instead of FTP, another is to close the FTP port. Likewise, it is recommended to apply the fixes wisely.

A vulnerability title is of the first example is a Cross-site scripting (XSS) found on an application homepage.

Let's take a scenario where the vulnerability scan resulted in a vulnerability of XSS for one of the applications scanned while running on a target host. Details for the XSS are given in the following Nessus report, reflecting on which application the page vulnerability exists:

Once a cross-site scripting is reported by a vulnerability scanner, and if you are engaged to conduct penetration testing for that machine, you are required to further penetrate the vulnerability. This can be done by running malicious scripts, to do the proof of concept, and by exploitation.

Cross-site scripting, which is also known as XSS, can either be in an input parameter that takes some input in the URL or be in one of the input boxes on the web application. To exploit it, you need to tamper the end user's input that goes in the parameter which further displays the same input. You may want to use a tools such as Burp Suits, Bayden Tamper IE, or any other HTTP traffic interceptor. By using the interceptor, you can fiddle with the HTTP request going from the client machine to the server.

To test if XSS exists or not, the following sample payloads can be used as input to the end user's input parameters:

<script>alert("XSS Exist")</Script>
"><script>alert("XSS Exist")</Script>

The preceding payloads need to be tweaked based on the code which you are exploiting.

To penetrate further, you can use the following sample payloads:

<script>alert(document.cookie)</script>
onmouseenter="alert(document.cookie);
onreadystatechange="alert(document.cookie);

This will pop up the live cookie details on the screen, as shown in the following screenshot:

In case of persistent XSS, where end user inputs get stored in the database and are displayed again for all users from the database while browsing the application page. You should try the following payload, which creates a hyperlink on the web page, which will redirect the user to the attacker's website:

http://TargetIP:8080/ShowingImage.asp?id=<img%20src="http://attackerURL.com/images/1/419979.JPG">
<a href = "http://www.attackerURL.com">click</a>

XSS can be exploited further with a deep understanding of scripts and coding.

The vulnerability title for the second example is exploitation of weak or easily guessable passwords found on the router.

Nessus has the capability to review Cisco device configurations against industry's best practices. One of the common vulnerabilities, which can be observed when the administrator has not carefully configured the Cisco device, is using default or weak passwords.

Cisco Internetwork Operating System (Cisco IOS) is the operating system for Cisco network devices such as routers and switches. We will take the example of a router for illustration purposes. The Cisco router configuration files have all the relevant configurations for the router to perform it's routing functionality in the network.

Cisco IOS provides an option to set different types of password: type 0 typically means a password with no encryption, type 7 means a password encrypted using service password encryption command, which uses a proprietary algorithm, and type 5 means the password is protected with the enabled-secret command, which uses MD5 hashing in the configuration. When we see type 5 or type 7 passwords in the Cisco router configuration, they will appear as encrypted.

A Cisco type 7 password is not considered to be safe, as it is encrypted using a weak algorithm, and can be cracked.

While scanning the Cisco router configuration by providing credentials with appropriate privileges, Nessus will highlight the use of a weak password.

It can be exploited once the Nessus report highlights the use of a weak type 7 password and can be cracked further using one of the many freeware utilities available on the Internet. For demonstration purpose, following URL is used:

http://www.ibeast.com/content/tools/CiscoPassword/index.asp

If the Nessus highlight uses of weak or type 7 passwords post scanning of the Cisco router; we have used a type 7 password used in our example ( 0822455D0A16 ).

If we take this password and use the preceding link to crack it, within a few seconds we will come to know that the default password, that is, cisco, has been used.

In the following screenshot, we enter a type 7 password in a commonly available password cracking tool:

The following screenshot displays the tool giving the output (cracked password):

The vulnerability title for the third example is possible SQL Injection.

SQL Injection is an application vulnerability which can be discovered by Nessus. SQL Injection allows an attacker to inject or run a malicious SQL command by which the attacker directly communicates with the database running behind the application and executes the SQL queries. This can be as destructive as running an fdisk command on a database server which will completely format the server, and creating a local admin on the server will compromise the server in all aspects. This also allows an attacker to run extended stored procedures, which are very powerful commands. By running malicious SQL queries, the attacker can modify the input strings that form the SQL queries in such a way that the outputs will reveal the required schema and data from the database.

When a SQL Injection vulnerability is reported by the vulnerability scanner and you are engaged in doing a penetration test, you need to exploit it further.

The following is the process for exploitation:

On the application login page, where the username and password need to be entered, use the input injections, mentioned in the following table, to check if a SQL Injection really exists for that particular page:

All exploits are unique in nature, hence, I recommend to construct your injections, scripts, and payloads depending on your target machine.