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.

Did you enjoy this post? Share it!

Comments

26 Comments
  • Hello Mikey,

    Thank you for reporting the issue in Easy WP SMTP plugin. I have used the plugin almost all of my clients website. I updated it now. It would be huge loss if something bad happens with my clients website. You saved me from disaster.

    Thank you again.

  • Thank you Mike for sharing this very detailed post. Our site @ Smartwatch Series had the Easy SMTP plugin active and it didn't take long before it was infiltrated few days back, but fortunately we noticed on time that visitors where being redirected to malicious sites and wp-admin redirected to getmytraffic . Com, showing very ugly codes.

    The first point of action was to move the site to a different folder to prevent our visitors from getting redirected to those malicious sites until we were able to restore backup. (Luckily, we did backup everyday)

    So, we simply restored backup. But digging further, we noticed the hacker was able to access the wp_option table on our database.

    At the first line of the table, where there's (siteurl), instead of our home page url, it was the hacker getmytraffic . Com url. So, the redirecting was done from the hackers server.

    It's true, WP SMTP have fixed this issue, but we simply have already deactivated the pluggin till further notice.

    We've changed password and name of our database. It's very important for administrators to backup daily, especially if the site is updated frequently.

    We installed Wordfence immediately too and did a site-wide scan. A lot of people recommended Wordfence, so henceforth it will play active role in keeping our site secured.

    Once again, thanks to the Wordfence team for the efforts and great services offered to help keep sites safe.

    Best regards, Jude.

  • Hello sire, I am using wordpress, everytime when i am logged in my blog, it is asking it is not secure. then I need to click on login again. after that, I am in. is there any problem with my blog or wordpress settings?

    Please suggest.
    thanks

    • Hi Suraj, without seeing the exact error you're receiving it's hard to tell what might be going on. Unfortunately, we don't provide support in our blog comments. If you think this is a WordPress issue, you might have luck on the WordPress.org support forums at this address: https://wordpress.org/support/

  • So does WordFence actually block attacks like this?

    • We sure do! It's a brand new WAF rule, so currently it's exclusive for Premium users.

  • thanks for the heads up.. got a few sites infected but was able to clean them (hopefully).
    And i though was compromised for using php 5.6

  • Why was the vulnerability disclosed **with** a POC on the same day that the patch was released by the plugin author?

    Why not give users of the plugin some time to get their systems updated before making the POC public?

    Given the severity of the exploit, one would think that at least a day or two would have allowed site owners to be notified of the need for the plugin upgrade.

    • Hi Christopher,

      This is definitely a point of contention in the security community. Even within our own team we've got some difference in opinion on whether a PoC was appropriate or not.

      In this case specifically, there was evidence the vulnerability was under active attack before a patch was developed. Put simply, it was already in the hands of the bad actors. Even if it weren't, the "head start" given to attackers by a PoC is usually pretty minimal.

      If a delay is necessary, such as to allow users more time to update, the entire vulnerability disclosure process needs to be delayed. The reason here is that any threat actor encountering a disclosure will be able to compare versions and work out an exploit themselves, whether a PoC was made public or not. Delaying such a disclosure may be an option when no attacks are happening, but keeps security teams and administrators in the dark when they are.

      In short, people would be attacking this within hours of the disclosure whether there was a PoC in it or not. The silver lining is that a bunch of attackers using the exact same exploit techniques are VERY easy to track from a threat intelligence perspective.

  • I spotted this a couple of days ago only after seeing an infected site and checking the changelog of all the plugins.

    It affected only the sites running 1.3.9 (typically those updated during March).

    With the redirect running you cant get back into an infected site via the dashboard to runs a scan. You need to go via your database directly (contact you host if you need to).

    Only the site_url had been changed on mine (and the new admin account added)

    Fix it by:

    1. Editing the site_url via the wp-options database (this should let you back into the site)
    2. Access site backend and remove malicious admin account (filet your user accounts to show only admins if you have lots of users)
    3. Update to the latest version of the Easy WP SMTP plugin 1.3.9.1
    4. Change your database password and any other insecure content an admin could see.
    5. Run a wordfence scan on the site and leave wordfence active.

  • Great work! Thank for this info!

  • Hi,
    Thanks for the important heads up!
    Being lazy saved me here: I had not yet updated to version 1.3.9 but instead was running an older version 1.3.7 and as such was not exposed to this vulnerability. Not good practice, but the paradox is that I was not exposed :)

    thanks for the great work,

  • I had a client site hacked on 19/03/2019 which was running v1.3.9 of Easy SMTP and redirected my client site to getmyfreetraffic.com. Spent all of yesterday getting to the bottom of it and restoring site.

    What are we meant to do as developers when we are constantly being told to update our site plugins to the latest versions. But if I hadn’t updated Easy SMTP plugin to the latest version (when they released v1.3.9 which added Export\Import settings functionality vulnerability) my client site wouldn’t have been hacked!

    Hard-place, I, Rock, am, between, caught....

    • It is indeed unfortunate when a new feature brings along a vulnerability. However, "always update" is a much stronger best practice than the opposite in the absence of a more structured deployment policy.

  • We had both of these hacking issues spread across three different sites. I wanted to add another user that was created on one of those sites. The user AdminZax with the email siid.donavan12345@gmail.com in case anyone else is out looking for a solution to this problem and had that email show up.

  • Had 5 sites hit, 2 while we were cleaning up the first 3 hits. I update plugins every 2 days on all sites, guess that is not enough. All hacks traced to devidpentesting99.

    Wordfence Cenral helps save a lot of time updating.

  • I wish I saw this yesterday! Overnight, one of my sites had this vulnerability exploited. The siteurl and home values were both changed to setforconfigplease[.]com. Thanks for the blog post. It saved me a lot of time.

  • One of my sites also succumbed to this. Interestingly they changed the site URL but did not add any admin account, nor change the setting to allow anyone to register. Nor were there any injected. Also the plugin is showing as the latest version. Is it possible the attacker could change the version number in the plugin list to make you believe it is updated? I've zipped up the old version and reinstalled a fresh copy.

    • Hi there!

      If your site was compromised and you're unsure what was done, it is likely worth reverting to an older backup copy of your site.

      As for whether an attacker could spoof the version of plugins, it's technically possible but nothing we've seen evidence of.

  • I got a client's website infected - probably a few days ago. The version of the plugin was 1.3.9.
    Thanks to your security bulletin, I checked all of my clients websites which are running this plugin and I discovered one of them was redirected to a malicious website.
    No file were altered but the wp_options table was compromised. The URL and the root of the website got changed. I restored both records and I got my access to the admin back.
    I did not found any new/odd administrator account but two settings had been changed: the default role was set to "admin" and "everyone can register" was set to "yes".
    I changed the passwords of all users, just in case, and of course I updated everything (I usually update this website manually once a month).

  • Additional to my previous comment. The IP 185.212.129.204 was also one of the IPs that "devidpentesting99" connected from. I've blocked them in the servers at the firewall.

    • Thanks Andrés. This IP was added to our real-time IP blacklist on the 21st at 17:51:56 UTC. We've blacklisted 157,157 unique IPs in the last 30 days.

  • Thanks for Update team,

    Following values found in one of the site I manage.

    siteurl: https://redrentalservice.com/tpn1.js
    home: https://redrentalservice.com

    Admin user : devidpentesting99

  • It is hard to understand why someone would publish a "how-to" hacking code dump publicly. It is a little reckless. At least make the code non-functional so it could not be lifted by would-be attackers who cannot write the code themselves. From what it sounds like, the bad code was used verbatim from a published vulnerability report. There has to be a better way to inform web security professionals without also giving away the bomb recipe. Just sayin... and yes, I got hacked too because I updated the plug-in as soon as I was told.

    The other issue is that plug-in makers like WP Easy SMTP are not warning people on their plug-in page. For something this big, users should be warned more explicitly. They should also put release dates on the versions since that would help people figure out timelines and which backup to use.

  • Hacked on two sites via the Easy WP SMTP vulnerability by two separate entities; the second entity (not mentioned on this page) added a plethora of unique admin users over time (unpredictable and not mentioned on this page; some from aonbola.info). The plugin admin suggests changing "WP administrator and your SMTP" passwords but I also *suggest changing your WP DB password immediately* as well.

    This one was a doosey. I agree with Andrew above... what the hey?

  • The other issue is that plug-in makers like WP Easy SMTP are not warning people on their plug-in page. For something this big, users should be warned more explicitly.