Biteme Writeup

 

Biteme link

Enumeration

Firing up nmap we can see that we have 2 ports open, 22(ssh) and 80(http), let's take a quick look at the webserver first and see what's running on it.

Just the default apache page, lets run gobuster and see if we can find any directories.

Looking at gobuster we only seem to have the one directory, /console/ so let's take a look at that, we may need to possibly run a bigger wordlist later if we can't net anything from this.

Interesting, we have a login page with a captcha, taking a quick look at the page source doesn't reveal any hidden details so let's take a look at what happens and what data is submitted when we attempt to login.

Interesting, it seems there was a message logged to the console when we attempted to sign in stating that php file syntax highlighting has been turned on.
We can also see that when we submit a sign in attempt there is an extra variable of clicked = yes.

Lets run a quick gobuster scan on the console directory and see what we can find.

Looks like we have a few different files here, the robots.txt has nothing of interest, securimage is related to the captcha, but we do have access to config.php and functions.php.

Lets take a look at these with the extension phps seeing syntax highlighting is enabled.

Interesting, looks like we have a login user listed in config.php, it appears that it is obfuscated though so we will need to de obfuscate it first.

Looks like functions.php shows us some more interesting details, lets start by decoding LOGIN_USER that we found in config.php now that we know bin2hex is used.

Using a simple browser based tool we can see we have decoded the user, so we now at least have a user, now onto password.

Looking at the is_valid_pwd function, all it is simply doing is taking the password input, hashing it with md5 and then checking if the last 3 digits of that md5 string are 001, so we could technically enter anything we wanted as the password provided the last 3 digits of the md5 string were 001.

To do this I'm going to use the Audero-MD5-Rainbow-Table, we can then simply search the table for an md5 hash that ends with 001" and then use the word that corresponds to that hash as our password.

Lets give it a try.

And it worked! Although we have another roadblock, mfa, lets take a look at what's going on here.

Looking at the debugger we can see there's another note left for fred, looks like there's no bruteforce protection on this field, so all we need to do is capture a request to this field with the current session cookie and try brute forcing pins 0000 - 9999 with burp and hopefully one of those will work.

Capturing the request in burp we can pass it along to the intruder tab, but that will take a really long time to iterate through 10,000 codes without the pro version, so lets use crunch to create a wordlist and then use ffuf to attempt to get the right code.

In crunch we set the min and max characters to 4 and then we set the character set to all numeric characters and we set our output file, this gives us a file that contains 0000 - 9999

We then set all our variables in ffuf, a really important one is -replay-proxy, this allows us to send all our requests through burp so that we can see the response data fed back, the first attempt I did with this I only put the cookie data using -b and the post data using -d, I had not set any extra header data with -H, which resulted in my request being malformed and the code not being submitted.
This first initial run we want to stop as soon as it starts almost, we only need a few requests to get the info we need for the next step.

After the initial run with ffuf, we can take a common variable, in this case I chose size and then we set a filter on the size using the -fs switch, this then means that every response ffuf gets that has a size of 1523 in our case will be ignored, when we get a response with a different size then we know we have our code and as above you can see our code is 1337 as it redirected us to dashboard.php.
Keep in mind your code will be different to mine most likely.

Exploitation

After entering our mfa code we get redirected to a dashboard that seems to have a couple file browsers which is interesting, lets see what we can do with these.

Testing out the file viewer, we can see that we can read /etc/passwd, this is handy to know, let's see what else we can explore.

After seeing what users are available we can see that we can navigate to jason's home directory, we can also view the user.txt file so that's an easy way to get our user flag.
Now lets find a way to get remote access to this machine.

Taking a look at jason's .ssh folder we can see a private ssh key, this is handy to have, lets put that file into the file viewer and copy it to our machine, don't forget to set the file permissions to 600 so that it can actually be used.

Using ssh2john we can convert the private key to a format john can accept, we can then run it through john to get the passphrase for the private key, now we should be able to ssh into jason's account.

And just like that we're in! Now let's see if we can get root.

Ah, well this will make things easy.

We don't have jason's password, so we aren't able to escalate to root, but we are able to run anything we want as fred without a password, so we simply run bash.
Now looking at what fred can run as sudo we can see that we can run /bin/systemctl restart fail2ban as root without a password, lets go ahead and exploit this so we can get a root shell.

PrivEsc

First we can check the fail2ban version using the above command.

Next we need to cd into the fail2ban directory which is located at /etc/fail2ban.
as we can see above there is a jail.local file, this is the file we want to look at first as this defines the configured jails for fail2ban.

As we can see ssh is configured in fail2ban so we know that's where we will be targetting, we can also see that after 3 failed attempts fail2ban will ban us, it is also using the ban action from iptables-multiport, usually in versions 1.0.1 and after it will use iptables.conf instead of iptables-multiport.conf.

Next we cd into the action.d directory, we can see that this directory is writeable by us, but we can't write to the iptables-multiport.conf file, so we will need to copy this to somewhere we can write to and then copy it back.

After copying the iptables-multiport.conf file, we need to comment out the actionban and put a new one in, the one we put in copies the bash file to tmp and then adds the suid bit to it.

Once that is done we need to copy it back to the action.d directory and then we can run the sudo command we have access to in order to restart the fail2ban service which will reload the conf files.

After restarting the fail2ban service we need to run hydra from our machine, we could also technically manually fail signing into ssh but running hydra for a few seconds is good enough, you can either use a small wordlist or just cancel hydra manually after several seconds.

Now back in our current ssh session we can check the tmp directory and see that bash was copied there and has had the suid bit set, so now all we need to do is run it with the -p switch and we should be root.

And just like that we're root! Now we can grab our root flag.