Blocking the Slider Revolution Plugin Vulnerability
There is a vulnerability for the Slider Revolution Plugin for WordPress that has already been disclosed in forums. More information regarding the vulnerability is available from Sucuri. We are now blocking the attack, and will be updating our block based on logs/feedback to keep clients safe.
The vulnerability makes it is possible for an attacker to read your wp-config.php and find your database credentials, which may allow them to compromise your site’s database. We don’t allow random IP addresses to connect directly to your database, but that may not prevent someone from finding a way to use database info to connect to your DB.
We will force-update plugins when serious vulnerabilities are found, but cannot do that here, because this is a premium plugin, available via ThemeForest. It is also built-into many themes, which makes it particularly problematic. Some users may not even realize they are running the plugin, and it’s hard to say if all themes will update their included files to remove the problem.
In order to fix this, we have added rules to our webapp firewall, ModSecurity, to block the attack. We’ve started by blocking all query strings that include ‘wp-config.php’. This isn’t something that should be used often in a query string, so I don’t expect it to cause many problems (and we haven’t seen any tickets regarding problems so far).
The basic rule we’re using is this:
SecRule ARGS_GET “wp-config.php” “t:lowercase,deny,status:403,log,id:9876543,msg:’wp-config query string'”
If you want to use this on your own server, you should replace the ‘id’ number with a different 7 digit string, making sure it does not conflict with any rules you use. This is just a placeholder here, as we use our own numbering system. This rule will look at all query string parameters and issue a 403 response to any that include ‘wp-config.php’ anywhere in the string. The block will be logged with the message ‘wp-config query string’.
We don’t always post info like this, because it can help attackers work around the block, by knowing what is being restricted. This was just a rough rule, however, which will be refined, and given that we are already seeing it stop attacks fairly regularly, I felt it might be helpful to share.
If you don’t use ModSecurity, it should also be possible to block this with .htaccess, and I believe that WordFence has been updated to protect against the attack.
Hopefully that helps someone running their own server that isn’t sure if they are vulnerable to this issue. If you are hosting your site here at Lightning Base the rule is already applied, you don’t need to take any of the actions described above.
