Tribulaciones de un escritor pulp. Ahora nos atacan la web ¿qué será lo próximo?

Mantener un sitio web online es una tarea titánica, ¡qué os voy a decir! A la dificultad de producir contenido original, posicionarlo, y darse a conocer para atraer visitas, junto con las labores propias de un humilde escritor autoeditor, autodidacta, y auto lo que sea…, hay que añadirle todos los problemas técnicos que van surgiendo por el camino, y que en definitiva terminan por imponerse de tal forma, que al final, no te queda más remedio que dedicarle todo tu tiempo a este tipo de cuestiones tan ingratas. Ya no basta con tratar de hacer las cosas bien —o al menos mejor que la competencia—, para no perder visitas y te coman terreno, sino que además tenemos que vérnoslas con los jodidos spamers, los plagiadores de contenido adictos al copypaste, los piratas con fobia al esfuerzo ajeno, las leyes estúpidas como las «cookies», y…, quizás, los más temidos de todos, los hackers. Dentro de lo malo estos tienen su mérito; no todo el mundo tienen los conocimientos técnicos que ellos poseen; es una pena que no los aprovechen para cosas más positivas. En la entrada de hoy comentaré el último ataque que hemos sufrido, entre otras cosas porque aún no tengo ni idea ni de cuál era su objetivo, ni cómo se hizo, por lo que nada mejor que darlo a conocer, y ver si así alguien puede arrojar algo de luz. Pues bien, este tipo de ataque hacker comienza con un aviso en tu correo, que dice lo siguiente: «Google ha detectado que se ha añadido a (xxxxx [arroba] gmail [punto] com) como propietario de (tu sitio web)». ¿Esto qué significa?

Es importante destacar que este mensaje —una alerta que Google envía a tu correo—, solo la recibirás si tienes tu blog o página web dado de alta en Google Search Console (Webmaster Tools; le han cambiado el nombre). Si no tienes dado de alta el sitio en esta función de Google, entonces no te enterarás de nada, y cuando lo hagas quizás sea demasiado tarde. Como es lógico, la primera reacción es de incredulidad total, y aún será necesario un tiempo de búsqueda por la red para saber de qué puñetas va todo esto de un nuevo propietario, claramente malicioso, falso, y cuyo correo electrónico suena fatal. Sí, el correo del nuevo propietario se incluye en el cuerpo del mensaje de alerta que te envía google (por si quieres agradecerle su interés en tomarse la molestia), y en ambos casos eran cuentas de gmail: (rentalLila.gj1500) una, y (ostrich4289), la otra. Son dos, porque nos han hackeado las dos webs con el mismo método, tanto RelatosPulp.com como ZonaPulp.com; dos por el precio de una, casi nada.

El siguiente paso, una vez que recibes el mensaje de alerta, es entrar en tu cuenta de Google Search Console (Webmaster Tools), y comprobar que, en efecto, existe una nuevo usuario autorizado para hacer lo que le de la real gana. Lo primero que observarás es que ha subido su propio sitemap del sitio, con nada más y nada menos que 8000 direcciones url, links, asociados a la web mediante redirección, y que enlazan con sitios de spam. Huelga decir que, de inmediato, es necesario borrar este sitemap, sino google lo reconocerá y lo incluirá en los resultados de búsqueda para tu web (por desgracia creo que los incluirá de todas todas, luego a pelearse por eliminarlos). El motivo de este tipo de “infección” no lo tengo claro, no sé por qué se hace esto, más allá de lo que es el perjuicio puro y duro, es decir, fastidiarnos y hacer que perdamos posiciones en los resultados de búsqueda. Es lo que, en el argot, se conoce como «ataques de SEO blackhat». Es decir, ahora la competencia, cada vez menos sana, va a por nosotros a saco. Éramos pocos y parió la abuela.

