# Round Two, electric boogaloo.
After averting a Christmas crisis, we must move on to an important stage of web security: actually securing ourselves!
Being security-conscious, the devs within Santa's Co. have created a website where users can add photographs of suspicious folks that hang about. Our manager, McSkidy, wants us to perform a security audit!
But before that, some knowledge.
## Using GET parameters
As we briefly learned in the last room, we can send data (like on a login page), to a server via a POST request. This lets the server know what to do with the data when it is received. We can also use "GET parameters," which in a way exposes the data being sent to the server as thits kept within the URL itself.
https://www.thebestfestivalcompany.xyz/index.php?snack=mincePie. This is a fictional example of adding the
mincePie value to a
snack parameter. We can break down this URL even further.
https://specifies the protocol used. This could also be HTTP, which as we learned from yesterday is the unsecure communication protocol.
- We have the
wwwsubdomain, which can be usually be referred to as the apex domain or the traditional main index page.
- The domain
thebestfestivalcompanyis a domain that good ol' Santa had purchased, which is registered and is the rememberable link to a given IP Address.
.xyzrefers to the TLD, or Top Level Domain. It is used in conjuction with the domain to help DNS where to look if they want to find your website. So instead of searching everywhere for a thebestfestivalcompany, we can search in only the
- In this URL, we have the
index.phppath after the
/that represents the resource we are after. The
index.phpfile is the index page of the server, and acts like
index.htmlbut with the benefits of the PHP programming language.
- Finally we get to the rest of the url. The question mark signifies a GET query parameter (which is
?snack=, snack being the query parameter.
mincePieis the value for that parameter.
### The Day's Challenge
So how does this relate to today's challenge? First, we need to discuss file uploads on the internet. Whenever you are able to upload a file to a server, this is a direct path to a potential security vulnerability known as RCE, or Remote Command Execution. You could technically upload a script, and if executed, could connect back to your attacking machine and then allows you to run any command you want.
Our goal is to detect if there are any vulnerabilities in uploading files that allow malicious actors to bypass the filtering of extensions/files. Some common types of filtering are:
- File extension filtering
- Bypass filtering techniques. For example, a simple filter would check for the extension by splitting at the
., but if a file was
script.png.php, the server may see a
.pngextension and think it was a correct file, only for it to be executed as it's actually a
When implementing an upload system, it's best to store the files in a directory that can not be accessed by the web server. This is because the web server can't see the files, and therefore can't execute them. To put it simply, don't store files in a location that can be accessed remotely.
So we understand GET parameters, and file uploads. What happens when we are able to upload a malicious file (by bypassing a filter)? We can upload a Reverse Shell script, which creates a connection via the network between our computer and the victim's computer. If the server is a PHP server, then our script could be a PHP reverse shell script. If you are on Kali, or using TryHackMe's AttackBox, you can see an example at:
WIthin the script, we are able to change the
$port variables to the IP address and port of our computer (which the victim's server would connect to). Within my Kali environment, I run
ip a show tun0 to get the IP address of the tunnel interface connected to TryHackMe. I then update the ip variable and the port set to 443.
Now, if I upload this file to a server, and then call it, it will "reverse the connection", and connect to me if I am listening for connections. This is known as a Reverse Shell Listener. This simplest way to listen is by using netcat on port 443. The reason we are using port 443 (or the HTTPS port), is that most firewalls would not bat an eye when connecting to such an important port, as it might just think it's a standard web connection. If you are on a linux system, you can use
sudo nc -l 443 to listen for connections.
Great, we now have the tools to begin our security audit. I visit the page where can upload images of suspicious people. It asks for a GET parameter with my specific id. Visiting the page, I can see an ability to upload a file. First, I would try uploading a few different types of files, just to see what the internal filtering system is checking for. First obvious guess, images. So I create some dummy files, and see I can upload them. I upload a file and see it calls a POST request to
/upload. There's no GET route there, so I know I will need to find the route where the uploaded files are located. I upload the PHP reverse shell script, named
php-shell.png (I know, super hidden), and then I run gobuster to check for potential routes.
I could also manually check using quite common paths like
/assets/, but I thought I'd give
gobuster a try. I see right away that when running:
gobuster dir -u 10.10.151.139 -w /usr/share/wordlists/dirb/common.txt, I get an immediate error as the server always returns a 200 status since it just directs the user to an index page. By the way
-u is for URL, and
-w is for wordlist. The
dir command is for directory listing. I decide to also exclude the length, as otherwise it would show every route since the index page has a length of 638. I update the command to ignore paths with a length of 638 (using the
--exclude-length flag) and get some nice results.
I see some dangerous files like
.htpasswd that should not be exposed. I also see an
/assets directory, a
/cgi-bin, and an
/uploads. I assume that the images are being uploaded to
/assets, but when I check I see it's the website's assets. So I check the
/uploads/ directory, and lo and behold, my files!
I click on the remote shell file (like a trojan horse!), and making sure NC is running, I see that I can shell access to the server. I can run commands like
id and see that I am
apache. I can also run
uname -a and see that I am running on a Linux system.
I check out
/var/www and I see a
flag.txt file. There's the flag, and after inputting the code into Day 2, It's now complete!
Well done to us for auditing the website, and now can create a report to the elf devs to let them know they need to upgrade that security!