Part 6 – The Importance of Responsible Disclosure

This section of the report looks at the importance of responsible disclosure. I do this by carrying out an analysis of Wordfence attack data following the responsible disclosure of vulnerabilities in two WordPress plugins, and comparing this to attack data following the irresponsible disclosure of a plugin vulnerability.

In order to determine disclosures to investigate, it was necessary to look at a number of factors, including:

• Can the vulnerability be exploited without authentication?
• Are any specific non-default settings required for this vulnerability to be exploitable?
• Can arbitrary options be modified?
• Can this vulnerability be used to deliver an XSS payload?
• How many steps are required to compromise a site?
• What is the install base of the component? i.e.  The number of installations.

To do this, the report will look at examples of responsible disclosure and those disclosed irresponsibly and analyse the different impact these disclosures had on attacks on WordPress sites globally. We will initially look at vulnerabilities in the Easy WP SMTP plugin which was responsibly disclosed by NinTechNet in March 2019 (Bruandet, 2019).

The developers describe the plugin as follows:

“Easy WP SMTP allows you to configure and send all outgoing emails via a SMTP server. This will prevent your emails from going into the junk/spam folder of the recipients.” (WordPress.org, 2019)

As WordPress installations will often use a local sendmail type implementation to send out mail to users or administrators, this will sometimes cause problems with the messages being blocked by receiving mail servers or clients. This plugin allows administrators to configure the site to send mail using an email account on a mail server which reduces the chance of this happening. This makes it a popular plugin, with currently over 400,000 active installs.

In terms of irresponsible vulnerability disclosures, the report will look at disclosures made by an unnamed security researcher who regularly makes such disclosures. They make disclosures in this way due to a dispute with the WordPress forum moderators.

(I have edited this section from the original to prevent publicising details of this researcher)

Their disclosure of the Social Warfare vulnerability is a good example of this type of behaviour. The WordPress download page describes the plugin as:

“Get more social shares which can lead to more website traffic with the best WordPress social sharing plugin! Built by a group of social media marketing experts and world class developers who are obsessed with performance” (WordPress.org, 2019)

It is essentially a plugin that allows site owners to add buttons to a site that allows visitors to easily share content on social media. This plugin has an install-base of 70,000 (less than a quarter of the install-base for Easy WP SMTP). The analyst described this as a drive-by XSS vulnerability, however further analysis by Defiant researchers determined it also allowed full Remote Code Execution (RCE). 

We will also take a look at another example of a responsible disclosure by Defiant concerning vulnerabilities in the Convert Plus plugin. 

Though the specifics of the exploit are different from others, this one allowed unauthenticated users to create administrator accounts, giving them full control of the site. This plugin has an install base of around 100,000. The vulnerability was discovered on Friday 24 May 2019. A patch was released by the developers on 28 May and the disclosure was made by Mikey Veenstra of Defiant the following day. (Wordfence.com, 2019)

Defiant holds historical data for attack attempts made trying to use these vulnerabilities to hack WordPress sites, dating back to their disclosure. It should be noted that these figures are for the number of attacks that were attempted by hackers to exploit the vulnerability in this plugin that were blocked by Wordfence. For Wordfence to have blocked and logged these attacks in the Defiant database, they will obviously need to have been made against WordPress sites where Wordfence was installed. There will have been many other attacks attempted against WordPress sites where Wordfence was not installed and as such there is obviously no data on this. These figures can, however, give an indication of the scale of hacking campaigns attempting to exploit these vulnerabilities. 

Easy WP SMTP Vulnerability – A Responsible Disclosure

Jerome Bruandet of NinTechNet described the vulnerability in their blog post on 17 March 2019. This was a responsible disclosure. He illustrated that the vulnerability allowed unauthenticated changes to the options table in WordPress databases running this plugin. It was found to exist in v1.3.9 of the plugin and they had seen the vulnerability being exploited from at least 15 March – two days earlier. They acted responsibly by contacting the plugin authors and the wordpress.org team on the same day. The authors fixed the issue and released version 1.3.9.1 on 17 March 2019, before NinTechNet released the blog post disclosing the vulnerability to the public later that day. Wordfence blogged about the vulnerability a couple of days later.

The Proof of Concept (PoC) demonstrated by NinTechNet looked like this:

• 

This had the effect of allowing anyone to register as a user and set the default user role as administrator. Anyone would then be able to register as an administrator, log in and compromise the site further in any way they chose. (Bruandet, 2019)

