17 Sep

Sucuri Doesn’t Understand the Recently Disclosed Vulnerability Created by Duplicator (or Security in General)

The reputation of security companies is often very different than the reality. One company that seems to have a good reputation is Sucuri. That is despite everything we have seen over many years indicating they really lack even a basic understanding of security (we wish that were a gross exaggeration). We once again were reminded of that by something that popped up in the monitoring we do to keep track of vulnerabilities in WordPress plugins, which involved a repost of a recent Sucuri blog post.

The Sucuri blog post is titled “Outdated Duplicator Plugin RCE Abused”.

As usual Sucuri is behind in becoming aware of a security issue being exploited as we discussed the exploitation a week before, right after it started. That is contrary to what you would believe from the testimonial they show on their homepage which claims:

Another thing we like is that Sucuri knows about security issues before they become a problem – in advance.

While a week late, the post is written by someone who doesn’t appear to understand the vulnerability at all as they write this:

It’s hard to tell why the wp-config.php files are removed or voided, breaking the site. We can only speculate that it was a failed attempt to tamper with it. In several related cases, there was also a variety of backdoors present on the attacked server.

That doesn’t make sense in that they clearly successfully tampered with it if they have been “removed or voided”. What makes this so odd is the vulnerability specifically involves voiding the wp-config.php, as you replace intended information in the file with malicious code.

You only have to get to the second paragraph of the report from Synacktiv on the vulnerability, which Sucuri linked to, to find the first mention of that:

Indeed, the installer.php and installer-backup.php files can be reused after the restoration process to inject malicious PHP code in the wp-config.php file. Thus, an attacker could abuse these scripts to execute arbitrary code on the server and take it over.

At the end of the report it states:

Please note that a successful exploitation is destructive as it breaks the WordPress configuration file and thus, the WordPress instance.

Even with our dim view of the security industry and Sucuri, it is stunning that they put out a post without understanding what they are talking about at all. This seems like the sort of thing that should be a huge black eye for them, but it unfortunately won’t. They can’t even blame an intern on this as the bio of the writer of the post starts this way:

Peter has been working in Information Security for over 12 years, currently as a Senior Malware Researcher at Sucuri.

How bad must the non-“senior” malware researchers at the company be?

The next paragraph is not quite as bad, but still pretty bad:

Whether these backdoors are added by attackers abusing this vulnerability, or through different infection vectors needs to be confirmed. The only fix in case of a broken site is to recreate the wp-config.php file with the correct DB login credentials.

Why haven’t they confirmed that? Determining how websites are hacked is a basic part of a hack cleanup, so to not have gotten around to that is an indication of something being very wrong (from past experience it looks like the closest they usually come to trying to determine how websites are hacked is by looking for a correlation between the websites instead of doing things properly by reviewing logs and other relevant data).

Making things more problematic they describe the vulnerability as having been fixed in version 1.2.42, but as we discussed before part of the issue still issue still using default settings in Duplicator in that version. Considering that they don’t have any understanding of how the vulnerability they are discussing worked, it seems odd that they could have possibly determined if it was fixed.

They end their post with an ad (we removed the link from that):

If you believe your website has been compromised by this attack, we can help. Stay safe.

If your website has been hacked you really would help by avoiding Sucuri, we have repeatedly been brought in over at our main business to re-clean websites where they didn’t do things right, which shouldn’t be surprising considering lack of expertise seen in just the blog we were discussing.

14 Sep

Astra Falsely Claims That Minor Vulnerabilities in Contact Form 7 Lead To Websites Being Hacked

If you are looking for information on vulnerabilities in WordPress plugins a common suggestion is to do a search for them, like this recent one from a moderator from the WordPress Support Forum:

Do a search for any known vulnerabilities in the plugin. If any exist for old plugins, they should be well known by now.

Beyond the fact that there are many vulnerabilities in old plugins that have yet to be found because people are not doing extensive security reviews of every plugin out there (unfortunately the moderators of the forum don’t seem to be interested keeping their advice to things that they have factual backing for), the results from such a search will lead to a lot of inaccurate information. While looking into something related to a recent vulnerability in the plugin Contact Form 7 we ran across article from a security company named Astra, which shows that at work. What was striking was the claim at the top of it “Your site is probably hacked”:

That is simply false.

Their whole article looks to be written by someone that doesn’t really have an understanding of what they are talking about, making it hard to decipher what is trying to be claimed in it if you actually understand the topic, but some parts are easy enough to decipher as being false.

The most important part in understanding this company doesn’t understand what they are talking about (while claiming to be security experts), much less know that any websites have been hacked due to the vulnerability they are discussing, is this portion of their article:

WordPress allows multiple user roles as contributors, editors, subscribers, authors etc. Due to this vulnerability a user logged in as a contributor can edit the content form, a feature which is presently the privilege of editors and admins only. This vulnerability is more severe than it seems because of the two features of the contact form 7:

  1. Contact Form 7 allowed absolute file path i.e. /host/home/somefile.pdf. Thus with the ability to edit the form the attacker could access files outside wp-content.
  2. ‘Filetypes’: A non privileged user can tweak the feature filetypes i.e. (filetypes: gif|png|jpg|jpeg)to include files like .php, .asp etc. i.e (filetypes: php|asp) and obtain reverse shells.

Possible Consequences of Privilege Escalation in Contact Form 7

