This chapter aims to helpÂ penetration testers who don't have direct access to targets for penetration testingÂ set up a vulnerable lab environment within AWS. ThisÂ lab will allow testers to practice various exploitation techniques using Metasploit and rudimentary scanning and vulnerability assessment using multiple tools within Kali. This chapter focuses on setting up a vulnerable Linux VM and a generic Windows VM on AWS, putting them on the same network.
In this chapter, we will cover the following topics:
- Setting up a personal pentesting lab for hacking on the cloud
- Configuring and securing the virtual lab to prevent unintended access
The very first step in setting up our vulnerable lab in the cloud will be to provision an instance that will be running a vulnerable operating system. For this purpose, we can use an Ubuntu LTS version. This can be accessed from the AWS Marketplace for quick deployment.
We will useÂ
Ubuntu 16.04 for this purpose:
Once we click on the
Continue to Subscribe button, we are prompted to configure the instance that we are going to launch. Since this is a pretty standard image, we will proceed with the default settings except for
Region, you can use the AWS Region that is closest to yourself. However, keep in mind that all the other instances you create on AWS need to be hosted in the same region or they cannot be a part of the same network.
VPC, make sure you note down the
VPC and the
subnet IDs that you are using to set up this instance. We will need to reuse them for all the other hosts in the lab. In this case, I will be using the following:
It should be noted that the
VPC IDs and the
subnet IDs will be unique for everyone. Once done, we can proceed to deploy the EC2 instance by clicking on the
Launch with the 1-Click button.
ssh -i <pem file> <IP address of the instance>
Once connected, run the following command:
sudo apt-get update && sudo apt-get dist-upgrade
These commands will update the repository listing and all the packages installed on the instance, so we don't have to deal with any old packages.
For this Ubuntu host, we will be installing a vulnerable version of an FTP server,
vsftpd. Version 2.3.4 of this FTP software was found to be backdoored. In this chapter, we will be installing this backdoored version and then will attempt to identify it using a pentesting box we will set up in the next chapter, and finally we will exploit it.
To make things easier, the backdoored version of
vsftpd 2.3.4 is archived on GitHub. We shall be using that code base to install the vulnerable software. To start with, we need to clone the
git clone https://github.com/nikdubois/vsftpd-2.3.4-infected.git
Next, we need to install packages for setting up a primary build environment. To do this, we run the following:
sudo apt-get install build-essential
Once done, save the file and just run
If all goes well, we should see a
vsftpd binary in the same folder:
Next, we need to set up some prerequisites before installing
vsftpd. Namely, we need to add a user called
nobody and a folder called
empty. To do that, run the following commands:
useradd nobody mkdir /usr/share/empty
Once done, we can run the installation by executing the following commands:
sudo cp vsftpd /usr/local/sbin/vsftpd sudo cp vsftpd.8 /usr/local/man/man8 sudo cp vsftpd.conf.5 /usr/local/man/man5 sudo cp vsftpd.conf /etc
With that done, we need to execute the
vsftpd binary to confirm whether we can connect to theÂ
mkdir /var/ftp/ useradd -d /var/ftp ftp chown root:root /var/ftp chmod og-w /var/ftp
Finally, enable local login to theÂ
vsftpd server by making the following change to
With a vulnerable Linux Server set up, we now set up an attack vector through a Windows serverÂ that'sÂ running a vulnerable web application. ThisÂ application shall provide two environments thatÂ readers without an actual test environment can try their hand at.
The provisioning steps are pretty much identical to what we used to set up the Linux instance earlier. Care should be taken that the VPC settings are similar to what we used for the previous instance. This will later allow us to configure the VMs to be on the same network.
After verifying the VPC settings and the region, we proceed to launch the instanceâprecisely as we did earlier. Finally, we set the key-pair that we have been using all along and we are good to go. Once the instance has been launched, we need to follow a slightly different process to access a Windows instance remotely. Since Remote DesktopÂ Protocol (RDP) doesn't support certificate-based authentication, we need to provide the private key to decrypt and get the password using which we can log in. This is done by simply right-clicking on the instance and selecting
Get Windows Password:
On the following screen, we are required to upload the private key that was downloaded earlier:
Once done, simply clicking on
Decrypt PasswordÂ will provide us with the password that we can use to RDP into our Windows server instance. Once done, it's a simple matter of firing up
Remote Desktop and connecting to the IP address using the displayed credentials.
Once we are logged in, the next step is to set up XAMPP on the Windows server so we can host a vulnerable website on the server. But before we proceed, we need to install the latest version of Firefox on the server, since the Internet Explorer version that comes packaged with Windows Server 2003 is pretty old and doesn't support some website configurations. To download XAMPP, just access https://www.apachefriends.org/download.html and download the version that's built for XP and Windows Server 2003:
Finally, we need to follow the default installation process, and we will be set up with a working installation of PHP, Apache, and MySQL, along with a few necessary utilities that we need to manage a website.Â
Create a new folder called
_bak and cut and paste all the existing files into that folder. Now, let's download the vulnerable website's source code. For this, we will use one of the many vulnerable PHP samples that are available on GitHub:Â https://github.com/ShinDarth/sql-injection-demo/.
The fastest way to get the files is to directly download the ZIP file:
Downloading the source code
The file structure
Once completed, the next step is to create a database for the application and import the data into it. To achieve this, you need to access the
phpMyAdmin interface, which is accessible atÂ
http://127.0.0.1/phpmyadmin. Once here, select the
NewÂ option under Recent:
Once we click on
Go we will see a success message. Now, if we browse to
http://127.0.0.1Â in our browser, we will be able to access the vulnerable website:
Congratulations, you have successfully configured a vulnerable web application on the Windows server! The next step will be to set up the networking rules within our VPC so that the vulnerable hosts are accessible from the other EC2 instances.
Now that we have set up two vulnerable servers, the next step is to configure network so that our web application isn't accessible to outsiders and, at the same time, so that the other lab machines can communicate with each other.
We had originally set all of the EC2 instances to be on the same VPC. This implied that the EC2 instances would be on the same subnet and would be able communicate with each other through internal IP addresses. However, AWS doesn't want to allow all 4,096 addresses on the same VPC to be communicating with each other. As a result, the default security groups don't allow communication between EC2 instances.
To allow connectivity from the Ubuntu instance to the Windows instance (you can repeat these steps for the Kali instance that will be set up in the next chapter), the first step is to get the
Private IPÂ address of the Ubuntu host:
Description tab showing the Private IPs
Next, we need to modify the security group rules for theÂ first Windows instance. This is as simple as clicking on the security
Group Name in the summary pane to get to the
Security Group screen:
Security GroupÂ screen
Now we simply need to click on the
Edit button and add the rule allowing all traffic from the Kali Linux instance:
curl -vL 172.31.26.219
In the next chapter, once the Kali PentestBox has been set up, the preceding steps can be used to whitelist the Kali Linux IP address on both the Ubuntu and the Windows server instances so we can get started with hacking the lab environment!
In this chapter, we have set up a lab that can prove useful to beginner penetration testers who do not have access to a test environment or hands-on exposure to a lab. In our lab, we have set up one Ubuntu host with a vulnerable service running on it, and we also set up a Windows server host that is running a vulnerable web application. This represents the two biggest surface areas for an attack in any environment. Additionally, we also went through the process of establishing a network connection between the various instances that we have set up so far. With these steps taken care of, the user can set up any operating system instances in the cloud, set up security groups to configure networking, and protect against unauthorized access as well.
In the next chapter, we will be looking at setting up a Kali PentestBox, using which we can perform scanning, enumeration, and exploitation of the two vulnerable EC2 instances that we have set up.
- Vulnerability and Exploit Database: https://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor
- Amazon Virtual Private Cloud (User Guide):Â https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html