Limpieza de WordPress: Lecciones aprendidas sobre la seguridad de sitios web

Has estado trabajando en un proyecto durante meses, has entregado las llaves al cliente, y entonces recibes ese temido correo electrónico…

… en la página [x] algunos usuarios han estado experimentando anuncios extraños y ventanas emergentes. ¡Creo que la página ha sido hackeada! No sé qué hacer. ¡Por favor, ayuda! …

Me he enfrentado a esta situación recientemente. Me ofrecí para terminar un proyecto para una organización sin ánimo de lucro (no en la que trabajo de 9 a 5). Llevaban un año de construcción de un nuevo sitio cuando el desarrollador que contrataron originalmente los dejó como fantasmas.

Soy un chico de JavaScript, así que no estaba tan familiarizado con la totalidad del ecosistema de WordPress, pero me imaginé que sabía lo suficiente, había estado construyendo mi propio plugin para el trabajo para inyectar una aplicación React a través de un shortcode, pensando, “¿Qué tan difícil puede ser? Ni siquiera es desarrollo real…”. (no os ofendáis, sólo expresaba lo que pensaba en ese momento).

Era muy consciente de los problemas de seguridad en un entorno Node.js, pero siempre había confiado en otros servicios para que se encargaran de la seguridad del hosting. Había oído hablar de los archivos .htaccess, pero nunca había puesto mi propia aplicación de pila LAMP en producción desde cero. Ni siquiera me lo había planteado ya que me he centrado más y en tecnologías como React, Gatsby, React Native, e incluso un poco de Angular.

Por muy fácil (en términos de dificultad) que fuera manejar todas las peticiones del front-end para conseguir que el sitio estuviera terminado a la altura de las expectativas del cliente, daba por sentada mi propia ignorancia del resto de lo que implicaba. Quiero compartir lo que he aprendido en estas dos semanas para que (1) no se me olvide la próxima vez, y (2) para que podáis evitar muchos de los errores que yo cometí.

Voy a intentar proporcionar enlaces a todas las fuentes que me han ayudado en mis últimas jornadas y a hablar brevemente de algunas de las partes más importantes. Llamemos a esto:



Seguridad en WordPress 101

1. Contrata siempre a un desarrollador que conozcas o en el que puedas confiar de forma verificable

Es muy tentador contratar al desarrollador más barato que pueda encontrar. Pero a veces se obtiene lo que se paga.

Me gusta que haya sitios en los que se pueda valorar a los desarrolladores, o dejar reseñas públicas, como Upwork o LinkedIn (¿quieres sugerir otros?). Estos ayudan a dar responsabilidad al desarrollador y cierta sensación de seguridad al cliente. En este caso particular, el desarrollador original tomó una tarifa baja para un sitio bastante complejo y cortó un montón de esquinas.
Enlaces:

2. Nunca descargues y utilices temas desbloqueados o nulled – paga la tarifa normal de un mercado de temas de confianza. De lo contrario, ¡¡¡puedes instalar Malware!!!

Ni siquiera cuestioné el uso del tema en el sitio del cliente. Conociendo al cliente, supuse que ellos mismos habrían comprado el tema, pero resulta que lo dejaron en manos del desarrollador, que tal vez por ignorancia o por querer recortar gastos descargó un tema en línea que estaba corrompido con el malware wp_vcd.

Sólo descubrí cuánto tiempo llevaba el malware comparando el sitio actual con versiones de la base de código que existían mientras el sitio estaba fuera de línea o en modo de mantenimiento.

Este malware en particular se encontró dentro de functions.php, y creó tres archivos dentro de wp-includes: wp-feed.php, wp-vcd.php, wp-tmp.php. Envolvía las páginas con scripts de publicidad maliciosa y además añadía un script que registraba las direcciones IP de los usuarios que tenían permisos para editar el sitio e ignoraba sistemáticamente a esos usuarios, por lo que nunca detectarían el comportamiento malicioso al navegar ellos mismos por el sitio, estuvieran o no logueados, navegaran o no de forma privada.

Después de iniciar sesión en el servidor remoto como usuario de nivel de administrador, encontré los archivos de aspecto extraño al principio dentro de la carpeta wp-includes. Los eliminé, pensando que había resuelto el problema. El malware estaba creando redirecciones a sitios con el dominio oclaserver y registrando direcciones IP en wp-feed.php. Utilicé el siguiente script de línea de comandos para encontrar estos archivos.

grep -Ril "oclaserver"
    • grep busca en los archivos las líneas que coinciden con un patrón dado.
    • R hace la búsqueda recursiva, buscando en todos los archivos y directorios dentro del director actual

.

    • i ignora las mayúsculas y minúsculas

.

    • l suprime la salida para listar sólo el nombre del archivo

.

En un principio, pensé que esto solucionaba el problema, pero la siguiente vez que lo comprobé, los archivos estaban de vuelta. Eliminé los archivos, luego comprobé de nuevo, inmediatamente, los archivos estaban de nuevo allí, llenos del mismo contenido. Esto significa que o bien mi wpdb estaba dañado, o algún otro archivo que es llamado repetidamente por WordPress estaba dañado, o posiblemente ambos.

¿Qué hice después?

Antes de rebuscar en mi DB en phpMyAdmin, primero identifiqué y borré todos los temas y plugins no utilizados. Los archivos seguían apareciendo. Así que empecé a buscar términos dentro de los archivos.