Thus the attacker can put the file type of his choice in the wp-contents directory and obtain a reverse shell paving way for further attacks. As a temporary solution, Takayuki Miyoshi the author of this plugin has disallowed file path that refers to a file placed outside the wp-content directory. Many users have started to complain about file attachment errors on the support forum of contact form-7. To stay secure update to the latest version and Move your files to <your WordPress root>/wp-content/ and replace the line in the File Attachments fields accordingly.

What those vulnerabilities actually could be used to do is very different than what is described there. One of the vulnerabilities apparently allowed lower level users access to a capability that they were not intended to have access to, as mentioned above. But as we described in our post detailing the other vulnerability, the second one would allow anyone with that capability to view the contents of arbitrary files. It doesn’t have anything to do with uploading files to the website. Making the whole thing more head scratching, restricting the uploading of malicious files to the wp-content wouldn’t stop them from being exploitable, so if you believed what they believed was allowed before, there would still be an issue with the plugin (even if you placed restrictions on running files using a .htaccess file in that directory, that could be overwritten with a .htaccess file that doesn’t have that restriction).

They Don’t Know How Websites Are Hacked

That isn’t a one off issue. In looking over their website a recent blog post stood out to us, since it seems to be written by someone who doesn’t know how websites are getting hacked, despite the company providing hack cleanups and claiming to be able to protect website from being hacked, so they should be well aware of how website are being hacked.

The post is titled “10 Joomla SQL Injection Vulnerabilities that Could be the Cause of Your Hacked Joomla” and it starts with this claim:

Joomla is one of the largest and the most popular content management system which is open source. Joomla has a large user base, and the popularity has brought the service under the notice of attackers and malicious programmers. Attackers often target this service since the users store a huge amount of data on their servers. Hackers often launch a Joomla SQL injection attack on accounts that have certain vulnerabilities. Any vulnerability will lead to a huge leak of data which would benefit the attackers. At Astra such attacks and hacked Joomla accounts are common. Any breach in the system can cause potential havoc for customers and their businesses. If you are a user then identifying an attack or vulnerability is very important. However, if your account is hacked, then the first step is to identify the attack. Identifying the attack will enable you to find the vulnerability and plug it. To help you with this, the following vulnerabilities might be a probable cause for your hacked account.

Almost none of that is true. Only a few variants of SQL injection vulnerabilities are likely to be exploited on the average website, so claiming that hackers “often” launch attacks against that type of vulnerability is untrue. It is telling that there idea of how to identify the source of the hack isn’t by say looking at the HTTP logging, which in the case of exploitation of Joomla extension would show evidence that was the source, but by seeing if you have a vulnerable piece of software on the website. The reality is that the vast majority of vulnerabilities we see disclosed in web software are things that are not likely to be exploited on the average website, so doing that is likely to lead you off in the wrong direction, especially if you are like this company and don’t even understand what is potential impact of a vulnerability.

Something else stood out to us from that. For most of the entries listed they start something like this:

Immediate Fix: Update to version greater than 2.x.x or Use Astra

or this:

Immediate Fix: Update to the latest version or use Astra

But for the only vulnerability that list as not being fixed they state this instead:

Immediate Fix: Remove the plugin since no update is available.

So they apparently only provide protection if the developer of software has already fixed the issue, in which case what is the supposed to be the additional value of their protection service over doing the security basic of keeping your website secure. On their homepage they claim to provide “360° real-time website protection”, which they clearly don’t based on that.

Why Are They Lying About Being At Least Partially Based in India?

In looking over these guys something seemed odd to us. If you look at the homepage they have a photo of the Golden Gate Bridge, which is located in San Francisco, California:

In the footer of the website is the claim that “Made with heart in” the USA, France, and Germany:

Yet other things we saw would point to them at least being based in part in India. Looking at the whois for the domain list the registrant being in Noida, India. If you check out some of the search results for the company or their parent Czar Security, the presence seems more clear, including the CTO being based in India despite that being someone who would seem to be intimately involved in making the service.

On their contact page they list their US address as being in Newark, New Jersey, which is 3,000 miles and completely across the country from the Golden Gate Bridge and it looks very different than the Golden Gate Bridge. While they suggest “Come over, coffee on us!” above the addresses, it looks like that is address is mail box drop, which seems less than honest.

We don’t why they would lie about this, but it seems to be a good indication that you can’t trust other claims they make, considering that isn’t well hidden. It really speaks to how fundamentally terrible the security industry is that obvious lies are so rampant in a business that is so trust based.

These Companies Have No Connection to Astra

Inaccurate claims abound even on the homepage. For example, they have this claim:

That seems impressive, but we would read that as they have employees that previously worked for those companies handling security, but in reality it just means that their employees had, prior to being involved in the company, reported some vulnerability to those companies:

They have received acknowledgements from various global companies on multiple occasions for pointing out security issues in their web portals. These companies include Microsoft, Yahoo, Adobe, Mediafire, IMDb, University of Sydney, AT&T, Bufferapp and Blackberry. They also donated the Bounty amount to Palestine Children’s Relief Fund.

Being able to find random vulnerabilities on websites and actually being able to fully secure high profile websites are very different things, and if the latter was as easy, security wouldn’t be in such bad shape. The lack of the basic understanding of security that the articles we mentioned would indicate about this company, is something we often find from people in the security industry that are more script kiddies than security professionals. Unfortunately they often have easy time selling companies on products and services of limited, at best, value, helping to lead to security being in such bad shape.

