Estamos na metade de dezembro de 2021, pouco antes do fim do ano civil, e a vulnerabilidade do log4j chegou ao topo da lista de tarefas de qualquer empresa, especialmente se ela tiver aplicativos que se comunicam com a Internet.

O objetivo desta publicação é descrever a falha do Log4Shell em termos compreensíveis e como você pode envolver nossa equipe para ajudar.

‍

Resumo:

1. O Log4Shell precisa ser levado a sério.

2. A vulnerabilidade contra o log4j, chamada de "Log4Shell", é oficialmente NIST CVE-2021-44228.

3. Atualizações concisas podem ser encontradas no aviso do Github aqui.

4. Uma ferramenta RASP (Runtime Application Self-Protection) o ajudará a se proteger durante a correção. Os clientes da AppDynamics podem aproveitar o Cisco Secure Application para proteção imediata durante a correção.

5. As organizações precisam de uma plataforma como a Lacework, que oferece visibilidade holística da segurança na nuvem.

6. Depois que a vulnerabilidade do Log4Shell for corrigida, as organizações deverão examinar sua infraestrutura e suas políticas de DevOps e garantir que estejam equipadas para responder a essas ameaças de forma fluida e decisiva.

‍

Versões do Apache Log4j afetadas: 2.0 a 2.14.1

Classificação de gravidade: Crítico (10.0 CVSS geral do NIST)

Listagem oficial do NIST: CVE-2021-44228

Aviso de ameaça da TALOS: CVE-2021-44228

Orientação de correção da Apache: Injeção remota de código no Log4j

‍

Os fundamentos: O que é o Log4Shell?

Contexto mais amplo

A vulnerabilidade do Apache Log4j, chamada Log4Shell, tem semelhanças com a vulnerabilidade da SolarWinds. É claro que elas são diferentes, mas são duas situações muito semelhantes. Por quê? A SolarWinds e a Log4Shell são ambas vulnerabilidades da cadeia de suprimentos de software. A vulnerabilidade SUNBURST (a que levou ao incidente da SolarWinds) foi uma inclusão maliciosa (um ataque) em uma DLL, e atualmente acredita-se que a vulnerabilidade Log4Shell seja uma inclusão acidental na biblioteca log4j, mas ambas são vulnerabilidades na cadeia de suprimentos de software.

‍

O que é uma "vulnerabilidade da cadeia de suprimentos de software"?

Escondidas no fundo de todos os aplicativos estão as bibliotecas de código que o desenvolvedor do aplicativo não escreveu e que ele não vetou pessoalmente. Elas são onipresentes. Essas bibliotecas são pequenos (às vezes não tão pequenos) pacotes de código pré-escrito que executam uma função específica ou um conjunto de funções.

Os desenvolvedores usam bibliotecas de código público para não reinventar a roda. Ou, neste caso, para não reinventar uma estrutura de registro em Java. Os desenvolvedores aproveitam bibliotecas como a log4j porque as bibliotecas provaram ser soluções robustas, poderosas e confiáveis para tarefas comuns de software.

Portanto, uma vulnerabilidade na cadeia de suprimentos de software ocorre quando uma biblioteca de código é comprometida mais adiante na cadeia de suprimentos do aplicativo.

‍

Como ocorrem as vulnerabilidades na cadeia de suprimentos de software?

Os problemas acontecem quando uma vulnerabilidade é encontrada em bibliotecas de software. Quer uma vulnerabilidade acabe no código da biblioteca de forma maliciosa ou acidental, se você a estiver usando, estará em risco. Os engenheiros de software e de segurança não podem se isolar totalmente da ameaça de vulnerabilidades em dependências. As equipes podem buscar auditorias rigorosas ou tentar evitar totalmente o uso de bibliotecas externas, mas essas opções geralmente não são economicamente viáveis.

Além da ameaça de vulnerabilidades encontradas em códigos existentes, novos códigos vulneráveis podem ser publicados no futuro. Essas bibliotecas estão sendo atualizadas constantemente. As atualizações vêm para correções de bugs e patches de segurança, que todos nós ficamos felizes em receber, mas novos recursos também são adicionados. Esses novos recursos representam uma superfície de ataque cada vez maior contra nossos aplicativos. Uma equipe de desenvolvimento pode decidir fixar suas dependências em uma versão específica, com apenas os recursos de que precisa, mas, assim, perde as correções de bugs e os patches de segurança. Nos piores casos, as vulnerabilidades podem ser adicionadas de forma maliciosa, o que tornaria isso um ataque à cadeia de suprimentos de software.

‍

O que é o Log4Shell especificamente?

Log4Shell, oficialmente CVE-2021-44228, é uma vulnerabilidade de execução remota de código (RCE) em uma estrutura de registro Java onipresente, log4j (v2).

‍

Há três fatores que tornam o Log4Shell tão perigoso:

1. A biblioteca vulnerável log4j é amplamente implantada.

2. A vulnerabilidade é surpreendentemente fácil de ser explorada.

3. A exploração dá aos invasores a capacidade de executar códigos arbitrários remotamente.

‍