Lo que me encontró el culpable fue que dentro de wp-temp el código estaba estableciendo una variable de contraseña. Mi único pensamiento es que esto era un hash de la contraseña de administrador (así que hice una nota para cambiar la contraseña de administrador después de la limpieza). Ejecuté el mismo comando grep pero buscando en su lugar ese valor de la contraseña.

Lo que se ve es que el functions.php del tema padre se iluminó. Allí, encontré un montón de código hacky que estaba envolviendo todas las páginas con el script malicioso e ignorando sistemáticamente las IPs en las que un usuario administrador había iniciado sesión.

Después de eliminar el código, borré los archivos maliciosos desde dentro de wp-includes y los archivos no volvieron. Todavía no estaba seguro de que el malware hubiera desaparecido por completo porque me di cuenta de que el código en wp-temp estaba creando una cookie en el cliente.

Después de eliminar el código, borré los archivos maliciosos dentro de wp-includes y los archivos no volvieron. Todavía no estaba seguro de que el malware hubiera desaparecido por completo porque me di cuenta de que el código en wp-temp estaba creando una cookie en el cliente.

Antes de cambiar la contraseña de administrador, reinicié las Claves SALT dentro del archivo wp-config.php usando https://api.wordpress.org/secret-key/1.1/salt/.

Luego, borré la caché y las cookies de mi navegador, y entré en el wp-admin del sitio desde una ventana de incógnito. Sólo entonces restablecí la contraseña de administrador.

Por último, creé un nuevo usuario de administrador para mí y animé al cliente a añadir 2FA para su inicio de sesión a través del Complemento Google Authenticator.

Enlaces:

3. En su servidor, añada un nuevo usuario y elimine el login de root para dificultar que alguien pueda hackear su servidor.

Como el cliente ya tenía su sitio instalado y funcionando en Ubuntu 18.04 un droplet de Digital Ocean, el desarrollador anterior tenía ssh acceso al droplet. Realmente no quería que pudieran volver a entrar, tuvieran o no intenciones nefastas. Me di cuenta de que sólo había un usuario root en el sistema, así que creé un nuevo usuario para mí:

sudo adduser myuniqueusername

A continuación añadí mi nuevo usuario al grupo de usuarios sudo:

sudo usermod -aG sudo myuniqueusername

Y luego he añadido privilegios administrativos a myuniqueusername:

sudo visudo

Dentro de /etc/sudoers:

myuniqueusername ALL=(ALL:ALL) ALL

Finalmente, dentro de /etc/ssh/sshd_config:

PermitRootLogin no

Después, desde la línea de comandos, reinicia ssh:

sudo service ssh restart

Desde ahí, haz lo que sea necesario para crear ssh claves para tu nueva cuenta, configúralas, cierra la sesión y luego ssh vuelve a entrar como tú.

4. Endurezca los permisos de los archivos en el servidor para evitar cambios injustificados. Desde el directorio raíz de su instalación de WordPress (quizás /var/www/html/) haga lo siguiente:

Busca a qué grupos pertenece tu usuario y tu servidor y asegúrate de que tu usuario tiene la propiedad de todos tus archivos de WordPress.

sudo groups
sudo usermod -aG nombredelgrupo minombredeusuario
sudo find . -exec chown myuniqueusername:groupname {} +

Cambiar los archivos para que sólo puedan ser escritos por el propietario (tú), y sólo puedan ser leídos por otros, Cambiar los directorios para que sólo puedan ser creados, modificados o eliminados por ti o por WordPress, y evitar que nadie más que tú o wordpress pueda leer o escribir en wp-config.

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

Enlaces:

5. Añade endurecimiento a tu configuración de httpd.conf Apache deshabilitando los banners del servidor, endureciendo tu archivo .htaccess, deshabilitando el listado de directorios, deshabilitando el HTTP Trace, previniendo el MIME sniffing, previniendo el clickjacking, previniendo algunas formas de cross-site scripting, y asegurando tus cookies dentro de wp-config.php.

Dentro de /etc/apache2/httpd.conf o /etc/apache2/apache2.conf:

ServerSignature Off
ServerTokens Prod

Entonces desde la línea de comandos:

sudo service apache2 restart

Dentro de .htaccess, inserte entre # BEGIN WordPress y # END WordPress:

Opciones -Indices
RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F]
Header set X-Content-Type-Options nosniff
Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection "1; mode=block"

Dentro de wp-config.php, añade al final:

@ini_set('session.cookie_httponly', true);
@ini_set('session.cookie_secure', true);
@ini_set('session.use_only_cookies', true);

Hay cierta discusión sobre si el método anterior es o no el mejor, también podrías y quizás deberías añadir el endurecimiento de las cookies a la configuración de tu servidor apache, consulta los enlaces de abajo.

Enlaces:

6. Añade plugins de seguridad como Sucuri Sanner y Limit Login Attempts.

.Enlaces:



Pensamientos finales

La lista anterior no es en absoluto exhaustiva, y sólo se basa en cosas que he ido aprendiendo en las últimas dos semanas. Estoy muy abierto a la corrección, adición o sustracción, de lo anterior por cualquier persona con más experiencia. Aunque no planeo centrarme principalmente en WordPress, estoy aprendiendo más y más LA de la pila LAMP a través de esta experiencia, y al final del día, con mi interés en Gatsby, probablemente me involucraré más y más con el ecosistema.

Dicho esto, no hay nada malo en aprender más sobre la seguridad de los sitios web.

.Aunque los sitios estáticos sean el futuro, mantener la seguridad de nuestros CMS y servidores web no debería perderse o quedarse como un conocimiento asumido.

Categorías : # seguridad, # wordpress

Deja una respuesta

Tu dirección de correo electrónico no será publicada.