La seguridad de los sitios web es algo difícil de resolver de forma correcta. Específicamente con los problemas de seguridad relacionados con XML-RPC – como se explota comúnmente en los ataques a los sitios de WordPress. Hay mucha información disponible en Internet que ofrece todo tipo de soluciones, pero ¿cuáles son las correctas? Este artículo explicará el cómo, las soluciones que existen, y cuál es realmente la mejor solución. Vamos a sumergirnos.
XML-RPC es más antiguo que el propio WordPress. Este sistema fue introducido en WordPress para combatir el dilema de la conexión lenta a Internet, ayudando a los usuarios a escribir nuevas entradas sin conexión y luego subirlas al servidor. La capacidad de conectar WordPress remotamente con otras aplicaciones sólo era posible con el archivo xmlrpc.php.
*********************************************
21/09/2022 10:55
Actualización de instrucciones funcionales al final del documento
*********************************************
ncluso algunos desarrolladores experimentados no entienden completamente XML-RPC y las amenazas de seguridad asociadas con él. Es muy posible que el sitio/sitios que usted administra tengan un archivo XML-RPC activo que necesita su atención inmediata, pero sólo puede ejecutar un plan de acción eficaz después de conocer cómo funciona XML-RPC y cuál es la mejor manera de manejarlo de forma segura.
Aunque WordPress tiene ahora su propia API REST, el archivo xmlrpc.php todavía está presente dentro del núcleo y está habilitado por defecto exponiendo el sitio de WordPress a varios ciberataques. En este artículo, aprenderemos el uso de este archivo, las vulnerabilidades asociadas a él y cómo manejarlo sin poner en riesgo la seguridad de su sitio.
¿Qué es un archivo xmlrpc.php?
En su forma más simple, XML-RPC (Remote Procedure Call) fue creado para la comunicación entre plataformas. Este protocolo sirve para realizar llamadas a procedimientos utilizando HTTP como transporte y XML como codificador. El cliente realiza estas llamadas enviando una petición HTTP al servidor y recibe a cambio la respuesta HTTP. XML-RPC invoca funciones a través de una petición HTTP y luego estas funciones realizan algunas acciones y envían respuestas codificadas a cambio.
Comparemos esto con una llamada a la API REST para entender bien el concepto.
[su_table]
| Procedure | RPC | REST |
| Signup | POST/signup | POST/users |
| Read User | GET/readUser?userid=123 | GET/persons/1234 |
[/su_table]
REST consume los parámetros de la URL para identificar los recursos, mientras que RPC utiliza los parámetros de consulta para suministrarlos como argumentos de la función.
WordPress utilizó XML-RPC para permitir a sus usuarios interactuar con su sitio de forma remota. Todavía lo utiliza para alimentar su aplicación móvil y para soportar plugins como JetPack, WooCommerce, etc. El uso del archivo xmlrpc.php tiene sus desventajas, pero ¿desactivarlo completamente es la única solución viable? Para responder a esto, primero tenemos que ver las vulnerabilidades asociadas con él y cuáles son las soluciones disponibles para evitarlas.
¿Qué tan viciosos pueden ser los hackers con el archivo xmlrpc.php?
Utilizando XML-RPC , los hackers aprovechan las llamadas a procedimientos remotos (RPC) e invocan funciones para obtener los datos que desean. En la mayoría de los sitios de WordPress, el archivo xmlrpc.php es fácilmente rastreable, y con sólo enviar datos XML arbitrarios, los hackers controlan el sitio para ejecutar el código que han preparado para ejecutar un determinado tipo de ataque.
Para entender cómo se compromete el XML-RPC de WordPress, veamos los ciberataques más populares asociados a él.
Ataque de fuerza bruta
En el ataque de fuerza bruta, el hacker intenta adivinar el nombre de usuario y la contraseña correctos realizando numerosos intentos de acceso. Desafortunadamente, un gran número de sitios de WordPress utilizan contraseñas de administrador débiles o no tienen ninguna capa de seguridad añadida para detener a los atacantes. Esos sitios son fácilmente comprometidos con este tipo de ataque.
Otros utilizan una contraseña fuerte y también tienen mecanismos de seguridad en su lugar como reCaptcha, y el bloqueo automático de IP que es eficaz contra los ataques de fuerza bruta, pero si el hacker decide utilizar XML-RPC ; ni siquiera necesita acceder al admin de WordPress.
Una herramienta muy común de Kali Linux, WPSCAN se utiliza para enumerar todos los nombres de usuario y una vez que se hace, los hackers fuerza bruta la contraseña utilizando el archivo xmlrpc.php mediante el envío de la siguiente solicitud HTTP al sitio de la víctima.
POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>
En el ejemplo anterior, un hacker puede enviar miles de variaciones hasta recuperar la contraseña correcta.
La siguiente respuesta se devuelve contra la solicitud anterior. La respuesta contiene el código de error y un mensaje claro que indica que el nombre de usuario y la contraseña intentados eran incorrectos. Es una indicación clara que le dice al hacker que lo intente de nuevo hasta que la contraseña correcta coincida.
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403<?xml version=»1.0″ encoding=»UTF-8″?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
La respuesta devuelve el código HTTP 200 y el mensaje de que el nombre de usuario y la contraseña suministrados son incorrectos. Al pasar por el canal XML-RPC , un hacker no tiene que preocuparse por los plugins de reCaptchas o de limitar los intentos de inicio de sesión. Puede seguir ejecutando las variaciones hasta que se recupere la contraseña correcta.
Nota: Los ataques de fuerza bruta consumen muchos recursos y también causan problemas de rendimiento. El proceso de prueba y error se ejecuta en un bucle durante un período de tiempo más largo que puede mantener su servidor ocupado para servir a los visitantes reales. Este consumo innecesario de recursos hace que los servidores consuman más energía.
Ataque DDoS
La Denegación de Servicio Distribuida (DDoS) es uno de los ciberataques más letales que puede paralizar el servidor al golpearlo con cientos y miles de peticiones concurrentes. Los hackers utilizan la función pingback de WordPress junto con el archivo xmlrpc.php para ejecutar este tipo de ataques.
Lo ideal es que el hacker se dirija al punto final o a una página que pueda ser golpeada varias veces y que tarde más en responder. De esta manera, un solo golpe puede tener un impacto máximo en los recursos del servidor y, en nuestro caso, XML-RPC sirve al hacker para exponer tales puntos finales.
Se utilizan varios sitios de WordPress ya comprometidos para ejecutar el método pingback.ping para dirigirse a una sola víctima. Las abrumadoras peticiones HTTP GET y POST atascan el tráfico regular y acaban por colapsar el servidor.
En primer lugar, el hacker comprueba si el archivo xmlrpc.php está habilitado o no, enviando la siguiente petición.
POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175<?xml version=»1.0″ encoding=»utf-8″?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>
Una vez que se confirma que el XML-RPC está habilitado en el sitio web objetivo, el atacante comienza a golpearlo utilizando la red de sitios explotados para enviar múltiples solicitudes de pingback a un sitio víctima. Esto puede ser automatizado desde múltiples hosts y ser utilizado para causar un ataque DDoS masivo en el sitio víctima.
POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>
Ataque de puertos cruzados (XSPA)
Los ataques de puertos cruzados (XSPA) son muy comunes en los que el hacker inyecta el script malicioso para recuperar información en puertos TCP y direcciones IP. En el caso de WordPress, se utiliza XML-RPC junto con su mecanismo de pingback para eludir cualquier enmascaramiento de IP, como un WAF básico como Cloudflare.
En un ataque XSPA, el hacker utiliza el método pingback.ping para hacer pingback a una publicación en un sitio web objetivo que, a su vez, envía la dirección IP como respuesta. El hacker utiliza un sniffer para crear el endpoint para enviar el pingback y una URL en vivo de un post del blog.
Los hackers envían la siguiente petición desde su servidor.
<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>
Si la respuesta contiene faultCode y un valor superior a 0, significa que el puerto está abierto para empezar a enviar los paquetes HTTP directamente.
Métodos Ineficaces de Bloqueo de Ataques XML-RPC
Hasta ahora en el artículo, hemos establecido que el archivo xmlrpc.php es propenso a algunos ataques cibernéticos serios a como DDoS, Bruteforce, y Cross-site Port Attack, por lo tanto, es crucial manejarlo adecuadamente para bloquear estos ataques.
Eliminando el XML-RPC completamente
Puede simplemente eliminar el archivo XML-RPC que hará que su servidor empiece a lanzar errores 404 a cualquiera que intente acceder a él. La desventaja de esta solución es que el archivo se volverá a crear cada vez que actualice WordPress.ç
Desactivando completamente el XML-RPC
La otra opción más viable es deshabilitar el archivo xmlrpc.php. Puede hacer esto simplemente añadiendo el bloque de código dentro de su archivo .htaccess. Asegúrese de hacer esto antes de las reglas .htaccess que nunca cambian y que son añadidas por WordPress.
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>
Esto desactivará el archivo xmlrpc.php para cada aplicación o servicio que lo utilice. Puede poner en la lista blanca una determinada dirección IP en caso de que aún desee acceder a su sitio de WordPress a través de XML-RPC . Para ello, debe añadir el siguiente comando:
<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>
Pros
Elimina los riesgos de abuso de XML-RPC en los ciberataques.
Beneficios de rendimiento a largo plazo y ahorro de recursos del servidor.
Contras
Desactivar XML-RPC es lo mismo que desactivar el acceso remoto para las aplicaciones que utilizan esta versión de acceso remoto. Esto significa que Jetpack, la aplicación móvil de WP, o cualquier otra solución que se conecte con su sitio de WordPress a través de XML-RPC ya no puede conectarse con su sitio.
El código heredado de las aplicaciones personalizadas podría no funcionar tampoco.
Por qué instalar un plugin de seguridad realmente perjudica a su sitio
Los usuarios de WordPress a menudo se apoyan en los plugins para cualquier característica o funcionalidad necesaria sin pensar mucho en su impacto en el rendimiento del sitio. Hay varios plugins de seguridad para WordPress que prometen proteger su sitio web de problemas de seguridad relacionados con XML-RPC , pero en realidad, perjudican más a su sitio.
Estas son algunas de las razones por las que asegurar su sitio con un plugin no es la mejor opción.
- Los plugins de seguridad sólo son efectivos a nivel de aplicación y no protegen a su servidor de ser atacado.
- Añaden código innecesario en su sitio que disminuye su rendimiento y aumenta el tiempo hasta el primer byte (TTFB).
- Algunos de estos plugins hacen más daño que bien y son utilizados por los hackers para crear puertas traseras en su sitio web.
- Estos plugins requieren una gestión frecuente que añade más carga de trabajo.
De la evaluación anterior, ninguna de las opciones ofrece una solución ideal para manejar el problema de seguridad de XML-RPC . Esto nos lleva a Accelerated Domains. Un servicio que está construido para resolver problemas complejos relacionados con la seguridad y mucho más. Veamos cómo Accelerated Domains puede resolver eficazmente el problema de XML-RPC para usted.
Reflexiones finales
Los ciberataques son cada vez más sofisticados y, como webmaster y propietario de un negocio, es vital que los entiendas y conozcas las herramientas para enfrentarte a ellos. La mayoría de los ataques se evitan con un enfoque proactivo como la monitorización constante y la actualización del software o añadiendo herramientas como Accelerated Domains que hacen todo eso en piloto automático. Una vez activada, Accelerated Domains filtra de forma inteligente el tráfico y toma las medidas necesarias cuando es preciso para mantener su servidor de origen y su sitio web protegidos de los ciberataques.
Y no lo dudes, si tienes problemas de seguridad o estabilidad en tu web contacta y nos ponemos manos a la obra.
Fuente: servebolt.com
*****************************************************************************
Actualización y datos complementarios
*****************************************************************************
Dos formas de desactivar completamente el XML-RPC de WordPress
El plugin Disable XML-RPC no funciona como la gente supone
No es culpa del autor del plugin, pero el plugin con este nombre sólo desactiva una parte del espacio de métodos XML-RPC definidos. Esto se debe a que todo lo que hace es llamar a add_filter( ‘xmlrpc_enabled’, ‘__return_false’ ); – lo que por cierto podrías hacer desde cualquier lugar, como el functions.php de tu tema.
El problema es que después de debatir cómo debería funcionar el gancho, los desarrolladores del núcleo de WordPress ataron las manos de los desarrolladores aquí, y el filtro xmlrpc_enabled en el núcleo se dejó deliberadamente ineficaz. Por compatibilidad con un control de conmutación anterior que se eliminó hace tiempo de la interfaz de usuario de wp-admin, sólo desactiva los métodos XML-RPC autentificados, no todos los métodos XML-RPC.
Se podría pensar que un gancho llamado xmlrpc_enabled apagaría completamente el subsistema XML-RPC, ¿verdad? No es así.
Así que digamos que no tienes ningún uso para el subsistema XML-RPC, piensas que es un peligro para la seguridad (lo es), y simplemente quieres que desaparezca. La mayoría de los desarrolladores terminan bloqueándolo desde el .htaccess, pero le mostraré dos maneras.
Alternativa 1: Desregistrar todo el espacio de métodos XML-RPC desde functions.php
Esta técnica engancha el filtro xmlrpc_methods y vacía el espacio de métodos en tiempo de ejecución:
// disable xmlrpc function remove_xmlrpc_methods( $methods ) { return array(); } add_filter( 'xmlrpc_methods', 'remove_xmlrpc_methods' )
Cualquier solicitud posterior para cualquier método devolverá un objeto XML-RPC Fault informando «el método solicitado no existe». Feo, tal vez, pero efectivamente cierra el servicio, y es fácilmente desplegado en el functions.php de tu tema o tema hijo.
Alternativa 2: Bloquear xmlrpc.php desde .htaccess
La mayoría de los usuarios acaban siguiendo esta ruta porque es el principal consejo que se obtiene al buscar el problema en Google:
# disable xmlrpc <FilesMatch "^xmlrpc\.php$"> Require all denied </FilesMatch>
Eso va en .htaccess en la raíz de su instalación de WordPress. Apache entonces responde 403 Forbidden para todas las peticiones a xmlrpc.php. (De hecho, también bloqueo un par de cosas más que no quiero que los atacantes carguen de esta manera). Fíjese en el uso del estilo de Apache 2.4 mod_authz Require ya que las antiguas directivas Allow y Deny del estilo de Apache 2.2 están ahora obsoletas.
Puede utilizar ambas técnicas con seguridad. No interferirán la una con la otra, y tendrá una defensa en profundidad en caso de que cualquiera de ellas sea eliminada accidentalmente.
Probando que el bloqueo de XML-RPC funciona
Ahora sólo tenemos que probar si el bloqueo funciona o no.
Los fragmentos de código de mi antiguo post para enviar peticiones de ataque especialmente diseñadas a xmlrpc.php fueron escritos para Python 2 y ya están obsoletos. Aquí hay algo de código nuevo bueno para Python 3.
Si sólo queremos saber si el subsistema XML-RPC está disponible, hay un método de demostración en el núcleo del subsistema XML-RPC llamado demo.sayHello() que hará el trabajo:
#!/usr/bin/python3 import ssl import xmlrpc.client # this disables ssl certificate verification so you can use this on dev targets c = ssl.create_default_context() c.check_hostname = False c.verify_mode = ssl.CERT_NONE proxy = xmlrpc.client.ServerProxy("https://your_server_address_or_hostname/xmlrpc.php", context=c) print(proxy.demo.sayHello())
Las importaciones están en la biblioteca estándar.
Para un subsistema XML-RPC desbloqueado, esto tendrá éxito e imprimirá «¡Hola!». Si ejecuta esto y ve «¡Hola!», XML-RPC sigue activado y respondiendo a las peticiones.
Bajo la técnica alternativa 1 de arriba (filtro xmlrpc_methods), saldrá con un rastreo a un xmlrpc.client.Fault reportando «el método solicitado demo.sayHello no existe».
Bajo la técnica alternativa 2 anterior (bloqueo de .htaccess) o la aplicación combinada de ambas técnicas, saldrá con un rastreo a un xmlrpc.client.ProtocolError reportando 403 Forbidden.
0 comentarios