Lo primero que hice fue consultarlo con colegas usuarios de WordPress. Para mi sorpresa a dos de los que contacté también les había pasado meses atrás, y en repetidas ocasiones. Lo que sucedía era que, sencillamente me habían hackeado la web. Habían logrado entrar en el archivo .htaccess y habían añadido unas líneas de código que hacían que lo que en principio era un sitio seguro (mi web), redireccionara automáticamente a otros donde se alojaba la infección.
Malware en WordPress: primeros pasos
Para conocer con más detalle las características de la infección había que utilizar Google Webmasters Tools y ver la información que Google recogía de mi sitio en sus revisiones. Los mensajes que daba del portal no eran del todo claros; decía que en el último acceso se había intentado redireccionar a otra url (totalmente ajena) al sitio:
When Google last tested this page, no content was returned from your server. Instead, the browser was redirected to a malicious web page. It is likely that your server configuration has been modified.
Y decía lo mismo sobre un post de la web. La página de Google Webmasters Tools no me daba o, yo no supe encontrar, detalles del código con las líneas que hubieran sido añadidas a mis páginas del servidor. Sin embargo, a uno de mis colegas sí que le daba esta información, diciendo cuál era ese código aunque sin especificar dónde. En este caso me contaron que lo que hizo fue buscar desde el navegador, a través de las páginas de la web, ese extracto de código que según Google Webmasters Tools tenía la siguiente pinta (pongo algunas palabras clave entre paréntesis para evitar crear links):
(iframe) (src)="(http)(2puntos)(barra doble)werolais(punto)tk(barra)68113562(punto)html" width="120" height="300">
Búsqueda exhaustiva del Malware
Pero no encontró nada. Parece ser que lo mejor para esto es descargarse todo al disco local a través de un programa de transferencia de archivos, como puede ser FileZilla y ahí ya ponerse a buscar, porque eso es lo que hay que hacer: encontrar el código insertado para suprimirlo.
Bien. Un buen comienzo para esto es empezar por el archivo .htaccess. No detallaremos mucho las características de este archivo, pues son numerosas, pero diremos que es el archivo donde se detallan los permisos de lectura y escritura de nuestros archivos, entre otros. Para más información acerca del archivo .htaccess podéis visitar los siguientes links: (1) El fichero .htaccess: ejemplos de uso, (2) PDF sobre cómo utilizar .htaccess.
reltime2012(punto)ru(barra)frunleh(interrogante)9.
Redireccionamientos en el .htaccess
Como ibamos diciendo, este redireccionamiento nos hizo sospechar que el archivo .htaccess había sido modificado. Y efectivamente, al descargarnos todo el sitio al disco duro y abrir el archivo (como un .txt o por ejemplo, con Notepad++), vimos que no tenía nada que ver con nuestro original.
Borramos TODO el contenido del .htaccess y lo completamos con lo necesario y lo subimos por medio de FileZilla, sobreescribiendo el del servidor, que era el que había sido modificado con malware. Después de esto no sabemos concretamente qué es lo que ocurrió… accedimos a la web pero seguía mostrándose el mismo error. Intentamos acceder a la página de Login (que anteriormente ya lo habíamos intentado, obteniendo la misma ventana roja como resultado) y lo que aparecía no lo tenemos en captura, pero era una pantalla del navegador completamente blanca con el texto en h1 FOUND y seguido un link con la palabra here y que direccionaba a la famosa dirección de reltime2012… Obviamente no le dimos al link, ya que se trataba de la url maliciosa. Seguido volvimos a probar la página principal y nada. Pero después, al de unos minutos, probamos la dirección de Login y se cargó bien. Era un paso. Sin dudarlo nos registramos y entramos en el panel de administrador. Ahora ya estabamos dentro, y sabíamos lo que teníamos que hacer…
Nuevamente dentro del panel de control de WordPress
Actualizamos a la última versión de WordPress, antes haciendo un back up, con el plug-in WP-Security Scan. Después cambiamos el theme. Sí, es una putada, porque perdemos configuración, el CSS… entre otras cosas. Pero no queríamos jugárnosla. Nos habían contado que este problema de la intrusión de malware había vuelto a ocurrir después de todos estos pasos hechos hasta ahora, y que cambiando el theme se había arreglado. No tuvimos dudas. Instalamos otro y eliminamos el que teníamos. De todas formas diremos que no está claro que la infección ocurriera por el theme. Es por esto que no diremos el nombre de éste, para evitar falsas acusaciones.
Lo cierto es que no lleguamos a dedicarle mucho tiempo a buscar el código malicioso en los archivos que habíamos descargado a local… Como hemos dicho antes, en nuestro caso Google WebMasters Tools no nos indicaba el código encontrado, pero sí que nos pusimos a buscar las palabras iframe, reltime, reltime2012… entre otros. Teníamos en la web links a direcciones maliciosas y, esos links tenían que estar por algún lado. La cantidad de documentos que hay dentro de un sitio es enorme, por lo que la búsqueda puede ser desesperadamente larga… Para evitar esto existe la opción de buscar una misma palabra en todos los documentos existentes dentro de un directorio, buscando también en las subcarpetas. Para esto podemos utilizar el programa NotePad++.
La prueba final: Google, ten piedad…
Una vez que parece que todo está limpio podemos pedirle a Google que nos analice nuestro sitio web. Esto se hace desde el panel de Google Webmasters Tools. Después de todo esto, tocará esperar. En los motores de búsqueda de Google se perderán los primeros puestos, teniendo que ir a la segunda o tercera página para encontrar nuestro sitio. Es el precio que hay que pagar, y por eso conviene que una vez enterados de que nuestra web ha sido atacada, la limpieza de nuestro sitio la hagamos cuanto antes.
Espera y conclusiones finales
Tras la espera de que Google terminara de analizar nuestra web y nos pusiera de nuevo en circulación, el problema se solucionó. No nos quedó claro cual fue la causa principal del malware. Por la necesidad de encontrar una solución atacamos varios frentes, tal y como especificamos arriba, y con alguno de ellos, o varios, dimos en el clavo. En conclusión, hay que hacer nuestro sitio WordPress más seguro. Conviene cambiar las claves de acceso de cuando en cuando, no mantener el nombre de usuario dado (por favor, quitad admin como username aunque la iluminada de vuestra jefa diga que no es necesario…) y también conviene instalar un código Captcha al inicio de sesión.
