Los Ataques por fuerza bruta son uno de los tipos más antiguos y comunes de los ataques que todavía vemos en el Internet hoy en día. Si tienes un servidor en línea, es más probable hayas sufrido estos tipos de ataques Podría ser a través de protocolos como SSH o FTP, y si se trata de un servidor web, a través de la fuerza bruta los intentos basados en la web contra todo lo que la CMS que está utilizando.





Estos ataques a menudo no son muy complejos y son teóricamente fácil de detener y mitigar, pero todavía ocurren y tienen éxito; sobre todo, porque la gente es muy mala en la elección de buenas contraseñas, o el empleo de los buenos hábitos de control de acceso. Hay una captura sin embargo, aunque simple, estos ataques de fuerza bruta son muy ruidosos. Tradicionalmente, para tratar 500 contraseñas diferentes, los atacantes tendrían que intentar 500 intentos de conexión diferentes que se capturaron en una relación 1 a 1 con cada solicitud al servidor. Por diseño, esto simplifica el enfoque de mitigación, como cada solo intento se registra y puede ser bloqueada una vez que se alcanza un cierto límite.

Amplificación con Fuerza bruta

¿Y si, el atacante podría reducir el ruido? ¿Y si el atacante podría hacerlo de modo que se trata de una relación 1 a muchos entre cada solicitud? Imagina una petición que fue capaz de tratar 500 contraseñas de una sola vez.

Imagina un mundo en el que un atacante podría amplificar sus ataques de fuerza bruta de tal manera que las estrategias de mitigación tradicionales están a la altura. En vez de 500 intentos de conexión diferentes, los atacantes podrían reducir sus intentos de conexión que decir 20 o 50 y todavía tratar 500 o incluso miles de contraseñas para cada solicitud. Como se pueden imaginar, esto comienza a hacer su estrategia de mitigación de un poco más difícil de emplear.

Esto sería algo similar a los ataques DDoS de amplificación que escuchamos en las noticias, en un único servidor de comando y control puede aprovechar las cosas como un DNS o métodos de amplificación de la respuesta del protocolo NTP para aumentar su poder de ataque 50 o 100 veces más.

Cualquier tipo de método de amplificación puede hacer el trabajo de un atacante, mucho más fácil.

Los ataques de fuerza bruta de amplificación a través de WordPress XML-RPC (PingBack)

Una de las características ocultas de XML-RPC es que se puede utilizar el método system.multicall para ejecutar múltiples métodos dentro de una única solicitud. Eso es muy útil, ya que permite la aplicación de pasar varios comandos dentro de una petición HTTP.

XML-RPC es una forma sencilla y portátil para hacer llamadas a procedimiento remoto a través de 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 soportan XML-RPC.

Recuerde, sin embargo, cualquier característica que se utiliza para el bien, es probable que se utiliza para el mal en algún momento.

Eso es exactamente lo que está pasando aquí.

En realidad hemos estado siguiendo esto durante un par de semanas (primer ataque descubierto en 2015 / Sep / 10), y se pone cada vez más tracción y cada vez más popular. En vez de ir en contra de wp-login.php (que puede ser fácilmente bloqueados o protegidos mediante .htaccess) o hacer un solo intento contra xmlrpc, los atacantes están aprovechando el método system.multicall intentar adivinar cientos de contraseñas dentro de una sola solicitud HTTP.

Sí, cientos de intentos de conexión dentro de una sola solicitud HTTP. Imagínese ver en su archivo de registro (sí, sólo por esta 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

¿Te imagino que esta entrada de registro provenía de una llamada al método system.multicall con cientos de contraseñas intentaron? Con sólo 3 o 4 peticiones HTTP, los atacantes podrían tratar miles de contraseñas, sin pasar por las herramientas de seguridad que están diseñados para verse y bloquear los intentos de fuerza bruta.

La mayoría de los ataques que estamos viendo en la naturaleza están utilizando el método wp.getCategories, que requiere un usuario / pase. Esta es la forma en la solicitud se ve así:

system.multicall
methodNamewp.getCategories
params
admindemo123
..
methodNamewp.getCategories
params
admin
site.com

...

WordPress (xmlrpc) responde si cualquiera de las combinaciones de usuario / pass utilizados tuvieron éxito (en este ejemplo, trató el admin / demo123 y admin / site.com combos contraseña):

[{‘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': ‘http://site.com/wordpress/’, ‘isAdmin': True, ‘blogid': ‘1’, ‘xmlrpc': ‘http://site.com/wordpress/xmlrpc.php’, ‘blogName': ‘wpxxx’}]]]

Mientras que estamos viendo el método wp.getCategories siendo utilizado, cualquier otro método que requiere autenticación se puede utilizar también, así que el bloqueo sólo wp.getCategories no hará mucho para detener estos ataques. Esta es 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

A continuación se muestra una ilustración de los ataques que hemos estado viendo la orientación del método system.multicall XML-RPC específicamente, y se atribuyen a estos intentos de fuerza bruta. Recuerde, cada solicitud puede significar un ataque de 100 de, si no 1000 del de nombre de usuario / contraseña de fuerza bruta intentos. Algunas operaciones matemáticas sencillas, y podrá apreciar la magnitud de los ataques y su implicaciones potenciales.

Cómo Protegerse ataques XMLRPC.PHP

Yo directamente recomendaría a la gente bloquean todos los accesos a xmlrpc.php, pero esto rompería la funcionalidad de algunos plug-in (en su mayoría JetPack). Con esto en mente, si usted no está usando JetPack o cualquiera de los otros plugin que lo requieran XML-RPC, podría ser una buena idea para bloquear el acceso directo a la misma por completo.

Si usas el CMS Wordpress añade estas líneas en el fichero de configuración de Apache:

# Block WordPress xmlrpc.php requests

order deny,allow
deny from all
allow from 123.123.123.123

 O instalar un plugin:

• https://es.wordpress.org/plugins/stop-xmlrpc-attack/installation/

Si no puede bloquear XML-RPC, y usted está usando un WAF (Web firewall de aplicaciones), le recomiendo el bloqueo de solicitudes system.multicall. Apenas se utiliza en la naturaleza y lo protegerá contra estos métodos de amplificación.


Fuentes:
https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html