Ataques de Força Bruta são um dos tipos de ataques mais antigos e comuns que ainda vemos na internet, hoje em dia. Se você possui um servidor online, é provável que ele esteja sendo atacado agora mesmo. Pode ser via protocolos, como SSH ou FTP, e, se for um servidor web, via tentativas de força bruta baseadas na web contra qualquer CMS que você esteja usando.
Geralmente, esses ataques não são muito complexos e é teoricamente fácil impedí-los ou mitigá-los, mas eles ainda acontecem e são bem sucedidos; principalmente, porque as pessoas não são boas em escolher senhas, ou em ter bons hábitos de controle de acesso. Mas há um problema, no entanto, mesmo simples, esses ataques de Força Bruta causam transtornos. Tradicionalmente, para tentar 500 senhas diferentes, o atacante precisaria inserir 500 tentativas de login diferentes que seriam capturadas numa proporção de 1 para 1 para cada pedido para o servidor. Isso simplifica a abordagem de mitigação, como cada tentativa é registrada e pode ser bloqueada uma vez que um certo limite é atingido.
Amplificação de Força Bruta
E se o invasor pudesse reduzir o ruído? E se o atacante pudesse fazê-lo de modo que seja uma proporção de 1 para muitos em cada pedido? Imagine um pedido que fosse capaz de experimentar 500 senhas em uma única vez.
Imagine um mundo onde um invasor possa amplificar seus ataques de Força Bruta de tal forma que as estratégias tradicionais de mitigação fiquem inviáveis. Em vez de 500 tentativas de login diferentes, os atacantes pudessem reduzir suas tentativas de login para 20 ou 50 e ainda tentar 500 ou mesmo milhares de senhas para cada pedido, isso dificultaria sua estratégia de mitigação.
Isso seria similar aos ataques de amplificação de DDoS que ouvimos falar nas notícias, em que um único comando e um único servidor de controle podem aproveitar coisas como métodos de amplificação de resposta de DNS ou de protocolo NTP para aumentar seu poder de ataque em 50 ou 100 vezes mais.
Qualquer tipo de método de amplificação pode facilitar, e muito, o trabalho do atacante.
Amplificação dos Ataques de Força Bruta via XML-RPC do WordPress
Uma das características ocultas do XML-RPC é que você pode utilizar o método system.multicall para executar múltiplos métodos dentro de um único pedido. Isso é muito útil e permite que a aplicação envie comandos múltiplos dentro de um único pedido HTTP.
XML-RPC é um método simples, portátil de fazer chamadas de procedimento remotas usando HTTP. Pode ser usado com Perl, Java, Python, C, C++, PHP e com muitas outras linguagens de programação. WordPress, Drupal e a maioria dos sistemas de gerenciamento de conteúdo dão suporte ao XML-RPC.
Lembre-se, porém, que qualquer método usado para o bem, acabará sendo usado para o mal em algum momento.
Ao invés de atacar o wp-login.php (o que pode ser rapidamente bloqueado ou protegido via .htaccess) ou fazer uma única tentativa de ataque contra o xmlrpc, os atacantes estão usando o método system.multicall para tentar adivinhar centenas de senhas com apenas um pedido HTTP.
Sim, centenas de tentativas de login em apenas um pedido HTTP. Imagine ver isso ocorrer no seu arquivo de log (sim, apenas uma 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
Você adivinharia que esse log veio de um método system.multicall com centenas de tentativas de adivinhação de senhas? Com apenas 3 ou 4 pedidos HTTP, o atacante poderia tentar milhares de senhas, burlando ferramentas de segurança que são feitas para procurar e bloquear ataques de força bruta.
A maioria dos ataques que temos visto estão usando o método wp.getCategories, que requer um usuário/senha. O pedido é assim:
<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 se qualquer combinação de usuário/senha tiverem sucesso (nesse exemplo, tentamos admin/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’: ‘http://site.com/wordpress/’, ‘isAdmin’: True, ‘blogid’: ‘1’, ‘xmlrpc’: ‘http://site.com/wordpress/xmlrpc.php’, ‘blogName’: ‘wpxxx’}]]]
Enquanto vemos métodos wp.getCategories sendo usados, qualquer outro método que requer autenticação pode ser empregado nesse caso, então bloquear somente o wp.getCategories não ajudará muito para tentar bloquear esse ataque. Segue uma lista de métodos que requerem autenticação:
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
Proteja-se
Recomendamos o bloqueio de qualquer tipo de acesso ao xmlrpc.php, mas isso estava quebrando a funcionalidade de alguns plugins (na maioria das vezes, o JetPack). Com isso em mente, se você não estiver usando o JetPack ou qualquer outro plugin que requer o XML-RPC, é uma boa ideia bloquear o acesso direto ao xmlrpc.php adicionando o código abaixo no .htaccess
<Files “xmlrpc.php”>
Order Allow,Deny
deny from all
</Files>
Fonte: Parte desse texto foi publicado originalmente em https://blog.sucuri.net/portugues/2015/10/09/ataques-de-amplificacao-de-forca-bruta-contra-xmlrpc-do-wordpress.html