Ataques de Amplificación de Fuerza Bruta Contra XMLRPC de WordPress

Ataques de Fuerza Bruta son uno de los tipos de ataques más antiguos y son la mayoría de los ataques comunes que todavía vemos en Internet. Si usted es dueño de un servidor en línea, es probable que él está siendo atacado en este momento. Puede ser a través de protocolos como SSH o FTP, y, si es un servidor web, a través de intentos de fuerza bruta contra cualquier CMS que está utilizando.

En general, estos ataques no son muy complicados y es teóricamente fácil detenerlos o mitigarlos, pero todavía ocurren y tienen éxito; principalmente porque las personas no saben elegir buenas contraseñas, o no tienen buenos hábitos de control de acceso. Pero, hay un problema, estos ataques de fuerza bruta causan trastornos. Tradicionalmente, para insertar 500 contraseñas diferentes, el atacante tendría que hacer 500 intentos de conexión diferentes que serían capturados en proporción de un 1 a 1 para cada petición al servidor. Esto simplifica el enfoque de mitigación ya que cada intento se registra y se puede bloquear cuando se alcanza un cierto límite.

Amplificación de Fuerza Bruta

¿Y si el atacante pudiera reducir el ruido? ¿Y si el atacante pudiera hacerlo de manera que se cambiase para una proporción de 1 a muchos en cada petición? Imagina una aplicación capaz de intentar adivinar 500 contraseñas de una sola vez.

Imagina un mundo en el que un atacante pudiera amplificar sus ataques de fuerza bruta, de tal manera que los enfoques convencionales de mitigación se conviertiran en inviables. En vez de 500 intentos de conexión diferentes, los atacantes podrían reducir sus intentos de conexión para, es decir, 20 o 50 y todavía intentar 500 contraseñas, o incluso miles de contraseñas para cada, eso obstaculizaría su estrategia de mitigación.

Esto sería similar a los ataques de amplificación de DDoS que escuchamos en las noticias, en que con un solo comando y un solo servidor de control los atacantes pueden aprovechar métodos de amplificación de respuesta DNS o protocolo NTP para aumentar su poder de ataque en 50 o 100 más veces.

Cualquier método de amplificación puede facilitar el trabajo del atacante.

Amplificación de los Ataques de Fuerza Bruta vía XML-RPC de WordPress

Una de las características ocultas del XML-RPC es que se puede utilizar el métodosystem.multicall para ejecutar métodos múltiples dentro de una sola petición. Esto es muy útil y permite que la aplicación envíe varios comandos en una sola petición HTTP.

XML-RPC es un método sencillo y portátil para hacer llamadas de procedimientos remotos utilizando HTTP. Se puede utilizar con Perl, Java, Python, C, C++, PHP y muchos otros lenguajes de programación. WordPress, Drupal y la mayoría de los sistemas de gestión de contenidos usan el XML-RPC

Recuerde, sin embargo, que cualquier método utilizado para el bien, terminan siendo utilizados para el mal en algún momento.

Eso es exactamente lo que está pasando aquí.

Lo hemos rastreado durante unas semanas (el primer ataque fue encontrado el 10 de septiembre de 2015) y los ataques continúan ganando relevancia y se convierten en cada vez más populares. En lugar de atacar a wp-login.php (que se puede bloquear rápidamente o proteger mediante .htaccess) o hacer un solo intento de atacar la xmlrpc, los atacantes están utilizando el método system.multicall para intentar adivinar cientos de contraseñas con una sola petición HTTP.

Sí, cientos de intentos de conexión fallidos en una sola petición HTTP. Imagínese ver esto en su archivo de registro (sí, sólo una entrada):

