We start off with a full-port nmap to check running services (most of output truncated)
We see port 22 with SSH and port 80 with HTTP. Let's check the HTTP.
We're greeted with a strange message:
It seems as if our job is to find the "backdoor" into the system. The source has nothing particularly interesting, except for a comment:
If we google this comment we come across an interesting GitHub repo with a collection of reverse shells. Let's put their names in a file called wordlist.txt and run gobuster:
It appears as if smevk.php is on the target! Let's head over to http://10.10.10.181/smevk.php and we what happens.
It definitely exists! The repo tells us the default credentials are admin:admin.
The webshell looks horrible, but we have an Execute input where we can run commands. We can now use this to get an actual reverse shell.
First we use nc on a terminal to listen for incoming connections:
Next we use a PHP reverse shell on the webshell to redirect execution to it:
We get a connection! This is a fairly bad shell, but we can easily upgrade it to be useful.
Now we have a foothold, let's check what's in our user's home directory. It appears to be a file called note.txt:
We have been left "a tool to practise Lua". As always, first thing we should do as a new user is check our permissions.
We can run luvit as sysadmin! We can guess that luvit is the tool that runs Lua scripts. Because we can run it as sysadmin, if we create a Lua script that spawns a shell we will spawn with higher privileges.
This is the command we want to run. We can simply use echo to create it:
Now let's run it as sysadmin!
You could also have done it in one line using the -e flag:
sudo -u sysadmin /home/sysadmin/luvit -e ‘os.execute(“/bin/bash”)’
We can now read user.txt!
Firstly, we want to get a nice SSH shell. We can get this using SSH keys.
First create the key pair:
I just hit Enter, meaning there's no passphrase. Now cat traceback.pub and echo it into ~/.ssh/authorized_keys - this registers the keypair as valid.
When using echo in these scenarios, use >> rather than >. Using only a single > will overwrite all the other contents, essentially erasing any keys owned by other people, which is not a great thing to do.
If ~/.ssh doesn't exist already, make sure you create it.
Make sure you spell it authorized not authorised!
Now we can log in via SSH using
To perform some automated privesc recon, I'm going to run linpeas. Port it over by hosting it on a python SimpleHTPServer:
The wget it on the box:
Then chmod, run and analyse the output.
Something that really sticks out is this:
These scripts get run every time someone logs in with SSH. If we can modify them (which we can), they will run whatever we modify them to. The important part here is they get run as root.
So the privesc is simple, but what should we get the file to do? There are a couple types of choices:
Run something that enables us to get root
Print the flag
In these situations, if both approaches are equivalently easy, then it's a good idea to go for the approach that affects the least other users. Nobody can notice our reverse shell since it's directly to our IP, so it doesn't affect other users.
Make sure you set up an nc listener on port 9002 and then log in via SSH again.
And bam, we have a root shell.
