Falhas no plug-in do WordPress rouba metadados da AWS

Um tipo de vulnerabilidade que pode ter consequências graves se explorada, mas que não é muito comentada, é a falsificação de solicitação do lado do servidor (SSRF).

O que é falsificação de solicitação do lado do servidor?

A falsificação de solicitação do lado do servidor (SSRF) é um tipo de vulnerabilidade que permite que um invasor abuse da funcionalidade normal do servidor, fazendo com que o servidor envie uma solicitação sobre a qual o invasor tem controle. Isso pode ser feito de maneira relativamente simples com um URL modificado em um navegador ou usando uma ferramenta como o Burp Suite para capturar a solicitação do navegador e modificá-la antes de enviá-la ao servidor.

As vulnerabilidades do SSRF geralmente não são difíceis de explorar, mas podem fornecer ao agente da ameaça informações que podem auxiliá-lo em novos ataques ou até mesmo permitir que ele faça solicitações a recursos internos que podem levar à alteração de dados. Em alguns casos, um agente de ameaça pode executar comandos arbitrários no servidor, permitindo que o agente conclua o controle total de um site vulnerável.

Um exemplo do mundo real: vulnerabilidade de falsificação de solicitação do lado do servidor no plug-in Google Web Stories

Em 25 de outubro de 2022, uma vulnerabilidade SSRF no plug-in Web Stories do Google foi divulgada nas versões <= 1.24.0. Essa vulnerabilidade foi descoberta e divulgada por Aymen Borgi, que solicitou um CVE ID da equipe do Wordfence.

Os usuários do Wordfence Premium, Care e Response receberam uma regra de firewall para bloquear tentativas de exploração direcionadas a essa vulnerabilidade SSRF em 27 de outubro de 2022. Os usuários do Wordfence Free receberam a regra de firewall 30 dias depois, em 26 de novembro de 2022.

A vulnerabilidade existia devido à validação imprópria de URLs fornecidos por meio do parâmetro ‘url’ chamado por meio do ponto de extremidade da API REST /v1/hotlink/proxy. Explorando essa vulnerabilidade, um usuário autenticado pode fazer solicitações da web para locais arbitrários provenientes do aplicativo da web. O usuário autenticado não precisa de privilégios de alto nível para explorar esta vulnerabilidade. O ataque pode ser bem-sucedido para usuários logados com uma conta que tenha permissões mínimas, como um assinante, que seria de fácil acesso em sites com registro aberto.

Essa vulnerabilidade exige que o agente da ameaça obtenha seu próprio REST nonce, que é um processo simples. Tudo o que é necessário para obter o nonce é fazer login no site e, em seguida, acessar o site com /wp-admin/admin-ajax.php?action=rest-nonce o nome de domínio anexado.

Uma vez obtido o nonce, a vulnerabilidade pode ser facilmente explorada. Nesse ponto, um invasor pode fornecer um caminho para um serviço interno por meio do parâmetro ‘url’ ao chamar o endpoint da /web-stories/v1/hotlink/proxyAPI REST e obter acesso aos recursos internos.

 

Aproveitando a falsificação de solicitação do lado do servidor para extrair informações confidenciais na AWS

Se o site estiver hospedado em um servidor Amazon Web Services (AWS), coletar os metadados da AWS é relativamente simples. Essa exploração requer apenas a chamada do endpoint de API REST apropriado com a carga útil correta no parâmetro ‘url’ para obter uma exploração bem-sucedida. 

O valor _wpnonce seria substituído pelo nonce obtido na primeira etapa. Assim que a vulnerabilidade for explorada com sucesso, os metadados da AWS serão exibidos no navegador. Como visto aqui, os metadados solicitados incluem informações confidenciais como AccessKeyId, SecretAccessKey e Token.

Esses metadados específicos são usados para identificar o software na instância para a instância do EC2 para usar recursos como o EC2 Instance Connect. Esse recurso pode permitir que um invasor bem-sucedido faça login no servidor virtual e execute comandos por meio do terminal. Existem muitas categorias de metadados fornecidas pela AWS, cada uma com usos específicos e vários graus de gravidade se forem mal utilizadas.