Eliminar el sitemap malicioso es muy fácil e inmediato, sin embargo, hacer lo mismo con el nuevo propietario que se ha hecho con los mando de tu cuenta en Google Search Console (Webmaster Tools), no será posible. No podrás hacerlo, pues cuando lo intentas te dirá que existe un archivo de verificación en el sitio web, del tipo google-site-verification: google<code>.html. Aquí comienzan las preguntas ¿cómo demonios ha podido subir este archivo el usuario malicioso a nuestro web, y dónde está? Ahora es cuando debes acceder al servidor, a la cuenta que te proporciona tu proveedor de hosting, y te pones a “estudiar” en profundidad el directorio raíz, el que se corresponde con public_html, y todo lo que allí se contiene.

Como es obvio, en efecto allí habrá un archivo html de verificación (por eso estás inscrito en el programa de google, y por tanto has recibido el mensaje de alerta), pero este archivo es el tuyo, y no el malicioso. Entonces, ¿dónde está para poder eliminarlo, y con ello la autoridad del nuevo propietario malicioso? No lo busques porque no existe, al menos como tal. La clave está en el archivo htaccess, editado con redirecciones maliciosas, y estás validan el archivo. Además, habrá numerosos archivos nuevos que no deberían estar en la raíz del directorio (scripts en php), y no solo en la raíz, sino también ocultos en subcarpetas. Suelen tener nombres comunes del sistema, pero que no están incluidos en el paquete de una instalación limpia, para que no se puedan sobreescribir, en caso de que esto se haga.

Observando en detalle el track de urls solicitadas al servidor tras la infección, y posterior limpieza, nos da pistas inequívocas y sumamente interesantes. Por ejemplo, cada cierto tiempo, y con una ruta diferente, encontramos peticiones a este tipo de archivos php: /joomla_style.php; /jm_default.php; /jm_manage.php; /com_loader.php (nuestra web está en joomla, pero da igual, si está en wordpress o cualquier otro sistema CMS; el procedimiento es el mismo para todos). Esto me lleva a la conclusión de que el hacker sube los ficheros maliciosos de forma aleatoria, pero ni el mismo sabe en qué rutas concretas se guardan (o se reparten la tarea entre varios), pues de lo contario no tendría razón semejante búsqueda dando palos de ciego. Buscar uno mismo estos archivos dentro el servidor es fácil, y de encontrarlo, lo más probable es que observes interminables líneas de código; código ofuscado. Si ejecutas este archivo desde un navegador seguro, visualizarás una consola en la que se pide una contraseña y, supuestamente, eso le permitirá tomar el control del servidor. Es lo que se conoce como una puerta trasera o «backdoor». La clave es saber por dónde y cómo la subió. De momento no encuentro mejor aliado que los “chivatos” del “log” o registro de errores y conexiones. Ahí, además de la denodada búqueda del atacante por encontrar los scripts php con los que hacerse de nuevo con el control del servidor, también observo como google nos envía constantes peticiones de rutas inexistentes en nuestra web, y que, durante la infección, redirigían a páginas de spam (siempre asociadas a imágenes). Estas rutas son del tipo que sigue:

misitio/wigshop13/d5k-u5v8-1310/123h5.bat

misitio/ mysite/1x6P/nice79462-26/.pl

Una vez anulado el mecanismo fraudulento de redirección, ahora todas redirigen a páginas de error 404, lo correcto, creo, y supongo que google aún tardará en deshacerse de ellas algún tiempo, hasta que recobremos la normalidad. Además, por si fuera poco, en estos registros también observo continuos ataques al formulario de login de administrador, supongo que de fuerza bruta, para hacerse con los controles de nuestra querida nave, Relatos Pulp. Vamos, que nos están dando por todos los frentes. De momento lo único que se me ocurre es bloquear todas estas IPs, y es lo que estoy haciendo. Espero que, por error, no termine bloqueando la IP de alguno de vosotros, mis bravos lectores, aunque de ser el caso ya no podrías leer este artículo.

Aún no tengo ni idea de cómo es posible que nos hiciesen semejante estropicio. No sé cómo lo habrán hecho; supongo que explotando alguna vulnerabilidad de la instalación que, todo hay que decirlo, no estaba actualizada a la última versión. Recordemos que uno es escritor, editor, webmaster, y un montón de cosas por las que no cobra nada, pero te hacen currar más horas que un reloj, por tirar de dicho fácil, que ahora no tengo la cabeza para rimas ingeniosas, y esto me impide estar siempre a la última; a pesar de que lo intento.

