Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC

80 millones de Webs expuestas

El ataque de fuerza bruta es uno de los ataques más antiguos y que con más frecuencia vemos en Internet.

Se basa en repetir el proceso de autenticación con diferentes combinaciones de usuarios y contraseñas con el fin de encontrar las credenciales adecuadas mediante un proceso automatizado de ensayo y error.

Son muy populares debido a los malos hábitos de los usuarios en la elección de las contraseñas y a la posibilidad de utilizar multiples equipos (botnet) para acelerar el proceso atacando simultáneamente un mismo objetivo.

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC. Mapa de ataques XMLRPC.

Bots atacando objetivos simultáneamente

Pero a su vez, son ataques muy sencillos de detectar y mitigar ya que generan un registro cada vez que se intenta el acceso a servicios como el correo electrónico, FTP o a la administración de nuestra Web.

Ejemplo de ataque de fuerza bruta contra el panel de acceso de WordPress wp-login.php

Log de actividad del servidor Web atacado por fuerza bruta en el archivo wp-login.php

[17/Oct/2015:12:11:16 +0200] "GET /?author=1 HTTP/1.1" 200
[17/Oct/2015:12:11:19 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:19 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:20 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:20 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:20 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:20 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:21 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:21 +0200] "POST /wp-login.php HTTP/1.1" 200
[17/Oct/2015:12:11:21 +0200] "POST /wp-login.php HTTP/1.1" 200
[...]
[17/Oct/2015:12:11:22 +0200] "POST /wp-login.php HTTP/1.1" 302

Este ataque es el más frecuente y se realiza introduciendo combinaciones de diferentes usuarios/contraseñas en el panel de acceso a la administración de WordPress tal y como lo haría un usuario legítimo. Es posible reducir el tiempo necesario para llevar a cabo este ataque utilizando un único usuario que se obtiene de la Web atacada introduciendo el parámetro ?author=1 después del nombre del dominio.

Este ataque produce un registro en el servidor Web por cada uno de los intentos de acceso. El acceso registrado a la Web de WordPress atacada con el parámetro ?author=1 es un indicador del comienzo del ataque de fuerza bruta.

Como se puede ver en el log, la velocidad de este ataque de fuerza bruta contra WordPress es de 4 intentos de usuario/contraseña por segundo.

Como primera medida de seguridad para combatir el ataque de fuerza bruta contra el panel de administración de WordPress, es posible limitar el número de intentos de acceso al panel de administración para prevenir que los ciberdelincuentes accedan a la información de terceros.

Un ejemplo de esta protección tradicional la tenemos en los cajeros automáticos que nos permiten introducir un número limitado de veces el PIN de la tarjeta antes de “tragársela”. Siendo solo 4 dígitos numéricos es una medida imprescindible, ya que si no, el encontrar el PIN correcto sería una mera cuestión de tiempo.

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC. Acceso al panel de administración y tarjeta de crédito.

Pero, ¿qué sucedería si un delincuente pudiera comprobar todas las posibles combinaciones en un solo intento? Éste es el panorama en el que nos encontramos en este momento.

La primera consecuencia es que terminaría con las medidas de protección tradicionales en las que muchos confían ciegamente y aumentarían los robos.

Como podemos ver en las estadísticas publicadas por Sucuri, empresa especializada en la seguridad de WordPress, durante el 2015 los ataques de fuerza bruta contra WordPress han aumentado un 500% porque estas medidas convencionales de seguridad no han conseguido detenerlos. No solo es una cuestión del número de ataques sino de su porcentaje de éxito.

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC. Estadísticas

Imagen publicada por Sucuri

Estamos por tanto ante un cambio en los métodos de ataque que no están contemplados por los desarrolladores de WordPress y que exponen a los usuarios de las Webs y a los servidores donde se alojan.

Siguiendo con el símil bancario imagínense que fuera posible obtener de manera inmediata el PIN, no de una tarjeta, sino de 80 millones y que no fuera necesario tenerla para acceder a la información del cliente, sino que estuviera disponible a través de Internet.

80 millones de páginas Web vulnerables.

Durante el 2015 los ataques por fuerza bruta han aumentado un 500%.

XMLRPC. La vulnerabilidad más explotada en la historia de WordPress.

Nada más que la funcionalidad XMLRPC fue habilitada por defecto en las nuevas instalaciones de WordPress limpias y “seguras” se utilizaron para realizar ataques de denegación de servicio distribuido (DDOS) contra otras Webs sin necesidad de infectarlos/vulnerarlos previamente. Posiblemente durante año y medio haya sido la botnet con más éxito de la historia, aunque esto no sea una buena publicidad para WordPress.

