Um guia definitivo sobre XMLRPC para WordPress (+ Como desativá-lo)

A segurança do site é uma coisa difícil de resolver da maneira certa . Especificamente com problemas de segurança relacionados ao XML-RPC – como comumente explorado em ataques a sites WordPress. Há muita informação disponível na internet que oferece todos os tipos de soluções, mas quais são as corretas? Este artigo explicará como, as soluções disponíveis e qual realmente é a melhor solução. Vamos mergulhar!

XMLRPC é mais antigo que o próprio WordPress. Este sistema foi introduzido no WordPress para combater o dilema da conexão lenta à Internet, ajudando os usuários a escrever novas postagens offline e depois carregá-las no servidor. A capacidade de conectar o WordPress remotamente com outros aplicativos só foi possível com o arquivo xmlrpc.php.

Mesmo alguns desenvolvedores experientes não entendem completamente o XMLRPC e as ameaças de segurança associadas a ele. É bastante provável que o site/sites que você gerencia tenham um arquivo XMLRPC ativo que precise de sua atenção imediata, mas você só poderá executar um plano de ação eficaz depois de saber como o XMLRPC é operado e qual é a melhor maneira de manipulá-lo com segurança.

Embora o WordPress tenha agora sua própria API REST, o arquivo xmlrpc.php ainda está presente dentro do núcleo e é ativado por padrão, expondo o site WordPress a vários ataques cibernéticos. Neste artigo, aprenderemos o uso desse arquivo, as vulnerabilidades associadas a ele e como lidar com isso sem colocar em risco a segurança do seu site.

O que é um arquivo xmlrpc.php?

Em sua forma mais simples, XML-RPC (Remote Procedure Call) foi criado para comunicação entre plataformas. Esse protocolo era usado para fazer chamadas de procedimento usando HTTP como transporte e XML como codificador. O cliente faz essas chamadas enviando uma solicitação HTTP ao servidor e recebe a resposta HTTP em troca. O XML-RPC invoca funções por meio de solicitação HTTP e, em seguida, essas funções executam algumas ações e enviam respostas codificadas em retorno.

Vamos comparar isso com uma chamada de API REST para entender completamente o conceito.

REST consome parâmetros de URL para identificar recursos enquanto RPC usa os parâmetros de consulta para fornecer argumentos de função.

O WordPress usou o XMLRPC para permitir que seus usuários interagissem remotamente com seu site. Ele ainda o usa para alimentar seu aplicativo móvel e para suportar plugins como JetPack, WooCommerce, etc. Usar o arquivo xmlrpc.php tem suas desvantagens, mas desativá-lo completamente é a única solução viável? Para responder a isso, primeiro precisamos olhar para as vulnerabilidades associadas a ela e quais são as soluções disponíveis para evitá-las.

Como hackers cruéis podem ser com o arquivo xmlrpc.php?

Usando XMLRPC, os hackers aproveitam as Chamadas de Procedimento Remoto (RPC) e invocam funções para buscar os dados que desejam. Na maioria dos sites WordPress, o arquivo xmlrpc.php é facilmente rastreável, e apenas enviando dados XML arbitrários, os hackers controlam o site para executar o código que prepararam para executar um determinado tipo de ataque.

Para entender como o WordPress XMLRPC é comprometido, vejamos os ataques cibernéticos mais populares associados a ele.

Ataque de força bruta

No ataque do Bruteforce, o hacker tenta adivinhar o nome de usuário e a senha corretos executando várias tentativas de login. Infelizmente, um grande número de sites WordPress usa senhas de administrador fracas ou não possui nenhuma camada de segurança adicionada para impedir invasores. Esses sites são facilmente comprometidos com esse tipo de ataque.

Outros usam uma senha forte e também possuem mecanismos de segurança como reCaptcha e bloqueio automático de IP que é eficaz contra ataques de força bruta, mas se o hacker decidir usar XMLRPC; ela nem precisa acessar o administrador do WordPress.

Uma ferramenta muito comum do Kali Linux, o WPSCAN é usado para enumerar todos os nomes de usuário e, uma vez feito, os hackers forçam a senha usando o arquivo xmlrpc.php enviando a seguinte solicitação HTTP para o site da vítima.

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

No exemplo acima, um hacker pode enviar milhares de variações até recuperar a senha correta.