194.150.168.95 – – [07/Oct/2015:23:54:12 -0400] “POST /xmlrpc.php HTTP/1.1” 200 14204 “-” “Mozilla/5.0 (Windows; U; WinNT4.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1

¿Lo ha adivinado que este registro proviene de un método
system.multicall con cientos de intentos para adivinar la contraseña correcta? Con solo 3 o 4 peticiones HTTP, el atacante podría intentar miles de contraseñas, sin pasar por las herramientas de seguridad que se instalan para buscar y bloquear los ataques de fuerza bruta.

La mayoría de los ataques que hemos visto, están utilizando el métodowp.getCategories, que requiere un nombre de usuario/contraseña. La aplicación se ve así:

<methodCall><methodName>system.multicall</methodName>
<member><name>methodName</name><value><string>wp.getCategories</string></value></member>
<member><name>params</name><value><array><data>
<value><string></string></value><value><string>admin</string></value><value><string>demo123</string></value>
..
<member><name>methodName</name><value><string>wp.getCategories</string></value></member>
<member><name>params</name><value><array><data>
<value><string>admin</string></value>
<value><string>site.com</string></value>

WordPress (xmlrpc) responde a cualquier combinación de usuario/contraseña con éxito (en este ejemplo, pruebeadmin/demo123 e admin/site.com):

[{‘faultCode’: 403, ‘faultString’: ‘Incorrect username or password.‘}, {‘faultCode’: 403, ‘faultString’: ‘Incorrect username or password.‘}, {‘faultCode’: 403, ‘faultString’: ‘Incorrect username or password.’}, {‘faultCode’: 403, ‘faultString’: ‘Incorrect username or password.’}, {‘faultCode’: 403, ‘faultString’: …
[[{‘url’: ‘https://site.com/wordpress/’, ‘isAdmin’: True, ‘blogid’: ‘1’, ‘xmlrpc’: ‘https://site.com/wordpress/xmlrpc.php’, ‘blogName’: ‘wpxxx’}]]]

Mientras vemos métodos wp.getCategories utilizados, cualquier otro método que requiere autenticación se puede emplear en este caso, entonces bloquear sólo los wp.getCategories no ayuda mucho para intentar bloquear este ataque. Sigue una lista de los métodos que requieren autenticación:

wp.getUsersBlogs, wp.newPost, wp.editPost, wp.deletePost, wp.getPost, wp.getPosts, wp.newTerm, wp.editTerm, wp.deleteTerm, wp.getTerm, wp.getTerms, wp.getTaxonomy, wp.getTaxonomies, wp.getUser, wp.getUsers, wp.getProfile, wp.editProfile, wp.getPage, wp.getPages, wp.newPage, wp.deletePage, wp.editPage, wp.getPageList, wp.getAuthors, wp.getTags, wp.newCategory, wp.deleteCategory, wp.suggestCategories, wp.getComment, wp.getComments, wp.deleteComment, wp.editComment, wp.newComment, wp.getCommentStatusList, wp.getCommentCount, wp.getPostStatusList, wp.getPageStatusList, wp.getPageTemplates, wp.getOptions, wp.setOptions, wp.getMediaItem, wp.getMediaLibrary, wp.getPostFormats, wp.getPostType, wp.getPostTypes, wp.getRevisions, wp.restoreRevision, blogger.getUsersBlogs, blogger.getUserInfo, blogger.getPost, blogger.getRecentPosts, blogger.newPost, blogger.editPost, blogger.deletePost, mw.newPost, mw.editPost, mw.getPost, mw.getRecentPosts, mw.getCategories, mw.newMediaObject, mt.getRecentPostTitles, mt.getPostCategories, mt.setPostCategories

Sigue una ilustración de los ataques que hemos visto que usan el sistema XML-RPC system.multicall para hacer ataques de fuerza bruta. Recuerde que cada solicitud puede significar cientos de ataque si no miles de intentos de fuerza bruta de nombre de usuario/contraseña. Un poco de matemáticas y tendrás una idea de la escala de estos ataques y de sus posibles implicaciones.

Protéjase

Yo solía recomendar el bloqueo de todos los accesos a xmlrpc.php, pero eso estaba rompiendo la funcionalidad de algunos plugins (la mayor parte del tiempo, el Jetpack). Con esto en mente, si usted no está utilizando el Jetpack o cualquier otro plugin que requiere XML-RPC es una buena idea bloquear el acceso directo a xmlrpc.php.

Si no bloquear XMLRPC, y está utilizando nuestro WAF (web application firewall), lo recomiendo bloquear las solicitudes system.multicall. Estas solicitudes casi no se usan y lo protegerán de estos métodos de amplificación.

Tenga en cuenta que los usuarios de nuestro WAF ya están protegidos contra estos ataques, por lo que si usted está utilizando CloudProxy ya está seguro.

Fuente:https://blog.sucuri.net