En marzo de 2014, Sucuri informó de 162.000 sitios basados en WordPress estaban siendo utilizados para realizar un ataque de DDOS a través de un agujero de seguridad en la implementación del protocolo XMLRPC.

Exactamente a través del método system.pingback. De hecho, puede que tu instalación de WordPress haya sido utilizada para atacar otras Webs sin que ni siquiera te hayas dado cuenta.

¿Qué es el protocolo XMLRPC?

XMLRPC es un interfaz muy sencillo utilizado en WordPress, Joomla o Drupal que permite hacer operaciones remotas en nuestras páginas Webs.

Tareas como publicar contenidos remotamente, acceder a la Web desde aplicaciones para móviles o algunos de los plugins más utilizados de WordPress utilizan el protocolo XMLRPC para su funcionamiento. Está habilitado por defecto desde la versión de WordPress 3.5 (diciembre 2012).

Puedes comprobar si lo tienes habilitado accediendo por HTTP al archivo xmlrpc.php en la raíz de tu instalación de WordPress o en la siguiente dirección:

http://xmlrpc.eritreo.it

Loading...

El protocolo XMLRPC se utiliza un gran variedad de plugins y aplicaciones estrechamente relacionadas con el desarrollo principal de WordPress cuya implementación necesita revisión.

Algunos plugins y aplicaciones de WordPress que utilizan el protocolo XMLRPC

  • Jetpack. Plugin de WordPress con más de un millón de instalaciones desarrollado por Automattic empresa participada por los creadores de WordPress.
  • BuddyPress. Plugin de WordPress con más de 100 mil instalaciones creado por Matt Mullenweg, desarrollador original de WordPress.
  • Microsoft Windows Live Writer. Microsoft Office permite publicar los contenidos directamente en tu blog desde el interfaz de Word.
  • WordPress móvil (iOS y Android). Aplicación para administrar WordPress desde dispositivos móviles, desarrollado por Automattic.
  • Galerías de imágenes. Algunas galerías de imágenes utilizan XMLRPC para publicar las fotos remotamente.

Pero system.pingback no es el único método disponible a través del protocolo XMLRPC. Podemos ver una lista de todos los métodos disponibles revisando el archivo /wp-includes/class-wp-xmlrpc-server.php o haciendo una llamada con el método system.listMethods. La forma más sencilla de hacerlo en Linux es mediante el comando cURL. El siguiente comando envía el XML contenido en el archivo llamada.txt como una petición POST al API remoto de WordPress:

El archivo llamada.txt contiene la llamada del API de WordPress:

Como hemos comentado anteriormente, el ataque de fuerza bruta contra WordPress a través del la página de acceso del administrador es fácil de detectar y mitigar así que los ciberdelincuentes han evolucionado hacia otra forma de lanzar ataques de fuerza bruta difícil de detectar utilizando el protocolo XMLRPC.

Algunos de estos métodos XMLRPC son autenticados para poder modificar la Web de forma segura. Por ejemplo cuando administramos la Web desde el iPhone o cuando añadimos un post a través de Microsoft Office. Los ciberdelincuentes explotan esto para probar un número ilimitado de combinaciones de usuarios y contraseñas hasta que obtienen acceso a la Web.

Comprobación de credenciales del administrador a través de XMLRPC en WordPress

Log de actividad del servidor Web del archivo xmlrpc.php

[18/Oct/2015:05:04:05 +0200] "POST /xmlrpc.php HTTP/1.1" 200
[18/Oct/2015:05:04:09 +0200] "POST /xmlrpc.php HTTP/1.1" 200

Este ataque también produce un registro en el servidor Web por cada uno de los intentos de acceso. Pero en vez de explotar el archivo wp-login.php (monitorizado ya que es el responsable de gestionar el acceso al panel de administración) utiliza el archivo xmlrpc.php.

El siguiente paso es automatizar el proceso de generación de las consultas a través del interfaz XMLRPC. Para eso utilizo un pequeño script en php que obtiene los usuarios y posibles contraseñas de un archivo externo.

Ataque de fuerza bruta a través de XMLRPC en WordPress

Script en PHP para realizar el ataque de fuerza bruta mediante XMLRPC
md5: 2C5A2316BCC73D7C7B54BBC5DACE7C27
sha1: 2F6B7344DA21E380F990A137C210D2F89CDF9615

Log de actividad del servidor Web del archivo xmlrpc.php

