En Jetpack, lidiar con distintos tipos de amenazas y ataques web forma parte de nuestra rutina. La mayoría de las veces, esto consiste en recopilar un archivo malicioso y encontrar el vector de ataque, además de ayudar a restaurar un sitio web a partir de la copia de seguridad más reciente. Pero a veces entramos en otra dimensión de ataques realmente creativos, una dimensión de reinfecciones inexplicables: entramos… en la dimensión desconocida.
Vale, probablemente estoy dramatizando demasiado, pero ten paciencia mientras preparo el escenario para este relato misterioso. ¿Preparado? Acompáñame en este viaje al reino de los fantasmas, el spam y los motores de búsqueda.
El comportamiento malicioso
Descubrimos un sitio web que estaba sufriendo un tipo de ataque muy interesante. Todo salió a la luz por primera vez en un correo electrónico enviado por Google Search Console: una URL poco habitual (y, además, con un aspecto muy sospechoso, ya que dentro aparecía una URL en la que se podía hacer clic) figuraba como una de las páginas con 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 había detectado nada ni le había advertido de nada. Además, cuando comprobaron estas páginas, ni siquiera existían en el sitio web, pero Google las estaba indexando de todos modos. La situación se volvía cada vez más surrealista.
Mientras comprobábamos si había algún archivo sospechoso que Jetpack Scan pudiera haber pasado por alto (ninguna herramienta de seguridad detecta el 100 % de las amenazas), las cosas se volvieron aún más extrañas. El núcleo de WordPress y los plugins estaban intactos: no había ningún archivo ni script inyectado en la base de datos. Un par de plugins obsoletos no tenían ninguna corrección de seguridad, WordPress iba una versión por detrás (5.6) y la última actualización no incluía ninguna corrección de seguridad importante. No había nada sospechoso. Ni sospechosos habituales ni indicios de ataques; al menos, todavía no.
El siguiente paso lógico es consultar los registros de acceso. Quizá puedan arrojar algo de luz sobre este misterio. ¿Descubriríamos que nos enfrentábamos a un ataque de día cero o que por fin habíamos encontrado una prueba de la teoría del multiverso y que este sitio web solo estaba infectado en el universo n.º 1337? ¡A por los registros!
Como era de esperar, no había nada extraño, aparte de un montón de solicitudes a esas páginas de spam, como puedes ver en las capturas de pantalla. Y todas devolvían un `200 OK`. Así que la página existía en algún punto del continuo espacio-tiempo 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 detectó el problema, pero las solicitudes procedían de Bing) estaban indexando páginas de resultados de búsqueda. ¿Y por qué? Hasta donde sabemos, el rastreador no realiza búsquedas en la página, ¿verdad?
La paradoja de la indexación
Los conceptos básicos del funcionamiento de un motor de búsqueda son bastante sencillos si te dedicas a gestionar sitios web. Hay un robot (o script automatizado) que rastrea las páginas web, indexa su contenido, hace su magia y almacena los recursos consultables en algún lugar de la nube.
Teniendo esto en cuenta, examinamos un poco más los registros para ver si alguna de esas solicitudes contenía alguna otra pista, como una URL de referencia, pero no hubo suerte. Todas las solicitudes registradas procedían de motores de búsqueda. Por suerte, Google Search Console tenía una de las páginas de referencia en uno de los registros.
Ahora creo que ha llegado el momento de cambiar el sombrero de The Twilight Zone por uno de CSI y desenterrar algunos huesos del sitio web para ponerlos bajo el microscopio.
Para un ojo experto, 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 añadió para confundir al propietario del sitio web. Después hay otro directorio aleatorio y un archivo PHP con un nombre aleatorio, que probablemente es un cargador que obtiene la carga útil final: `cargese4/cca442201.htm`, que también es aleatoria. 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é se había indexado del sitio de referencia confirmó que, efectivamente, estaba infectado y llevaba un tiempo mostrando spam de SEO. El sitio pertenece a una empresa de alimentación de la India, pero anuncia ofertas de SUV en Japón; sí, eso es spam.
Pero ninguno de los resultados enlazaba al sitio web de nuestro amigo, así que decidí averiguar si otros sitios se habían visto afectados por este mismo comportamiento extraño.
Para buscar más víctimas de este ataque de spam, usamos, únicamente con fines educativos, nuestros conocimientos de Google-fu para crear una consulta de búsqueda que devolviera sitios terminados en .edu, que tuvieran `/?s=` en la URL y la palabra «buy» en el título. Obtuvimos 22 resultados, suficientes para nuestra búsqueda.
Esto demuestra que el sitio denunciado no era el único afectado; parece tratarse de un problema más extendido. Reflexionamos sobre qué podría haber hecho que Google indexara esas páginas. ¿Cómo llegó Googlebot hasta ellas? Siguiente paso: herramientas para comprobar los backlinks.
Hay varias herramientas online que ofrecen informes sobre los backlinks de los sitios web; la que usamos en esta investigación fue Ahrefs, pero otras herramientas podrían obtener los mismos resultados. Algunos resultados de búsqueda maliciosos aparecen en la lista, lo que confirma que íbamos por el buen camino.
Al seleccionar uno de esos sitios web para comprobar qué ocurría, vimos casi 5.000 comentarios de spam, como puedes ver en la siguiente captura (deberían echar un vistazo a Antispam de Jetpack). Cada comentario enlazaba a una página de búsqueda del 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 encuentran un enlace a una página, lo seguirán. Y si la página no indica al script automatizado que no se puede indexar, la añadirá.
Este es un ingenioso método para «inyectar» spam en un sitio web con el fin de llenar de spam los resultados de los motores de búsqueda y aumentar el posicionamiento de la página mediante una granja de enlaces de baja calidad.
Una vez entendido el problema, ¿cómo les decimos a los bots de los motores de búsqueda que no sigan los enlaces a las páginas de búsqueda (o que simplemente se nieguen a indexarlas)? La mejor opción sería hacer un cambio en el núcleo de WordPress, que ayudaría a proteger a toda la comunidad (si quieres informar de un error o contribuir al código, únete a nosotros).
Para evitar rehacer trabajo innecesariamente, consultamos el Trac del núcleo de WordPress y encontramos este problema que se solucionó en la versión 5.7, pero, por desgracia, no se incluyó en el registro de cambios como un problema de seguridad.
Voy a citar al autor, que describió el problema mejor de lo que yo podría hacerlo (gracias, abagtcs, por informar):
Los spammers de la web han empezado a abusar de las funciones de búsqueda de esos sitios introduciendo términos de spam y nombres de host con la esperanza de mejorar el posicionamiento de sus propios sitios.
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, después, visiten e indexen las páginas de resultados de búsqueda generadas, llenas de contenido basura.
Este ataque está sorprendentemente extendido y afecta a muchos sitios web de todo el mundo. Aunque algunos CMS y sitios basados en código escrito a medida pueden ser vulnerables a esta técnica, según una investigación preliminar, parece que, al menos en el ámbito .edu, la plataforma web más atacada, con diferencia, es WordPress.
No es sorprendente que más del 41 % de los sitios más grandes de la web sean sitios de WordPress.
Caso cerrado
Este incidente nos deja algunas lecciones importantes:
- La URL que aparece en Páginas con mayor crecimiento no se ha saneado correctamente, por lo que las URL de spam que ves separadas por emojis se pueden abrir directamente al hacer clic (hola, amigos de Google; esto es cosa tuya ;) ); los usuarios desprevenidos podrían hacer clic en ellas y acceder a contenido no deseado.
- Google debe hacer algunos ajustes para evitar indexar páginas claramente llenas de spam. Según el informe de la herramienta, se rastrearon algunas páginas legítimas y no se indexaron, mientras que sí se añadió spam.
- Los atacantes aprovecharán hasta la más pequeña brecha de tu sistema, y debemos mantenernos alerta en todo momento.
- Escucha siempre a la gente y comprende sus problemas. Si solo hubiéramos comprobado los registros de nuestras propias herramientas, no nos habríamos enterado de este problema ni habríamos podido ayudar a solucionarlo en su sitio.
- Mantén tu software actualizado. Siempre.
En Jetpack, nos esforzamos por garantizar que tus sitios web estén protegidos frente a este tipo de vulnerabilidades. Para ir un paso por delante de las nuevas amenazas, echa un vistazo a Jetpack Scan, que incluye análisis de seguridad y eliminación automática de malware.
Y gracias a Erin Casali por destacar este problema y ayudar con la investigación.
Jetpack 