They Rely On Someone Else For Security

What seemed more notable in the domain name registration is that they are running their own website through a competing security service, as the name servers are from Cloudflare:

Name Server: chris.ns.cloudflare.com
Name Server: sue.ns.cloudflare.com

07 Sep

Wordfence Security Doesn’t Protect Against Exploited Vulnerability (or Finding a Balance When it Comes To Detailing Vulnerabilities)

One of the ways we work to make sure we have the best information on vulnerabilities in WordPress plugins for our customers is to monitor the WordPress Support Forum. Through that we came across a couple of threads yesterday that involved exploitation of a vulnerability connected to the plugin Duplicator (and yet another example of the incredibly bad handling of the discussion of security by the moderators of that forum and inability for them to be willing to have a discussion to avoid those problems going forward). In looking closer at the information put out about that we noticed a couple of issues that we thought worth bringing more attention to.

Making it Easier for Hackers to Exploit Vulnerabilities

One issue that we evaluate on an ongoing basis is how we handle disclosure of vulnerabilities, since there isn’t an obvious balance to be struck. On the one hand, more information can make it easier for hackers to exploit vulnerabilities. On the other, we have often found that vulnerabilities are disclosed with a claim that they have been fixed when they only partially been fixed or not fixed at all. In those instances the more information provided makes it easier to determine that there is still an issue and work to get it fixed, before hackers figure that out and take advantage of it.

Sometimes even as a company in the security industry that understands the nuance of the issue it seems as if other security companies are doing things in a way that is intended to make it easier for hackers to exploit websites. A troubling example of that involves a company named Check Point and the Drupal software. Earlier this year there was serious vulnerability that was fixed in the Drupal software and plenty of press coverage of the need to update was provided. For two weeks after the fixed versions were released there was no exploitation of the vulnerability. Exploitation instead started right after Check Point, which was not involved in discovering the vulnerability, had released details on how it could be exploited. Their reason for doing that was explained with the following:

After seeing earlier publications on Twitter and several security blogs, it was apparent that there was much confusion among the community regarding this vulnerability announcement, with some even doubting the severity of it. As a result, we considered it worthwhile to looking deeper into.

The research however was challenging as we were starting from a very large attack surface since the patch blurred the real attack vectors. To expedite our findings, we were fortunate to be joined by experts in the Drupal platform. The final results highlight how easy it is for organization to be exposed through no fault of their own, but rather through the third party platforms they use every day.

What stood out to with that is they claim that it was challenging to figure out how to exploit it, but then how it easy it for someone to be impacted by it, which was due to their own actions, which seems to provide a very different lesson then they claim to be providing.

So why do that? It might be explained by the end of their article:

Check Point customers are protected against such vulnerabilities due to IPS signatures.

When you create a threat without needing to and then tout that you can protect against like that, your intentions seem questionable at best.

Duplicator’s Security Issue Still Exists

With the issue related to Duplicator, what immediately stood out to us in looking at discussion of the issue is by both the discoverers, Synacktiv, and Wordfence, which was released shortly before the wave of exploitations mentioned in the Support Forum and could conceivably have help lead to them, was that they provided a much easier way for hackers to exploit the issue then would be needed for anyone to confirm the issue had existed (and to a large degree still exists).

The vulnerability isn’t too complicated to understand. The plugin generates files for duplicating a WordPress website. After using those files to duplicate the website, files that are part of the duplication are not automatically deleted and those would allow anyone to change the contents of the WordPress configuration file. To us the obvious issue with that would be that someone could set it so that WordPress connects to a remote database and from their hackers could use access to the admin area of WordPress to do almost anything that is possible from the hosting account, say sending spam emails. That isn’t some idea we came up with, that is something that has been publicly discussed at least as far back as 2012.

For some reason though neither Synacktiv or Wordfence stopped with suggesting that was possible, instead they suggested that you could put malicious code right into the WordPress configuration file, which could then easily be run. Synacktiv further provided the exact information needed to do that. That makes it much easier to exploit then if they had just left it at explaining how you could change the database to take control, which would in all likelihood greatly increase the amount of hackers who would have the skills and tools to exploit this.

Making things worse here, the Wordfence post is titled “Duplicator Update Patches Remote Code Execution Flaw”, but that isn’t all that accurate since by default the new set of files generated during duplication still allows changing the database details, it does attempt to limit code execution (though we haven’t tested that out to see if it totally effective), and then use the website to take a variety malicious actions. Strangely the writer of the article portrays it this way:

Even though the user-supplied connection strings are now sanitized before being written to a site’s active wp-config.php file–preventing new code from being introduced and executed–the existing values are still getting replaced by this process. This means if a patched but unprotected installer.php file is found, an attacker has the ability to bring down a site just by supplying incorrect database credentials to the installer.

In reality they can do much worse than bring down the site, it is unclear if the writer didn’t understand the significance despite linking earlier in the post to another Wordfence post describing what actually can be done.

So far we have decided not to include this issue in our data set, since it isn’t a vulnerability that exists in the plugin itself, but in something produced by it. Though we are still mulling if it might make sense to, especially in the light that the issue would still exist to a large degree with the latest version of the plugin.

Wordfence Security Doesn’t Stop You from Being Hacked

