Blog Cisco Brasil
Compartilhe
tweet

Blog Cisco Brasil > Segurança

Segurança

A história se repete com o “Log4Shell”?


15/12/2021

blog atualizado, 18/12

Bem-vindo, leitor ávido por conhecimento…

Irei começar este artigo com algo que já havia colocado em um outro artigo:

“Aqueles que não se lembram do passado estão condenados a repeti-lo”. (George Santayana, filósofo, ensaísta, poeta e romancista espanhol).

Sim, estamos fadados a experimentar, em nossa vida pessoal e profissional, situações que parecem se repetir de forma cíclica, apesar de muitos discordarem, pois com o tempo e experiência estas situações podem ter outra perspectiva em nossas vidas.

Já vimos no passado vulnerabilidades como Heartbleed (2014), EternalBlue[1] (2017), Meltdown (2018), Spectre-V1 (2018) e Spectre-V2 (2018) – para citar algumas.

Se avaliarmos a nova vulnerabilidade CVE-2021-44228, também conhecida como a vulnerabilidade do Apache Log4j2 (ou Log4Shell), perceberemos que já estivemos face-a-face com vulnerabilidades críticas (como exemplificado acima), com impactos significativos, para nossos sistemas críticos… Porém esta colocou toda a comunidade de segurança cibernética alerta para os potenciais danos que podem e/ou poderão ser causados.

Mas você deve estar se perguntando:

“Qual a diferença desta vulnerabilidade atual para as outras?”

Não irei entrar em detalhes muito técnicos, pois já há fontes como detalhes sobre ela (vide Cisco Talos e Cisco Security Advisory), mas sim uma percepção peculiar sobre a natureza desta vulnerabilidade.

Qual a diferença desta vulnerabilidade atual para as outras?

Primeiro vamos ver um detalhe que vem chamando muito a atenção da comunidade de segurança cibernética, sua pontuação CVSS (Common Vulnerability Scoring System), comparada com outras vulnerabilidades críticas (como exemplificado acima):

 

Vulnerabilidade CVE CVSS (3.x) Base Score
Heartbleed CVE-2014-0160 7.5
EternalBlue CVE-2017-0144 8.1
Meltdown CVE-2017-5754 5.6
Spectre-V1 CVE-2017-5753 5.6
Spectre-V2 CVE-2017-5715 5.6
Log4Shell CVE-2021-44228 10.0

 

Uma pontuação 10.0 é a pontuação mais alta… CRÍTICA! Sim, isto pode ser óbvio, porém vemos poucas vulnerabilidades alcançarem esta pontuação tão alta e, neste caso, uma vulnerabilidade também qualificada como 0-Day (Zero Day), isto é, uma vulnerabilidade que não foi reportada através de um fabricante ou centro de pesquisa, mas sim encontrada sua presença, em execução na Internet, sem aviso prévio. Em outras palavras: explorada até ser notada[2].

Outro detalhe a ser considerado é a abrangência de exposição à esta vulnerabilidade, pois o Log4j é uma biblioteca muito popular no Apache Foundation, isto é, qualquer solução que utilize esta biblioteca está em risco, pois é uma ameaça real.

Finalmente, as possibilidades de explorar esta vulnerabilidade não estão limitadas a um protocolo específico, pois há diversos protocolos que podem ser utilizados (LDAP(S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP). Em outras palavras: há diversas formas de um atacante conseguir explorar esta vulnerabilidade.

Estes pequenos detalhes à tornam uma ameaça em potencial para criação de um Worm – algo como foi feito com EternalBlue e WannaCry Ransomware.

Como me proteger?

Bem, a forma mais falada é aplicar as correções necessárias e/ou utilizar a versão mais atual do Apache Log4j: 2.17.0 (vide Addendum).

Mas sabemos que os ambientes são complexos, as aplicações são complexas, a nuvem é complexa… Enfim, não é uma tarefa fácil, pois não sabemos o impacto que haverá ao aplicar-se as correções necessárias e/ou utilizar-se da versão mais atual… Então, você como líder de segurança cibernética, pode começar com perguntas simples:

  1. Quais são meus sistemas mais críticos?
  2. Eles estão expostos a esta vulnerabilidade?
  3. O que minha equipe tem para proteger esses sistemas, até conseguir aplicar todas as correções?
  4. Meu ambiente está usando multicamadas (defesa em profundidade) para se proteger contra essa ameaça?
  5. A equipe já tem um plano de homologação e aplicação da correção nesses sistemas?
  6. Como meu ambiente é protegido para pós-exploração?
  7. Como meu parceiro de negócios está lidando com essa ameaça?
  8. Meus sistemas possuem interoperabilidade mapeada entre eles? Consigo utilizar Black-list e White-List?
  9. Temos um catálogo de aplicações, ou inventário de ativos, completo com mapeamento de dependências junto com pontos de contato para essas aplicações??
  10. Há um Playbook específico para lidar com este tipo de incidente?

Os próximos dias prometem muitas emoções, então pense em fazer o básico, pois o básico, muitas vezes, é o melhor ponto de partida para enfrentar ameaças como esta.

Addendum

Outra vulnerabilidade, CVE-2021-45046 (Base CVSS 3.x Score 9.0), foi identificada no Log4j 2.15.0, deixando-o suscetível a ataques em certas configurações. O Log4j versão 2.16.0 corrige essa vulnerabilidade, desabilitando o acesso ao JNDI por padrão e limitando os protocolos padrão (JAVA e LDAP(S)).

[Atualização de 17 de Dezembro de 2021]

Outra vulnerabilidade, CVE-2021-45105 (Base CVSS 3.x Score 7.5), foi identificada no Log4j 2.16.0, deixando-o susceptível a ataques de Denial-of-Service (negação de serviço), onde a utilização de certas strings podem causar recursão infinita, isto é, Denial-of-Service (CVE-2021-45105). O log4j versão 2.17.0 corrige essa vulnerabilidade.

[1] Vulnerabilidade explorada pelo infame WannaCry Ransomware.

[2] Há relatos que já estaria sendo explorada contra a plataforma de jogo eletrônico Minecraft.

Tags:
Deixe seu comentário

4 Comentários

  1. Artigo muito bom,bem explicito.parabês.

  2. Muito bem escrito, parabéns!

  3. Obrigado pelo artigo

  4. MUITO IMPORTANTE,PARA OS PROFOSSIOBAIS DE CYBERSECURITY.