Qué hacer si está infectado con SEO Spam en WordPress

En Jetpack, lidiar con diferentes tipos de amenazas y ataques web es parte de nuestra rutina. La mayoría de las veces, va desde recopilar un archivo malicioso y encontrar el vector de ataque hasta brindar asistencia para restaurar un sitio web desde la última copia de seguridad. Pero a veces entramos en una dimensión diferente de ataques realmente creativos, una dimensión de reinfecciones inexplicables: entramos... en la zona de penumbra.

De acuerdo, probablemente estoy siendo demasiado dramático, pero tengan paciencia conmigo mientras preparo el escenario para esta historia de misterio. ¿Listo? Únase a mí en este viaje al reino de los fantasmas, el spam y los motores de búsqueda.

El comportamiento malicioso

Encontramos un sitio web que estaba bajo un tipo de ataque muy interesante. Apareció por primera vez como un correo electrónico enviado por Google Search Console: una URL poco común (y una de aspecto muy sospechoso, con una URL en la que se puede hacer clic dentro) se incluyó como una página de mayor crecimiento.

El propietario del sitio web estaba un poco molesto ya que este tipo de comportamiento suele ser el resultado de una infección, pero Jetpack no lo había detectado ni advertido sobre nada. Además, estas páginas ni siquiera existían en el sitio web cuando se verificaron, pero Google las indexaba de todos modos. La zona crepuscular se intensifica .

Mientras buscamos archivos sospechosos que Jetpack Scan pueda haber pasado por alto (ninguna herramienta de seguridad detecta el 100% de las amenazas), las cosas se pusieron aún más extrañas. WordPress Core y los complementos estaban intactos: no se inyectaron archivos ni scripts en la base de datos. Un par de complementos obsoletos no tenían ninguna solución de seguridad, WordPress estaba una versión atrás (5.6) y la última actualización no incluía ninguna solución de seguridad importante. No había nada sospechoso en absoluto. Sin sospechosos habituales, sin pruebas de ataques; no todavía, de todos modos.

El siguiente paso lógico es comprobar los registros de acceso. Tal vez podría arrojar algo de luz sobre este misterio. ¿Descubriríamos que nos enfrentamos a un ataque de día cero, o que finalmente encontramos una prueba para la teoría del multiverso, y este sitio web solo está infectado en el Universo #1337? ¡A los troncos!

Como era de esperar: nada extraño, aparte de un montón de solicitudes a esas páginas de spam como puede ver en las capturas de pantalla. Y todos devolvían un `200 OK`. Entonces, la página existía en algún lugar en el continuo de tiempo y espacio, o... espera un segundo... ¿la ves ahora?

Todas esas páginas apuntaban a la misma ubicación: `/?s=`, lo que significa que los motores de búsqueda (Google notó el problema, pero las solicitudes provienen de Bing) estaban indexando las páginas de resultados de búsqueda. ¿Y por qué es eso? Hasta donde sabemos, el rastreador no realiza búsquedas en la página, ¿verdad?

La paradoja de la indexación

Los conceptos básicos de cómo funciona un motor de búsqueda son bastante sencillos si está en el negocio de sitios web. Hay un robot (o secuencia de comandos automatizada) que rastrea páginas web, indexa su contenido, realiza algo de magia y almacena los recursos consultables en algún lugar de la nube.

Con eso en mente, investigamos un poco más los registros para ver si alguna de esas solicitudes tenía alguna otra pista, como una referencia, pero no hubo suerte. Todas las solicitudes registradas procedían de motores de búsqueda. Afortunadamente, Google Search Console tenía una de las páginas de referencia en uno de los registros.

Ahora creo que es hora de cambiar nuestro sombrero de Twilight Zone por un sombrero CSI y desenterrar algunos huesos del sitio web para ponerlos bajo el microscopio.

Para el ojo entrenado, es fácil ver que la URL de la página de referencia pertenecía a un sitio web comprometido; por suerte, ¡tenemos ojos bien entrenados! El directorio `index.php` no tiene sentido y probablemente se agregó para confundir al propietario del sitio web. A continuación, le sigue otro directorio aleatorio y un archivo PHP con un nombre aleatorio, que probablemente sea un cargador que recibe la carga útil final: `cargese4/cca442201.htm`, que también es aleatorio. Todas estas son características de una infección de malware de granja de enlaces.

Una búsqueda rápida en Google para ver qué estaba indexado para el sitio de referencia confirmó que, de hecho, estaba infectado y sirviendo spam de SEO durante un tiempo. El sitio es para una empresa de alimentos en India, pero ofrece ofertas en SUV en Japón; sí, eso es spam.

Pero ninguno de los resultados se vinculaba con el sitio web de nuestro amigo, así que decidí averiguar si otros sitios se veían afectados por este mismo comportamiento extraño.