In the case of Wordfence they went from describing how to exploit this right to advertisement for their services, that advertisement provides a good reminder of their frequent dishonesty and their willingness to combine that with leaving websites vulnerable to being hacked.

From April of 2016 to October of 2017, several sentences in to the description of the Wordfence Security plugin on wordpress.org was an unqualified claim that it would protect websites from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

That was then moved to a FAQ question and continues to be there to this day.

That claim is simply a lie, as a WordPress plugin could not possibly stop websites from being hacked in a blanked fashion. It is possible that they could stop some hacks, though curiously Wordfence doesn’t provide evidence, much less from independent testing, that their plugin is effective at protecting against things it should be possible for it to protect against. We actually did just that type of testing, for which the results were not good, and when we presented the results to the head of the company he didn’t exactly provide a compelling response. And before we get somebody responding that people using the plugin wouldn’t believe that it could provide the level of protection claimed there, they do believe that.

At the same time in the description it was also claimed:

Wordfence Security is 100% free and open source.

Beyond the fact that a plugin can’t protect against a lot of threats, there is the issue that Wordfence intentionally leaves websites vulnerable. Here is part of their ad from the Duplicator post:

At the time of this writing, we have identified a number of malicious actors probing sites for the existence of installer.php and installer-backup.php. If you’ve used Duplicator in the past to migrate a WordPress site, take some time to confirm that any leftover files from the process have been properly removed. Wordfence Premium users will begin receiving alerts from their malware scanner if vulnerable versions of these files are detected on new scans. Additionally, a new rule has been deployed to protect Premium WAF users from exploits of the Remote Code Execution vulnerability discussed above as long as Extended Protection has been enabled. Free users will receive these new rules thirty days from today.

Considering that wide exploitation looks to already be going on, protection in thirty days won’t be much good. Wordfence is a business, so they can leave people vulnerable like this, but they have lead people that what they provide is very different from what it is. Including claiming in the past that “We will always put our customers and the community first.” (how you can put them both first seems like an obvious problem with that statement). It doesn’t have to be this way.  We provide data on vulnerabilities in plugins we see being exploited in the free data that comes with our service’s companion plugin and our focus is on providing paid services for websites that need a higher level of security, instead of trying to getting lots of average websites to purchase a low quality service, while leaving other vulnerable. The problem though is that our plugin currently only has 4,000+ active installs versus Wordfence’s 2+ million. The popularity of their plugin ties into something else worth mentioning here.

The second paragraph of Wordfence’s advertisement states:

As always, if you believe your site has fallen victim to the successful exploitation of an attack like this or any other, please don’t hesitate to contact our team of experts to discuss a site cleaning or security audit.

So they leave websites not paying for their service vulnerable and then they can get people to hire them to clean them up afterwards. How they promote that clean up service seems pretty awful:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

If they had the most popular WordPress security plugin it wouldn’t mean they have the most expertise in the industry, just the most popular plugin. They often have shown a fairly extreme lack of expertise. There need to mislead people like this seems also most pathological. But its worse when you consider their popularity is partly based on a false belief that their plugin would stop website from needing a cleanup in the first place.

Wordfence Security Isn’t The Most Popular WordPress Security Plugin

In line with Wordfence’s many falsehoods and outright lies, not surprisingly it isn’t even true the they have the most popular WordPress security plugin. Instead they are tied with the plugin Limit Login Attempts:

In an indication that the popularity of security plugins isn’t a great measure, consider the fact that plugin hasn’t been updated in years:

In addition to that, the plugin is focused on protecting against brute force attacks against admin passwords, which are not even happening. Not only does Wordfence also tout their plugin also protects against those, they put forth evidence that unbeknownst to them ends up showing that they are not happening (which seems like a good example of their lack of expertise).

With Limit Login attempts there is also the little issue that the current version of the plugin contains a vulnerability.

05 Sep

Hackers Will Try To Exploit Vulnerabilities in WordPress Plugins in Ways That Will Never Succeed

One the things we find rather telling about the security industry is that they seem to find various statistics valuable, but ones they seem to be totally uninterested in are any that would actually show that their products and services are actually effective at protecting websites (despite that seeming like it should be a prerequisite before using so many of them). One type of statistic that we have seen them focus on instead is supposed measures of how many attacks the average website is facing. Earlier this year one company promoting their service with such a statistic, seemed to make a case that they are not really valuable, as they promoted the increase in attacks as being a concern and then when it when it went down they claimed that was also a bad sign:

“A decrease in attacks does not mean that websites are safer. In fact, it may even be the opposite,” says Neill Feather, president of SiteLock. “Hackers are constantly trying new avenues and even leveraging older tactics that continue to be successful. As our research shows, cybercriminals are now able to successfully breach a site with fewer, more targeted attacks. Now more than ever, businesses need to evaluate their current security posture and ensure they have both the right technology and a response plan in place should a hack occur.”

While that quote would imply that they are aware of how many attacks are effective they don’t provide that stat. If they truly know that (and based on everything we know about SiteLock they likely don’t), the reason for that would be quite obvious. The success rate of hacking attempts is in incredibly low, with the average website not even being successfully hacked once a year. It is a lot easier to sell a security services that don’t even focus on actually securing websites by getting people to fear thousands of attacks a year then less than one successful attack a year.

So why are so many attacks not successful? Something we recently looked at shows some of why that is.