[18/Oct/2015:05:25:40 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:41 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:41 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:41 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:42 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:42 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:42 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:43 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200
[18/Oct/2015:05:25:43 +0200] "POST /xmlrpc.php/xmlrpc.php HTTP/1.0" 200

Este ataque también produce un registro en el servidor Web por cada uno de los intentos de acceso siendo muy fácil de detectar y mitigar.

Como se puede ver en el log, la velocidad de este ataque de fuerza bruta a través del archivo xmlrpc.php es de 3 intentos de usuario/contraseña por segundo.

Ataques de amplificación de fuerza bruta. Esquema de ataque convencional

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC

La respuesta del servidor al realizar la petición system.listMethods devuelve la lista de métodos API disponibles en la instalación de WordPress. Como hemos visto, algunas de esas llamadas requieren autenticación para garantizar su seguridad.

Dentro de la respuesta se encuentra el método system.multicall que nos permite anidar las consultas al API de WordPress en una sola petición.

Combinando el método system.multicall junto con las llamadas con autenticación el servidor nos confirmará si las credenciales de cada una de las consultas son correctas en una sola petición haciendo el ataque muchos más eficiente (amplificación).

¿Cuántas consultas podremos hacer a través del API de WordPress en una sola petición? ¿Cuánto podremos amplificar el ataque convencional de fuerza bruta?

Para responder a esta pregunta he creado un sencillo script en PHP que genera un archivo de consulta XML con las peticiones autenticadas a partir de un archivo de claves en texto plano.

El archivo de claves que he utilizado contiene las 1.000 contraseñas más utilizadas en Internet. Según estudios realizados a raíz de las claves filtradas de Adobe, Hotmail, Sony, etc… las claves del 91% de los usuarios se encuentran entre las 1.000 más utilizadas. Por tanto solo deberíamos de probar 1.000 contraseñas para acceder al 90% de las Webs basadas en WordPress.

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC. Claves

Una vez generado el archivo XML llamadas.txt con las 1.0000 claves combinadas con el usuario admin realizamos la petición a la API de WordPress utilizando cURL.

Ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC

Log de actividad del servidor Web del archivo xmlrpc.php

[19/Oct/2015:09:50:18 +0200] "POST /xmlrpc.php HTTP/1.1" 200

Como se puede ver en el log del servidor Web las 1.000 consultas autenticadas con usuario y contraseña solo han generado un registro. Además el tiempo de respuesta del servidor a esa petición anidada ha sido de apenas 5 segundos.

El ataque de amplificación de fuerza bruta contra WordPress mediante XMLRPC system.multicall es 50 veces más rápido que un ataque de fuerza bruta convencional y evita las medidas de seguridad tradicionales que nos protegen frente a este tipo de ataques ya que no queda registro de este abuso en el servidor Web.

Ataques de amplificación de fuerza bruta. Esquema de ataque amplificado

Mientras que las medidas de seguridad tradicionales como limitar los intentos de acceso añadir la doble autenticación son efectivas bloqueando los ataques contra la página de acceso del administrador, no protegen contra los ataques amplificados de fuerza bruta contra WordPress mediante XMLRPC.

Algunas medidas que no nos protegen frente a los ataques de amplificación de fuerza bruta contra WordPress mediante XMLRPC:

  • Limitar el número de intentos de acceso al panel de administración.
  • Cambiar la URL de acceso al panel de administración.
  • Autenticación en dos pasos.
  • Comprobación CAPTCHA.
  • Instalar el plugin de Latch para WordPress.
  • Bloquear el acceso a la administración a través del archivo .htaccess.
  • No utilizar el usuario “admin” para acceder a la administración.

Con mucha frecuencia podemos encontrar en Internet artículos sobre lo seguro que es WordPress y hasta algunos se aventuran a afirmar que lo seguirá siendo (casi nada). Solo es necesario revisar el histórico de vulnerabilidades que ha tenido esta gran plataforma, tanto es su núcleo, plugins y temas, para, por lo menos, ser muy prudentes a la hora de hablar de seguridad y WordPress en el mismo artículo.

Por el contrario, creo que un pensamiento crítico y la divulgación técnica pueden ayudar a concienciar a la comunidad y evitar que el éxito de WordPress sea su punto más débil.

En el siguiente artículo sobre WordPress comentaré con detalle qué medidas de seguridad podemos adoptar para combatir esta vulnerabilidad.

Referencias:
SUCURIMore Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack

Contenido en contínua edición. No dudes en enviarme tus comentarios para completarlo.
Sígueme

Carlos Sánchez Santos

Presidente de Bilbaodigital y gerente de Imagina Works, S.L.
Forense informático
Auditor de Seguridad FTSAU - RHCT 605007791313908 - RHCSA 100/014/133 CEH ECC942714
Sígueme