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);
}
die();
}

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.

Conclusion

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

Live Event: Wordfence Central Official Launch and Demo

Today we are very excited to announce the launch of Wordfence Central. Our team has been working hard for almost a year on this ground-breaking project. Wordfence Central gives you the power of a security events and information manager for WordPress.

Join me for a live event starting at 8am Pacific time, 11am EST where I will provide a walkthrough of the new product. I will also be taking your questions at the end of the event. Dan Moen, our head of product, will be joining me for the webcast.

You can pre-post your questions right here as a comment on this blog post. I will start off our Q&A by answering questions that have already been posted and you are welcome to post new questions while we are streaming.

This video is live with a delay of less than 3 seconds, so I will be able to take your questions in real-time. Please note that I may answer some questions offline due to time and content constraints.

I hope to see you tomorrow at 8am Pacific, 11am Eastern time!! Until then you can read the official Wordfence Central announcement on this page.

This live stream has ended.

Thank you to everyone who participated. In future we will record the live streams our team does. This has been a fun experiment and we received a lot of questions from everyone – thank you all so much for participating. It was a resounding success and we will be experimenting more with this medium in future.

Mark Maunder – Wordfence Founder & CEO.

The post Live Event: Wordfence Central Official Launch and Demo appeared first on Wordfence.

Read More

Introducing Wordfence Central

Over the last several months, we have been focused on making Wordfence a better option for organizations with a large number of WordPress sites to protect. To start, we added the ability to secure your staging and development environments with a single Wordfence premium license, something you should take advantage of if you haven’t already.

Next we changed the way we handle volume discounts to make managing a large number of sites easier.

Shortly after that we launched Wordfence Agency Solutions, empowering our client partners to develop custom security solutions for agencies and our enterprise customers.

Today we are thrilled to announce the launch of Wordfence Central. Wordfence Central provides an efficient way to manage the security of many WordPress sites in one place. It includes a powerful dashboard, a single interface to view and manage security findings across all of your sites and powerful new tools that make managing Wordfence configuration for your websites a breeze.

It’s Completely Free to Use

One of the first questions we get from people when we show them Central is, “What’s the catch? This can’t really be free, can it?”

There’s no catch, it’s really free.

You’re welcome to use Wordfence Central to manage all of your websites at no charge. There are no limits or restrictions of any kind.

The Wordfence Central Dashboard

The Wordfence Central Dashboard shows you the security status of your websites at a glance.

A high level summary of the latest scan tells you how many issues were discovered, along with a brief summary of the highest severity findings. You can view detailed findings with a single click, never leaving Wordfence Central.

High level metrics show you the current configuration status for the Wordfence firewall and scanner. The Premium license status lets you know which sites need to be upgraded. You can upgrade sites and update their configurations in just a few clicks, without ever leaving Wordfence Central.

Powerful sort, filter and search capabilities make managing even hundreds of sites a breeze.

Security Findings

Before Wordfence Central, keeping up with Wordfence scan results meant either visiting your sites regularly or reading through a constant flow of email alerts. Now you can view the current status of all your sites in one place, and drill down to view detailed findings without leaving Central.

In many cases you can take action on a finding without leaving Central. When you do need to visit your site to deal with a security finding, Central makes it easy by taking you to the relevant page with a single click.

If your site hasn’t been scanned recently, no problem! Launch a scan in Central and watch the results stream back in real-time.

Configuration

The default Wordfence configuration works for most site owners, but advanced users tend to make changes. As someone responsible for multiple sites, this can be a daunting task. With Wordfence Central you can now make those changes quickly and efficiently.

When you first land on the Configuration page in Wordfence Central you are greeted with a high level summary, showing you the current firewall, scan and premium license status for each site, whether a template has been applied to it and whether its configuration still matches the template. More on the magic of templates later!

To view or make changes to a site’s configuration you can simply click the “Manage Site” link, which will bring you to the equivalent of the “All Options” page in the Wordfence plugin. Once the changes you need to make are complete, hitting “Save Changes” will send your changes down to your site in seconds. It’s that easy.

Templates!

The real configuration workhorse in Wordfence Central is templates. Templates give you the ability to create and manage as many Wordfence configurations as you like. For example, you might want one template for your VIP clients and another for everyone else.

Templates make configuring new sites incredibly easy. Simply add the new site to Central, navigate to Configuration and apply a template to the new site. This will take care of 99% of the settings in Wordfence. Enabling “extended protection” for the firewall, which is strongly recommended, still requires a visit to the admin area of your site.

Getting Started

To get started with Wordfence Central, go to wordfence.com/central. You’ll be greeted with a high-level overview of Central including screenshots. To dive right in click the “Get Started” button. You will need to sign in or create an account if you don’t already have one.

Once you’re logged in you will be asked to set up two-factor authentication, or 2FA, for your account. It’s optional, but we strongly recommend that you set it up. Wordfence Central will have the ability to make changes to how Wordfence is configured for all of the sites you connect, so we want to take extra care to keep your account safe.

Once you’ve set up 2FA, you will be prompted to connect your first website. After you submit the site URL, Wordfence Central runs a quick series of connectivity checks. If everything checks out your site is added and you will be prompted to add another. It’s that easy.

Live-Stream Demo + Q&A

Tomorrow morning (Thursday) at 8am Pacific / 11am Eastern Mark Maunder, our CEO, will be live-streaming a Wordfence Central demo followed by Q&A. You can attend by visiting https://wordfence.com/blog/2019/02/wordfence-central-livestream/. Submit your questions via the comments for that post now and during the event.

Conclusion

We couldn’t be more excited about launching Wordfence Central this week. We hope it will make life easier for you, whether you manage three sites or three thousand. New features are already in the works, so expect to see additional functionality released throughout the year.

As always we’d love to hear from you in the comments and we hope you can join us for tomorrow’s live-stream demo and Q&A!

The post Introducing Wordfence Central 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;
die();
}

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);

die();
}

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; 
}else{ 
$_count = $_POST['interval_count'] ;
}

$plan = MStripe_Plan::create(
array(
"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;
die();
}

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;
die();
}

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( 
$wpdb->prepare( 
"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 ) ;
$row++;
}

echo json_encode($data);
die();
}

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."'";
$wpdb->query($sql); 
}

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"; 
}

die();
}

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);