We have had several recent exploit attempts that requested the following URL:

/wp-content/plugins/ungallery/source_vuln.php?pic=../../../../../wp-config.php

Those requests would be attempting to access a file from the plugin UnGallery, which currently has 100+ active installs according to wordpress.org. Seeing as we have never used that plugin those attempts would have never succeeded, nor would they on almost any other website considering the number of installs. But things get worse from there.

The filename, source_vuln.php, seemed odd to us. Specifically the “_vuln” part of it. When we went to look into this we didn’t find a file named that in any of the versions of the plugin we checked. A quick search though showed what was going on. The file that had been vulnerable was source.php, but for some reason in a report about it was instead listed as source_vuln.php.

So you have a hacker who is trying to exploit a vulnerability on what looks like it would be a fairly wide scale without doing any testing first. From what we have seen over the years that is not an uncommon situation. That is good news for people running websites, other than ones that get tricked in to using an ineffective to outright scammy security services based on attacks stats, since that means that a lot of the hackers’ resources are being wasted.

In this case there is another indication that the hacker didn’t do any research before trying to exploit this, as the vulnerability was resolved seven years ago, so even if they were not going after the wrong file they would have had to hit websites that are really out of date for the exploit to work.

Looking at what happened though is a reminder of why disclosing vulnerabilities so that others can review the details is important.

In version 1.5.8 of the plugin had commented out the following code in source.php:

if ($_GET['zip']) {
	$filename = $_GET['zip'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);
 
	header("Content-type: application/x-zip-compressed;\r\n"); 
	header("Content-Length: $len;\r\n");
	header('Content-Disposition: attachment; filename="' . $name . '"');  // Create a download stream link
	readfile($filename);	
}

That code would display the content of a user specified file from the website, also known as an arbitrary file viewing vulnerability. That was explicitly commented out due to the security issue as the changelog entry for that version was “Disabled zip archiving feature due to security issue. Will add back later if possible.”

Right below that were two more instances of nearly identical code that were not commented out in version 1.5.8:

if ($_GET['pic']) {
	$filename = $_GET['pic'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);   
 
	header("Content-type: image/jpeg;\r\n");
	header("Content-Length: $len;\r\n");
	header("Content-Transfer-Encoding: binary;\r\n");
	header('Content-Disposition: inline; filename="'.$name.'"');	//  Render the photo inline.
	readfile($filename);
} 
 
if ($_GET['movie']) {
	$filename = $_GET['movie'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);   
 
	header("Content-type: video/mp4;\r\n");
	header("Content-Length: $len;\r\n");
	header("Content-Transfer-Encoding: binary;\r\n");
	header('Content-Disposition: inline; filename="'.$name.'"');	//  Render the video inline.
	readfile($filename);
}

Where not sure what would have lead anyone to believe that only the first one was vulnerable, but that is what happened. It took two months for that additional vulnerable code to be dealt with. The exploit attempts we saw were trying to exploit the second one, but the third one was also exploitable.

Proof of Concept

The following proof of concept will display the contents of the WordPress configuration file, wp-config.php.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-content/plugins/ungallery/source.php?movie=../../../wp-config.php
04 Sep

Phishing Email Claiming to Be Related to WordPress Database Upgrades Being Sent Out

We have an email address we use to handle all communications related to notifying the developers of WordPress plugins about security issues in their plugins (whether those are ones that we have found or ones that others have disclosed before they have been fixed). The email address isn’t publicly disclosed, so it shouldn’t receive  email not related to those messages unless someone that had received communication from us either shared it with a third party intentionally or had their communication system breached. Not surprisingly, we don’t receive much in the way of emails not related to the intended use of the account. That made an email we received a few days ago stand out more.

The email’s subject was “WordPress Database Upgrade required !” and the body of the email was as follows:

What was obvious to us for a variety of reason was that this was a phishing email, but we weren’t aware of this phishing email being something out there, so did a little bit of looking into this.

The email itself seems to not all that well put together, seeing as, for example, it doesn’t even have a consistent capitalization of the words database or WordPress.

When clicking the “Click here to Upgrade WordPress” we were first taken to a website that just showed a “loading” message (which isn’t a WordPress thing):

From there it redirected us to a fake login page on another website:

The title of that page, “WordPress.com – upgarde”, in addition to misspelling the word upgrade, seems to indicate that this is targeted at logins for the WordPress.com service, not stand alone WordPress installs.

Both of the websites involved were legitimate websites running WordPress that must have been compromised somehow, though not necessarily through any security issue related to WordPress. We have notified both websites of the issue.

Once you enter username and password you are sent to this page:

Needing to enter either of those details when you just entered the username and ostensibly are on WordPress.com or your own website is something that would seem like it should be an indication that something is amiss.

Once you enter that information you are taken to the plans page for WordPress.com, which seems like further indication this intended to be targeted at WordPress.com accounts:

Interestingly while a quick search didn’t bring up any recent postings about this phishing email, we did find that a very similar precursor was written about nearly five years ago (that phishing email also was inconsistent with the capitalization of WordPress).

24 Aug

Sucuri’s Post With FUD Claim of Massive Infection Really Shows That They Are Failing Their Customers

