Login

Tag Archives: Total Security

16 Dec 2016

No WordPress Security Plugin Prevented Exploitation of Unfixed Arbitrary File Upload Vulnerability in Popular Plugin

When it comes to the chances of vulnerabilities being exploited the reality is that many types of vulnerabilities are highly unlikely to have anyone even try to exploit them. Unfortunately far too often we see security companies and the press making a big deal of vulnerabilities that are are of little to no threat, while ignoring vulnerabilities and broader security issues that are leading to websites being hacked (that lead us to providing information on likelihood that a vulnerability is to be exploited to the data for our service). When it comes to types that are likely to be exploited, the arbitrary file upload vulnerability, which allows a hacker to upload files of any kind to a website, is probably the one with the most exploit attempts and also then ends up leading to the most websites being hacked. So if a WordPress security plugin is going to protect against any type of vulnerability this seems like this is the one you would most want it to be able protect against.

Back in September we tested out security plugins against this type of vulnerability and the results were not good. Of the 12 plugins tested only 3 provided any protection. The protections 2 of them provide was easily bypassed for this particular vulnerability and the remaining plugin’s protection also meant that Editor level and below users could not upload files either. [Read more]

18 Jul 2016

Wordfence’s Firewall Doesn’t Protect Against a Real World Unauthenticated Stored XSS Vulnerability

At the end of last month we wrote a post about our finding that despite Wordfence’s unqualified claim that their plugin’s firewall protects against stored XSS (or what we refer to as persistent cross-site scripting (XSS)) that it did not protect against a real world vulnerability. After we posted that we though that maybe the vulnerability we used for the test wasn’t totally fair, since it required the exploiter to be logged in (or authenticated) to WordPress. Wordfence doesn’t seem to think that matters much, seeing as how the have frequently left out the detail that a vulnerability is only exploitable when logged in when disclosing them. But seeing as it severely limits the amount of website that are impacted (since many don’t allow people that are not trusted to have account), we wanted to run another test on a vulnerability that didn’t have that limitation.

The same day we put up that post, we notified the developer the security plugin Total Security that we had found a persistent cross-site scripting (XSS) vulnerability in their plugin. In the case of this vulnerability you do not need to be logged in to exploit the vulnerability, the only limitation is that the 404 Log feature needs to be enabled. Due to another security vulnerability in that plugin, anyone can change the plugin’s settings, so they could enable that feature themselves and then exploit the other vulnerability. [Read more]

18 Jul 2016

Settings Change Vulnerability in Total Security

We were recently doing some basic security checks over WordPress security plugins and identified a possible issue in the plugin Total Security. While the issue we first were looking into turned out to not be exploitable, we noticed a couple of other security vulnerabilities in the plugin. The first being a persistent cross-site scripting (XSS) vulnerability. The second vulnerability allows anyone to change the plugin’s settings.

While it seems pretty bad that a security plugin has security vulnerabilities of its own, what is more incredible is the response from the developer. It took them 5 days to get back to us and at that point it doesn’t even look like they have really looked over the information we provided them, since they were asking what the solution to the vulnerabilities despite much of that being provided in a link we had included in original message. Yesterday, 17 days later, they released a new version of the plugin, 3.3.8, which didn’t fix either of the vulnerabilities. Oddly the version available before that was 3.4, so they move backed versions as well. [Read more]

18 Jul 2016

Persistent Cross-Site Scripting (XSS) Vulnerability in Total Security

We were recently doing some basic security checks over WordPress security plugins and identified a possible issue in the plugin Total Security. While the issue we first were looking into turn out to not be exploitable, we noticed a couple of other security vulnerabilities in the plugin. The first one is a persistent cross-site scripting (XSS) vulnerability that is in the 404 log feature, which is disabled by default, due to lack of proper handling of user input data.

While it seems pretty bad that a security plugin has security vulnerabilities of its own, what is more incredible is the response from the developer. It took them 5 days to get back to us and at that point it doesn’t even look like they have really looked over the information we provided them, since they were asking what the solution to the vulnerabilities despite much of that being provided in a link we had included in original message. Yesterday, 17 days later, they released a new version of the plugin, 3.3.8, which didn’t fix either of the vulnerabilities. Oddly the version available before that was 3.4, so they move backed versions as well. [Read more]