Un pingback es uno de los cuatro tipos de métodos de retroenlace que utilizan los autores web para solicitar una notificación cuando alguien enlaza a uno de sus documentos. Esto permite a los autores realizar un seguimiento de quién enlaza o hace referencia a sus artículos. Algunos software de blogs y sistemas de gestión de contenido , como WordPress , Movable Type , Serendipity y Telligent Community , admiten pingbacks automáticos, en los que se puede hacer ping a todos los enlaces de un artículo publicado cuando se publica el artículo. Otros sistemas de gestión de contenido, como Drupal y Joomla , admiten pingbacks mediante el uso de complementos o extensiones.
Básicamente, un pingback es una solicitud XML-RPC (que no debe confundirse con un ping ICMP ) enviada desde el Sitio A al Sitio B, cuando un autor del blog del Sitio A escribe una publicación que enlaza al Sitio B. La solicitud incluye el URI de la página enlazada. Cuando el Sitio B recibe la señal de notificación, vuelve automáticamente al Sitio A para comprobar la existencia de un enlace entrante activo. Si ese enlace existe, el pingback se registra correctamente. Esto hace que los pingbacks sean menos propensos a ser spam que los trackbacks . Los recursos habilitados para pingbacks deben utilizar un encabezado X-Pingback o contener un <link>elemento para el script XML-RPC.
La especificación Pingback fue desarrollada en 2002 por Stuart Langridge , Simon Willison e Ian Hickson . [1] [2] [3] [4] [5]
En marzo de 2014, Akamai publicó un informe sobre un exploit muy conocido que involucraba pingbacks y que tenía como objetivo sitios WordPress vulnerables. [6] Este exploit provocó un abuso masivo de blogs y sitios web legítimos y los convirtió en participantes involuntarios de un ataque DDoS . [7] Los detalles sobre esta vulnerabilidad se han hecho públicos desde 2012, [8] y Akismet informó en 2013 que "casi el 100% de los trackbacks y pingbacks son spam". [9]
Los ataques de pingback consisten en "reflexión" y "amplificación": un atacante envía un pingback a un Blog A legítimo, pero proporcionando información del Blog B legítimo ( suplantación ). [10] Luego, el Blog A necesita comprobar el Blog B para la existencia del enlace informado, ya que es como funciona el protocolo de pingback, y por lo tanto descarga la página del servidor del Blog B, lo que provoca una reflexión . [10] Si la página de destino es grande, esto amplifica el ataque, porque una pequeña solicitud enviada al Blog A hace que realice una gran solicitud al Blog B. [10] Esto puede llevar a amplificaciones de 10x, 20x e incluso mayores ( DoS ). [10] Incluso es posible utilizar múltiples reflectores, para evitar agotar cada uno de ellos, y utilizar la potencia de amplificación combinada de cada uno para agotar el Blog B de destino, ya sea sobrecargando el ancho de banda o la CPU del servidor ( DDoS ). [10]
WordPress cambió un poco el funcionamiento de la función pingback para mitigar este tipo de vulnerabilidad: la dirección IP que originó el pingback (la dirección del atacante) comenzó a ser registrada, y por lo tanto se muestra en el registro. [11] No obstante, en 2016, los ataques pingback continuaron existiendo, supuestamente porque los propietarios de los sitios web no revisan los registros del agente de usuario, que tienen las direcciones IP reales. [11] [10] Si el atacante es más que un script kiddie , sabrá cómo evitar que se registre su dirección IP, por ejemplo, enviando la solicitud desde otra máquina/sitio, de modo que la dirección IP de esta máquina/sitio se registre en su lugar, y el registro de IP, entonces, se vuelve menos valioso. [12] Por lo tanto, todavía se recomienda deshabilitar los pingbacks, para evitar atacar otros sitios (aunque esto no evita ser blanco de ataques). [11]
Este problema surge del hecho de que es posible que un atacante A se haga pasar por el blog de T conectándose al blog de R y enviando una notificación de enlace que especifica el blog de T como el origen de la notificación. En ese punto, K intentará conectarse automáticamente a T para descargar la publicación del blog. Esto se llama reflexión. Si el atacante tuviera cuidado de seleccionar una URL que tenga mucha información, esto causaría amplificación. En otras palabras, para una solicitud relativamente pequeña del atacante (A) al reflector, el reflector (R) se conectará al objetivo (T) y causará una gran cantidad de tráfico. [...] En el lado del reflector para la solicitud de 200 bytes, la respuesta puede ser fácilmente de miles de bytes, lo que resulta en una multiplicación que comienza en 10x, 20x y más. [...] Para evitar sobrecargar el reflector, se pueden emplear varios reflectores para escalar. De esta forma, el objetivo tendrá su ancho de banda saliente, y posiblemente los recursos computacionales, agotados. [...] Otro punto a considerar son los recursos computacionales vinculados al lado objetivo. Si se considera una página que es computacionalmente costosa de producir, puede ser más eficiente para el atacante sobrecargar la CPU de un sistema en lugar del ancho de banda de la conexión. [...] Esta no es la primera vez que un CMS, y en particular WordPress, se ha utilizado para DDoS u otra actividad maliciosa. En gran medida, esto se debe a que WordPress atrae a usuarios que no tienen los recursos para administrar sus sitios web y a menudo usan WordPress para facilitar su trabajo. Como resultado, muchos usuarios no tienen un programa de administración de parches adecuado o un monitoreo apropiado para observar irregularidades en su tráfico.
A partir de la versión 3.9, WordPress comenzó a registrar la dirección IP de donde se originó la solicitud de pingback. Eso disminuyó el valor de usar WordPress como parte de un ataque; la plataforma ahora registraría la dirección IP original de los atacantes y aparecería en el agente de usuario de registro. [...] A pesar de la posible reducción de valor con el registro de IP, los atacantes siguen utilizando esta técnica. Probablemente porque los propietarios de sitios web rara vez verifican los registros del agente de usuario para derivar la dirección IP real de los visitantes. [...] Aunque es genial que WordPress registre la dirección IP del atacante en las versiones más nuevas, aún recomendamos que deshabilite los pingbacks en su sitio. No lo protegerá de ser atacado, pero evitará que su sitio ataque a otros.
Una mejora que WordPress agregó a los pingbacks en 3.7, que al menos rastreaba la IP de origen de la solicitud. Si bien esto no resuelve el problema, al menos le permite rastrear de dónde provienen las llamadas. Sin embargo, a menos que el atacante sea muy, muy ingenuo, esta IP simplemente se rastreará hasta otra máquina o sitio infectado. Generalmente, estos sistemas de solicitud son parte de una red de bots para enmascarar y distribuir las solicitudes. [...] La herramienta de pingback dentro de WordPress sigue siendo un sistema explotable para cualquier sitio de WordPress que no la haya detenido explícitamente. Desde la perspectiva de un proveedor de alojamiento web, esto es bastante frustrante.