Category: Bad Security

If you follow the news what seem pretty clear is that cybersecurity is not in good shape these days, whether it’s major credit card breaches at retailers or hacks of high profile organizations, clearly something is very wrong. It seems unlikely that is due to a lack of spending on security products and services, consider that estimates of yearly spending on cybersecurity are in the 10s of billions of dollars and expected to continue to rise. Instead part of the explanation is that much of that money is being spent on products and services from companies that know and or care little about security.

To give you one example, anti-virus software from well known companies Kaspersky Lab, Norton, McAfee, Sophos, and Trend Micro all were found by Google researcher Tavis Ormandy to have had exploitable vulnerabilities in them. When you have to be concerned that security products are increasing your security risk that indicates something is quite wrong. But what is more striking about those vulnerabilities is the ease of exploiting some of these and that they were due in part to the companies doing dumb things. For example, in the case of Norton, quite of few of their products, including enterprise products, were subject to a remote code execution vulnerability that could be exploited by sending an email (it wouldn’t have had to be opened) that was due in part to running code at a higher privilege level than was have been needed.

As we have ramped up our Plugin Vulnerabilities service for keeping track of vulnerabilities in WordPress plugins, we have run across more of what WordPress security companies are up to and what is seen is that are not the exception when it comes to the poor state of security companies. One such example is Wordfence, we have frequently seen things that showed they either didn’t know or care much about security.

What we have wondered for some time though, is it more that they don’t know about security or if they just don’t care about it. To see why that is, take their involvement in the widespread claim that brute force attacks against WordPress admin password are occurring, despite the fact the evidence from Wordfence and other security companies actual shows that they are not. Does Wordfence had no clue what they were talking about or do they know they were telling people a falsehood to help push their product and service, seeing as those wouldn’t be needed if people knew what the malicious login attempts falsely being labeled as part of brute force attacks were most likely part of, dictionary attacks, which can be protected by simply using a strong password. We really were not sure.

In another example, Wordfence made a bold claim about being able to protect against stored XSS attacks, which we found to be false with some simple testing. In that case it could have either been that they were saying something they knew wasn’t true or it could have been that they understand so little about this type of vulnerability that they didn’t understand what incredible claim they were making and that they needed to be very careful about making it without being sure about the claiming.

We think the latest false information put forward them makes it pretty likely that they are lacking a basic understanding of security, which is frightening since so much of the WordPress community is relying on them for information and protection.

In a post about what they say are the most attack plugin vulnerabilities (worth mentioning here is that we recently found that Wordfence seems to be oblivious to vulnerabilities in plugins that are actually the biggest threat) they made a claim that we and they found out surprising, that many of the vulnerabilities being targeted were local file inclusion (LFI) vulnerabilities:

The large number of local file inclusion vulnerabilities that are being exploited is surprising. I should also note that many of these LFI’s were discovered by Larry Cashdollarwho I had the pleasure of seeing speak at Defcon in Las Vegas 2 weeks ago. So I suspect that many of these are being used in an attack script of some kind which may explain their prevalence in the attacks we’re seeing.

The clustering of LFI’s together and Shell exploits together in the list order is odd, but I don’t have a theory to explain that and there is no error in the data that accounts for that. It appears to be coincidence.

Considering that everything we know from monitoring plugin vulnerabilities and dealing with lots of hacked websites is that this type of vulnerability is rarely targeted, this seemed odd. But a quick look at the data they presented showed a simply explanation, local file inclusion vulnerabilities were not actually be targeted. Instead what was being targeted were what we refer to as arbitrary file viewing vulnerabilities (they are also often referred to arbitrary file download or directory traversal vulnerabilities), which are very different.

Before we get in to what each of those type of vulnerabilities is,  it is worth mentioning that Wordfence really had to go out of their way to get this wrong, as can easily seen by the fact that the first five vulnerabilities they listed as being local file inclusion vulnerabilities are actually listed in the linked to advisories as being the following types of vulnerabilities:

• Arbitrary File Download
• File Disclosure Download
• Arbitrary File Download
• Aribtrary File Download
• Arbitrary File Download

Not one of those is listed as listed local file inclusion vulnerability, so Wordfence must have thought they were all wrong.

A local file inclusion (LFI) vulnerability allows an attacker to include a file that exists on the file system of the server the website is on (a remote file inclusion (RFI) vulnerability allows the same with a file that exists somewhere else). For this type of vulnerability to useful to a hacker they either need to be able to place a file on the website or there needs to be a file thats inclusion in this way causing a security issue. Since those do not appear to be readily available in most cases it follow that this type of vulnerability is not often being exploited.

An arbitrary file viewing vulnerability allows viewing the contents of a file that exists on the website. With WordPress websites we frequently see attempts to exploit this type of vulnerability to view the contents of the wp-config.php file. If successful that would provide the attacker with the database credentials associated with the website. For that to be useful the attacker would need to be able to connect to the database, their ability to do that varies greatly depending on the hosting setup. While we see many attempts to exploit this type of vulnerability, we see it being the cause of a website being hacked much less than arbitrary file upload vulnerabilities, which we also see many exploit attempts against.

While Wordfence’s lack of understanding what each of these vulnerabilities would likely has some impact on protecting against them, it would have an even bigger impact on their properly doing hack cleanups (which they also offer) since it greatly helps to understand what security vulnerabilities have existed on the website to determine the source of the hack and the impact the exploitation of a vulnerability could have had.

If you care about security we would recommend you help us get the truth about Wordfence out to a wider audience so that together we can lessen the damage they are doing toward the security of so many websites.