It has taken us a long time to fully grasp the level of dishonesty in the security industry, since it is so rampant that is hard to believe how bad things truly are, even seeing examples every day. That there is almost any dishonesty should be surprising since trust is so important when it comes to security, especially when you consider the almost total lack of evidence that security companies put forward to back incredible claims they make about their products and services. As an example of how bad things are take the company Sucuri, which claims that trust is one of four of their claimed values:

The security space is filled with snake-oil and unnecessary FUD (fear, uncertainty, and doubt). We are committed to building services in the best interest of website owners.

That is pretty clearly contradicted by everything about we know about them. Take a post from just a couple of days ago, which is titled “Massive WordPress Redirect Campaign Targets Vulnerable tagDiv Themes and Ultimate Member Plugins”. So how massive is it? Not massive at all:

At the moment of writing, we see 1700+ sites with the cdn.eeduelements[.]com script and 500+ sites with the cdn.allyouwant[.]online script.

The post indicates that these websites were running WordPress, one estimate out there from December of 2016 was that there were 75 million websites running WordPress. If that were accurate then by Sucuri’s measurement a massive campaign could involve only 0.00002933333 percent of WordPress website, which is nonsense.

That would seem to be an example of textbook FUD, but looking at the rest of the post things seem even worse when it comes to them than just a misleading blog post.

Sucuri Doesn’t Know of Issues Before They Become a Problem

On Sucuri’s homepage a testimonial is prominently displayed that ends with the following claim:

Another thing we like is that Sucuri knows about security issues before they become a problem – in advance.

From everything we have seen over the years that isn’t true and in fact them seen in the past they seem to become aware well after we have written public blog post about issues. That is problem when they promote their service as being used instead of handling security properly and when their service possibly being an effective alternative would require them to at least be staying up with new threats.

In this case, one of the two vulnerabilities they mention as being part of this campaign is a vulnerability in Ultimate Member that we discussed on this blog back on August 8th, which was before the vulnerability was fixed. At the same time we had started warning our customers of our service and anyone using the free companion plugin to the service if they were at risk. Sucuri though wasn’t even aware of the vulnerability until an unstated amount of time after it had been fixed (as they don’t indicate when they did that analysis):

In the logs we analyzed, we see the first successful attempts to exploit that security hole on August 11th, just two days after the release of version 2.0.22 where the issue was initially addressed. Around that time, we registered an increased number of infections covered in this article. This proves once again that website owners have a very short window between the disclosure of a vulnerability and first massive attempts to exploit it –especially for popular themes and plugins.

When we discussed it here it was in the context of it being exploited already and we are not aware of any disclosure of the vulnerability prior to the exploitation starting. From what we have seen it was being exploited at least as far back as July 27.

Sucuri’s Mess of a Conclusion

The final portion of Sucuri’s post seems to be written by someone that really has no idea what they are talking about. The first two paragraphs contradict each other:

This massive infection clearly demonstrates how zero-day attacks occur and exponentially grow during the vulnerability window.

When vulnerabilities are disclosed, the volume of opportunistic attacks often immediately increases. Hackers are vigilant and monitor closely for changes of popular themes and plugins. If a bad actor sees that a security issue has been fixed, they will try to create exploits for older versions to target vulnerable sites who haven’t yet patched to the latest available version.

A zero-day vulnerability is one that is being exploited before the developer is aware of it, the number of days refers to the number of days that since the developer became aware of the vulnerability until it is exploited. So it doesn’t make sense that hackers would start exploiting one of those based on seeing that it has been fixed, since it won’t have been fixed when it starts being exploited, otherwise it wouldn’t be a zero-day vulnerability. It also doesn’t make sense that hackers would be looking to see if vulnerabilities have been fixed to find out there has been disclosure, instead they would look for disclosures directly since they are usually indexed on a number of public websites. In this case of the vulnerability in Ultimate Member, it was being exploited despite not being disclosed first.

The third and final paragraph is where you get to an ad for Sucuri (we removed the link to their service in this):

Timely updates of all site components are very important to minimize the risk of infection. If you are concerned that you are unable to maintain updates to your themes, CMS, and plugins, your best option is a website firewall that can block the majority of new attacks.

In this case the vulnerability was being exploited before being fixed, so keeping things up to date wouldn’t have protected you. That is where a security service that actually provides you something over keeping your software up to date can provide additional value, which should be where a service like Sucuri’s should be useful. That is exactly what our service offers, in terms of warning about unfixed vulnerabilities and trying to catch exploitable vulnerabilities as they are introduced and before they get exploited. Considering from what we have seen, to provide protection with a service like Sucuri claims to offer requires being aware of vulnerabilities, they would have been late in providing protection and they would have somehow have had better information if they followed our blog then what their own systems provide. Considering that we are a much smaller entity, their lack of capability is a good reminder of how poor so much of the industry is at providing security, especially companies that many will claim to be better than others.

24 Aug

RIPS CodeRisk Doesn’t Look To Produce All That Reliable Risk Scores for WordPress Plugins

While so much of the security industry seems to have no interest in providing accurate information about security, for those that do care, if our experience is any indication, it is difficult to find a way to present information in a way that provides the proper concern without creating unnecessary fear due to misinterpretations of the information presented and many people’s belief that they have a better understanding of security than they really do. That seems to come in to play with something we ran across recently in our monitoring of the WordPress support forum for indication of security issues in WordPress plugins.

Yesterday a thread was started with the following:

I was browsing this directory today to look at plugins that my team regularly uses and noticed that this plugin has a very high vulnerability score:
https://coderisk.com/wp/plugin/admin-menu-tree-page-view

100 is the highest possible and may be due to the high amount of DB queries performed.

Is this something that can be looked into for future updates? I’m afraid the convenience of this plugin does not outweigh any security risk, so I’d really love to see it updated. Thanks!

When you follow the link in that you see the following information:

No information is provided as to what lead to that score and there is actually no mention of database queries. We are not sure why simply having a large amount of database queries would be a security risk, but considering that the result indicates that there are only 593 lines of code in the plugin it seemed unlikely that there were that many database queries.

In doing a quick look over the code we found only five database queries that appear to run and they all seem properly secured using a prepared statement:

392
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = menu_order+2 WHERE post_parent = %d AND menu_order >= %d AND id &lt;> %d ", $ref_post->post_parent, $ref_post->menu_order, $ref_post->ID ) );
434
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = menu_order+1 WHERE post_parent = %d", $ref_post->ID) );
549
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = menu_order+1 WHERE post_parent = %d", $post_ref_node->post_parent ) );
553
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = menu_order+1 WHERE menu_order >= %d", $post_ref_node->menu_order+1) );
570
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = menu_order+2 WHERE post_parent = %d AND menu_order >= %d AND id &lt;> %d ", $post_ref_node->post_parent, $post_ref_node->menu_order, $post_ref_node->ID ) );

There is also one commented out database query:

573
#$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET menu_order = %d, post_parent = %d WHERE ID = %d", $post_ref_node->menu_order+1, $post_ref_node->post_parent, $post_node->ID ) );

Changing the plugin to reduce the score that is not necessarily tied to any true issue seems like a bad use of a developer’s time, so the whole scoring system seems problematic, especially when it is such a black box. Making this all the more problematic our previous run in with the results of this company left a lot to be desired.

A Truly Vulnerable Plugin Gets a Score of 0

To get better idea of the quality of the results we checked a plugin we know currently contains a vulnerability. The latest version of the plugin Advanced Contact form 7 DB introduced a vulnerability that while unlikely to be exploited on most websites using the plugin, would be very serious on some and could be used effectively in a targeted attack. The possibility of that vulnerability is something flagged by our own automated security checker for plugins and since the same check is used for our proactive monitoring of changes made to plugins to try to catch serious plugin vulnerabilities before they can be exploited we already ran across the issue and have notified the developer of the issue. Hopefully it will be fixed soon.

That plugin gets a RIPS CodeRisk score of 0 despite all of that:

Providing Clearer Results

Our tool, the Plugin Security Checker, doesn’t provide a black box score like that tool does. Instead it provides information on any possible issues detected and for customers of our services the underlying code is provided to help a qualified individual to check to see if there is in fact a vulnerability in the code that the developer should be made aware of. As can be seen by the result for Advanced Contact form 7 DB we specifically recommend not contacting the developer just based on the result of the tool:

13 Jul

ThreatPress’ Strange Claim That Plugins Are the Most Common Cause of WordPress Website Hacking

When it comes to improving web security, one of the big problems we see is that there is so much inaccurate and outright false information put out by the security industry. That among other things, leads to people spending a lot of time and money trying to protect against threats that don’t really exist. Even when real threats get mentioned we often find that claims are being made that are not supported by the cited source of the claim (assuming there even is one). That is often the case when it comes to security surrounding WordPress, including our specific focus, WordPress plugins. As a quick example that we ran across not too long ago, a WordPress focused security company named ThreatPress claimed in a post that:

Plugins are the most common cause of WordPress website hacking.

Following that link gets you to a page that makes no mention whatsoever as to the cause of WordPress websites being hacked. What makes that so strange is that what is linked to is another post on ThreatPress’ own website, which is about how many plugin and theme vulnerabilities they added to a data set they collect last year. Considering the services that company provides they should be well aware that number of vulnerabilities found in WordPress plugins wouldn’t in any way tell you how often they are the cause of WordPress website being hacked.

It is also worth noting that their data set is missing a very significant number of vulnerabilities considering they claim to have only added 200 new plugin vulnerabilities last year, while we had added over 500. That doesn’t match up with one of their employees claim that their data set “includes all known vulnerabilities”.

28 Jun

CVE Doesn’t Provide Great Information on WordPress Related Vulnerabilities

The last few days we have had a bit of traffic to our website from a page on the website of the Common Vulnerabilities and Exposures (CVE), which aims to be “a list of common identifiers for publicly known cybersecurity vulnerabilities” and is “is sponsored by US-CERT in the office of Cybersecurity and Communications at the U.S. Department of Homeland Security“. The page that traffic is coming from is for a claimed vulnerability in WordPress, described as follows:

WordPress version 4.8 + contains a Cross Site Scripting (XSS) vulnerability in plugins.php or core wordpress on delete function that can result in An attacker can perform client side attacks which could be from stealing a cookie to code injection. This attack appear to be exploitable via an attacker must craft an URL with payload and send to the user. Victim need to open the link to be affected by reflected XSS. .

There are not any more details to indicate if this refers to something that has been fixed or even enough to confirm if it truly has existed. Strangely a post on a reflected cross-site scripting (XSS) vulnerability in the plugin WP Statistics that we released in April of last year is the only reference:

What connection that post has with that claimed vulnerability is a mystery to us. One possibility is that someone just listed it since it also is a vulnerability of the same type and related to WordPress.

That isn’t the only problematic recent entry.

Earlier today we discussed how other data sources on vulnerabilities in WordPress plugins have incorrectly labeled that a vulnerability in the plugin WordPress Comments Import & Export has been fixed despite it still existing in the current version. While the CVE entry for that vulnerability doesn’t specifically say it has been fixed it states “The plugin “WordPress Comments Import & Export” for WordPress (v2.0.4 and before) is vulnerable to CSV Injection.”

The references listed for that seem problematic in a couple of ways:

First they provide a link to the changelog of the plugin as confirmation. Based on the description of what confirmation means it appears that is only intended to confirm that vulnerability existed, not that it has been fixed. The problem with that, which should be apparent to anyone that deals with claimed vulnerabilities, is that developers do not always have a good understanding of security and we have seen plenty of situations where a developer repeated a claim that a vulnerability had existed in their plugin that hadn’t existed (at the same time developer often don’t acknowledge that there had been vulnerabilities that had existed). In this case while the vulnerability still exists the changelog for version 2.0.5 reads “CSV Injection was fixed – reported by one of our user (Bhushan B. Patil) CVE-2018-11526”. That changelog entry was added after we had notified them that the vulnerability had not in fact been fixed in that version.

The other is unexplained link to the WPScan Vulnerability Database entry for this vulnerability, which doesn’t offer any unique information and actually falsely claims that the vulnerability was fixed in an earlier version than anyone else is claiming:

Considering that database has a commercial service it seems inappropriate that a government sponsored entity is being used to provide it free advertising like that.

28 Jun

Other Data Sources on WordPress Plugin Vulnerabilities Belatedly Add Vulnerability While Falsely Claiming It Has Been Fixed

When it comes to the problems with the security industry one of the fundamental issues is the abundance of false and misleading claims about the capabilities of products and services. The breadth of that is on display in how often that occurs with our little piece of the industry, data on vulnerabilities in WordPress plugins, where among other issues you have a company falsely claiming their data set contains all known vulnerabilities despite actually not even adding the most vulnerabilities and Wordfence claiming the data they use only contains  “Confirmed/Validated” vulnerabilities. On that latter front we recently came across another example of other data sources falsely claiming that a vulnerability had been fixed, when it hadn’t. Getting that right seems like a critical element in providing this type of data, since correctly informing about unfixed vulnerabilities seems like it would the most important element. This time it involves a vulnerability that we were warning our customers for a month before the other data sources even added to their data set.

One of the things we do to make sure we provide the most complete data on vulnerabilities in WordPress plugins is to monitor for indications that a new version of a plugin includes a fix for such a vulnerability. With version 2.0.5 of the plugin WordPress Comments Import & Export, which was released on May 7, originally one of the changelog entries was “Fix the vulnerable to Remote Command Execution.”. Minutes later it was changed to “Bug fix, comment data filtered.” We looked into that and found that there was a CSV injection vulnerability that was attempted to be fixed in that version, but the fix was incomplete. We then put out a post with the details of the vulnerability on May 17. We notified the developer of the plugin that the vulnerability had not been fixed then as well. On June 6 the changelog was modified again to add “CSV Injection was fixed – reported by one of our user (Bhushan B. Patil) CVE-2018-11526”.

While the details of our post on the vulnerability are only available to our customers, other data providers could have known a fair amount about the vulnerability with just the title of our post. The final version of the changelog would have also given them a lot to go on and yet they didn’t add the vulnerability until it was disclosed by the discoverer.

When the discoverer, Bhushan B. Patil, disclosed it, they incorrectly stated it had been fixed. That isn’t an uncommon situation. Despite that, other data sources just blindly repeated that it was fixed without checking things over.

Here is ThreatPress’ entry:

The most widely used data source, the WPScan Vulnerability Database, got things even more wrong since they claim it was fixed in version 2.0.4:

Proper Warning Missing

One key difference with those data sources and ours is that they are accessible for free, so there is a tradeoff to be made when using a free data source. If the lack of checking if vulnerabilities were fixed was the only limitation with those data sources, you could mitigate that by testing out if vulnerabilities in plugins you use have actually been fixed, but that isn’t only one of the issues with them. Another is that they are missing plenty of more important vulnerabilities than the one in WordPress Comments Import & Export from their data sets. Take for example an unfixed vulnerability in the plugin KingComposer that we discovered and had disclosed on May 16. That is a vulnerability that we have seen evidence that hackers are already trying to exploit, so it would be something that you would want to be warned about, but those data sources still don’t contain that vulnerability. Since we don’t want people to be left in the dark in that type of situation we includes the details of vulnerabilities that look like they are being exploited in the free data that comes with the companion plugin for our service, so even those not using our service can be warned.

Any providers using data sources like those should be providing proper warning about the quality issues that are inherent in the data they are using. Unfortunately that isn’t the case. Some even take it further. Earlier we mentioned how Wordfence claims that the data they use on plugin vulnerabilities is “confirmed/validated”, but there data is none other than the WPScan Vulnerability Database, which as this situation shows, doesn’t do that. Lying in that way seems like it should be a serious issue, but considering that Wordfence has a long history of serious lies like that, which haven’t impacted them so far, we unfortunately don’t think it will cause them any damage.