WordPress es el sistema de administración de contenido más popular del mundo, utilizado por más del 40% de todos los sitios web.
Esta amplia adopción lo convierte en un objetivo principal para los actores de amenazas y los investigadores de seguridad a los que se les paga por informar problemas de seguridad a través de su programa público de recompensas por errores.
Los corredores de vulnerabilidades también están muy interesados en adquirir vulnerabilidades sin parches que les permitan hacerse cargo de las instancias de WordPress, a veces ofreciendo hasta $300,000 por las críticas.
Como tal, WordPress tiene una base de código muy revisada en la que ya no se espera que los investigadores encuentren frutos al alcance de la mano. Nuestra investigación anterior sobre este objetivo requirió una amplia experiencia y esfuerzo para descubrir problemas de seguridad.
Esta publicación de blog describe una vulnerabilidad sorprendentemente simple en la implementación de pingbacks de WordPress.
Si bien el impacto de esta vulnerabilidad es bajo para la mayoría de los usuarios en el caso de WordPress, el patrón de código vulnerable relacionado es bastante interesante de documentar, ya que probablemente también esté presente en la mayoría de las aplicaciones web.
La vulnerabilidad
El cliente HTTP tiene que volver a analizar la URL y volver a resolver el nombre de host para enviar su solicitud. Mientras tanto, ¡un atacante podría haber cambiado el ip que apunta dominio para apuntar a el dominio a un servidor diferente antes de ser validado!
Esta clase de error también se llama Time-of-Check-Time-of-Use: un recurso se valida pero se puede cambiar más tarde antes de su uso efectivo. Es común encontrar dichas vulnerabilidades en las mitigaciones contra Server-side request forgery (SSRF).
Diagrama del problema:
