Login

Tag Archives: Analysis

3 Mar 2020

Bad Practices by Fortinet and the WPScan Vulnerability Database Lead to False Claim of Vulnerability Being Fixed in WordPress Plugin

Years ago we recommended data from the WPScan Vulnerability Database as good alternative to our service, since while their data was of lower quality, it was available for free. Now more and more access is being charged for, while the quality of the data has gotten worse since we used to recommend it. Here is a recent example of that, which also shows bad practices from Fortinet made it hard to figure when they screwed up in disclosing a vulnerability.

Here is the current version of the entry from WPScan of a vulnerability in Testimonials: [Read more]

30 Sep 2019

WebARX’s Idea of Threat Intelligence Involves Copying From the Low Quality Data of the WPScan Vulnerability Database

The phrase “threat intelligence” seems like it is becoming popular among security companies that are more focused on BSing  than doing the work that threat intelligence would entail, with the results for their customers being poor (up to their customers getting unnecessarily hacked). We recently ran across a post from WebARX, which we will get to the details of in a second, but at the end of was this claim:

Threat intelligence and prevention is our main focus and thus our firewall engine is updated on a daily basis. [Read more]

30 Sep 2019

The Temporary and Permanent Closures of Plugins on the WordPress Plugin Directory Don’t Mean What You Probably Think

Recently the team running the Theme Directory on the WordPress website was re-organized to create five sub-teams, by comparison the team running the Plugin Directory only has six people in total. The undersized plugin team seems very much intentional, as the stated reason for not allowing anyone else to join them team doesn’t add up and from our experience they are unable handle people having different opinions than them, much less work with others to fix problems they are causing. Of the six people, it isn’t even clear how much more than two of them even are involved. Whether it is two or six people handling so much, the results are not likely to be very good. That seems to be the case for recently changed wording shown on the pages for plugins that have been closed on the Plugin Directory.

In a support forum topic about a vulnerability being exploited in a plugin that was closed after we noticed a hacker probing for it this was written: [Read more]

25 Sep 2019

Exploitation of Vulnerability in Simple Fields WordPress Plugin Shows That Unlike Other Security Providers We Keep Ahead of Hackers

If you want to understand why security, whether related to WordPress plugins or more broadly, is in such bad shape looking at the state of security journalism would be a good place to start. What you will find with WordPress plugins is that there are frequent stories telling people to update or remove plugins after they have already been widely exploited, which is too late. You might think that journalists would stop and think about that and realize there what is going on isn’t working (there is a line about the definition of insanity that comes to mind), but it doesn’t ever seem to occur for them. If anything they seem to think trying to better address the situation is a bad thing. For example, earlier today we mentioned that a journalist was criticizing us for having spotted a hacker targeting a plugin and then publicly warning everyone about that before there was confirmed exploitation. If journalists were actually interested in doing good journalism another element of that post is worth covering, as a new version of the plugin that fixes the exploited vulnerability has been released, but the WordPress is not allowing those using the plugin to get access to it.

That plugin was part of what looks to have been a set of nine plugins so far that a hacker has been recently looking to exploit. With another of those, Simple Fields, we saw what looked to be the hacker probing on the September 15 and we warned about a persistent cross-site scripting (XSS) vulnerability that it looked like the hacker would be interested in exploiting the next day. Other security providers still don’t seem to be aware of the issue (they at least have not warned about the issue), even though there is now public confirmation that it is being exploited. What that shows is not only how our service can often help to avoid websites being hacked by warning before the hackers exploit vulnerabilities instead of after, but also that we can help to address security situations that are beyond the scope of the average webmaster on their own. [Read more]

25 Sep 2019

WordPress Isn’t Allowing Users of DELUCKS SEO to Get New Version of the Plugin That Fixes Exploited Vulnerability

When it comes to the poor security surrounding WordPress plugins what we have long found so unfortunate is that it would be easy for the team running the Plugin Directory to improve the situation, but for reasons that have never made sense they continue to refuse to do things that would make a big difference and likely greatly reduce the number of websites being hacked (we and others have repeatedly offered to help them do those things).

