[Vulnerability management]How to manage vulnerabilities using Nmap and OpenVAS

Overview

you’ll focus on Asset Management. Asset Management ensures an organization’s assets are accounted for, maintained, and eventually disposed of. And what is an asset? Defined simply, an asset includes hardware, software, or the information an organization values. Over the next few challenges, you’ll focus on scalable ways to approach Asset Management (and Vulnerability Management). You’ll also witness how Asset Management can help you investigate suspicious behavior.

Nmap: Host Inventory Analysis

Your job is to create a network baseline (through nmap) so you can investigate future changes.

• To investigate the suspicious behavior, you need to create a network baseline. (This will allow you to witness future changes.) To create this baseline, you’ll leverage nmap to scan the subnet in question (172.31.37.0/24). At this point, you want to deduce what hosts are on the network. In other words, you're looking to perform a Host Discovery scan.

nmap -sn -T4 172.31.37.0/24

• -sn: Instructs nmap to do a Host Discovery scan. (This option will prevent a time-intensive port scan after the Host Discovery phase).
• -T4: Increases the scan speed “With a moderately fast and reliable connection between the source and target networks”

When -sn is leveraged, nmap (by default) will leverage these Host Discovery scans:

• ICMP echo request
• TCP SYN to port 443
• TCP ACK to port 80
• ICMP timestamp request

• 172.31.37.10: The main Security Information and Event Management (SIEM) system. This system analyzes various logs and creates security-related alerts.
• 172.31.37.11: A logging collector for the SIEM. Logs are sent from various hosts to this system. After initial parsing, the logging collector forwards the logs to the SIEM.

While the Nmap scan (above) was helpful, it isn’t a scalable solution.

This is where the ndiff command comes in ndiff is a utility that compares the results of two nmap scans. To leverage ndiff, you must leverage nmap’s xml format.

nmap -sn -T4 -oX $HOME/scans/first.xml 172.31.37.0/24

The xml output will be our network baseline!!

We manually trigger securityt event.

[ec2-user@ip-172-31-24-230 ~]$ cat repo/scenario_1.sh 
#!/usr/bin/env bash
ssh -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
     ubuntu@siem-log-collector.lab <<'ENDSSH'
sudo shutdown now > /dev/null
ENDSSH

• conduct the second nmap

nmap -sn -T4 -oX $HOME/scans/second.xml 172.31.37.0/24

• lets compare the both results

ndiff $HOME/scans/first.xml $HOME/scans/second.xml

[ec2-user@ip-172-31-24-230 ~]$ ndiff scans/first.xml scans/second.xml 
-Nmap 7.92 scan initiated Thu Jan 13 05:31:22 2022 as: nmap -sn -T4 -oX /home/ec2-user/scans/first.xml 172.31.37.0/24
+Nmap 7.92 scan initiated Thu Jan 13 05:36:26 2022 as: nmap -sn -T4 -oX /home/ec2-user/scans/second.xml 172.31.37.0/24
-ip-172-31-37-11.us-west-2.compute.internal (172.31.37.11):
-Host is up.

the — at the beginning of the selection (the — signifies removal). In other words, when ndiff compared second.xml to first.xml, the findings were no longer present. So at this point, you see that 172.31.37.11 was removed from the network.

Question:

So why would the SIEM’s logging collector go down? Was there a benign issue with the host? Or, is an attacker trying to hide malicious activity?

Nmap: Application Inventory Analysis

you’ll continue your Asset Management journey by increasing the thoroughness of the nmap scans. By increasing the thoroughness, you’ll be able to observe changes to externally available applications that are running on the SIEM.

What we do next ? trigger the next security event

bash $HOME/repo/scenario_2.sh
cat repo/scenario_2.sh 
#!/usr/bin/env bash
ssh -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
     ubuntu@siem-main.lab sudo docker run -d --rm --name apache-clean -p 443:443 zachroofsec/ps-lab-openvas-apache-non-vuln > /dev/null

• Lets scan

sudo nmap -O --osscan-guess -p 1-65535 -sV --version-all --script "safe" -T4 -oX $HOME/scans/third.xml 172.31.37.0/24

• -O: Enable OS detection.
• If an OS is unexpectedly replaced, this could indicate suspicious behavior.
• sudo is needed for this type of scan.
• — osscan-guess: Will increase the aggressiveness of the OS detection.
• -p 1–65535: Will scan all ports on any hosts that are discovered. With this addition, you’ll be moving away from the default Host Discovery scan settings. (You are now trying to observe all ports on any discovered hosts).
• -sn: If you look closely, you’ll notice this flag is no longer used! (This flag instructs nmap to only do Host Discovery scans.) If you leveraged this flag, it would conflict with the port scan flag (above).
• -sV: Will probe open ports to determine service/version information. This would help you witness if software was downgraded to a vulnerable version or if any unexpected services are being leveraged.
• — version-all: Try every single service/version probe
• — script “safe”: This will leverage the “safe” Nmap scripts to probe for additional information. If you use this option, you can prevent crashing services, using large amounts of resources and exploiting security holes

• Apache httpd:the SIEM’s management portal.
• OpenSSH:the log collector uploads logs (to the SIEM) through this service.
• Now trigger intentional security events

bash $HOME/repo/scenario_3.sh

[ec2-user@ip-172-31-24-230 ~]$ cat repo/scenario_3.sh 
#!/usr/bin/env bash
ssh -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
     ubuntu@siem-main.lab <<'ENDSSH'
sudo docker stop apache-clean > /dev/null
sudo docker run -d --rm --name apache-infected -p 443:443 zachroofsec/kube-hunter-tutorial > /dev/null

• you’ll execute nmap to see if the baseline changed.

sudo nmap -O --osscan-guess -p 1-65535 -sV --version-all --script "safe" -T4 -oX $HOME/scans/fourth.xml 172.31.37.0/24

• lets see the difference between third and fourth

[ec2-user@ip-172-31-24-230 ~]$ ndiff scans/third.xml scans/fourth.xml 
-Nmap 7.92 scan initiated Thu Jan 13 06:16:26 2022 as: nmap -O --osscan-guess -p 1-65535 -sV --version-all --script safe -T4 -oX scans/third.xml 172.31.37.0/24
+Nmap 7.92 scan initiated Thu Jan 13 06:22:13 2022 as: nmap -O --osscan-guess -p 1-65535 -sV --version-all --script safe -T4 -oX scans/fourth.xml 172.31.37.0/24
ip-172-31-37-10.us-west-2.compute.internal (172.31.37.10):
 PORT    STATE SERVICE  VERSION
-443/tcp open  ssl/http Apache httpd 2.4.25 ((Debian))
+443/tcp open  ssl/http Apache httpd 2.4.10 ((Debian))
+|  ssl-heartbleed: 
+|    VULNERABLE:
+|    The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
+|      State: VULNERABLE
+|      Risk factor: High
+|        OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
+|            
+|      References:
+|        http://cvedetails.com/cve/2014-0160/
+|        http://www.openssl.org/news/secadv_20140407.txt 
+|_       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
 OS details:
-  Linux 3.10 - 3.13
-  Linux 3.8
   Linux 3.1
   Linux 3.2
   AXIS 210A or 211 Network Camera (Linux 2.6.17)
+  Linux 3.10 - 3.13
+  Linux 3.8
   ASUS RT-N56U WAP (Linux 3.4)
   Linux 3.16
   Adtran 424RG FTTH gateway
   Linux 2.6.32
   Linux 2.6.39 - 3.2
ip-172-31-37-11.us-west-2.compute.internal (172.31.37.11):
 OS details:
-  Linux 3.10 - 3.13
-  Linux 3.8
   Linux 3.1
   Linux 3.2
   AXIS 210A or 211 Network Camera (Linux 2.6.17)
+  Linux 3.10 - 3.13
+  Linux 3.8
   ASUS RT-N56U WAP (Linux 3.4)
   Linux 3.16
+  Adtran 424RG FTTH gateway
   Linux 2.6.32
   Linux 2.6.39 - 3.2
-  Linux 3.1 - 3.2
[ec2-user@ip-172-31-24-230 ~]$

• the Apache version changed from version 2.4.25 to 2.4.10.
• the Apache server is now vulnerable to Heartbleed!

Nmap: Closed-box Limitations

you’ll learn about closed-box and open-box testing.

[ec2-user@ip-172-31-24-230 ~]$ cat repo/scenario_4.sh 
#!/usr/bin/env bash
ssh -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
     ubuntu@siem-main.lab <<'ENDSSH'
sudo docker stop apache-infected > /dev/null
sudo systemctl start apache2 > /dev/null
ENDSSH

• lets run this

bash $HOME/repo/scenario_4.sh

• lets scan

sudo nmap -O --osscan-guess -p 1-65535 -sV --version-all --script "safe" -T4 -oX $HOME/scans/fifth.xml 172.31.37.0/24

• This command will ssh into the SIEM host, query the SIEM’s package manager (dpkg), and then output the currently installed version of OpenSSL.

ssh -o StrictHostKeyChecking=no ubuntu@siem-main.lab sudo dpkg-query -l | grep ' openssl '

the version of OpenSSL that is installed (1.0.1e-2). In an earlier section, you learned that OpenSSL versions 1.0.1 through 1.0.1f (inclusive) are vulnerable. Clearly, 1.0.1e-2 is vulnerable to Heartbleed!

When you perform Asset Management, you want to collect data through multiple perspectives. When you gather information from inside a system, you’re performing open-box testing. In other words, the internals of a system are being tested directly. In contrast, the nmap scans are an example of closed-box testing. In other words, the internals of the system are being tested indirectly.

While open-box testing can be more accurate, it can also be more complicated. For example, to gain the additional visibility, you usually need to install an agent (across all hosts). Or, if an agent isn’t leveraged, you’d need to authenticate to the system to observe its internals. While closed-box testing can be less accurate, it is often easier to configure. Additionally, this technique takes the perspective of the attacker. So if a closed-box scan uncovers a major vulnerability, it should be fixed immediately.

OpenVAS: Open-box Vulnerability Testing

OpenVAS can perform open-box and closed-box tests.

• Navigate to and enter the console

chromium-browser --allow-insecure-localhost https://localhost > /dev/null 2>&1 &

• lets configure a task.

summary

A common objective of attackers is to implant a persistence mechanism (i.e., backdoor) that allows for future access. This persistence mechanism can take the form of a Command and Control implant (or some other rogue software program). However, if this implant is discovered, the Security Team would have a clue of compromise. On the other hand, if a vulnerable version of a “normal” program is discovered (e.g., OpenSSL’s Heartbleed), it might not create as much suspicion. a solid Asset Management practice can help discover these compromises as well as flag other suspicious activity.