No, ni mucho menos voy a hablar de amor y romanticismo por este blog hoy aunque sea el día de San Valentín. No está este sitio para estas cosas, así que, si pensabas entrar hoy por aquí y encontrarte un mensaje de amor, romanticismo o esperanza, éste no es el sitio.  Hoy, dejando atrás el amor, os voy a hablar con todo el cariño de los ataques de amplificación de XMLRPC.PHP en los sitios basados en un CMS como WordPress.

Figura 1: Ataques (al corazón) de tu WordPress en San Valentín

Nosotros hace poco descubrimos que también teníamos publicado el fichero XMLRPC.php en nuestro servidor de ElevenPaths aunque deshabilitado por el sistema de publicación estática que tenemos, pero ya que nuestro amigo BTShell (thanks!) me lo ha reportado este fin de semana, hemos decidido quitarlo definitivamente.

Me habían hablado de él tiempo atrás, pero no me había parado a verlo en detalle hasta hoy, así que aprovechando el día concreto me he decido a echarle un ojo para también poder explicároslo. La idea es bastante fácil de entender y durante el año 2014 y 2015 se estuvo explotando en muchos sitios con WordPress, así que vamos a verlo para que tomes medidas si quieres tener tu WordPress un poco más seguro.

XML-RPC

El protocolo XML-RPC sirve para utilizar la invocación de Llamadas a Procedimientos Remotos ("Romote Procedure Calls") sobre el protocolo HTTP usando XML como formato de codificación de las peticiones y las respuestas. Es un interfaz de comunicación definido allá por finales del siglo XX y que está implementado por muchos servicios web.

Figura 2: Especificación XML-RPC

Por supuesto, WordPress tiene su propia implementación de los métodos que se pueden invocar vía XML-RPC, y que prácticamente permiten automatizar la gestión completa del sitio. En el sitio de WordPress.org tienes una descripción completa del API que puede ser invocada vía XML-RPC para gestionar las funciones del CMS.

Figura 3: API de WordPress via XML-RPC

Esto quiere decir que mediante peticiones POST usando XML-RPC se pueden solicitar cosas usando como punto de acceso a la API el fichero XMLRPC.php que se encuentra en muchos servidores Wordpress. Puedes comprobar si el tuyo lo tiene abierto simplemente con solicitar el fichero. Si tu CMS está abierto para la gestión remota del sitio vía XML-RPC entonces saldrá un mensaje como el siguiente.

Figura 4: Un blog aleatorio con WordPress y xmlrpc.php activado

Evidentemente, para hacer gestiones se necesitan privilegios, pero es aquí donde entra en juego una de las capacidades del protocolo XML-RPC. La opción de hacer invocaciones múltiples en una sola petición POST. Es decir, usando una petición de red, se ejecutan varias llamadas en el servidor CMS. Para ello se configura una opción de System.Multicall y se ponen todas las llamadas a procedimientos de la API de XML-RPC que se quieren invocar de las que están soportadas por el CMS de WordPress.

Ataques de Fuerza Bruta a WordPress con XMLRPC.php

Como se puede ver en el ejemplo publicado por CloudFlare, una petición a una función de la API que necesite privilegios de administración podría permitir la ejecución de un proceso de login. Usando la opción de System.Multicall se podrían utilizar 100 peticiones de login usando un único POST de XMLRPC.php. Haciendo 10 peticiones HTTP POST se podrían probar mil contraseñas en nada.

Figura 5: XML-RPC para una petición con uso de System.Multicall

Al final, esta técnica permitiría a un atacante realizar muchas pruebas en un ataque de Fuerza Bruta a un servidor WordPress y ya se publicó en su momento un exploit en Python que hace este ataque de Brute Force usando System.Multicall, que puedes descargar desde GitHub.

Figura 6: Exploit de XMLRPC Brute Force usado System.Multicall

Lógicamente, si no vas a exponer tu blog a la administración vía XML-RPC a ninguna herramienta, puedes simplemente quitar el fichero, o mitigar este ataque eliminando, como explican los ingenieros de CloudFlare la opción de llamar al método de System.Multicall editando el fichero functions.php de tu servidor WordPress. Para un pentester o un atacante es fácil comprobar si este método está habilitado o no haciendo unas cuantas pruebas con el Repeater de Burp o Zap Proxy y ver los resultados como se hace con el resto del Hacking de Web Technologies.

Figura 7: Bloqueo de System.Multicall en functions.php

Por supuesto, utilizar un WAF (Web Application Firewall) que detecte este tipo de exploits también ayudaría, pero sobre todo haz una gestión segura de tus identidades para que ningún ataque que consiga tu password permita al atacante entrar, así que pon Latch para WordPress y listo. Si alguien consigue tu contraseña, no podrá entrar y recibirás una alerta.

Figura 8: Cómo proteger WordPress con Latch en 10 minutos

Además, recuerda que gestionar un WordPress en los tiempos en los que vivimos exige un trabajo de fortificación constante, así que te recomiendo que te empapes bien el libro de Máxima Seguridad en WordPress que cuenta muchos de estas técnicas para tener lo más protegido posible este CMS.

Saludos Malignos!