One of the problems we have long seen is that after plugins are closed on the Plugin Directory due to vulnerabilities, even after the vulnerability has been fixed, the plugin remains closed, so those already using the plugin can’t get the updated version. This often looks to be because the team running the Plugin Directory requires more changes to be made, sometimes security related. The problem with that is that if those websites could update they would stop the possibility of the fixed vulnerability being exploited. [Read more]

20 Sep 2019

Responsible Disclosure and Closing a WordPress Plugin With an Unfixed Vulnerability Didn’t Prevent Websites From Being Hacked

One of the things we do to keep track of vulnerabilities in WordPress plugins to warn customers of our service if they are using publicly known insecure plugins is monitoring WordPress support forum. Recently that hasn’t led to us finding out about any vulnerabilities we didn’t know about, but it does provide a regular reminder of the lack of concern of people in charge of WordPress about addressing the poor handling of security problems with plugins.

Yesterday a topic was started on the forum of Rich Reviews, “Plugin not supported; open to malware – uninstall now!“, which starts: [Read more]

11 Sep 2019

Wordfence Security and Wordfence Premium Failed to Protect Against Widely Exploited Vulnerability

A month ago we noted an instance of us running across the Wordfence Security plugin, despite being marketed with the claim that it “stops you from getting hacked”, failing to protect against exploitation of a vulnerability in a WordPress plugin that was being widely exploited. That has happened again. In a post earlier today we mentioned a topic on the WordPress Support Forum discussing websites being exploited due an already fixed arbitrary file viewing vulnerability in the plugin Advanced Access Manager, which we had warned customers of our service about the same day it was fixed. In that topic there was a claim that the Wordfence Security plugin failed to protect against that:

It happened to me. I cleaned up but it came again one day later, even websites with last version of WP, with Wordfence, Block Bad Queries, etc.
Does somene knows where it comes from ? Is it an injection ? [Read more]

11 Sep 2019

If a Hacker Has Modified Your WordPress Website’s Database That Doesn’t Mean a SQL Injection Vulnerability Was Exploited

Among the many areas where there seems to be confusion over security when it comes to WordPress websites, and websites more broadly, is a type of vulnerability known as SQL injection. SQL is short for Structured Query Language, a language used for communicating with some databases. SQL injection involves injecting malicious code into SQL statements, causing code specified by the attacker to run against the database. What can be done through that depends on the specifics of the vulnerability, but in most instances with WordPress plugins all that can be done with that is to slowly read out the contents of the database. What often gets referred to as SQL injection, involves any changes being made to the database, which in recent history with WordPress plugins being exploited, almost never involves SQL injection.

One of the ways we keep up with vulnerabilities in WordPress plugins, so that we can warn customers of our service about any of them that impact them is by monitoring topics on the WordPress Support Forum related to them. These days though what we are usually finding though is that vulnerabilities we already warned our customers about are now being exploited. That was the case with an arbitrary file viewing vulnerability in the plugin Advanced Access Manager that we warned our customers about on the 5th when it was fixed. We rated the vulnerability as having a high likelihood of exploitation. Early on the 7th a topic was started on the forum that appears to be due to that vulnerability being exploited. [Read more]

10 Sep 2019

SiteLock is Making the WPScan Vulnerability Database’s Low Quality Data Worse

One of the things that we believe leads to the poor state of security of WordPress, as well more generally, is the amount of inaccurate and outright false information spread by those involved in security. That also creates unnecessary hassle for others. When it comes to our area of focus, the security of WordPress plugins that is a constant issue. While we properly vet claimed vulnerabilities before adding them to our data set, if you are getting data elsewhere it likely comes from the WPScan Vulnerability Database, which is data source where the people behind it don’t seem to be concerned about the accuracy of their data (or other things that seem important for providing what they claim to provide).

If they were even a little concerned about that it seems hard to believe what has happened with the plugin WooCommerce PayPal Checkout Payment Gateway would have occurred. They are currently claiming that plugin, which has 800,000+ installs according to wordpress.org, contains an unfixed vulnerability: [Read more]

9 Sep 2019

NinTechnet and WordPress Plugin Directory Team Fail to Make Sure Vulnerability in Search Exclude Was Actually Fixed

Last week we disclosed a settings change vulnerability in the plugin Search Exclude after it had been closed on the WordPress Plugin Directory and noted that wasn’t the only probable issue:

There also appear to be other security issues with the plugin. [Read more]