A resposta a seguir é retornada em relação à solicitação acima. A resposta contém o código de erro e uma mensagem clara informando que o nome de usuário e a senha tentados estavam incorretos. É uma indicação clara que diz ao hacker para tentar novamente até que a senha correta seja encontrada.

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

A resposta retornou o código HTTP 200 e a mensagem de que o nome de usuário e a senha fornecidos estavam incorretos. Passando pelo canal XMLRPC, um hacker não precisa se preocupar com plugins reCaptchas ou limitar tentativas de login. Ela pode continuar executando as variações até que a senha correta seja recuperada.

Observação: os ataques de força bruta consomem muitos recursos e também causam problemas de desempenho. O processo de tentativa e erro é executado em loop por um longo período de tempo que pode manter seu servidor ocupado para atender aos visitantes reais. Esse consumo desnecessário de recursos faz com que os servidores consumam mais energia.

Ataque DDoS

A negação de serviço distribuída (DDoS) é um dos ataques cibernéticos mais letais que podem paralisar o servidor, atingindo-o com centenas e milhares de solicitações simultâneas. Os hackers usam o recurso pingback do WordPress junto com o arquivo xmlrpc.php para executar esses ataques.

Idealmente, o hacker tem como alvo o endpoint ou uma página que pode ser acessada várias vezes e leva mais tempo para responder. Dessa forma, um único hit pode ter um impacto máximo nos recursos do servidor e, no nosso caso, o XMLRPC atende bem ao hacker ao expor esses endpoints.

Vários sites WordPress já comprometidos são usados ​​para executar o método pingback.ping para atingir uma única vítima. As solicitações HTTP GET e POST esmagadoras bloqueiam o tráfego regular e, eventualmente, travam o servidor.

Primeiro, o hacker verifica se o arquivo xmlrpc.php está habilitado ou não enviando a seguinte solicitação.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

Uma vez confirmado que o XMLRPC está ativado no site de destino, o invasor começa a atacá-lo usando a rede de sites explorados para enviar várias solicitações de pingback ao site da vítima. Isso pode ser automatizado a partir de vários hosts e usado para causar um ataque DDoS em massa no site da vítima.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

Ataque de porta entre sites (XSPA)

Cross-site Port Attacks (XSPA) são muito comuns em que o hacker injeta o script malicioso para recuperar informações sobre portas TCP e endereços IP. No caso do WordPress, o XMLRPC é usado junto com seu mecanismo de pingback para ignorar qualquer mascaramento de IP, como WAF básico, como Cloudflare.

Em um ataque XSPA, o hacker usa o método pingback.ping para pingback de uma postagem em um site de destino que, por sua vez, envia o endereço IP em resposta. O hacker usa um sniffer para criar o endpoint para enviar o pingback e uma URL ativa de uma postagem no blog.

Os hackers enviam a seguinte solicitação de seu servidor.

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

Se a resposta contiver faultCode e um valor maior que 0, significa que a porta está aberta para você começar a enviar os pacotes HTTP diretamente.

Métodos ineficazes de bloqueio de ataques XMLRPC

Até agora no artigo, estabelecemos que o arquivo xmlrpc.php é propenso a alguns ataques cibernéticos graves, como DDoS, Bruteforce e Cross-site Port Attack, portanto, é crucial tratá-lo adequadamente para bloquear esses ataques .

Excluindo completamente o XMLRPC

Você pode simplesmente excluir o arquivo XMLRPC que fará com que seu servidor comece a lançar erros 404 em qualquer pessoa que tente acessá-lo. A desvantagem desta solução é que o arquivo será recriado toda vez que você atualizar o WordPress.

Desativando completamente o XMLRPC

A outra opção mais viável é desabilitar o arquivo xmlrpc.php . Você pode fazer isso simplesmente adicionando o bloco de código dentro do seu arquivo .htaccess . Certifique-se de fazer isso antes das regras .htaccess que nunca mudam, adicionadas pelo WordPress.

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

Isso desativará o arquivo xmlrpc.php para cada aplicativo ou serviço que o utiliza. Você pode colocar um determinado endereço IP na lista de permissões caso ainda queira acessar seu site WordPress via XMLRPC. Para isso, você precisa adicionar o seguinte comando:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

Prós