This vulnerability involves more than one step to compromise a site – the attacker must first upload the new settings, then determine if it has been successful by creating a new administrator user, and finally log on as administrator and inject whatever additional payload they wish. As we will see with the other vulnerabilities, this is possibly less desirable to hackers as there is more manual work involved.

Defiant holds data showing blocked attacks for the relevant period that this vulnerability was disclosed. There are a number of ways this attack could be blocked by the Wordfence Web Application Firewall (WAF). Firstly, the hackers could be launching attacks from IP addresses that are on the Wordfence blacklist – i.e. they are known to have been used by hackers in the past. The attacks could also be logged if the IP addresses launching the attacks are on the watchlist – that is a list of IP addresses that have been listed as suspicious due to previous malicious activity. The attacks could also have either been blocked due to existing rules for things like XSS attacks, or they could be blocked due to specific rules created to block specific attacks against known vulnerabilities.

Figure 6.1 – Number of Attacks against the Easy WP SMTP Plugin Vulnerability in the 30 Days Following Disclosure

This graph illustrates that there was a spike of attacks on 21 March, gradually going down to single figures over the ten days following the responsible disclosure. The total number of attacks of this type blocked over this 30-day period was 51,129.

Analysis was also carried out into the number of site cleaning cases raised over the 30 days following disclosure, where the analyst determined that the intrusion vector (IV) was through the exploit of this vulnerability. This data was obtained by carrying out an analysis of the site cleaning reports created by the analyst carrying out the clean. There were around 300 site cleaning tickets to analyse for this period. 

It can be seen from Figure 6.2 below, that other than two spikes in activity, one in March when the disclosure was made, and again in September, there was little activity against this vulnerability outside of these campaigns.

Figure 6.2 – Number of Easy WP SMTP Attacks Blocked in the Months After Disclosure

We can see from Figure 6.3 below, customers started to find that their sites were hacked and raised a request to have their sites cleaned from 18 March onwards.

Figure 6.3 – Number of Easy WP SMTP Vulnerability Related Site Cleaning Tickets Raised in the Days Following Disclosure

Over this 30-day period, 20% of tickets were raised as a result of customers’ sites being attacked through this vulnerability. At its height, 100% of related tickets raised on the 19th March were attributable to the Easy WP SMTP vulnerability.

Social Warfare Vulnerability – Irresponsible Disclosure

As mentioned, this vulnerability was disclosed by an unnamed security researcher in an irresponsible way, without having first discussed the vulnerability with the plugin developer. The disclosure was made on 21 Mar 2019.

The following is the specific line of code which enables this vulnerability:

The following is an example of this vulnerability being exploited from the apache logs:

This unnamed security researcher failed to realise that this vulnerability also allowed Remote Code Execution (RCE). The Threat Intelligence team at Defiant were quick to release a firewall for this vulnerability and carried out additional research which identified the RCE. The plugin’s author also released a fix for the vulnerability shortly after the unexpected disclosure. The knowledge of this RCE element of the vulnerability was initially withheld until it could be certain that the majority of users had patched their installations. Defiant researcher, Mikey Veenstra released a post detailing this a few days later on 25 March 2019. (Wordfence, 2019)

The original and most exploited element of the vulnerability allowed attackers to inject malicious JavaScript code into the social share links present on a site’s posts. Mikey Veenstra described this as a “fire-and-forget XSS campaign, used the way they did, meant the attackers could send one request to a vulnerable site and the job is done, it’s infected and making them money”. This has advantages over other vulnerabilities in that it is easier to automate the infection and monetisation of these attacks.

In the example logs above, it can be seen that the exploit downloads a file from pastebin.com. This was a JSON file containing the usual settings required by the plugin, but also including malicious code that injected the malicious script into the link code on the site. In the RCE version of the exploit, it was discovered that code within the <pre> tags of this file were passed to eval() and executed. This effectively allowed the execution of arbitrary PHP code on the site, meaning that attackers could run system commands, install backdoors or create users as required.

We analysed the data for attacks attempting to exploit this vulnerability that were blocked by the Wordfence Web Application Firewall following this irresponsible disclosure. The original blog post by the unnamed security researcher was released on Twitter at 16:00 GMT on 21 March 2019. It was then brought to the attention of the Defiant Threat Intelligence team at 17:14 GMT on the same day and a firewall rule was developed and deployed. It can be seen from the data that the Web Application Firewall started to see and block attacks from 17:00 onwards on that day, with 256 attacks blocked during the hour between 17:00 and 18:00. The number of attacks steadily grew over the following 24 hours and reached a peak of 30,160 attacks blocked between 05:00 and 06:00 GMT the following day.