A biblioteca vulnerável log4j é amplamente implantada: O Log4J2 existe como biblioteca desde 2001 e tem quase 21 anos de idade. No momento em que este texto foi escrito, ele tinha apenas 11.500 commits em seu repositório git (https://github.com/apache/logging-log4j2) e seu uso é totalmente gratuito, licenciado pela Apache Foundation, uma organização sem fins lucrativos. Os desenvolvedores podem tentar replicar 21 anos de trabalho contínuo ou podem usar essa biblioteca gratuita e prontamente disponível que já é confiável e usada em quase todos os lugares.

‍

A vulnerabilidade do Log4Shell é incrivelmente fácil de ser explorada: Basta ser capaz de fazer com que um aplicativo vulnerável registre algo de sua escolha.

Isso é muito mais fácil do que parece. Digamos que um usuário vá a uma loja on-line. Ele tenta fazer login e o aplicativo da Web registra a tentativa. O nome de usuário é registrado juntamente com a data da tentativa, se ela foi bem-sucedida ou não etc. Portanto, se esse usuário for um invasor e decidir digitar uma cadeia de caracteres maliciosa no campo de nome de usuário, ela será registrada. O site não precisa nem mesmo ter uma opção de login. Quando um usuário navega para uma página, ela registra sua visita. Muitas vezes, o identificador do agente de usuário do navegador é registrado. Um invasor pode falsificar esse agente de usuário com uma cadeia de caracteres de sua escolha e, em seguida, o aplicativo registrará essa cadeia personalizada.

O registro da cadeia de caracteres personalizada de um invasor por si só não seria problemático. O problema está em um dos muitos recursos do log4j: substituição de pesquisa de mensagens. Quando as pesquisas de mensagens estão ativadas, elas dão ao log4j a capacidade de enriquecer os dados executando pesquisas nos URLs da mensagem registrada.

‍

Agora, os invasores podem executar códigos arbitrários remotamente: Um invasor hospeda um URL que serve um código mal-intencionado e força um aplicativo que esteja executando o log4j a registrá-lo. Quando registrado, o log4j realizará uma pesquisa e se conectará a esse URL, baixando e executando o código malicioso. O código mal-intencionado explora a vulnerabilidade do Log4Shell e injeta um segundo estágio do ataque no jvm. O segundo estágio permite que o invasor execute seu próprio código remotamente. Essa é uma versão simplificada do processo completo, que a Talos Intelligence descreve aqui:(https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html).

‍

Que medidas devo tomar?

Em minha experiência com o Log4Shell nos últimos dias, a fonte mais confiável de informações concisas e precisas foi aqui:

Consultoria CVE-2021-44228 do Github

‍

As etapas de ação imediata são:

- Se você utiliza um RASP, verifique se ele está configurado para bloquear explorações contra essa vulnerabilidade.

- Faça um inventário de onde seus próprios aplicativos são vulneráveis por meio de varredura de vulnerabilidades ou outros métodos.

- Faça um inventário de seu software de terceiros e verifique seus avisos.

- Corrija seus aplicativos atualizando todas as bibliotecas log4j em uso para >=2.16.0.

- Corrija seu software de terceiros seguindo as instruções dos avisos de seus fornecedores.

- Caçar possíveis ameaças internamente. A velocidade com que o Log4Shell foi explorado pelos atacantes significa que, mesmo que uma organização tenha feito tudo certo, ainda assim poderia ter havido uma violação.

‍

Como a Evolutio pode ajudar?

As organizações não consertarão completamente a vulnerabilidade do Log4Shell da noite para o dia, nesta semana ou mesmo neste mês. As equipes de segurança, DevOps, infraestrutura e liderança de TI precisam trabalhar juntas tanto no curto quanto no longo prazo.

As equipes de segurança e tecnologia precisam de maneiras de obter visibilidade, simplicidade e usabilidade para plataformas empresariais complexas, a fim de liderar a transformação digital e abordar as vulnerabilidades rapidamente, sem a cascata de dores de cabeça de TI resultante.

Podemos oferecer chamadas de consultoria com nossos especialistas para validar se nossos clientes estão lidando com as vulnerabilidades corretamente. Normalmente, podemos ajudar na identificação de aplicativos e componentes vulneráveis no cenário de um cliente, por meio de varredura automatizada. Há maneiras de prestarmos assistência com a mitigação real, especialmente em cenários mais complexos. E, por fim, podemos dar conselhos sobre como proteger os sistemas no futuro, incluindo sugestões sobre ferramentas e gerenciamento de riscos.

‍

Conclusão

Em resumo, o Log4Shell é uma ameaça séria, mas provavelmente não será a última ameaça desse tipo que as equipes de segurança encontrarão. Também é importante estar preparado para esses tipos de ameaças no futuro, pois veremos mais delas. Por mais assustadoras que sejam essas ameaças, as ferramentas modernas (como o Cisco Secure Application) estão bem equipadas para ajudá-lo a se proteger e obter visibilidade. Os profissionais de segurança com visão de futuro devem continuar a implementar essas ferramentas e a governança antes da próxima vulnerabilidade, e a Evolutio pode ajudar.

Se quiser saber mais, use o formulário "Fale conosco" e poderemos conversar.