As always we start with an Nmap scan to see what ports the target system is offering. As figure 1 shows there is an Nginx web server on port 80 and RPC actively listening for connections. Interesting is, that there is no SSH, which means that we have to gain access over a reverse shell and do not need and try to find any SSH-keys or passwords.
When we take a look at the website we see that it is PHP based without any relevant information.
When we try to find anything that offers some sort of user interaction we only see a site called contact.php.
We try to do some basic injection but it seems like we are not getting any new knowledge. Furthermore we are not able to access our own contact information that we submitted. After submission we are only presented with a page that says “Thank You” but nothing else of interest.
After a very close look we could potentially see that the year provided on the footer for the Copyright information is different for the thankyou.php page than for the rest of the website (for comparison see figures 2 and 4).
When we take a closer look at the source code we see that there is a class called footer-wrapper. We try to access the footer by guessing the filename footer.php and are able to verify that it shows different annual figures for every access.
If the Copyright changes, but source code shows its a static content, it has to be some PHP include magic.
We need to find out how this PHP include works. It has to reference the footer.php file, which is why we need to search for the correct parameter. To do this we use a Fuzzer like Gobuster.
We see that most responses are 851 characters of length. We run the command again and exclude every response with 851 characters and are able to identify the parameter file as shown in figure 7.
And since we are including a file lets try some local file inclusion as shown in figure 8.
We can verify the LFI vulnerability from figure 8 by using the browser as shown below.
Since there is no SSH there is no need to search for an password or SSH key. Another way to gain access to a system when having LFI is by log poisoning. To do so we need to be able to inject a payload into a logfile and then display the logfile via LFI to get the injected code executed.
From the Nmap scan we know that the web server is Nginx. This means that we know that the web server log should be on /var/log/nginx/access.log and error.log.
When we try to include error.log we see the actual content of the log file. So we try to verify if we are able to determine the content of that file by accessing
which gives us no concrete result at first. But when we access
we see that our URL got into the error.log file.
So the next step is to inject a string that would be interpreted as a PHP file with command execution into the log file and execute it by displaying the log file via LFI.
Listening on port 445 gives us a reverse connection from the target system back to our machine as user www-data.
The next step is to escalate our privileges. To do so we use a handy tool called LinPEAS. The script shows us a possible privilege escalation by abusing screen version 4.5.0.
We find the exploit by using Searchsploit.
Simply copying the exploit code to the target system and executing it does not work. As figure 15 shows, the exploit aborts after the first step.
We take a closer look at the exploit code and try to figure out what it is actually doing. The exploit writes two files to the /tmp directory and compiles them later on. We create those to files manually on our Kali-Linux and compile them. Afterwards we copy the created libhax.so and rootshell to the /tmp directory on the target system.
As last step we trigger the exploit by hand and gain root privileges as shown in figure 17.