Figure 6.4 – Hour by Hour attacks blocked after disclosure at 16:00 GMT for a period of 56 hours

The number of attacks remained steady at several hundred per hour until 12:00 on 23 March, when we saw another surge in attacks which this time reached a peak of 74,834 attacks per hour between 15:00 and 16:00 GMT that day.

When we look at the number of attacks blocked over the 30-day period following disclosure, we can see that the following day. 24 March, was also the busiest day for attacks against this vulnerability, with 862560 attacks blocked on this day alone.

Figure 6.5 – Day by day attacks blocked for 30 days following disclosure

If we look at attacks over the year, we can see that the hacking campaign continued at a pace until around July/August, when levels calmed down. At its height, there were around 24 million attacks blocked in April 2019, however even after the main phase of the campaign ended, we still saw around half a million attacks attempted per month up until December 2019.

Figure 6.6 – Month by month attacks blocked after disclosure

When we look at the number of cleans carried out by the Site Security Team over the 30 days after disclosure, 5.6% of tickets over that period that were raised as a result of customers’ sites being attacked through this vulnerability. 

Figure 6.7 – Social Warfare Site Clean Volumes for 30 Days After Disclosure

Convert Plus Vulnerability – Responsible Disclosure

As mentioned previously, the vulnerability was discovered on Friday 24 May 2019 with a patch released by the authors on 28 May and the responsible disclosure was made by Mikey Veenstra of Defiant the following day.

The plugin itself is a lead generation plugin that allows site owners or administrators to include marketing popups on their site, for example email subscription messages or coupon codes. The plugin is not included in the WordPress repository and must be downloaded from the plugin author’s site. Despite this, the plugin has a similar or slightly higher install-base as the Social Warfare plugin, with around 100,000 installations.

The vulnerability had similarities to the Easy WP SMTP plugin vulnerability, in that it allowed attackers to easily create administrator users on a vulnerable site. Discussing this with Mikey Veenstra, he made the point that “Convert Plus .. is really easy for a human to exploit when you’re sitting in front of a vulnerable site but less easy to slap together a mass exploitation campaign for”. 

The plugin allowed administrators to create forms that enable users to subscribe to the site. The default role assigned to new users was “None”, however a dropdown allowed administrators to assign any role to new users, such as “subscriber”. Administrators were prevented from specifying “administrator” as the default role by not presenting it as an option in the dropdown. In vulnerable versions of the plugin, this setting was reflected in a hidden field on the plugin’s forms called cp_set_user. It was therefore possible for attackers to alter this HTTP request to set the role of a new user to administrator. As with other vulnerabilities, creating an administrator user on the site gives an attacker full control to install whatever malicious code or backdoors on the site. Again, this requires multiple steps to compromise a site so is therefore not as attractive a proposition as some other vulnerabilities. 

The vulnerable section of code was as follows:

The authors of the plugin dealt with the problem in a sensible manner as part of the responsible disclosure process, releasing a patch within a few days and also creating a blog post warning all users to update as soon as possible. (Wordfence.com, 2019)

If we look at attacks over the year, we can see that there were very few attacks attempted against this vulnerability, other than a spike in August 2019, when there were over 54,000 attacks blocked by Wordfence. There were no attacks in May, the month that the vulnerability was originally disclosed – responsibly.

Figure 6.8 – Month by Month Convert Plus Attacks Blocked After Disclosure

As can be seen from Figure 6.9 below, in the 30 days following the responsible disclosure around 6% of cleaning tickets raised were determined to have been due to the Convert Plus vulnerability. 

Figure 6.9 – Convert Plus Site Clean Volumes for 30 Days After Disclosure

The Importance of Responsible Disclosure with a Further Analysis of the Findings

There are a number of obvious highlights from the figures detailed above. Below is a table that brings together the relevant figures for each of the attack campaigns discussed.

Vulnerability	Responsible Disclosure?	Install Base	Attacks Blocked in 2019	Related site clean tickets raised in the following 30 days
Social Warfare	No	70,000	54,252,975	5.6%
Easy WP SMTP	Yes	400,000	95,772	20%
Convert Plus	Yes	100,000	54,925*	6.38%

* Attacks only started following responsible disclosure in May, as opposed to March for the other two plugins.

As mentioned earlier, these figures are for the number of attacks that were attempted by hackers to exploit the vulnerabilities in the three plugins that were blocked by Wordfence. 