if(is_user_logged_in())
do_action('wp_ajax_'.$action);
else
do_action('wp_ajax_nopriv_'.$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

Analyzing a Week of Blocked Attacks

If you’ve never taken a few minutes to look at the information available in the Wordfence Live Traffic feature, I strongly recommend it. It gives you a detailed look at what attackers are trying to do to break into your site, and how Wordfence is blocking them.

For today’s post we analyzed all of the blocked attacks on Defiant.com for a week. In order to see them in Live Traffic, I simply selected “Blocked by Firewall” from the “filter traffic” drop-down above the data table.

What Attackers Were Up To

For the week there were a total of 223 attacks blocked. I was excited to see that all of them were blocked by the Wordfence real-time IP blacklist. We are used to seeing really high percentages blocked by our blacklist – usually in the high 90s. The real-time IP blacklist is a Premium feature that blocks all requests from IPs that are actively attacking WordPress sites.

Attacks originated from 14 unique IP addresses from around the world. Of the countries represented, Germany was the origin for the most attacks at 85. India was second with 61 and France was third with 45. Other countries represented were Ukraine, South Africa, China, Italy and the United Kingdom.

Next we’ll break down what they were trying to do to break in.

Reconnaissance

Five of the IPs appeared to just be performing reconnaissance, as they were simply requesting our home page or some other page on the site. They were likely just checking to see if the site was up and responding to their requests. Since all of the IPs were on the Wordfence real-time IP blacklist, their requests were blocked and they moved on after a couple of blocked page requests.

Author Enumeration

A Chinese IP attempted to retrieve a list of author usernames for the site. Since the authors of posts are very often also administrators, this information can significantly improve the odds of success for a brute force password guessing attack. The attacks all look like the following:

https://www.defiant.com/?author=1

The attacker worked through fifteen author numbers before giving up and moving on. In the Wordfence “Brute Force Protection” settings, look for the following option to enable this feature:

“Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API”

Once you enable this, Wordfence will block these scans. This option is enabled by default and is available for both free and premium users.

We have blocked 382,131 attacks from that IP in the last 7 days across all of our customers. It seems quite likely that had the attempt to retrieve usernames been successful, attempts to log in using lists of common passwords would have followed.

Login Attempts Via XML-RPC

Sixty Three of the blocked attacks were attempts to log in to the site via the XML-RPC interface, which is an API developers can use to communicate with WordPress sites. We see a high percentage of brute force password guessing attempts hit this interface.

In our case we saw a single IP from Chennai, India attempt 61 login attempts in the period of just over an hour. Two other IPs, one in Hong Kong and another in Italy, made just one attempt each. They most likely moved on because they were blocked.

Login Attempts Via wp-login.php

We had just one IP attempt to login via the interface you use to login your site. The first attempt to login was followed immediately by an attempt to access our home page. The script was most likely checking to see if they were only being blocked from accessing the login page or the entire site. A second attempt following the same pattern occurred just two minutes later. We didn’t see additional attempts from that IP. I assume the attacker’s bot is programmed to move on if it’s blocked twice in a row.

A French IP Probes for Opportunities

A single French IP sent 43 requests in a 33 second burst. The first was a simple home page request, which I assume was an attempt to verify the site was up and accepting requests. Surprisingly the attack continued despite being consistently blocked by the Wordfence firewall. The following are a few examples of what the attacker was up to.

One request was checking for the existence of a known malicious file, commonly used by attackers to upload files to hacked websites. The request looks like this:

https://www.defiant.com/wp-upload-class.php

Another interesting request was looking for opportunities to exploit fresh WordPress installs, which we wrote about in July of 2017. Here’s what the request looks like:

https://www.defiant.com/wp-admin/setup-config.php?step=1

We also saw two attempts to find a copy of searchreplacedb2.php laying around. In July of 2017 we wrote about how hackers use the searchreplacedb2.php script to make malicious database changes. Here’s an example request:

https://www.defiant.com/searchreplacedb2.php

A German IP Probes for Opportunities

A single IP from Hirschfield, Germany attacked our site 85 times in just under two minutes. Most of the attacks were repeats of what we saw from the French IP. So it’s possible that it was a different bot at work for the same attacker. However, this IP also attempted to exploit a number of known theme and plugin vulnerabilities.

All of these attempts to exploit known vulnerabilities were trying to download the wp-config.php file, which is a WordPress file that includes the database credentials for the site. If successful, these attacks would give the attacker an easy route to obtaining administrative control of target website.

In one example, the attacker is attempting to exploit an arbitrary file download vulnerability in the “Epic” theme that was disclosed way back in 2014.

https://www.defiant.com/wp-content/themes/epic/includes/download.php?file=wp-config.php

In another, the attacker is trying to exploit a different arbitrary file download vulnerability – this time in the WP Hide & Security Enhancer plugin. The vulnerability was disclosed less than six months ago.

https://www.defiant.com/wp-content/plugins/wp-hide-security-enhancer/router/file-process.php?action=style-clean&file_path=%2Fwp-config.php

It’s important to note that we are not running any of the themes or plugins this attacker is attempting to exploit on Defiant.com. Many of the attacks on WordPress sites are what we often refer to as “spray and pray” attacks, where the attacker simply tries hundreds or thousands of exploit attempts hoping to get lucky. It’s likely that attack volumes are lower for Defiant.com because it’s protected by the Wordfence real-time IP blacklist. Like you, attackers don’t want to waste resources. If all of their attacks are being blocked they will move on to an easier target.

Conclusion

As you know, WordPress sites are under constant attack. There are many attackers, all of whom deploy different tactics. The free version of Wordfence includes protection for all of the attacks outlined above. For even better peace of mind, and likely lower attack volumes, consider upgrading to Wordfence Premium. For only $8.25 per month (billed annually) you can put the Wordfence real-time IP blacklist to work protecting your site around the clock.

The post Analyzing a Week of Blocked Attacks appeared first on Wordfence.

Read More

Analyzing a Week of Blocked Attacks

If you’ve never taken a few minutes to look at the information available in the Wordfence Live Traffic feature, I strongly recommend it. It gives you a detailed look at what attackers are trying to do to break into your site, and how Wordfence is blocking them.

For today’s post we analyzed all of the blocked attacks on Defiant.com for a week. In order to see them in Live Traffic, I simply selected “Blocked by Firewall” from the “filter traffic” drop-down above the data table.

What Attackers Were Up To

For the week there were a total of 223 attacks blocked. I was excited to see that all of them were blocked by the Wordfence real-time IP blacklist. We are used to seeing really high percentages blocked by our blacklist – usually in the high 90s. The real-time IP blacklist is a Premium feature that blocks all requests from IPs that are actively attacking WordPress sites.

Attacks originated from 14 unique IP addresses from around the world. Of the countries represented, Germany was the origin for the most attacks at 85. India was second with 61 and France was third with 45. Other countries represented were Ukraine, South Africa, China, Italy and the United Kingdom.

Next we’ll break down what they were trying to do to break in.

Reconnaissance

Five of the IPs appeared to just be performing reconnaissance, as they were simply requesting our home page or some other page on the site. They were likely just checking to see if the site was up and responding to their requests. Since all of the IPs were on the Wordfence real-time IP blacklist, their requests were blocked and they moved on after a couple of blocked page requests.

Author Enumeration

A Chinese IP attempted to retrieve a list of author usernames for the site. Since the authors of posts are very often also administrators, this information can significantly improve the odds of success for a brute force password guessing attack. The attacks all look like the following:

https://www.defiant.com/?author=1

The attacker worked through fifteen author numbers before giving up and moving on. In the Wordfence “Brute Force Protection” settings, look for the following option to enable this feature:

“Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API”

Once you enable this, Wordfence will block these scans. This option is enabled by default and is available for both free and premium users.

We have blocked 382,131 attacks from that IP in the last 7 days across all of our customers. It seems quite likely that had the attempt to retrieve usernames been successful, attempts to log in using lists of common passwords would have followed.

Login Attempts Via XML-RPC

Sixty Three of the blocked attacks were attempts to log in to the site via the XML-RPC interface, which is an API developers can use to communicate with WordPress sites. We see a high percentage of brute force password guessing attempts hit this interface.

In our case we saw a single IP from Chennai, India attempt 61 login attempts in the period of just over an hour. Two other IPs, one in Hong Kong and another in Italy, made just one attempt each. They most likely moved on because they were blocked.

Login Attempts Via wp-login.php

We had just one IP attempt to login via the interface you use to login your site. The first attempt to login was followed immediately by an attempt to access our home page. The script was most likely checking to see if they were only being blocked from accessing the login page or the entire site. A second attempt following the same pattern occurred just two minutes later. We didn’t see additional attempts from that IP. I assume the attacker’s bot is programmed to move on if it’s blocked twice in a row.

A French IP Probes for Opportunities

A single French IP sent 43 requests in a 33 second burst. The first was a simple home page request, which I assume was an attempt to verify the site was up and accepting requests. Surprisingly the attack continued despite being consistently blocked by the Wordfence firewall. The following are a few examples of what the attacker was up to.

One request was checking for the existence of a known malicious file, commonly used by attackers to upload files to hacked websites. The request looks like this:

https://www.defiant.com/wp-upload-class.php

Another interesting request was looking for opportunities to exploit fresh WordPress installs, which we wrote about in July of 2017. Here’s what the request looks like:

https://www.defiant.com/wp-admin/setup-config.php?step=1

We also saw two attempts to find a copy of searchreplacedb2.php laying around. In July of 2017 we wrote about how hackers use the searchreplacedb2.php script to make malicious database changes. Here’s an example request:

https://www.defiant.com/searchreplacedb2.php

A German IP Probes for Opportunities

A single IP from Hirschfield, Germany attacked our site 85 times in just under two minutes. Most of the attacks were repeats of what we saw from the French IP. So it’s possible that it was a different bot at work for the same attacker. However, this IP also attempted to exploit a number of known theme and plugin vulnerabilities.

All of these attempts to exploit known vulnerabilities were trying to download the wp-config.php file, which is a WordPress file that includes the database credentials for the site. If successful, these attacks would give the attacker an easy route to obtaining administrative control of target website.

In one example, the attacker is attempting to exploit an arbitrary file download vulnerability in the “Epic” theme that was disclosed way back in 2014.

https://www.defiant.com/wp-content/themes/epic/includes/download.php?file=wp-config.php

In another, the attacker is trying to exploit a different arbitrary file download vulnerability – this time in the WP Hide & Security Enhancer plugin. The vulnerability was disclosed less than six months ago.

https://www.defiant.com/wp-content/plugins/wp-hide-security-enhancer/router/file-process.php?action=style-clean&file_path=%2Fwp-config.php

It’s important to note that we are not running any of the themes or plugins this attacker is attempting to exploit on Defiant.com. Many of the attacks on WordPress sites are what we often refer to as “spray and pray” attacks, where the attacker simply tries hundreds or thousands of exploit attempts hoping to get lucky. It’s likely that attack volumes are lower for Defiant.com because it’s protected by the Wordfence real-time IP blacklist. Like you, attackers don’t want to waste resources. If all of their attacks are being blocked they will move on to an easier target.

Conclusion

As you know, WordPress sites are under constant attack. There are many attackers, all of whom deploy different tactics. The free version of Wordfence includes protection for all of the attacks outlined above. For even better peace of mind, and likely lower attack volumes, consider upgrading to Wordfence Premium. For only $8.25 per month (billed annually) you can put the Wordfence real-time IP blacklist to work protecting your site around the clock.

The post Analyzing a Week of Blocked Attacks 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 WordPress.org 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 WordPress.org 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 WordPress.org 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: https://twitter.com/fs0c131y/status/1085828997013954560

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 WordPress.org 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.

Conclusion

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

WordPress 5.0.1 Security Release – Immediate Update Recommended

WordPress 5.0.1 was released Wednesday night, less than a week after the much anticipated release of WordPress 5.0. This security release fixes seven security vulnerabilities, a few of which are quite serious.

Sites running versions in the 4.x branch of WordPress core are also impacted by some of the issues. WordPress 4.9.9 was released along with 5.0.1 to address the issues for those users.

We have not seen attempts to exploit these vulnerabilities in the wild yet, but given the number of sites impacted we expect that to change.

The speed at which these security issues were discovered, reported and fixed is a testament to the strength of the WordPress community working together.

Vulnerability Details

Sensitive Data Exposure

Team Yoast discovered that the user activation screen could be indexed by search engines in some uncommon configurations, leading to exposure of email addresses, and in some rare cases, default generated passwords. WordPress has addressed this by stripping the activation key used in the URL, and storing the value in a cookie instead.

PHP Object Injection

Sam Thomas discovered that contributors could craft meta data in a way that resulted in PHP object injection. This looks to be similar to the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. This vulnerability allows an author to assign an arbitrary file path to an attachment. The file path supplied by the author uses the phar:// stream wrapper on a previously uploaded attachment which leads to object injection utilizing a “feature” of the PHAR file type which stores serialized objects in the metadata of the PHAR file. Sam Thomas presented this technique at BlackHat earlier this year.

Unauthorized Post Creation

Simon Scannell of RIPS Technologies discovered that authors could create posts of unauthorized post types with specially crafted input. The requirement that an attacker would need at least ‘author’ level privileges makes the likelihood of this being exploited on a widespread basis very low.

Privilege Escalation / XSS

Tim Coen discovered that contributors could edit new comments from higher-privileged users, potentially leading to a cross-site scripting vulnerability. This is another vulnerability that requires a higher-level user role, making the likelihood of widespread exploitation quite low. WordPress addressed this issue by removing the <form> tag from their HTML whitelist.

Privileged XSS

Tim Coen and Slavco discovered that users with ‘author’ privileges on Apache-hosted sites could upload specifically crafted files that bypass MIME verification, leading to a cross-site scripting vulnerability. Yet again, the ‘author’ level user requirement makes an unlikely target for attackers.

XSS That Could Impact Some Plugins

Tim Coen also discovered that specially crafted URL inputs could lead to a cross-site scripting vulnerability in some circumstances. The code change in WordPress core affects the wpmu_admin_do_redirect function which is not used in WordPress, but a plugin may call this function somewhere.

Unauthorized File Deletion

Karim El Oeurghemmi discovered that author-level users could alter metadata to delete files that they weren’t authorized to. This issue stems from the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. The fix in WordPress addressed how attachment files are deleted, by restricting the file paths to the uploads directory, but did not address the issue of authors having the ability to change the attachment paths to arbitrary files. An author can use this to delete other users’ attachments.

What To Do

We have released firewall rules to protect our Premium customers against the vulnerabilities most likely to be exploited. Sites running the free version of Wordfence will receive them in 30 days.

Sites on WordPress 5.0 should update to version 5.0.1 as soon as possible. Those with automatic updates enabled for WordPress core should have already been updated, but given the nature of the vulnerabilities we recommend you check your sites manually just in case.

Sites running WordPress 4.x versions should update to version 4.9.9 as soon as possible. We’ve heard conflicting reports about automatic updates working for this upgrade. If you need to manually upgrade, the 4.9.9 update can be downloaded here.

You can find the official release announcement from the WordPress team here.

The post WordPress 5.0.1 Security Release – Immediate Update Recommended appeared first on Wordfence.

Read More

WordCamp US Recap

WordCamp US was held in Nashville, Tennessee this year. We sponsored the event, had a booth and of course provided lock picking lessons, as has become our tradition at WordCamps. Our goal is to get you to think like a hacker, so that you can better secure your sites. Picking a lock really gets you into that mindset. Plus it is a lot of fun!!

From our team we had Sean Murphy – Director of Threat Intelligence, Tim Cantrell – Customer Service Engineer, Dan Moen – Chief Marketing Officer, Kathy Zant – Client Partner and of course me, Mark Maunder – CEO.

We sponsored 13 WordCamps this year and our team spoke at an additional three. I attended Atlanta, Los Angeles, Portland (Oregon), Vancouver (BC), Seattle and Nashville. On a personal note WCUS was intense for a few reasons. Our team has traditionally attended security conferences like DEF CON, Black Hat, RSA, DerbyCon and more – and we haven’t spent much time attending or sponsoring WordCamps. This year we changed that and put a lot of energy into engaging with the WordPress community.

By the time WCUS rolled around I had already made a lot of friends across the industry. In many cases, these are people in the WordPress community that I have been engaging with for over 6 years via Slack or email but have never met in person. Others I met at WordCamps across the country and when WCUS arrived, it was like a giant reunion which was a lot of fun.

One of my favorite new friends from this year’s WordCamps is Matt Mullenweg, the WordPress founder. I had the pleasure of having a beer with Matt at WordCamp Portland, where he made a surprise appearance. My colleagues Kathy Zant, Mikey Veenstra and I spent over 2 hours just hanging out with Matt in Portland and chatting. Matt is a really cool dude and we again met up at WCUS a few times. Matt came around to our booth and it turns out he has been into lock picking for some time and is quite good at it! (Photo below)

One of the things I love about WordCamps is it really brings the community together, including vendors like us and our peers in cybersecurity. My colleague Kathy Zant is deeply involved in the WordPress community and has made many friends across the industry. This is one of my favorite pictures from WCUS.

From left to right: Alycia Mitchell from Sucuri/GoDaddy, Jamie Schmid from SiteLock, our own Kathy Zant from Wordfence and Rianna MacLeod from Sucuri/GoDaddy.

 

I would be remiss if I didn’t mention Kathy Zant from our team in a bit more detail. Kathy has the most incredible energy and she really brought it at WCUS and WordCamps throughout the year that we sponsored. I would show up at our booth to set up at 7:30am to find that Kathy had already been there for an hour and was just about done booth-building.

Or I’d show up at 9am on a Sunday morning because I was up till 3am the previous evening “networking”, and Kathy was at the booth bright and early chatting with customers and solving security problems. During gaps at the booth she would be on her phone helping our larger customers with their challenges in her role as client partner. And as if that isn’t enough, Kathy is an Executive Producer on a certain project we are collaborating on (I think many of you already know what that is – more news on that soon) and is of course completely owning that role too. And most of that work happens at WordCamps.

Kathy. Is. Amazing.

During WordCamp Atlanta I had the great pleasure of meeting Kathy Drewien, one of the Atlanta organizers. Kathy is also an organizer for WordCamp US and of course we spent some time catching up. Kathy does a lot for WordCamps around the US and my team and I are very grateful for her contribution!!

This is a rather hasty selfie of Kathy Drewien and me at WordCamp US in front of our booth. Looks like Dan and Tim are having an animated conversation behind us and a few visitors are busily picking locks. Kathy Zant is on the far right talking to customers. As you can tell we fully utilized our booth space, and will most likely get a larger space next year.

 

WCUS is awesome. There is no other way to put it. By 9am every morning my body was producing its own caffeine, and by the time the evening came around I was literally high on life after spending time with the most incredible people. If you are passionate about WordPress, WCUS is Disneyland for WP.

This is Tim Cantrell with one of the harder practice locks we had at our table. A lot of our students had a hard time picking this one!!

 

This is Kathy Zant surrounded by her newly minted lock picking prodigies, working on a difficult lock of her own. Tim is on the right answering customer questions.

 

This is Matt Mullenweg with Josepha Haden from Automattic picking locks and chatting with Tim Cantrell.

 

The after-party for WCUS was held at the Adventure Science Center in Nashville. One of my life goals has been to go to a party that has beer at a science center. Goal achieved!!

This is a photo of me and another WCUS attendee battling it out on a mind game. You put a strap with electrodes on your forehead and the goal is to calm your mind as much as possible. The person with calmer mind pushes a ball towards their goal. I got absolutely killed on this game within a few seconds. My colleague apparently has a way calmer mind than I do. This was the moment of my defeat.

 

The after-parties hosted by sponsors were incredible. They really allowed our team and the attendees to experience Nashville, and Broadway in particular. The first time I walked onto Broadway my jaw dropped. I hadn’t actually heard much about Nashville’s party central, and the light show was incredible. I took this photo.

 

Thank you very much to the City of Nashville for hosting WordCamp US 2018. We had a wonderful time in your amazing city. I will be visiting again even if I can’t find a conference to attend. See you all in St Louis next year for WordCamp 2019. The Wordfence team will definitely be there!

~Mark Maunder

The post WordCamp US Recap appeared first on Wordfence.

Read More

How We Think About WordPress Security and Research

This weekend I had a really fun conversation with Doc Pop from Torque Magazine. Torque is a great news source for WordPress news. They are part of WP Engine, but maintain editorial independence.

I chatted with Doc in Nashville, in the Music City Center where WordCamp US was being held. Music City Center is an amazing facility and you can see some of it in the background of our interview. Nashville is also an incredible city. We will be posting a roundup of WordCamp US tomorrow morning.

In our conversation, Doc asked me various questions about WordPress security and the research we do. He got me talking about how we work, how we think about security, responsible disclosure of vulnerabilities and WordPress security in general.

The video of the interview is below. I’ll be around to answer any questions in the comments.

~Mark Maunder

 

The post How We Think About WordPress Security and Research appeared first on Wordfence.

Read More
Page 1 of 1,01212345»102030...Last »