Con el fin de buscar más víctimas de este ataque de spam, solo con fines educativos, utilizamos nuestro conocimiento de Google-fu para elaborar una consulta de búsqueda que arrojaría sitios que terminaran en .edu, que tenían `/?s=` en la URL, y la palabra “comprar” en el título. Y obtuvimos 22 resultados. Lo cual es suficiente para nuestra cacería.

Esto es evidencia de que el sitio reportado no fue el único afectado; parece ser un problema más generalizado. Reflexionamos sobre lo que podría haber hecho que Google indexara esas páginas. ¿Cómo llegó Googlebot a ellos? Siguiente paso: verificadores de backlinks.

Existen varias herramientas en línea que brindan informes sobre vínculos de retroceso a sitios web; el que usamos en esta investigación fue Ahrefs, pero otras herramientas pueden llegar a los mismos resultados. Algunas de las páginas de búsqueda maliciosas se enumeran en los resultados, lo que confirma que estábamos en el camino correcto.

Al seleccionar uno de esos sitios web para verificar lo que estaba sucediendo, vimos casi 5,000 comentarios de spam, como puede ver en la siguiente captura de pantalla (deberían consultar Jetpack Anti-spam). Cada comentario estaba vinculado a una página de búsqueda de un sitio web con spam en la consulta.

Atrapar al conejo blanco

Como mencioné antes, los robots de los motores de búsqueda no realizan consultas en las páginas de los sitios web. Pero, si encuentra un enlace a él, será seguido. Y si la página no le dice al script automatizado que una página en particular no es indexable, la agregará.

Este es un método inteligente de "inyectar" spam en un sitio web para enviar spam a los resultados del motor de búsqueda y aumentar el rango de la página del sitio a través de la agricultura de enlaces de bajo esfuerzo.

Ahora que entendemos el problema, ¿cómo le decimos a los robots de los motores de búsqueda que eviten seguir los enlaces a las páginas de búsqueda (o que simplemente se nieguen a indexarlos)? La mejor manera sería hacer un cambio en WordPress Core, lo que ayudaría a proteger a toda la comunidad (si desea informar un error o desea contribuir con el código, únase a nosotros).

Para evitar reelaboraciones innecesarias, verificamos el seguimiento de WordPress Core y encontramos este problema que se resolvió en la versión 5.7 pero, desafortunadamente, no llegó al registro de cambios como un problema de seguridad.

Citaré al autor, quien describió el problema mejor que yo (gracias abagtcs por el informe):

Los spammers web han comenzado a abusar de las funciones de búsqueda de esos sitios al pasar términos de spam y nombres de host con la esperanza de mejorar las clasificaciones de búsqueda de los sitios de los spammers.

Los spammers colocan estos enlaces en wikis abiertos, comentarios de blogs, foros y otras granjas de enlaces, confiando en que los motores de búsqueda rastreen sus enlaces y luego visiten e indexen las páginas de resultados de búsqueda resultantes con contenido spam.

Sorprendentemente, este ataque está bastante extendido y afecta a muchos sitios web de todo el mundo. Aunque algunos CMS y sitios impulsados ​​por código personalizado pueden ser vulnerables a esta técnica, según una investigación preliminar, parece que, al menos en el espacio .edu, la plataforma web más específica con diferencia es WordPress".

Esto no es sorprendente cuando más del 41% de los sitios más grandes en la web son sitios de WordPress.

cerrando el caso

Hay algunas buenas lecciones que aprender de este incidente:

1. La URL presentada en las páginas de mayor crecimiento no está bien desinfectada, por lo que se puede hacer clic directamente en las URL de spam que ves separadas por emojis (hola, amigos de Google, eso depende de ti); los usuarios inconscientes podrían hacer clic en ellos y acceder a contenido no deseado.
2. Google necesita algunos ajustes para evitar la indexación de páginas claramente fraudulentas. Según el informe de la herramienta, algunas páginas claras se rastrearon y no se indexaron, mientras que se agregó spam.
3. Los atacantes aprovecharán incluso la apertura más pequeña de su sistema y debemos estar atentos en todo momento.
4. Siempre escuche a las personas y comprenda sus problemas. Si solo revisáramos los registros de nuestras propias herramientas, no estaríamos al tanto de este problema ni podríamos ayudar a reparar su sitio.
5. Mantenga su software actualizado. Siempre.

En Jetpack, trabajamos arduamente para asegurarnos de que sus sitios web estén protegidos contra este tipo de vulnerabilidades. Para estar un paso por delante de cualquier nueva amenaza, consulte Jetpack Scan, que incluye análisis de seguridad y eliminación automatizada de malware.

Y una propina a Erin Casali por resaltar este problema y ayudar con la investigación.