Last week through our proactive monitoring of changes made to WordPress plugins in the Plugin Directory to try to catch serious vulnerabilities we found a vulnerability that would be likely to be exploited in the plugin Social Warfare, which has 70,000+ active installations according to wordpress.org. Due the continued unwillingness of Matt Mullenweg or anyone on the WordPress team to rein in the inappropriate behavior of the moderators of the WordPress Support Forum the vulnerability got full disclosed and a lot of websites got hacked when they didn’t need to. The plugin was removed from the Plugin Directory after our disclosure and subsequently restored with the vulnerability removed, but the insecure code that surrounded it remained unchanged. That seems like something that team running the Plugin Directory should have caught since our post went through what the insecure code was, but they don’t seem to have a great grasp of security, which the inappropriate behavior of the moderators of the Support Forum helps to hide.

To give us a better understanding of the how secure or insecure in general a plugin that had such an easily spotted serious vulnerability is, we did some more checking over the plugin. What we found is that the code had numerous security issues and there clearly wasn’t a consistent handling of security in the plugin. The code also seems like it is need of cleanup, as in one place we found insecure code that appears to relate to functionality that isn’t even active in the plugin anymore.

If someone wants an exhaustive security review of the plugin done, we offer just such a service for doing that, but for the moment let’s give you an example of a security vulnerability we found in that checking.

The plugin causes the function save_user_profile_fields() to run when a user is changing their profile settings:

93

add_action( 'personal_options_update', array( $this , 'save_user_profile_fields' ) );

That function will set unsanitized user input to two settings for the user, “swp_twitter” and “swp_fb_author”:

93
94
95
96
97
98
99
100
101

public function save_user_profile_fields( $user_id ) {
 
	if ( ! current_user_can( 'edit_user', $user_id ) ) {
		return false;
	}
 
	update_user_meta( $user_id, 'swp_twitter', $_POST['swp_twitter'] );
	update_user_meta( $user_id, 'swp_fb_author', $_POST['swp_fb_author'] );
}

While that should be sanitized, as long as the value is escaped when output that would avoid there being a vulnerability.

When the values are output on the Profile admin page, /wp-admin/profile.php, they are escaped:

66

echo '<input type="text" name="swp_twitter" id="swp_twitter" value="' . esc_attr( get_the_author_meta( 'swp_twitter' , $user->ID ) ) . '" class="regular-text" />';

73

echo '<input type="text" name="swp_fb_author" id="swp_fb_author" value="' . esc_attr( get_the_author_meta( 'swp_fb_author' , $user->ID ) ) . '" class="regular-text" />';

But, speaking of inconsistent handling of security, that doesn’t happen when the value is output on the frontend page authored by the user. Which, since there is a lot of code that leads to that, we won’t through all the code, but you can see it in action with the proof of concept below. That is what is referred to an authenticated persistent cross-site scripting (XSS).

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Proof of Concept

When logged in as an Author level user, set the value of the “Twitter Username” profile setting to:

"><script>alert("XSS");</script>

Then when visiting a post created by that user an alert box with the message “XSS” will be shown.

Concerned About The Security of the Plugins You Use?

Plugin Security Scorecard Grade for Social Warfare

See issues causing the plugin to get less than A+ grade