Penetration testing through GUI is more intuitive and easy to use when compared to testing from terminal access. This blog is aimed at junior penetration testers who’re more likely to have a similar preference.
Recently, I worked on a penetration testing assignment for a client. They 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. Maybe so. But, some who are relatively new to the penetration testing field need more than that. In this blog I have documented the problems I faced, the approach I followed and the solutions I found with the intention of providing some direction for novice penetration testers who want to test a network with limited access.
“Can you test with just a terminal Access?”
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.
So let’s get to it then. Here’s how I was able to gain GUI access when 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.
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 <username> <IP-to-Access> -i <pem-key>
- ssh : This is stating that you are attempting a ssh connection
- -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 that machine.
- 5901: This is the port on your local stem that you want to receive the connection to.
- 127.0.0.1:5902 : This is where the VNC server is hosted on the remote machine. 127.0.0.1 is just the localhost IP, and 5902 is the port where the vnc server is accessible.
- -C : This option is to compress the connection. Depending on how fast the network is and how many connections you want, -C is a good option to maintain connection bandwidth.
- -l : Lowercase L. It's the login name parameter.
- <username> : This is where you input the login name
- <IP-to-Access> : This is where you use the IP of the remote machine you are connecting to.
- -i : This stands for identity. You need this if you are using a pem key to login. In most cases, you are using this.
- <pem key> : This is the file path to your pem key file.
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.
Once your port-forwarding is successful, your terminal will look something like the below image.
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 gray 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)
# 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" &
Once you save the file, you need to restart the VNC server on the remote machine.
- To get the VNC servers list: $vncserver -list
- To kill one of the servers: $vncserver -kill :[display ID] (The display id will be listed following previous command)
- To get it up and running: $vncserver
After all this, I re-connected, and viola! A GUI desktop never looked prettier.
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.