¿Cómo eliminamos la infección?

Bueno, permitidme la expresión: ¡joder, me cago en todo! Esto es lo primero, maldecir. Según un estudio más o menos científico, si gritas y maldices cuando te golpean, entonces te dolerá menos. La verdad es que no las tengo todas conmigo, y aunque creo que lo peor ya ha pasado, es probable que aun quede alguna rata oculta en algún sitio del servidor, y nos tumbe la web de un momento a otro. De ser así, trataré de poneros al corriente a través de nuestra cuenta en Facebook Relatos Pulp:

Tras maldecir, y sin perder un instante, lo que hice, y lo que supongo que debemos hacer, es:

1. Eliminar el sitemap malicioso en Google Search Console (webmaster tools)
2. Anular la propiedad del usuario fraudulento en Google Search Console.
3. Borrar todos, repito, todos los archivos del root. Es la única manera de asegurarse que no existe algún script php oculto que se nos pueda escapar
4. Aplicar un paquete de instalación actualizado, extensiones incluidas, lo cual supone un coñazo de proporciones bíblicas.
5. Volcar las tablas de la base de datos en otra nueva (cambiando prefijos y contraseñas), y conectarla a la nueva instalación.
6. Observar los registros de conexiones entrantes y de error, y bloquear todas las IPs sospechosas.

Respecto a lo de “anular la propiedad del usuario fraudulento en Google Search Console”, decir que, por desgracia, esto no es algo inmediato. Y creo que esto se produce por una “cagada” de Google, un agujero de seguridad. Es curioso como lo hacen. En realidad el archivo de verficación no existe. Se trata de una infección del archivo Htaccess, que establece una redirección falsa, tal y como apuntamos más arriba. Mientras exista esta redirección, google no te dejará anular al usuario fraudulento.

Algunos pensaréis por qué no restaurar una copia de seguridad, un backup, que es mucho más cómodo y rápido; pues bien, el motivo de no hacerlo es que no tenía nada claro cuando se produjo la infección, y es posible que llevase tiempo en estado latente.

Como de todo, incluso de lo malo, se saca algo positivo, lo cierto es que ahora ya sé un poquito más de servidores, en mi proceso de formación como autoeditor, escritor y webmaster, que trata de buscarse la vida por sí mismo, tal cual como un arenque en medio de un banco de tiburones. Además, contar la experiencia me ha servido para publicar otro artículo original en esta, nuestra querida y humilde web. Y estoy convencido que tendrá muchas visitas, pues seguro que esta forma de infección tan «sui géneris», pillará a más de uno con el pie cambiado, y aquí está este tocho didáctico, por si sirve de algo.

Conclusión, da siempre de alta tu sitio en Google Search Console y, tan pronto recibas un correo avisándote de un nuevo propietario, entra en el programa Google Search Console, busca el sitemap que seguro habrán subido y bórralo. Después entra en el servidor, y ponte a la faena, porque te queda chollo por delante que no veas. Consuélate pensando que si la competencia trata de tumbarte, o si alguien se toma tantas molestias, es porque quizás, tu web, es más importante de lo que crees, y eso es bueno.

Menos mal que no vivo de esto, que sino… Lástima que a los hackers no les guste la Literatura Pulp, seguro que se lo pasarían genial leyendo nuestros relatos.

Ahora recemos para que nos den una tregua, y que todo vuelva a la normalidad. Cruzo los dedos. Mientras tanto, si quieres contratar a un webmaster pulp…, aquí estamos, cogiendo experiencia.

IMPORTANTE: Si notas algo raro, si ves que algún enlace en la web no funciona, si tienes problemas de acceso con tu login, si no puedes registrarte, si tienes alguna sugerencia, aportación técnica, duda, o lo que sea que creas que no está bien, por favor, házmelo saber. Puedes ponerte en contacto con nosotros a través de facebook, o en nuestro correo electrónico relatospulp [arroba] gmail [punto] com También os aviso que los próximos días haré pruebas y puestas a punto, por lo que es posible que el sitio falle en más de una ocasión.