This next post in the network penetration testing lab series will get you acquainted with the technical details of the pentest blueprint and settings required to test security capabilities and run pentesting on AWS or Google Cloud.
To know what an attacker is going to do, you have to learn to think like an attacker - only then can you understand the pain of attackers and make their lives that much harder. This exercise requires you to deploy the “Network Penetration Testing Playground” blueprint that I have published on the Ravello Repo.
If you don’t yet have a Ravello account, sign up for one for free. It’s free to try - you don’t even have to provide your credit card information - your VMs are complimentary during the trial period. Add the blueprint to your Library and proceed to the Ravello dashboard.
After selecting the ‘Library’ → ‘Blueprints’ tab on the dashboard sidebar, you can then select the blueprint you just added to your library and click the orange ‘Create Application’ button.
This will take you to the ‘Applications’ section of the dashboard, where you can launch the application by publishing it to the cloud.
In roughly 10 minutes, you will have deployed a 5-node Cyber Range in the cloud. Once you see that all 5 VMs are running, we will begin our journey of infiltration. Even though it is probably obvious from the hostnames of the servers, I will not be revealing details about this environment at this point. We will treat this as a black box, and attempt to find out precisely how these nodes are connected to one another, what they are running, and see if we can find anything of value - just like an attacker will.
Consider that you have somehow gained access to a host in this unfamiliar, foreign network. Conveniently, this host happens to run Kali Linux - all the tools for network exploitation are literally at your fingertips. You may think this is cheating - but remember that many of the tools that Kali provides out-of-the-box can be installed on arbitrary servers on demand.
Using the ‘Console’ feature of the Ravello platform is the easiest way to get command line or graphical access to the boxes within your web browser. You can also SSH into the boxes in your own terminal by following the instructions provided in the ‘More’ tab in the bottom of the dashboard right sidebar under ‘Summary’. Select the “Kali Linux” VM under the “VMs” tab of the Ravello dashboard, and click the “Console” button to launch a new tab where you can login to the box with the username
root and password
Given that we have no idea what other servers are on this network, determining the landscape will be our first task. Most security professionals swear by nmap, (network mapper) a probing tool that discovers hosts and services by sending specially crafted packets to a range of IP addresses and ports, then parsing their responses to gather intel. In this step, we will use a higher level tool, Zenmap, that makes use of nmap under the hood, but also has some other convenient features that makes our task slightly easier. Zenmap can be found under the ‘Applications’ drop-down menu in the Kali desktop menu bar. You’ll find it under the ‘Information Gathering’ group.
The only thing you have to do is to provide a target IP range for scanning. What’s the IP of the box you’re on? Opening a terminal window and looking at the network interface configuration seems like a good way to find out.
$ ifconfig eth0 Link encap:Ethernet HWaddr 2c:c2:60:7a:0f:5a Inet addr:10.0.0.3 Bcast:10.0.0.255 Mask 255.255.0.0. ...
The internal IP address of the eth0 interface is ‘10.0.0.3’ (yours may be different, but just substitute 10.0.0.3 for the value you see under the ‘inet addr:’ listing in ifconfig). What range of IP addresses should you scan for? You could scan the entire IP range, but it’ll take too long, and the chances of being detected are too high. You want to keep these port scans brief and targeted to avoid any kind of detection mechanisms that the victim has in place. It seems pretty reasonable to start off by scanning the “10.0.0.*” range. Enter that into the ‘Target’ text field and you’ll see that it translates into this ‘nmap’ command:
nmap -T4 -A -v 10.0.0.*
Hitting the ‘Scan’ button executes an ‘Intense scan’ on the IP range, targeting only the most common TCP ports. The ‘-T4’ option specifies a timing template, the slowest being 0 and the fastest being 5. The ‘-A’ option tells nmap to enable OS detection, version detection, script scanning, and traceroute. The ‘-v’ option is a verbosity setting that gives us some feedback as the scan is under way. The scan should take a few minutes to complete…
When the scan is complete, you should see the message “Nmap done: 256 IP addresses (7 hosts up) scanned…” Let’s explore the results. Immediately, you should see that there are 7 servers reachable from the host we are on. Wait - isn’t it only a 5-node environment? Let’s go over to the “Ports/Hosts” tab and look at all the servers/open ports we found.
Focus your attention on the “hvx_dhcp_11128.localdomain (10.0.0.1)” host. We see that port 53 is open, and nmap has identified it to run a domain resolution service. Indeed, port 53 is the DNS port, and from the server hostname, it’s reasonable to guess that this server is the DHCP server for the environment. In fact, this host is there by default in every Ravello application, and is used for internal DNS resolution.
The second item on the list has hostname “default-tcuilj99qx4ss….”, but doesn’t seem to have any common open ports. This seems like some Ravello application management node that’s also not part of the Ravello user space. However, because it doesn’t have any open ports, it’s less interesting to us. Let’s move on.
The next 5 servers are more interesting. We see the host we’re currently on, with hostname “kali.localdomain” at IP 10.0.0.3, but also “wordpress-a.localdomain”, “wordpress-b.localdomain”, “mysql.localdomain”, and “loadbalancer.localdomain”. The pot of gold at the end of the rainbow is most probably the server named “mysql.localdomain”. Does it actually run the MySQL database? We can check by selecting it on the sidebar. Indeed, we see that port 3306 is open, running service “mysql” - more specifically, “MySQL 5.1.73”. Why are databases so exciting to attackers? Data dumps are perhaps the most valuable and destructive form of attacks, and access to a database presents the possibility of data dumps to attackers. Data dumps may contain anything from usernames, password hashes, email addresses, telephone numbers, and credit card numbers etc. - you can see why attackers will be excited by these.
At a glance, it seems like this network environment could be a typical web server setup. As you may have noticed by now, it’s often difficult and tedious for attackers to be 100% certain of anything about the environment. Making informed guesses about systems often works just as well, keeping in mind that people tend to stick to defaults. A web developer would guess that the load balancer server probably load balances across two instances of wordpress on the two hosts “wordpress-a” and “wordpress-b”. Some research will inform you that wordpress installations, by default, require a MySQL database instance. This is probably what the mysql host is for.
Exploring further, we see that the “Topology” tab gives us a nice visualization of the detected network topology that seems to confirm our guesses about the web server environment. This visualization is part of the extras that Zenmap has over pure nmap. For purposes of this exercise, we won’t be using information from the “Topology” tab. Now, how do we get access to the mysql database?
One can of course use a password cracking tool like Jack the Ripper to brute force username/password combinations, but we’ll save that technique for another day. We’ll try to find other security weaknesses in the network. Anyone familiar with wordpress will know that the wordpress database username and passwords are located in the wordpress config files. We will have to get access to either of the wordpress servers, and we may be able to locate those config files. Servers set up by careless administrators sometimes have passwordless SSH access to other servers in the network. Let’s try to enumerate the possibilities… (some guesswork required) Why don’t we try this?
We’re in. The sad but true fact is that, in reality, you don’t actually have to be that lucky to come across something like that. Well, now that you’ve pivoted to the ‘wordpress-a’ host, let’s get cracking on finding that wordpress config file. Some research will tell you that the config filename is
wp-config.php. We could perform a Unix find command, or just navigate to the typical path for served web page -
/var/www. Once there, we see the
wordpress folder, with the haloed
wp-config.php contained within it.
Screenshot Of LS with Highlighted wp-config.php
With any luck, we have read permissions. Explore the file, and you will soon realise that we have struck gold.
Screenshot Of Wordpress DB Username Password
Since we are certain that the wordpress hosts must have access to the mysql database, let’s try using the mysql command line interface to login to mysql.
$ mysql -h 10.0.0.6 -u ravello -p
Enter the password
Screenshot Of MySQL Database
Well, the only thing left to do is to see what databases there are (and if we have access)
$ SHOW DATABASES;
I wonder what’s in the “confidential_user_info” database? From here onwards, you can use
mysqldump or similar tools to exfiltrate data. We have successfully pwned this web server environment.
If you followed through the above exercise, you have successfully performed a database dump, and stolen user information from a web site, possibly containing credit card numbers, email addresses, and all kinds of personally identifiable information.