How I rooted HackDay Albania CTF (2016)

Start out by mapping the target:

Then to gain more information about the found services, I run the nmap aggressive scan against the open ports:

Let's check out the web server in port 8008 and find an image from Mr Robot tv series. There's also text, which translates to "If I am, I know where to go;)". I guess this is hinting us that we should check out robots.txt, but we knew that already, thanks to nmap!

I saved the entries in robots.txt to uris.txt and checked them with dirb:

It's pretty easy to see which directory stands out from the crowd. Let's check it out:

and 

When we follow the link to client-folder, we land on "Very Secure Bank" login page.

When we try a simple SQL injection in the login form, we get SQL error:

When we then try to exploit the injection, we can't get in. Time to fire up the sqlmap. The default doesn't find anything, but when I raise the level attribute to 4, we get something new. The command I executed was:

  sqlmap --data="username=foo&password=bar" \ 
  -u http://192.168.56.101:8008/unisxcudkqjydw/vulnbank/client/login.php --level=4

When we then enter "foo' RLIKE SLEEP(5)-- -" as the username and "bar" as the password as suggested by the sqlmap output, we are in as Charles Dobson!

As a logged in user, we have the ability to open support tickets to the service. What makes it interesting is that there is also a file upload possibility in the submit ticket form:

So, we first tested if we can upload just any files, but only jpg and gif were allowed. We then take an existing jpg file and add a simple comment to the file with exiftool

When we then check the image, we see something really interesting:

The target server must use the include-function of php to include the referred image. So we change the comment to something more usable in our quest. We used a simple shell "system($_GET['c']);" but feel free to do as you wish, anyhow we now have code/command execution on the target server.

We set up a reverse shell and when I execute it, I get shell as the www-data user (apache):

We then start exploring the system. First we take note about the database credentials:

Unfortunately the password isn't accepted for any users on the target host. Then we gather the usual information about the system... We check the kernel version and try to find out if any users have sudo privileges:

So user taviso is a potential target, because he has sudo privileges.
We also dump the database contents, but there is nothing interesting, except the fact that passwords for very secure bank are stored in clear text... :p

We then execute the usual information gathering scripts, which you find around the Internet and accompanied with your Kali linux. We hit 1 really interesting result:

The passwd file is world writeable! If you don't know what the passwd-file is, then you better go find out. What is interesting about this, we can add new users or set passwords for existing users. We decided to add a new user to be more stealthy, after all if we reset an existing users password that user can't log in anymore and can then know that their system is hacked. Naturally there could be some tripwire kind applications, which monitor changes in the core system files, but in that case any change to the file would raise an alarm. To add a new user, we must decide a username and calculate a password hash we want to use. I used openssl as suggested in stackexchange.

I checked the existing users for reference:

The x between the first and second colon on each line tells the system, that it should look for the password hash in the shadow file instead. But it's still possible to also have the password hashes in the passwd file! The next 2 values are user id and group id and if we add a new user with the same values, we are effectively the same user to the system. So I execute the following command:

 And then confirm that everything is in place

And now we can log in with ssh, using username foobar and password SuprScrt. We get in with ssh and the system tells us that we are the user "taviso". Good! Now if we would've changed the password for user taviso, we could've used sudo to elevate our privileges, but since we now don't know the password for taviso, we have to do something different. So we add yet another user to the system, this time using user and group id 0, thus creating another root-user.

We then checked if we could log in with ssh using the newly created credentials, but we were met with Access Denied messages. We had a hunch that perhaps ssh is configured to disallow root login. Luckily we had already an interactive access (ssh) to the system and could switch users with su:

Seems like a win to us! Then we check the /root folder for any loot:

We found the root flag so we must be done here. We still checked why we couldn't login with user bar with ssh and found that our hunch was correct:

So root user was not allowed to log in using password authentication, which makes sense. Why would you allow root to log in with password anyway?

Thanks to R-73eN for creating the challenge and to vulnhub for hosting it!