5.2 OpenStack Penetration Testing
5.2.1 External Pentesting
For experimentation, the Kali Linux installed externally is the "Kali Linux custom image" provided by Offensive Security3and the image version used was"Linux kali 4.3.0-kali1-amd64 #1 SMP Debian 4.3.3-7kali2 (2016-01-27) x86_64 GNU/Linux".
In this scenario, the Test tenant is the attacker, who has prior information about the cloud URL (http://192.168.137.10/horizon) and the floating IP addresses – the External network - of the Test two VM instances in the cloud: 192.168.100.11 and 192.168.100.16
The OpenStack External Penetration testing was the first attempt in using the pentesting methodology and therefore several commands were executed as an initial test drive; nmap, TCPdump and amap, Fping. After comparing the results with what we found using Zenmap and Sparta the test-drive tools were very limited. However, the test drive provided a good view of the live host on the pre given network range other than what the Test tenant already knew. For example, the Test tenant knew that the IP address 192.168.37.10 had been used to access the web dashboard. The test drive tools revealed another active IP, 192.168.137.11, in the cloud management network, and five other active IPs within the external/public network. These were later used as another input for Zenmap and Sparta.
5.2.1.1 Zenmap output
Zenmap uses nmap as a scanner with a profile name of“Slow Comprehensive Scan”. This is translated Zenmap to the following nmap statement after including the targeted network of the management network, see Figure 5.2:
nmap -sS -sU -T4 -A -v -PE -PP -PS80 ,443 -PA3389 -PU40125 -PY -g 53 --script "default or (discovery and safe)" 192.168.137.10-11
Despite zenmap providing a list of nmap statements, we used the Slow Comprehensive Scan as it is uses the full capability of nmap and guaranteed that no useful information was lost. The summary of the analysis of the output is presented in Table 5.1.
Table 5.1 presented only two active IP addresses in the management network: 192.1638.137.10 and 192.168.137.11. Each IP address listed several open ports using TCP and UDP, where some
Host IP Port Service Version
192.168.137.10
22/TCP SSH OpenSSH 6.6.1p1 Ubuntu
2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
3306/TCP MYSQL MYSQL
5000/TCP HTTP Apache HTTPd 2.4.7 ((Ubuntu))
67/UDP DHCPs ?
123/UDP NTP NTP v4 (secondary server)
192.168.137.11
22/TCP SSH OpenSSH 6.6.1p1 Ubuntu
2ubuntu2.8 (Ubuntu Linux; protocol 2.0) 5900/TCP VNC VNC (protocol 3.8) 5901/TCP 5902/TCP 5903/TCP 67/UDP DHCPs ?
123/UDP NTP NTP v4 (secondary server) Table 5.1: Zenmap Analysis of Openstack Management Network 192.168.3137.0/24
ports are of interest and others are not, hence we choose to ignore the latter. For example, the IP address 192.168.137.10 listed the ports 3306/TCP for MySql service, 5000/TCP for HTTP (cloud dashboard) service and 123/UDP for the NTP service. Those ports are needed for the OpenStack packages that are vital for the installation of the OpenStack testbed as illustrated in Chapter 3. Additionally, port 67/UDP, which listens to the PHCP service, was ignored as although it was discovered via the cloud network IP, it was not relevant to the cloud system as it belongs to the network range 10.0.0.0/24 as shown in Figure 5.2. Zenmap didn’t specify the OS of the node other than noting it was Linux. Port 22/TCP, associated with the SSH service, was ignored as it was open by default within the OS. However this port along with the HTTP port specifically indicates that the system is an Ubuntu Linux distribution. Hence, from the ports belonging to 192.168.137.10 a conclusion could be made that this IP belongs to the OpenStack Controller Node.
Logically, every cloud needs a hypervisor node and as there is only one IP remaining on the management network, Table 5.1 also shows the first IP traces of services run in the Controller Node. The second IP address can be presumed to belong to the Hypervisor (Compute Node).
Looking at the second IP address in the table and the associated open ports, this confirms our assumption. The port ranges of 5900/TCP – 5903/TCP belong to VNC service, which as explained above is used for remotely controlling the VMS inside the cloud. There are four VNC ports open, which indicated that there are four VMs running inside the cloud. At this point it was concluded that VNC ports are resident in the Compute Node, however we had no knowledge of which port belongs to which VM and who owns each VM. On that note, Zenmap flagged a warning on the VNC ports as there is no security type applied and the ”Server does not require authentication”. As in the Controller Node, we ignored the DHCP ports and we used SSH to identify the OS of the Compute Node to be Ubuntu Linux.
As the attacker is a tenant of the cloud, they have preliminary information about the two addresses of the public ranges. These belong to the Test tenant’s two VMs, 192.168.100.11 and 192.168.100.16, which are used to access the instances remotely via the SSH protocol. Zenmap exposed additional addresses as listed in Table 5.2.
Host IP MAC Port Service Version
192.168.100.10 FA:16:3E:D0:0E:A9 68/UDP DHCPC 1124/UDP pvmmcontrol 1646/UDP radacct 5002/UDP rfe 16974/UDP unknown 17533/UDP unknown 18994/UDP unknown 19039/UDP unknown 19936/UDP unknown 22029/UDP unknown 28973/UDP unknown 49174/UDP unknown 192.168.100.11 FA:16:3E:D0:0E:A9 22/TCP SSH Dropbear SSHD 2012.55 (protocol 2.0) 192.168.100.12 FA:16:3E:5A:08:14 192.168.100.13 FA:16:3E:61:6B:F7 192.168.100.14 FA:16:3E:5A:08:14 22/TCP SSH Dropbear SSHD 2012.55 (protocol 2.0) 192.168.100.15 FA:16:3E:61:6B:F7 22/TCP SSH Dropbear SSHD 2012.55 (protocol 2.0) 192.168.100.16 FA:16:3E:D0:0E:A9 22/TCP SSH (closed)
Table 5.2: External Pentesting Zenmap Analysis of Openstack External Network 192.168.100.0/24
One thing to be noted after analyzing the information collected from Zenmap on the public network range is that there are seven active IP addresses and only three physical addresses. Several Public IP addresses share the same physical address. For example, the IP addresses 192.168.100.10, 192.168.100.11 and 192.168.100.16 share the physical address
FA:16:3E:D0:0E:A9 and those belong to the Test tenant. Therefore, it was concluded that at least there are another two tenants active in the cloud. The tenant’s own resources are the IP addresses 192.168.100.12 and 192.168.100.14 because they share the MAC address FA:16:3E:5A:08:14. However, the other tenant owns 192.168.100.13 and 192.168.100.15 as they share the MAC address FA:16:3E:61:6B:F7. From the pre-knowledge we know that 192.168.100.11 is a Test VM which uses SSH to connect the VM from outside, while 192.168.100.16 is a VM reserved for internal testing. Test does not require an external connection to it as SSH is closed. Based on this we can assume that the other tenant IPs with SSH ports open might be the tenant’s own IPs, however this is not confirmed at this point. At this level the resources with IP that do not show any open ports are still unknown in nature. The Test tenant knows of 192.168.100.10 as it is the vRouter connecting the Test VN. Table 5.2 shows numerous unknown ports other than DHCP, whose purpose we do not know at this stage.
Figure 5.3:Zenmap External Pentesting Output Graphical Representation of OpenStack Cloud Active Resource Topology.
Zenmap provides a graphical representation of the scanned system based on the scans run. Figure 5.3 represents the OpenStack resources found and listed in Tables 5.1 and 5.2 by running two nmap scans on the OpenStack Cloud Networks 192.168.137.0 and 92.168.100.0. Their location was graphically represented by the network distance found using the traceroute command within each nmap script scan. Finally, IP address 192.138.100.15 is not part of the test as it is the address of the External Kali Linux where the Zenmap scan was launched. The targets, which are colour coded, represent how risky they are due to their open ports; 192.168.137.10 is represented
by yellow to indicate that it contains between 3-6 open ports, while 192.168.137.11 is the riskiest as the Zenmap red colour code means the target contains over 6 open ports.
Using Zenmap, open ports and active and physical addresses can be collated and unknown resources or links noted.
5.2.1.2 Sparta Output
Sparta uses the nmap scanner as the initial action using preliminarily input from the pentester/at- tacker and the outputs are used further by other phases of testing with tools within Sparta, such as nikto, hydra and others. Sparta runs nmap in five stages, each with its own list of port scanning and options, and results from each stage are accumulated and used to run further tests. There are no additional IP addresses found by Sparta that are not found by Zenmap and all ports found by Zenmap were found by Sparta. However, Sparta exposed more ports that were not visible by Zenmap, especially those marked as filtered or open filtered. Due to the long list of ports provided by Sparta for each targeted IP listed in Tables 5.1 and 5.2, the findings are summarised in Table 5.3.
IP address/
Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 Ports per stages
192.168.137.10 80 3306, 137, 161, 162, 1434 500, 5060 4369, 5000, 5672, 6080, 8774, 8775, 9191, 9292, 9696, 11211, 25672 35357 192.168.137.11 161, 162, 1434 500, 5060 5900, 5901, 5902, 5903 192.168.100.10 192.168.100.11 80, 443 25, 135, 137, 139, 445, 1433, 3306, 5432, 137, 161, 162, 1434 21, 22, 23, 110, 111, 2049, 3389, 8080, 500, 5060 192.168.100.12 192.168.100.13 192.168.100.14 80, 443 25, 135, 137, 139, 445, 1433, 3306, 5432, 137, 161, 162, 1434 21, 22, 23, 110, 111, 2049, 3389, 8080, 500, 5060 192.168.100.15 80, 443 25, 135, 137, 139, 445, 1433, 3306, 5432, 137, 161, 162, 1434 21, 22, 23, 110, 111, 2049, 3389, 8080, 500, 5060 192.168.100.16 80, 443 25, 135, 137, 139, 445, 1433, 3306, 5432, 137, 161, 162, 1434 21, 22, 23, 110, 111, 2049, 3389, 8080, 500, 5060
Table 5.3: Sparta: External Pentesting Analysis of OpenStack Management Network 192.168.137.0/24 and External Network 192.168.100.0/24
more were ports found by Sparta. This result confirmed the doubts raised in Zenmap with regard to whether or not these were VMs or other components. We know that 192.168.100.11 and 192.168.100.16 are the Test VMs and Table 5.3 shows the pattern of ports found in each stage of Sparta’s five test stages. The Test VMs match the ports found in 192.168.100.14 and 192.168.100.15. Hence, we confirm that both targets are VMs and they belong to different tenants as found in Zenmap through the shared MAC addresses. However, unlike Zenmap, which exposed some unknown ports related to 192.168.100.10, Sparta did not discover any ports related to the targets 192.168.100.10, 192.168.100.12 and 192.168.100.13. To our knowledge 192.168.100.10 is related to the Test vRouter, however this did not provide us with information about the other IPs represented by other tenant’s vRouter.
Another Sparta finding is related to the target 192.168.137.11 and ports found in the stage four scan. Sparta confirmed the warning raised by Zenmap related to the VNC ports (5900, 5901, 5902, 5903), and the lack of security for authentication. Sparta uses an embedded tool called VNCViewer that takes the exposure a step further than Zenmap, and viewed the active VMs in the cloud through the VNC ports. This is shown in Table 5.4
VNC Port Desktop Name Tenant Username/ Password
Information collected
Command Values
5900 instance-00000004 Test Root/toor
IP a Eth0: 10.190.0.7MAC: fa:16:3e:00:ca:d3 IP route GW: 10.190.0.1 Hostname KaliLight
5901 instance-00000001 Test Cirros/ cubswin:)
IP a Eth0: 10.190.0.6MAC: fa:16:3e:62:a6:c3 IP route GW: 10.190.0.1 Hostname my_first_instance
5902 instance-00000003 Unknown Cirros/ cubswin:)
IP a Eth0: 192.168.20.3MAC: fa:16:3e:05:a6:8e IP route GW: 192.168.20.1 Hostname T1u2vm
5903 instance-00000002 Unknown Cirros/ cubswin:)
IP a Eth0: 192.168.10.3MAC: fa:16:3e:aa:8b:b8 IP route GW: 192.168.10.1 Hostname T1u1vm
Table 5.4:Sparta: VNCViewer Finding from VNC Ports in the Target 192.168.137.11.
Sparta VNCViewer is used on each VNC port on the Compute Node to access the cloud’s VMs remotely and found the following:
• Ports 5900 and 5901 belong to the Test tenant VMs, where the attacker knows their credentials as well as the network details and host name. See Figures 5.4 and 5.5.
but the credentials are given in the login prompt as well as the host name as in Figures 5.6 and 5.7.
• Both the other tenant VMs were created from the sample image provided by the cloud platform for testing and this is a possible lack of awareness of the tenant case. The effects of this are noted in Chapter 6.
• Guessing the credentials provides an increased chance of learning about other tenants’s network details, which matches the information in the DeepDive in Chapter 3, such as IP address, MAC address and gateways as presented in Table 5.4 and Figures 5.4 - 5.7.
Figure 5.4:VNCViewer of instance-00000004.
Figure 5.6:VNCViewer of instance-00000003.
Figure 5.7:VNCViewer of instance-00000002.
Therefore, using Sparta allows an identification of infrastructure components and an understand- ing of tenant address values and names.
5.2.1.3 Nessus Output
Nessus is an "open source network vulnerability"[132] assessment tool [136][135]. Nessus is a toolkit providing several scanners, plugins, compliances, policies, scans and reports[131] [134][133]. The version used here for the External Kali Linux tests uses Nessus version "Nessus- 6.10.3-debian6-amd64.deb"4.
The Nessus test is the longest test in our penetration test, due to the limited information the scans could find from the cloud. We ran as many scans as possible and then analyzed the findings. We created 30 Nessus policies, and from these policies 60 scans were created to cover
both 192.168.137.0/24 and 192.168.100.0/24 networks. Some of these scans revealed classified vulnerabilities as critical, medium and low and some revealed none. The Tables 5.5 and 5.6 show the Nessus scan results along with the targets and the number of classified vulnerabilities in each target.
S.Q Scan Targets
Vulnerabilities
Critical High Medium Low 1 Basic Network Scan: All Ports 192.168.137.0 192.168.137.10192.168.137.11 2 41 22 3 Basic Network Scan: Custom 192.168.137.0 192.168.137.10192.168.137.11 2 11 22 3 Web Application Test: All Ports 192.168.137.0 192.168.137.10192.168.137.11 2
4 Web Application Tests: Custom 192.168.137.0 192.168.137.10192.168.137.11 4 4 5 Advanced Scan: Firewall Plugins-192.168.137.0 192.168.137.10192.168.137.11 1
6 Advanced Scan: General Plugins-192.168.137.0 192.168.137.10192.168.137.11 1
7 Advanced Scan: full scan-192.168.137.0 192.168.137.10192.168.137.11 75 117 33
Table 5.5:Nessus Scan: Vulnerabilities of 192.168.137.0/24 - Management Network Targets.
Nessus Scans provided a large amount of information of each target, for example the Network 192.168.137.0 has to target the cloud nodes (Controller and Compute Nodes). For those two targets 30 scans were run and two reports were collected from each scan; one is a summary and another is a custom report. Table 5.5 presents the data collected from the summary document detailing the number of classified vulnerabilities of each target. However, 7 out of 30 scans reported vulnerabilities across a range of vulnerability level classes, which range from High to Low as shown in Table 5.5. Appendix B contains the table of vulnerability names for the targets along with the suggested solutions.
The Nessus custom reports showed no information that would conflict with what has been found by Zenmap and Sparta, or any additional knowledge except for vulnerability details. Their severity for each target and specific ports used is also reported along with the best solution to secure that risk.
Similarly the Network 192.168.100.0/24 had 30 scans but only scans of three addresses showed vulnerabilities, as seen in Table 5.6. It is clear that the VMs are the most vulnerable part of the cloud and yet VMs can be secured better as demonstrated by 192.168.100.16 (KaliLight) showing no vulnerabilities compared to the VMs built by the test image provided by the cloud
S.Q Scan Targets
Vulnerabilities
Critical High Medium Low
1 Basic Network Scan: All Ports 192.168.100.0
192.168.100.10 192.168.100.11 1 1 2 192.168.100.12 192.168.100.13 192.168.100.14 1 1 2 192.168.100.15 1 1 2 192.168.100.16
2 Basic Network Scan: Custom 192.168.100.0
192.168.100.10 192.168.100.11 1 1 2 192.168.100.12 192.168.100.13 192.168.100.14 1 1 2 192.168.100.15 1 1 2 192.168.100.16
3 Advanced Scan: full scan 192.168.100.0
192.168.100.10 192.168.100.11 1 2 3 192.168.100.12 192.168.100.13 1 192.168.100.14 1 2 3 192.168.100.15 1 2 3 192.168.100.16
Table 5.6: Nessus Scan: Vulnerability classes of 192.168.100.0/24 - External Network Targets.
platform. From investigating the vulnerability list of each VM, all VMs other than KaliLight use the same image source, hence, it is easier to reveal their system details more accurately. Target 192.168.100.13 unexpectedly exposed a high vulnerability named “Firewall UDP Packet Source Port 53 Rule set Bypass”. This target is a tenant vRouter as the port is 53/UDP, which represents a network service DNS server. However, despite the vRouters being consistent in the cloud, the question remains why only one vRouter has exposed a vulnerability and the other two did not. The Nessus custom reports confirm all the information displayed by Zenmap and Sparta on the network 192.168.100.0/24 targets, and added the vulnerability details with the solution to manage them.
Using Nessus, vulnerabilities are listed for each target using the ports and protocols used. Thus, assuming an external attacker, the information gained from Nessus, Sparta and Zenmap has indicated network distances, open ports, addresses and both protocol and service vulnerabilities.