Before the irresponsible disclosure of the vulnerability in the Social Warfare plugin, there were no attempts to attack sites running this plugin. As seen in the charts in the previous section, the number of attacks attempted and blocked against the Social Warfare vulnerability were extremely high throughout the year, but particularly in the campaign directly following the disclosure. Around one hour after the disclosure, attacks started to be blocked and recorded. Many of these attacks were blocked and recorded as they were coming from IP addresses on the Wordfence blacklist as having carried out malicious activity previously.

6.38% of site cleaning tickets raised in the 30 days following disclosure were for sites compromised through the Convert Plus vulnerability. The percentage of cleaning cases for the Convert Plus and the Social Warfare vulnerabilities in the 30 days following their disclosures were very similar.

Despite Social Warfare having an install base nearly six times smaller than Easy WP SMTP, and around 20,000 fewer installs than Convert Plus, it still attracted over 54 million attempts to hack it. This compares with 95,772 attempts for Easy WP SMTP over a similar timeframe, and 54,925 attacks blocked for Convert Plus from May to the end of 2019 (around two months shorter). 

We did, however, see fewer site cleaning cases for Social Warfare than we did for Easy WP SMTP over the 30-day period. There could be a number of explanations for this. 

1. The install base is much greater for Easy WP SMTP than it is for Social Warfare. There are many more installations available to compromise and so we saw higher numbers of sites that were compromised. The figures obtained only show attacks that were detected and blocked by the Wordfence WAF.
2. The initial Social Warfare attacks were blocked as the attacks were coming from known malicious IP addresses. It seems likely that there are regular visitors to the unnamed researcher’s Twitter feed and blog post, that wait for irresponsible disclosures and then create hacking campaigns based on the Proof of Concepts provided. These malicious actors would likely be using IP addresses previously blacklisted due to campaigns based on earlier irresponsible disclosures by this researcher. Had these IP addresses not been blocked already by Wordfence, the number of successful attacks and therefore the number of site cleaning requests will have been likely to have been much higher.
3. The Social Warfare attack was easier to automate in a “fire and forget” model, which could explain the millions of attempted attacks for a plugin which only has between 70,000 and 80,000 installations. 
4. As Easy WP SMTP was not disclosed by the unnamed security researcher, it may not have been noticed by the malicious actors that watch this account for disclosures. Initial attacks against this vulnerability will not have been blocked as coming from the known malicious IP addresses. Any attacks will have been more targeted against sites running the plugin, with less of a scattergun approach. This will have led a number of the attacks to be more successful, explaining the higher number of site cleans seen for this attack.

For the Social Warfare vulnerability, we analysed the number of attacks in the 56 hours after disclosure and also on a day-by-day basis for the 30 days following disclosure. We were able to see patterns and spikes in attacks from immediately after the disclosure. There was little point in carrying out this detailed level of analysis for the other two plugins. We saw zero attacks against Convert Plus after disclosure in May, and only four attacks logged for this vulnerability in the month of June. Similarly, for the Easy WP SMTP vulnerability, whilst we saw 50,597 attacks blocked in March, there was only one attack blocked in the four days after disclosure on 17 March. The spike in attacks didn’t start until 21 March. The number of attacks recorded daily was down to single figures by the end of that month. There therefore seemed to be little point in analysing the number of attacks recorded in the 56 hours after disclosure, as the figure was zero. 

There were only a very small number of attacks against the Convert Plus vulnerability recorded for June. Similarly, there were only a small number of site cleaning tickets raised in the 30 days after disclosure, with all of those orders placed in the first two weeks of June. The timeline for the discovery and disclosure was as follows:

• May 24 – The vulnerability was discovered by members of the Defiant Threat Intelligence Team and the developers were notified privately.
• May 28 – A patch was released by the developers and a Wordfence WAF rule was released for Premium users of the plugin.
• May 29 – The vulnerability was disclosed by the Defiant Threat Intelligence Team.
• June 27 – The firewall rule was released for free users of the plugin.

The site cleaning cases that were reported in the first two weeks of June will have been compromised due to one of the following factors:

1. They were not running a Web Application Firewall that protected them from these attacks.
2. They were only running the free version of the Wordfence plugin which did not receive the relevant firewall rule until the end of June.
3. They had not applied the security update released by the developers prior to disclosure at the end of May.

On to Part 7 – Hardening and keeping WordPress Sites Secure

Back to Part 5 – Providing Customers with a Clean WordPress site