• Elimina os riscos de abuso de XMLRPC em ataques cibernéticos.
• Benefícios de desempenho de longo prazo e economia nos recursos do servidor.

Contras

• Desabilitar o XMLRPC é o mesmo que desabilitar o acesso remoto para aplicativos que usam essa versão de acesso remoto. Isso significa que o Jetpack, o aplicativo móvel WP ou qualquer outra solução que se conecte ao seu site WordPress via XMLRPC não pode mais se conectar ao seu site.
• O código legado para aplicativos personalizados também pode não funcionar.

Por que instalar um plug-in de segurança realmente prejudica seu site

Os usuários do WordPress geralmente se apoiam em plugins para qualquer recurso ou funcionalidade necessária sem pensar muito sobre seu impacto no desempenho do site. Existem vários plugins de segurança do WordPress que prometem proteger seu site contra problemas de segurança relacionados ao XMLRPC, mas, na realidade, eles prejudicam mais seu site.

Aqui estão algumas das razões pelas quais proteger seu site com um plugin não é a melhor escolha.

• Os plug-ins de segurança são eficazes apenas no nível do aplicativo e não protegem seu servidor de ser atingido.
• Eles adicionam código desnecessário em seu site que diminui seu desempenho e aumenta o tempo até o primeiro byte (TTFB).
• Alguns desses plugins fazem mais mal do que bem e são usados ​​por hackers para criar backdoors em seu site.
• Esses plugins requerem gerenciamento frequente que adiciona mais carga de trabalho.

Da avaliação acima, nenhuma das opções oferece uma solução ideal para lidar com o problema de segurança XMLRPC. Isso nos leva aos Domínios Acelerados. Um serviço criado para resolver problemas complexos relacionados à segurança e muito mais. Vejamos como os domínios acelerados podem resolver efetivamente o problema XMLRPC para você.

Como os domínios acelerados lidam com problemas de XMLRPC para seus clientes?

O Accelerated Domains resolve problemas complexos de desempenho, segurança e escalabilidade da maneira mais eficiente. Accelerated Domains oferece segurança gerenciada de nível empresarial que bloqueia qualquer tipo de ataque cibernético, incluindo aqueles associados ao XMLRPC.

O mecanismo de segurança inteligente da Accelerated Domains fica na frente do servidor e filtra cerca de 40% de todo o tráfego HTTP. Ele detecta até os ataques cibernéticos mais sofisticados no início da linha do tempo por meio de seus recursos heurísticos inteligentes alimentados por alimentação contínua de dados e conhecimento prático e análise de tráfego da Servebolt. O Accelerated Domains faz sua mágica sem prejudicar o desempenho do seu site de forma alguma. Na verdade, ele acelera.

O mecanismo de segurança proativo do Accelerated Domains protege automaticamente seu site contra ataques DDoS. Com capacidade de rede próxima a 60 Tbps, ele está bem equipado para suportar até mesmo alguns dos maiores ataques DDoS na internet. Da mesma forma, ele fornece um mecanismo de defesa eficaz contra ataques do Bruteforce por meio de um recurso de limitação automática de taxa, onde o número de solicitações geradas de uma única fonte é identificado e limitado para evitar atividades maliciosas.

Prós

• Domínios acelerados mitiga a maioria das vulnerabilidades de segurança associadas ao XMLRPC, portanto, não há necessidade de desativá-lo.
• Permite que o usuário continue usando os plugins como Jetpack, aplicativo WooCommerce e outras ferramentas que dependem do arquivo xmlrpc.php.
• Integração sem complicações em qualquer domínio, portanto, não há necessidade de modificar o arquivo .htaccess .
• Não há necessidade de instalar plugins adicionais.

Contras

• Não tem nenhum.

Pensamentos finais

Os ataques cibernéticos estão se tornando cada vez mais sofisticados e como webmaster e empresário, é vital que você os compreenda e conheça as ferramentas para enfrentá-los. A maioria dos ataques é evitada com uma abordagem proativa, como monitoramento constante e atualização do software ou adicionando ferramentas como Domínios Acelerados que fazem tudo isso no piloto automático. Uma vez ativado, o Accelerated Domains filtra o tráfego de forma inteligente e toma as ações necessárias quando necessário para manter seu servidor de origem e seu site protegidos contra ataques cibernéticos.