Login

Tag Archives: Security Vulnerability in Security Plugin

7 Feb 2017

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

When it comes to trying to improve the security surrounding WordPress one of the big impediments is the security industry. One of the things we see them doing is providing misleading and sometimes outright false information to the public about security. One outright falsehood that has been widely spread is that there are lots of brute force attacks against WordPress admin passwords, when based on security companies own evidence are not happening at all. What is really happening are dictionary attacks, which involve an attacker try to login using common passwords. That type of attack is easily protected against by using a strong password, something that WordPress does a good job of helping you do. What might explain why security companies are saying something that isn’t true here is so that they can use the false claim to promote their plugins and services, like we have found Wordfence doing. The problem with this is that every plugin on the website introduces the possibility of a vulnerability, including security plugins.

Take the plugin XO Security that we recently ran across, which is promoted as providing “enhanced login security.” It provides a number of features and by default it will log login attempts. That involves storing and outputting user input data, which needs to be properly handled, but in that wasn’t happening, which was allowing for persistent cross-site scripting (XSS). [Read more]

2 Jan 2017

Information Disclosure Vulnerability in Pike Firewall

In our testing of WordPress security plugins to see what, if any, protection they provide against the exploitation of actual vulnerabilities in other plugins the results haven’t been good so far. Most of the plugins tested haven’t provided any protection against those vulnerabilities. That hasn’t really surprised us, as much of what these plugins do doesn’t have any impact on what hackers actually try to do. One example is that many of these plugins check if you have change the database prefix to something other than the default “wp_”, but knowing the database prefix is rarely needed for vulnerabilities we see being exploited. If knowing the database prefix was a big deal then the vulnerability we recently found in a security plugin would be a big deal, as the vulnerability exposes that.

While doing a few quick security checks over the plugin Pike Firewall we noticed that it has the capability to log login attempts. We and others have found that capability in plugins has introduced security vulnerabilities into plugins due to improper handling of user input that comes through that. One of things that has been an issue with other plugins is that malicious JavaScript code placed in the HTTP header field X-Forwarded-For will get displayed on the plugin’s pages unsanitized or unescaped leading to cross-site scripting (XSS). In this case we found it caused another issue when tried logging in with it set to malicious code we got this error: [Read more]

2 Sep 2016

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in Centrora Security

Recently while during some quick security checks over security plugins we noticed that the protection against cross-site request forgery (CSRF) in the Centrora Security plugin was easily bypassed. To provide an example of that in action we looked at how that could be used to insert JavaScript code into a page, which would be a cross-site scripting (XSS) vulnerability. While we doing that we realized there was an additional security issue with the plugin, it fails to restrict its AJAX functions to intended user levels. Using the example from the first vulnerability that leads to authenticated persistent cross-site scripting (XSS) and it could have possibly lead to other issues as of version 6.5.6.

The plugin makes the function runAction() accessible through WordPress’s AJAX with the following code in the file /vendor/oseframework/ajax/oseAjax.php: [Read more]

2 Sep 2016

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Centrora Security

When it comes to writing secure code one good piece of advice is to use the security functions provided in the environment you are using instead of making your own. The developers of Centrora Security decided not to do that in the cross-site request forgery (CSRF) protection for AJAX requests in the plugin and in their custom code they made a mistake that nullified the protection as of version 6.5.6.

According the plugin’s description it is able to help identify security vulnerabilities, but it would seem not this one: [Read more]

29 Jul 2016

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in User Activity Log

Every additional plugin that you add to your WordPress website adds additional security risk, that includes security plugins. Recently we did a quick check over plugins designed to allow you to keep track actions taken by users on your website. In several of cases we found rather minor security vulnerabilities. Like the first issue we found in the plugin User Activity Log, this one involves a lack of protection against cross-site request forgery (CSRF).

This vulnerability involves a lack of protection against CSRF when saving the plugin’s settings. That is due to a lack on a nonce. [Read more]

29 Jul 2016

Cross-Site Request Forgery (CSRF) Vulnerability in User Activity Log

Every additional plugin that you add to your WordPress website adds additional security risk, that includes security plugins. Recently we did a quick check over plugins designed to allow you to keep track actions taken by users on your website. In several of cases we found rather minor security vulnerabilities. We found two related issues in the plugin User Activity Log due to a lack of protection against cross-site request forgery (CSRF).

A CSRF vulnerability involves causing someone to take an action they didn’t intend to. In the case of the first vulnerability in the plugin, if you could get an Administrator to visit a page you control you could cause them to in turn access the page /wp-admin/admin.php?page=general_settings_menu&db=reset, which would cause all logged activity to be deleted. You can see that the URL doesn’t contain a nonce, which is what is used to protect agains this type of vulnerability. This isn’t something that is likely to be exploited, but it is concern since it would make it easier for someone to erase some of the evidence of what malicious action they might have taken. [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]

12 Jul 2016

Remote Code Execution (RCE) Vulnerability in wSecure Lite

We recently disclosed a minor, but very obvious, vulnerability in a WordPress plugin for logging user activity. What we found kind of stunning about this was that the developer of the plugin was a WordPress security company that claimed to “specialize” in doing security reviews of plugins. We later got an email from someone at the company who seemed to be surprised that we would have a negative view of the security industry. We have hard time believing that someone who actually cares about security and sees what is going on would not have such a view, considering how bad things are. We recently found another reminder of that from a security plugin with an incredibly serious vulnerability.

wSecure Lite is a plugin that makes it so that visiting the normal URLs to login to the WordPress admin area does not work and instead you have to visit a special URL to login (as the name suggest there is also a paid version of the plugin). That isn’t something that really provides you much protection, as the only thing the average website needs to do in regards to login security is use a strong password. In this case though using this plugin opened you up to a remote code execution (RCE) vulnerability, which would allow a hacker to do just about anything on a website. [Read more]