Wednesday, May 8, 2013

Secure WordPress: Part 2 - Configuration Settings


In part 1 of this series we focused on the one of the most common security problems related to user accounts that often result in attackers easily taking over your WordPress site. In this part we will be tackling insecure configuration settings in PHP, WordPress itself, etc and present secure alternatives that strongly improve the security level of your site.

PHP Settings


General Recommendations

General best practices dictate disabling "Safe Mode" and "Magic Quotes" as both are deprecated and might cause problems with your site.
Change settings by adapting the according entries in the file php.ini:
safe_mode = Off;
magic_quotes_gpc = Off;
magic_quotes_runtime = Off;
magic_quotes_sybase = Off;

Logging Recommendations


When hackers are targeting your site, every bit of information, such as physical paths, error messages displaying source code, etc can be leveraged in later attacks. Also, it is crucial to have proper logging in place to be able to trace hack attempts and have the possibility to analyze the attacks and understand what they were doing.
Change settings by adapting the according entries in the file php.ini:
expose_php = Off
log_errors = On
display_errors = Off
html_errors = Off
display_startup_errors = Off
error_reporting = 32767 //E_ALL starting from PHP 5.4

Security Recommendations


Now let's talk about more critical configuration settings that might protect your site from being fully taken over by attackers. "Register Globals" has been deprecated as of PHP 5.3.0 and removed as of PHP 5.4.0, but unfortunately there still exist quite a few PHP installations that have this option enabled. This option opens up a lot of attack possibilities and often allows attackers to take over your web application easily, so it should be disabled.

Another security consideration is restricting powerful PHP functionality that, when used in an insecure fashion by e.g plugin developers, can make your site vulnerable. This powerful functionality is also commonly used after a site was initially hacked to install backdoors. Users should leverage the "Disable Functions" option to disable those functions thus limiting what attackers can do on your site.

For example, "fopen", a commonly used function in many PHP applications allows the reading and writing to file resources. If the allow_url_fopen option is activated, PHP allows to use URIs for fopen or includes, which has been the cause of countless web site compromises in the last decade. More information about this attack, which is called "remote file inclusion", can be found on Wikipedia.
Change settings by adapting the according entries in the file php.ini:
register_globals = Off
disabled functions = system,exec,passthru,shell_exec,proc_open
allow_url_fopen = Off
allow_url_include = Off
Note: If you can't change the php.ini directly, some of these settings can be changed in the wp-config.php file with the following syntax:
@ini_set('log_errors','Off');
/* That's all, stop editing! Happy blogging. */

File Permissions


File permissions are often cause for security related discussions. Let's explore the core concepts and main considerations for file permissions in WordPress hosting environments.

In shared hosting environments, you share one server with dozens or hundreds of other customers. These setups are cheap, but often very difficult to secure, because in many cases it could be possible for another user on the same server to access files belonging to your Wordpress site (e.g. your wp-config.php file),  or read your DB passwords and them take over your site this way. If the file permissions are set poorly then it might even be possible for a user on that server to write and change arbitrary files for your site as well. So obviously if an attacker takes over any one site in the shared environment, they could spread to all the other sites fairly quickly.

Ideally, in a Linux- or Unix-based shared environment each user should be assigned an unique user account that has exclusive read and write permissions to its own files. The group permissions should be set to "read" for all files so the web server so the WordPress site can work properly.  However, users should not have any read permission or write permission to another user's files. That way it is prevented that anybody else on this shared environment can read or write the files of other users. However, the problem remains that if any other user on that server would upload a file browsing PHP script it would run with the privileges of the web server which would allow it to still read all the files. Check if your hosting provider is using open_basedir restrictions or ask them directly how they ensure that users are limited to their virtual hosts.

In self-hosted environments the same best practices apply, although the risk is heavily reduced due to the fact that the server is not shared with hundreds of other users.

WordPress Settings


The last section of this part we will be looking at some WordPress specific settings that, if configured insecurely, could turn your WordPress site into an open door for attackers.

File Editing: The WordPress "file edit" functionality can be useful for making quick changes to plugins or themes, but generally it is not needed in production systems. This functionality is often exploited by attackers who have gained access to the admin interface to quickly compromise the website. On production systems, this functionality should be disabled if it is not explicitly needed.

Allowed MIME Types: WordPress allows the upload of media. By default this functionality is limited to file types that are considered safe such as image files. It is crucial to never allow dangerous file types such as .php scripts, because this would allow any user with the author or editor role to take full control over the site.

Debugging: Similar to the debugging and error messages that PHP provides, WordPress has a debugging switch that can be enabled to show errors during e.g plugin development or to facilitate troubleshooting. In a production environment this should never be active to prevent attackers from obtaining sensitive information that could be exploited in further attacks against the site.

Summary


  1. Ensure that PHP is configured securely in only necessary features are enabled. 
  2. Ensure that file permissions don't give other users the possibility to write/read your files.
  3. Ensure that dangerous WordPress features are disabled on a production system.

Don't know if your WordPress site is configured securely? Don't worry, just go ahead and download MVIS Security Center for free and it will help you to identify security issues with your setup and give you exact information on how to improve the security of your site.