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-nonceo 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 _wpnonceseria 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:
