Penetration testing through GUI is more intuitive and easy to use when compared to testing from terminal access. This blog is aimed at penetration testers who’re more likely to have a similar preference. It documents the problem statement, the approach and the solution, with the intention of providing some direction for penetration testers who want to test a network with limited access.
This is a real time case study from one of our clients. The client had an internal network of 25 IPs, all interconnected and hosted on the AWS environment. The network policy limited any kind of external incoming connection to the network. We were given access to only one system: ssh connection through port 22.
Now, I know some of you are thinking “that should be enough” to do the testing. But, some who are relatively new to the penetration testing field need more than that.
The short answer: Yes. But, it is not easy. Especially when someone is used to working with GUI and is under time constraints. You need extensive knowledge about how to query through the terminal. Some tools such as Burp, Nessus, and ZAP can be very challenging to run using only the terminal.
“But, are these tools absolutely necessary?” Yes, these tools are top of the line right now, and yield results that cover a majority of what we need to continue testing for. Nessus for example has a vast library that it uses while testing the target IPs. This results in wider coverage and voluminous result sets, which even though not free from false positives provides for a more comprehensive testing make up.
As we know GUI is a Graphical user interface. It is a system of interactive visual components for computer software. A GUI displays objects that convey information, and actions that can be taken by the user. The objects change color, size, or visibility when the user interacts with them. Examples of GUI are: Boxes with buttons and CTAs.
Here’s how I was able to gain GUI access
I had only a single ssh connection to the testing terminal that was hosted on an AWS EC2 instance using a linux OS. I could install a Virtual Network Computing (VNC) server, which would give me the necessary GUI access. “But, how can I access this server if I only had one port access? The VNC server will be hosted on the machine, and can only be accessed through a port, right?” Due to my rudimentary understanding of how ports worked, I assumed that if I ran the VNC server and accessed it, I can only do it through port 22. This meant losing the existing SSH connection to the terminal.
Port forwarding is the act of configuring a router to make a computer or network device that is connected to it accessible to other computers and network devices outside the local network. In other words, when enabling port forwarding for a device, you are turning on remote internet access for it.
Thanks to some of my more experienced colleagues, I came across the concept of port-forwarding. At first, it was hard for me to visualize how this would solve the problem. If I am forwarding the VNC server port to port 22, I’m still going to lose the ssh connection. This is when I realized that my understanding of how SSH tunneling works was also very rudimentary. After a bit of reading, I realized that I can still have ssh access to the terminal even after forwarding the VNC server port to port 22. Turns out that you can have as many servers running on different ports on the machine, and pipe them through 22. This does not mean that by forwarding from one port to 22, you are losing the existing connection. You are just piping them all together to port 22, which you can remotely access from your local machine. After I understood this, port-forwarding became easy. A bit of explanation on the port-forwarding command.
ssh -L 5901:127.0.0.1:5902 -C -l -i
Now, a quick side note: You need to install the VNC server on the remote machine, and get it up and running first. The first time you run it, it will ask for you to set a password for viewing. Once its successfully running, it will give you the default port 5901 where you can access it.
Okay, now that I am connected, I should be able to access the system on machine’s port 5901. So, I opened up firefox and typed up localhost:5901. This is what I saw:
Error RFB 003.008. Turns out that my firefox did not have the necessary files to support a VNC protocol. I have to use a VNC viewer on my system for the GUI. Thankfully, my Ubuntu 16 had come with pre-installed VNC viewer called Remmina. Once I had Remmina up and running, I created a new profile, which included the server IP I’m trying to access.
This was a silly mistake on my part. Instead of the remote server IP, I need to put localhost:5901 under server IP tab. Because, keep in mind that I am already connected to the remote machine, and the GUI traffic has reached my local machine to port 5901. From there, I’m viewing the traffic via a VNC viewer.
After I got the configuration right, I connected. I used the VNC password that I had set-up when installing the VNC server on the remote machine before port-forwarding. Guess what? All I saw was the a grey screen with a large x for my mouse pointer. It wasn't over yet! After a bit of web-search, I found out that I didn’t have the desktop environment on the remote machine configured properly. This can be fixed by editing the startup configuration file. If you are using linux, it would be in ~/.vnc/xstartup. You need to edit the file and the content should look exactly like the below code. (I’ve commented out the lines that were in the file before)
#!/bin/sh
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 120x50+50+25 -ls -title "$VNCDESKTOP Desktop" &
#x-terminal-emulator -geometry 1400x850 -ls -title "$VNCDESKTOP Desktop" &
x-window-manager &
gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &
Once you save the file, you need to restart the VNC server on the remote machine.
After all this, I re-connected, and viola! A GUI desktop never looked prettier.
In order to gain GUI Access on the AWS Instance, we need to set up a VNC Server on the AWS instance and by using Local Port Forwarding, we can forward all the traffic on the remote machine to a specific port on the local machine and can obtain the GUI Access using the VNC Client running on the local machine i.e 'Remmina’ in my case as I am using Ubuntu 20.04 OS.
Local Port-Forwarding using VNC Server
Step1 : The first step is to update and upgrade the Ubuntu machine or the ec2 instance so that all the libraries, packages and modules gets updated.
Step2 : In order to forward remote traffic to the local machine , we need to set up the VNC server on the remote machine. To set up VNC Server, we need to install the VNC server and other dependencies on the remote machine. This can be achieved by entering the command
sudo apt-get install ubuntu-desktop gnome-panel gnome-settings-daemon metacity nautilus gnome-terminal xfce4 vnc4server
Step3 : Once the VNC Server is installed on the remote machine, we need to launch the VNC server and set a password for the same. The same password needs to be entered while taking the GUI Access on the local machine. Use the below command on the remote machine’s terminal to set the password.
vncserver
Step4 : Once the password is set, we need to change the contents of the VNC startup configuration file so that, we can get a proper desktop environment after gaining GUI Access on the local machine. Use the following command to edit the VNC startup configuration file.
sudo vi ~/.vnc/xstartup
Step5 : Once the configuration file loads, replace the contents of the file with the below mentioned contents, where GUI Access and VNC server related utilities are mentioned.
#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
unset DBUS_SESSION_BUS_ADDRESS
startxfce4 &
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &
gnome-terminal &
Step6 : Once the configuration file is edited. Logout from the instance and login again using the port-forwarding command to forward remote traffic to local machine
The command used here is
ssh -L 5902:localhost:5902 -i
ssh : Command used to run SSH service.
-L : This is for local forwarding. This is the right option, because the forwarding happens after you connect to the IP-to-Access (remote) server. The forwarding is happening locally on the machine.
5902: Port on the local system that the user wants to receive the connection to.
localhost:5902 : This is where the VNC server is hosted on the remote machine. localhost is just the localhost IP, and 5902 is the port where the vnc server is accessible.
-i : This stands for identity. Users need this file, if they are using private keys to login. This .pem file is used while taking ssh connection.
: The file that contains your AWS Private Keys.
: The remote machine’s Name
Step7: Once we do the port-forwarding and take ssh access into the remote machine, we need to start the VNC server by using the command
vncserver -geometry 1340x750
Here 1340x750 is the resolution of the screen on the local machine.
Step8 : After running VNC server on the remote machine, we need to connect the VNC client to the VNC server on the remote machine by entering the following command
localhost:5902 and enter the password, when VNC client prompts the password window.
Step9 : Enter the VNC password and click on ‘OK’. This will prompt GUI Screen for the remote AWS EC2 Instance.
Conclusion
Another thing I learned from this: With just one VNC server, if you and your colleague are trying to access the same system, you will see the same desktop. Only one of you can work on it at the same time. So, instead you can have separate desktops by running multiple VNC servers on the remote machine. Make sure to specify which port the second or third VNC server is running on when you are port-forwarding to your system.
For someone who had never done this before, this was a bit of challenge in itself. There are multiple blogs out there that shows how to set up VNC and SSH, but I couldn’t find any good sources that gave me a simple explanation on this matter, along with the “how-to” get the GUI access. Since, there is a good chance that most new and junior testers will face this problem. Here is my write-up. Hope you found this to be a useful read.