Embora o plug-in do Google Web Stories tenha tentado validar o parâmetro ‘url’ em sua primeira tentativa de corrigir a vulnerabilidade, ele não levou a AWS em consideração no código. Dois blocos de código foram atualizados para corrigir totalmente a vulnerabilidade no plug-in. No primeiro bloco de código, intervalos adicionais de endereços IP foram adicionados à lista de validação de URL.

O IP da AWS também foi adicionado como um endereço IP não permitido.

Com o patch aplicado na versão 1.25.0 e mais recente, as tentativas de obter metadados da AWS falharão.

Como impedir a criação de vulnerabilidade de falsificação de solicitação do lado do servidor

Impedir a criação de vulnerabilidades SSRF é semelhante a outras vulnerabilidades. Os desenvolvedores devem desenvolver seu código de forma a levar em conta as vulnerabilidades na linguagem de programação escolhida e também garantir que qualquer entrada seja adequadamente sanitizada e validada.

Para validar adequadamente a entrada, o desenvolvedor deve entender como a funcionalidade pode ser mal utilizada e eliminar programaticamente cada forma como a funcionalidade pode ser mal utilizada. É por isso que entender o impacto de vulnerabilidades como vulnerabilidades SSRF é fundamental para os desenvolvedores. Manter o código seguro pode ser difícil de garantir durante a fase de desenvolvimento, e é por isso que o código deve ser testado quanto a vulnerabilidades durante e depois de ter sido escrito.

Especificamente para vulnerabilidades de SSRF, o melhor método para os desenvolvedores protegerem o terminal é garantir que todas as formas de entrada sejam validadas adequadamente e que as URLs sejam restritas adequadamente se passadas para uma função que faz uma chamada para a URL. 

Isso significa que cada entrada só deve ser aceita se atender à formatação e ao conteúdo esperados, e devem ser feitas verificações para garantir que o usuário atual tenha permissão para fazer a solicitação. Se a requisição não se enquadrar no que se espera da aplicação, o usuário não está autorizado para a requisição, ou o local de origem da requisição não é o esperado, então a requisição deve simplesmente retornar um erro.

Como proteger sites e redes contra falsificação de solicitação do lado do servidor

Existem etapas que podem ser tomadas para proteger os sites dessa e de outras vulnerabilidades. Embora nem sempre seja possível evitar totalmente as vulnerabilidades, tomar medidas para proteger os sites minimiza significativamente as chances de um comprometimento bem-sucedido.

Atualizar plugins, temas e o núcleo do WordPress é a melhor maneira de proteger os sites do WordPress contra vulnerabilidades. Como as vulnerabilidades podem ser desconhecidas, um firewall de aplicativo da Web (WAF), como o firewall Wordfence, ajuda a bloquear tentativas de ataque contra vulnerabilidades não corrigidas em um site e também o alerta quando as vulnerabilidades estão presentes em seu site.

SSRF e confiança zero

As vulnerabilidades de falsificação de solicitação do lado do servidor servem como um lembrete importante de que a estrutura Zero-Trust deve ser praticada em ambientes modernos. Em essência, as vulnerabilidades do SSRF são possíveis porque os recursos internos e externos podem ser configurados para assumir que as solicitações enviadas de um local interno são inerentemente confiáveis. Ao exigir validação e autorização para cada ação, essa confiança padrão é removida e as solicitações devem ser validadas adequadamente antes de serem consideradas confiáveis.

Se você acredita que seu site foi comprometido como resultado dessa vulnerabilidade ou de qualquer outra vulnerabilidade, oferecemos serviços de resposta a incidentes por meio do Wordfence Care. Se você precisar que seu site seja limpo imediatamente, o Wordfence Response oferece o mesmo serviço com disponibilidade 24/7/365 e tempo de resposta de 1 hora. Ambos os produtos incluem suporte prático caso você precise de mais assistência.

Para mais detalhes, acesse este link.

LEIA TAMBÉM: