A few days ago there was a background on Twitter about how to ensure a WordPress installation in which you cannot update the core, themes, plugins or translations. In these cases, the solution is not simple, but it does not mean that the installation is unsafe.
In these cases, the first thing we have to analyze is whether the plugins / themes are safe or not, in addition to the WordPress version that there is not having severe holes. If we start with the core part, we must know that there are ancient versions that have security patches… For this, we can visit the WordPress releases page, where we will find them. For example, right now, July 2018, we have versions like:
- Branch 3.7: Version 3.7.27
- Branch 3.8: Version 3.8.27
- Branch 3.9: Version 3.9.25
- Branch 4.0: Version 4.0.24
- Branch 4.1: Version 4.1.24
- Branch 4.2: Version 4.2.21
- Branch 4.3: Version 4.3.17
- Branch 4.4: Version 4.4.16
- Branch 4.5: Version 4.5.15
- Branch 4.6: Version 4.6.12
- Branch 4.7: Version 4.7.11
- Branch 4.8: Version 4.8.7
Typically, these branches appear on or after the same day as the most current versions of the main branch. So, this is the first task that must be done, try to update, at least, the core of WordPress. In case they have touched the core, the truth is that the disaster is already so great that I do not know very well what solution to give.
As a second round, I highly recommend trying to do a maintenance of the server operating system. Obviously, you have to make a copy of everything, set up a development environment and test the system with current versions of PHP, MySQL and operating system. This does not mean that you have to switch to Ubuntu 18 if you have Ubuntu 14, or change from PHP 5.4 to 7.2, but that the branches of the operating system itself, PHP and MySQL, make an update. The operating system and the database should usually not give problems. On PHP, although there is not so much retro compatibility, we should try to make the effort to use the latest versions of PHP 5.6 or 7.2. It’s rare for a WordPress plugin to use weird features that aren’t compatible with either of these two versions. For example, right now, July 2018, we have versions like:
Of course, in these cases it is essential to use some type of firewall, most likely it must be external, so if your hosting is not able to provide you with a file cage system (so that WordPress can not be mixed with other installations of anything else) and can not provide you with an external layer of locks, you should consider someone who does. Currently, for example, I am working on a solution for my clients who have this problem, a system that separates user accounts and also maintains different versions of PHP.
Next step: find known vulnerabilities in certain plugins… For this, we can use as a basis the system of the WPScan Vulnerability Database that at least will indicate if there are serious holes in certain versions of what we use. You have WordPress reviews, plugins or themes. If you find that a plugin has vulnerabilities, the advantage that everything is GPL, is that you should have at your disposal the source code of the new versions, and you could patch the code with the most serious that there is.
From here, which is the most basic of the whole system, you have to make some blocks of WordPress itself. These systems may not fully protect you from an attack, but they could at least try to minimize the detection of old versions of some elements.
Another important element to keep in mind, mainly due to data leakage and possible code injections, is the installation of a TLS certificate and activating HTTPS by default (this should not affect the system), but perhaps more to include a series of CSP (Content Security Policy) rules, at least the one that activates the automatic “upgrade” from HTTP to HTTPS.
Moreover, for the database we should do a review of the permissions (I would even dare to say that if it is an “untouchable” installation), let’s just leave SQL permissions of INSERT, SELECT, UPDATE and DELETE and delete the others.
Although without a doubt what you have to do is hide the detection to the maximum of the versions of WordPress and plugins. It should be remembered that there are many methods of detection and, therefore, of concealment. Also, for security, we hide the possibility of burning the database if the connection fails.
Above all, remember to make backups and test them, which do not become Backup Schrödinger, and if after passing an analysis by WordPress Danger you still have detections, do not hesitate to contact me that we will analyze in more detail the casuistry of that installation and protect it in the best possible way.
About this document
This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.