Log4J2 JNDI/LDAP Lookups - Dos elos evitáveis ao apocalipse 🔥 | CVE-2021-44228

🧵 Uma thread de quase 10 anos de acontecimentos que poderiam ter sido previstos e evitados.

Sumário  

• Sumário
• Sobre
• Reflexão
  • Os elos
  • Nossas falhas
  • Lições Aprendidas
• Referências

Sobre  

Em 9 de dezembro, uma grave vulnerabilidade com possibilidade de exploração remota no Log4J da Apache foi publicada, uma biblioteca de log muito utilizada em aplicações Java. A vulnerabilidade afeta uma ampla gama de aplicações.

A vulnerabilidade possibilita que qualquer invasor possa injetar texto em mensagens de log ou parâmetros de mensagem de log em logs de servidor que carregam código de um servidor remoto; O servidor de destino executará esse código por meio de chamadas para o Java Naming and Directory Interface (JNDI). O JNDI faz interface com uma série de serviços de rede, incluindo o protocolo Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS), Java’s Remote Interface (RMI) e o Common Object Request Broker (CORBA). Sendo a forma mais comum de exploração detectada via LDAP, DNS e RMI, usando uma URL marcada para esses serviços redirecionados para um ser externo.

Reflexão  

Os elos  

Aplicações jamais deveriam executar JDNI lookups com dados ou origens não confiáveis.

Alvaro Munoz & Oleksandr Mirosh @BlackHat, 2016. 🎯

Nossas falhas  

Demorou 5 anos para alguem se dar conta ou simplesmente tropeçar no risco.

Aí surgem duas questões?

• Por quê desenvolvedores nunca se deram conta disso?
• Por quê nós, profissionais de segurança também não sabíamos disso?

E concordo com a opinião do Alvaro:

If developers dont know that untrustred data should not be passed to a JNDI lookup op then WE (the security community) have failed them. Its not THEIR fault https://t.co/bOhguVA9pQ

— Alvaro Muñoz (@pwntester) December 11, 2021

Sim, nós falhamos em nossa missão. E falhamos todos os dias. Por quê?

Lições Aprendidas  

• Assim como dito no vídeo, e que sempre tento incentivar meus pares e liderados, é que devemos saber com as aplicações são construídas, ou pelo menos ter algum tipo de experência com desenvolvimento e arquitetura de software.

• Evento não é “oba-oba”. Durante as conferências, devemos nos manter focados e ter ciência do nossa missão como profissionais. Esta vulnerabilidade passou em branco pela comunidade por 5 anos, mesmo sendo “briefada” em 2016 na BlackHat.

E é isso, keep hacking, learning and stay humble.

👾

Referências  

• A JOURNEY FROM JNDI/LDAP MANIPULATION TO REMOTE CODE EXECUTION DREAM LAND:

  • https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

• CVE-2021-44228:

  • https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

• LiveOverflow

  • Log4j Lookups in Depth // Log4Shell CVE-2021-44228 - Part 2

• Log4Shell Hell: anatomy of an exploit outbreak

  • https://news.sophos.com/en-us/2021/12/12/log4shell-hell-anatomy-of-an-exploit-outbreak/

• Log4j: List of vulnerable products and vendor advisories

  • https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/

• Feed de origens maliciosadas detectadas

  • OpenCTIBr
    • https://github.com/openctibr/threatFeeds/blob/main/Log4J_AttackersFeed.txt