Hello Cybersecurity enthusiasts, today I’m going to showcase a demo of a project which involves scanning vulnerabilities using Nessus. Now for the ones who don’t know what Nessus is, it is a vulnerability scanner used to scan a network / IP / domain to map any existing vulnerabilities to the already discovered ones out there.

Note: Using Nessus on any network / IP/ domain without having proper permission is illegal!! So in this blog, I’m going to show you running this scanner against Metasploitable 2 which is a vulnerable machine and is usually used for penetration testing purposes.

Prerequisites: A Kali Linux Virtual Machine (This is inevitable), A Metasploitable 2 Virtual Machine (Here is the link to download one: Download Metasploitable 2)

Installing Metasploitable 2

Now, I’m going to picture the setup of Metasploitable 2 as it is somewhat tedious (really it took me one hour to set it up properly).

Step 1) Download and extract the Metasploitable 2 (I will refer this as M2 from now on) VM.

Step 2) Download VirtualBox and create a new machine with these specifications:

Step 3) Click next and keep the default config for hardware as it is. Click next again and select this option:

Select the folder option to select a file and add this file to your list from extracted M2 folder:

Step 4) Choose the Metasploitable vmdk file and click next and on the final confirmation page click finish.

Step 5) Before we run this machine, click settings on the machine which you created a while ago and go to network tab. Change the network settings from NAT to Bridged Adapter. The reason behind the change is that our Kali VM can directly find and interact with M2 on the same network.

Now run the M2 VM that is created in your VirtualBox. After it is loaded properly you should see something like this:

The login username/password is: msfadmin/msfadmin (Yes they are the same don’t get confused!).

Now it finally we have our M2 machine ready with us, but wait where is the IP address which we need to scan? For this run ip a OR ifconfig command and you should get results like this:

Output for ip a:

Output for ifconfig:

The IP address of my machine is 192.168.2.29 (This IP address will vary from user to user)

Now we are just a few steps away from scanning M2 to find out vulnerabilites! The next step will be to open your Kali Linux VM and go to Firefox and follow these steps:

Step 1) Download the Nessus package for Debian on the Nessus website and make sure you set the Platform to Linux-Debian-amd64.

Step 2) When it’s finished downloading, open your Linux terminal and navigate to the directory where you downloaded the Nessus file.

Step 3) You need to be the superuser in order to execute the command so type the following to install Nessus from the .deb file:

sudo dpkg -i Nessus-<version number>-debian6_amd64.deb

Step 4) The next step will be to run Nessus. To do so type the following:

systemctl start nessusd

Note: If you’ve previously used Nessus, you may get an error stating you have a corrupt database. To fix this, you need to kill the service using service nessusd stop , remove all Nessus files, download the latest version, and install it again. To delete all files for a clean re-install, use the following command in the terminal: rm -rf /opt/nessus (recursively remove everything in the Nessus directory, opt/nessus)

Step 5) On your browser, go to https://kali:8834/. It would show a warning page.

6. Click on Advanced. Then, click on Accept Risk and Continue.

7. In this project I will be using Nessus Essentials, so I have selected the option accordingly if you wish to go for professional version you can select the third option and go ahead!

Step 8) Getting the activation code:

POV: You don’t really need to give your real email ID and name to get the activation code. Head over to temporary mail and get a temporary fake email. I’m suggesting this option because there are numerous data breaches happening around us. If you don’t want your identity to be disclosed, you can choose this path to get an activation code, and it does work!

Paste the activation code into the space provided and choose a username and password.

Click SKIP in next page as you already registered.

Step 9) After entering the activation code, Nessus will take 5–10 minutes to download and compile its plugins — perfect time to grab a coffee! This process equips the tool with the latest vulnerability checks.

Once complete, you’ll reach the dashboard. Nessus will then download its core essentials, which might take longer depending on your internet speed and Kali VM’s RAM. Stay patient — it’s worth it for the results!

Now we can see our dashboard:

This image will be different for you as you didn’t perform a scan yet, whereas I did. Now let’s head over and click the new scan option and enter your details of the target and scan name (Target will be your M2's IP).

Now on top of this, change some more settings as shown below to get some more results (This involves selecting UDP for Host Discovery, collecting identity data from Active Directory in the identity tab, and scanning for malware in the assessment section!):

Before saving it double check the target IP address to make sure you are not targeting someone else! Run the scan and wait for 5–10 minutes and click the scan after it is completed.

If you did everything as I stated above, you should have discovered 10 Critical, 5 High, 25 Medium and 8 Low level Vulnerabilities!

This doesn’t end here the last task is to generate a pdf report of the vulnerabilities we got by scanning M2.

Click the report button as you can see in the above screenshot and generate a report by PDF that lists Detailed Vulnerabilities by host. Generate the report and now you will have a report that is more than 200 pages listing all the known vulnerabilities that Nessus found in M2.

Some of the critical ones are listed below with what they are and how to mitigate them:

1) Apache Tomcat AJP Connector Request Injection (Ghostcat) (Plugin 134862)

• Issue: A file read/inclusion vulnerability was found in AJP connector. A remote, unauthenticated attacker could exploit this vulnerability to read web application files from a vulnerable server. In instances where the vulnerable server allows file uploads, an attacker could upload malicious JavaServer Pages (JSP) code within a variety of file types and gain remote code execution (RCE)
• Mitigation: Update Tomcat to 7.0.100, 8.5.51, 9.0.31, or later; restrict AJP access with authentication.

2) Bind Shell Backdoor Detection (Plugin 51988)

• Issue: A shell is listening on the remote port without any authentication being required. An attacker may use it by connecting to the remote port and sending commands directly
• Mitigation: Verify if the host is compromised and shut down the service on the open port.

3) Canonical Ubuntu Linux SEoL (Plugin 201352)

• Issue: According to its version, Canonical Ubuntu Linux is 8.04.x. It is, therefore, no longer maintained by its vendor or provider. Lack of support implies that no new security patches for the product will be released by the vendor. As a result, it may contain security vulnerabilities.
• Mitigation: Upgrade to a version of Canonical Ubuntu Linux that is currently supported.

4) Debian OpenSSL RNG Weakness (Plugins 32314, 32321)

• Issue: The remote SSH host key has been generated on a Debian or Ubuntu system which contains a bug in the random number generator of its OpenSSL library. The problem is due to a Debian packager removing nearly all sources of entropy in the remote version of OpenSSL. An attacker can easily obtain the private part of the remote key and use this to set up decipher the remote session or set up a man in the middle attack.
• Mitigation: Regenerate all cryptographic material (SSH, SSL keys) on a patched system and update OpenSSL.

5) SSL Version 2 and 3 Protocol Detection (Plugin 20007)

• Issue: The remote service accepts connections encrypted using SSL 2.0 and/or SSL 3.0. These versions of SSL are affected by several cryptographic flaws, including:- An insecure padding scheme with CBC ciphers.- Insecure session renegotiation and resumption schemes. An attacker can exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients.
• Although SSL/TLS has a secure means for choosing the highest supported version of the protocol (so that these versions will be used only if the client or server support nothing better), many web browsers implement this in an unsafe way that allows an attacker to downgrade a connection (such as in POODLE).
• Therefore, it is recommended that these protocols be disabled entirely. NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC’s definition of ‘strong cryptography’
• Mitigation: Disable SSLv2/v3; configure services to use TLS 1.2 or higher with strong ciphers.

Thank you for reading this blog. I hope this blog was able to add some value to your knowledge of Vulnerability Management!