Archivos "Si Miro A Las Nubes": Colección de material de Platero y Tú y Extremoduro.

Malware en WordPress: Cómo arreglar nuestra web tras un ataque

Web de Proactiva Open Arms
El problema con el que nos encontramos en nuestra web aproximadamente hace un mes (año 2012) fue el siguiente: al escribir nuestra url en el navegador, se mostraba una pantalla roja de alerta avisando de que no era un sitio seguro… Además de esto, en los resultados de los motores de búsqueda la web aparecía con la siguiente alerta: “Este sitio puede dañar tu ordenador”. ¡Maldición! ¿Qué podía hacer? ¿Cómo había ocurrido esto? Analizamos todo lo sucedido hasta su solución final.

Malware en WordPress

Lo que hicimos por intuición fue ponernos en contacto con amigos nuestros que fueran usuarios de WordPress. Para nuestra sorpresa a dos de los que contactamos también les había pasado meses atrás, y hasta en repetidas ocasiones. Lo que ocurría era lo siguiente: habían hackeado la web. Habían entrado en el código del archivo .htaccess y habían añadido unas líneas que hacían que lo que en principio era un sitio seguro (nuestra web), redireccionara 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 nuestro sitio en sus revisiones. Los mensajes que daba de nuestro portal no eran del todo claros; decía que cuando había entrado la última vez se había intentado redireccionar a otra url 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 amigos sí que le daba esta información, diciendo cúal era ese código pero sin especificar dónde. En este caso me contaron que lo que se 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 y otros):

(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.

En nuestro caso, a pesar de la pantalla roja de alarma, quisimos entrar a la web clickando en el link “a pesar de todo“. Por sorpresa, la dirección de la barra del navegador había cambiado y había añadido otra dirección por detrás, concretamente:

reltime2012(punto)ru(barra)frunleh(interrogante)9.

Sin embargo no me direccionaba a ningún lado; Firefox me mostraba un mensaje de servidor no encontrado pero… bien podría haber ido a la dirección maliciosa e infectar mi ordenador… Hay que tener cuidado con esto y estar muy seguro antes de dar este paso.

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.

Después había que cambiar las contraseñas. ¿Cúales? Todas. La de WordPress, la del FTP y hasta las del servidor, que en este caso era OVH. Lo mejor para evitar intrusiones son contraseñas complejas, aunque no sean fáciles de recordar. Apuntarlas y guardarlas bajo llave… Como hemos dicho más arriba, también eliminamos la entrada que Google Webmasters Tools decía que contenía malware. No hay que tener dudas con este tipo de acciones; lo mejor es cortar por lo sano.
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.

Desde la página de WebMasters Tools de Google se nos facilita el acceso a varias páginas informativas y de ayuda, pero los listamos a continuación: (1) Stop Badware, (2) PDF sobre qué hacer cuando nos hackean la web, (3) Guía práctica para hacer frente a las advertencias de malware de Google.

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 vuestra jefa diga que no es necesario…) y también conviene instalar un código Captcha al inicio de sesión.

Esperamos que este post pueda servir de ayuda para todo aquel que se vea afectado por este problema. Suerte y ánimo.
* * * *