To get started, we first determine the open ports, services and service versions running on the open ports as shown below:
The output reveals that only port 80 is open with Apache HTTP server running on it.
We can further run a more comprehensive port scan to ensure we do not miss any other open ports. We can even run an UDP scan as well; Both scans reveal that only port 80 is open for this box:
Our only path of attack is through port 80. We can open the web page on port 80 and see where it leads us:
This web page has a link to a Github repository hosting a semi-interactive phpbash web shell. We can do further enumeration on this web server to find interesting directories using Gobuster:
Directories — /images, /uploads, /php, /css, /fonts and /dev were discovered by Gobuster. Navigating to the above directories, we do not find anything interesting except for the /dev directory where we find the phpbash.php script and upon clicking it, we get a web shell!
We probe further to find out the capabilities of the obtained web shell:
NB: This rudimentary shell runs in the context of of Apache default user www-data. For this particular machine, we already have access to a low privileged shell which at least allows us to run basic Linux commands on the web server thus eliminating the need for us to spawn our own custom reverse shell.However, in a real penetration testing engagement, we would need to upload our own shell in the system in case the system owner notices this insecure configuration and removes the PHP script such that we would consistently have access to the system via our own shell that we control.
To model an actual penetration test scenario, let us set up our own reverse shell. In the attacker machine (Your Kali instance), configure/setup a listener:
Now, on the target/victim machine (Bashed), send back a reverse shell to the attacking machine:
The reverse connection appears to be dying so we try an alternative method of sending a reverse shell. The Pentestmonkey resource has a great list of reverse shells. We can try to use a Python reverse shell since our target shows that python is installed.
We edit the Python reverse shell from Pentestmonkey to change the parameters of the attacking IP and port to reflect those of our Kali (attacking) machine:
On running the Python reverse shell from the victim’s web shell that we obtained earlier, we are able to get a reverse shell back to our attacking machine:
We can now proceed and find the user flag. We first change to the home directory to view contents:
We notice that we have execute permissions on both arrexel and scriptmanager directories. Inspecting arrexel directory first, we find the user flag!
We now need to find out and determine what other privileges we have or that we can easily obtain. We can check the commands that our current user is allowed to run:
From above, we note that the user we are running in the context of www-data can run as the user scriptmanager without needing to provide user credentials. We will revisit this late. For now, we can do further enumeration.
If we check the root directory, we see that everything is owned by root except for the scripts directory which is owned by the scriptmanager.
Recall that from the previous step that we can run as scriptmanager without requiring a password. Once we are running in the context of the scriptmanager, we have read, write and execute privileges within the scripts directory.
Here we see two files test.py, owned by us and test.txt, owned by root. If we investigate the contents of test.py:
We see that test.py is a simple python program that writes to the file test.txt. Recall that the file test.txt is owned by root and runs as root! Also, notice that the last access time for test.txt is very recent (Mar 24 01:10) suggesting that there might be some form of job scheduling. As a matter of fact, the script seems to be running every minute suggesting that it’s a cron job owned by root!
This is a great milestone because it implies that if we change the contents of test.py file to send a reverse shell back to our machine, that shell will run as root.
Manipulating the test.py while still on the target machine proves to be a bit of a challenge so we opt to create the file on our attacking machine and transfer it to the victim once done.
We then change the file permissions to read/write/execute for all and from the same directory where the file is seated, we spin up a simple HTTP server:
Now, on the target machine, under scripts directory, we download the test.py file from our attacker machine (Kali). We also set up a listener on our attacker machine on the same port as specified on the test.py file.
We now wait for about a minute for the root cron job to be executed by the victim and….. Bravo! we have a reverse shell back running as root!
We can now navigate to the root directory and retrieve the root user flag.
BUT WHAT HAVE WE LEARNT SO FAR?
- Never ever leave web shells on your system that grants access to your system.
- System permissions security misconfigurations can open a new world of pain! This can easily be seen in the instances where a web daemon user (www-data)was able to escalate into a more privileged system user (scriptmanager). On a similar vein, we note a script test.py, created by a non-root user executable by root. Always adhere to principles of least privilege and proper separation of privileges.
- Sensitive but publicly accessible web directories — i cannot stress this well enough. A developer may think that no one can find web directories since they are not directly linked to the website. As witnessed above, this is not so! In fact, Gobuster was able to discover such directories in seconds. The /dev directory gave us a swift foothold onto the target system. Sensitive web server directories should be properly restricted from public access.