Hace unos días que rondaba por Twitter un runrún sobre cómo asegurar una instalación de WordPress en la que no puedes actualizar el core, themes, plugins o transations. En estos casos la solución no es sencilla, pero tampoco significa que la instalación sea insegura.
En estos casos lo primero que hemos de analizar es si los plugins / themes son seguros o no, además de que la versión de WordPress que haya no tenga agujeros extremadamente graves. Si comenzamos por la parte del core, hay que saber que existen versiones muy antiguas que tienen parches de seguridad… Para ello podemos visitar la página de WordPress releases donde las encontraremos. Por ejemplo, en este momento, julio de 2018, tenemos versiones como:
- rama 3.7: versión 3.7.27
- rama 3.8: versión 3.8.27
- rama 3.9: versión 3.9.25
- rama 4.0: versión 4.0.24
- rama 4.1: versión 4.1.24
- rama 4.2: versión 4.2.21
- rama 4.3: versión 4.3.17
- rama 4.4: versión 4.4.16
- rama 4.5: versión 4.5.15
- rama 4.6: versión 4.6.12
- rama 4.7: versión 4.7.11
- rama 4.8: versión 4.8.7
Normalmente estas ramas aparecen el mismo día o los posteriores a las versiones más actuales de la rama principal. Así que esta es la primera tarea que hay que hacer, intentar actualizar, al menos, el core de WordPress. En caso de que hayan tocado el núcleo, la verdad es que el desastre ya es tan mayúsculo que no sé muy bien qué solución dar.
Como segunda ronda, recomiendo enormemente intentar hacer un mantenimiento del sistema operativo del servidor. Obviamente hay que hacer una copia de todo, montar un entorno de desarrollo y probar el sistema con versiones actuales de PHP, MySQL y sistema operativo. Esto no significa que haya que cambiar a Ubuntu 18 si tienes Ubuntu 14, o cambiar de PHP 5.4 a la 7.2, sino que de las ramas del propio sistema operativo, del PHP y del MySQL, se haga una actualización. El sistema operativo y la base de datos, por lo general no deberían dar problemas. Sobre el PHP, aunque no hay tanta retro compatibilidad, sí que habría que intentar hacer el esfuerzo de usar las últimas versiones de PHP 5.6 o de 7.2. Es raro que un plugin de WordPress utilice funciones extrañas que no sean compatibles con alguna de estas dos versiones. Por ejemplo, en este momento, julio de 2018, tenemos versiones como:
Por supuesto, en estos casos es imprescindible el uso de algún tipo de firewall, lo más probable es que deba ser externo, así que si tu hosting no es capaz de proveerte un sistema de enjaulado de ficheros (para que ese WordPress no se pueda mezclar con otras instalaciones de cualquier otra cosa) y tampoco es capaz de proveerte de una capa externa de bloqueos, deberías plantearte alguien que sí lo haga. Justo en estos momentos, por ejemplo, yo mismo estoy trabajando en una solución para mis clientes que tienen esta problemática, un sistema que separa las cuentas de usuarios y también mantiene distintas versiones de PHP.
Siguiente paso: encontrar vulnerabilidades conocidas de determinados plugins… Para ello podemos usar como base el sistema de la WPScan Vulnerability Database que al menos nos indicará si hay agujeros graves en determinadas versiones de lo que usamos. Tienes revisiones de WordPress, plugins o themes. Si encuentras que un plugin tiene vulnerabilidades, la ventaja de que todo es GPL, es que deberías tener a tu disposición el código fuente de las nuevas versiones y podrías parchear el código con lo más grave que haya.
A partir de aquí, que es lo más base de todo el sistema, hay que hacer algunos bloqueos del propio WordPress. Estos sistemas seguramente no te protejan por completo de un ataque, pero sí que, al menos, podrían intentar minimizar la detección de versiones antiguas de algunos elementos.
Lo primero es la protección de usuarios y contraseñas. Habría que intentar buscar un un plugin de 2FA que sea compatible con la versión de WordPress. Además, puedes obligar al uso de una contraseña fuerte.
Otro elemento importante a tener presente, principalmente por la fuga de datos y posibles inyecciones de código es la instalación de un certificado TLS y activar el HTTPS por defecto (esto no debería afectar al sistema), pero quizá más incluir una serie de reglas de CSP (Content Security Policy), al menos el que activa el «upgrade» automático de http a https.
Y siguiendo con temas de hosting (tirando mucho de .htaccess): actualizar los permisos de los ficheros y bloquear la ejecución de PHP en determinadas carpetas.
Además, para la base de datos deberíamos hacer una revisión de los permisos (incluso me atrevería a decir que si es una instalación «intocable»), solo dejemos permisos de SQL de INSERT, SELECT, UPDATE y DELETE y eliminemos los demás.
Otro elemento es el de ir cambiando cada cierto tiempo las Security Keys, intentando sis e puede automatizarlo con el Salt Shaker.
Aunque sin duda lo que hay que hacer es ocultar la detección al máximo de las versiones de WordPress y plugins. Hay que recordar que existen muchos métodos de detección y, por tanto, de ocultación. También, por seguridad, ocultemos la posibilidad de petar la base de datos si falla la conexión.
Sobre todo, recuerda hacer backups y probarlos, que no se conviertan en Backup Schrödinger, y si tras pasar un análisis por WordPress Danger sigues teniendo detecciones, no dudes en ponerte en contacto conmigo que analizaremos con más detalle la casuística de esa instalación y la protegeremos de la mejor forma posible.
Sobre este documento
Este documento está regulado por la licencia EUPL v1.2, publicado en WP SysAdmin y creado por Javier Casares. Por favor, si utilizas este contenido en tu sitio web, tu presentación o cualquier material que distribuyas, recuerda hacer una mención a este sitio o a su autor, y teniendo que poner el material que crees bajo licencia EUPL.