Especialistas em segurança de TI comentam sobre a lacuna de segurança log4j para a qual o BSI declarou o nível de alerta vermelho. Especialistas da Barracuda Networks, Radar Cyber Security e ForeNova fornecem uma avaliação da situação.
Jonathan Tanner, pesquisador sênior de segurança da Barracuda Networks
Jonathan Tanner, pesquisador sênior de segurança da Barracuda Networks: "Como essa vulnerabilidade permite a execução remota de código, os riscos são bastante altos." (Imagem: Barracuda Networks).
Como as empresas podem identificar essa vulnerabilidade em sua tecnologia e quais são os riscos se ela não for corrigida?
“Primeiro você deve verificar se uma versão do log4j anterior a 2.15.0 é usada, também nas dependências. Tanto o Maven quanto o Gradle - ferramentas de gerenciamento de compilação baseadas em Java - fornecem a capacidade de imprimir toda a árvore de dependências de um projeto. Desta forma, pode ser determinado se uma versão vulnerável do log4j está sendo usada ou não. Mesmo com a versão 2.15.0 ou posterior, certifique-se de que a propriedade do sistema formatMsgNoLookups não esteja definida como 'true'.
A única razão pela qual esta versão não é vulnerável é que ela definiu o valor padrão de true para false. Em algumas versões do log4j, essa propriedade pode ser facilmente definida como falsa manualmente para atenuar a vulnerabilidade. Se o aplicativo não requer LDAP como parte de seu uso legítimo, também é possível bloquear todo o tráfego LDAP com um firewall ou filtro de aplicativo da Web para evitar que o código remoto seja alcançado caso a vulnerabilidade seja explorada.
No entanto, eles apenas verificam se o log4j é capaz de explorar essa vulnerabilidade RCE ou não. Se um sistema é ou não verdadeiramente vulnerável a um ataque é uma questão muito mais complicada sem um único teste como vulnerabilidades como HeartBleed tinha. Para explorar essa vulnerabilidade, um invasor precisa executar um ataque de injeção de log. Encontrar isso é um processo muito mais complexo, mas basicamente qualquer lugar onde a entrada de um usuário (ou invasor em potencial) é registrada pode ser vulnerável a esse ataque.
Portanto, para testar um RCE real, seria necessário tentar encontrar uma maneira de fazer uma solicitação JNDI LDAP nos logs do próprio contexto do usuário (por exemplo, por meio do site ou da API, se o aplicativo potencialmente afetado for um aplicativo da web). Como essa vulnerabilidade permite a execução remota de código, os riscos são bastante altos. Um invasor pode potencialmente penetrar na rede e tentar acessar recursos e dados importantes a partir dela.”
Que função o código aberto desempenhou nessa vulnerabilidade e quais são as principais considerações de segurança para organizações que usam ferramentas como o log4j?
“Como o log4j é uma biblioteca de código aberto muito popular, o número de aplicativos vulneráveis certamente foi maior. Em geral, qualquer software pode ser vulnerável a ataques, e o software de código aberto popular geralmente possui um grande ecossistema que procura e corrige ameaças à segurança. Mesmo que o software de código aberto ganhe a maioria das manchetes quando as principais vulnerabilidades são encontradas, isso não significa que seja proporcionalmente menos seguro (na verdade, é provavelmente muito mais seguro do que o código proprietário ou bibliotecas menos populares). A distribuição generalizada apenas aumenta a probabilidade de que vulnerabilidades sejam encontradas, não necessariamente a probabilidade de que elas existam.
Ao procurar bibliotecas de código aberto, as empresas devem escolher projetos grandes, respeitáveis e bem mantidos, como o log4j, pelos motivos acima. É claro que ainda pode haver vulnerabilidades, mas é mais provável que a comunidade encontre e corrija essas vulnerabilidades e também verifique se o código está livre de bugs que poderiam causar vulnerabilidades em primeiro lugar, do que em projetos menores.
Mesmo para aqueles cujos aplicativos não são vulneráveis ao CVE-2021-44228 ou que não usam o log4j para registro, essa vulnerabilidade é definitivamente um alerta de que a injeção de log é um método potencial que os invasores podem usar. Vale a pena verificar se todas as entradas do usuário registradas são devidamente higienizadas em cada aplicativo, independentemente do sistema de registro ou mesmo da linguagem de programação usada. Enquanto outras formas de injeção são muito mais comuns e são o foco de interesse, a injeção de log ainda é uma forma de ataque de injeção e, portanto, se enquadra nas 10 principais vulnerabilidades do OWASP.”
Como as empresas podem identificar essa vulnerabilidade em sua tecnologia e quais são os riscos se ela não for corrigida?
“Primeiro você precisa verificar se uma versão do log4j anterior a 2.15.0 é usada, também nas dependências. Tanto o Maven quanto o Gradle - ferramentas de gerenciamento de compilação baseadas em Java - fornecem a capacidade de imprimir toda a árvore de dependências de um projeto. Desta forma, pode ser determinado se uma versão vulnerável do log4j está sendo usada ou não. Mesmo com a versão 2.15.0 ou posterior, certifique-se de que a propriedade do sistema formatMsgNoLookups não esteja definida como 'true'. A única razão pela qual esta versão não é vulnerável é que ela definiu o valor padrão de true para false.
Em algumas versões do log4j, essa propriedade pode ser facilmente definida como falsa manualmente para atenuar a vulnerabilidade. Se o aplicativo não requer LDAP como parte de seu uso legítimo, também é possível bloquear todo o tráfego LDAP com um firewall ou filtro de aplicativo da Web para evitar que o código remoto seja alcançado caso a vulnerabilidade seja explorada. No entanto, eles apenas verificam se o log4j é capaz de explorar essa vulnerabilidade RCE ou não. Se um sistema é ou não verdadeiramente vulnerável a um ataque é uma questão muito mais complicada sem um único teste como vulnerabilidades como o HeartBleed.
Para explorar essa vulnerabilidade, um invasor precisa executar um ataque de injeção de log. Localizá-los é um processo muito mais complexo, mas basicamente qualquer local onde a entrada de um usuário (ou invasor em potencial) é registrada pode ser vulnerável a esse ataque. Portanto, para testar um RCE real, seria necessário tentar encontrar uma maneira de fazer uma solicitação JNDI LDAP nos logs do próprio contexto do usuário (por exemplo, por meio do site ou da API, se o aplicativo potencialmente afetado for um aplicativo da web).
Como essa vulnerabilidade permite a execução remota de código, os riscos em caso de vulnerabilidade são bastante altos. Um invasor pode potencialmente penetrar na rede e tentar acessar recursos e dados importantes a partir dela.”
Mais em Barracuda.com
Lothar Haensler, COO da Radar Cyber Security
Lothar Hänsler, COO da Radar Cyber Security: "A vulnerabilidade é relativamente fácil de explorar, os ataques podem ser facilmente ocultados." (Imagem: Radar Cyber Security).
o que aconteceu de qualquer maneira
“No fim de semana passado, uma vulnerabilidade no módulo log4j2 do Apache.org foi descoberta e rapidamente atribuída a uma pontuação CVSS de 10, o nível de criticidade mais alto. Autoridades como o Escritório Federal de Segurança da Informação (BSI) rapidamente elevaram sua avaliação de risco, que inicialmente era laranja, para vermelho”.
O que torna essa vulnerabilidade tão especial?
“As vulnerabilidades são relativamente fáceis de explorar, os ataques podem ser facilmente obscurecidos (ofuscação). Além disso, as medidas defensivas não são fáceis de implementar. Uma das razões para isso é que todas as estratégias de mitigação podem ter riscos e efeitos colaterais nos aplicativos afetados pela vulnerabilidade. No entanto, as avaliações nos grupos de especialistas são muito dinâmicas, resultando em diferentes perspectivas sobre as estratégias de mitigação.”
O que exatamente o Radar Cyber Security fez?
“No fim de semana, primeiro analisamos a situação dos dados com uma resposta ao incidente, estimamos o impacto, usamos várias fontes de informação de plataformas internacionais, como Computer Emergency Response Teams (CERTs), e projetamos uma estratégia para lidar com essa ameaça. Por fim, na manhã de segunda-feira, enviamos um aviso de segurança a todos os nossos clientes. Nosso Centro de Defesa Cibernética (CDC) foi definido para o modo de alerta máximo.
Agora dá atenção especial à ocorrência da vulnerabilidade no módulo log4j2, sem descuidar da postura geral de segurança. Atualizamos os módulos de detecção para verificar e relatar explorações dessa vulnerabilidade para nossos clientes. Isso varia de gerenciamento de vulnerabilidade a serviços SIEM clássicos e ferramentas de análise de rede individuais. Ao mesmo tempo, iniciamos uma análise de nossos próprios sistemas. Após a primeira varredura em um primeiro cliente, dois incidentes críticos foram identificados em um período muito curto. Outros serviços especiais analisam se os clientes são especificamente afetados por essa vulnerabilidade. Em casos extremos, os sistemas podem precisar ser desligados.”
Mais em RadarCS.com
Paul Smith, diretor de serviços profissionais da ForeNova
Paul Smit, diretor de serviços profissionais da ForeNova: "A vulnerabilidade de dia zero no log4j é extremamente perigosa porque pode ser explorada diretamente sem recarregar explicitamente o código malicioso." (Imagem: ForeNova).
“A vulnerabilidade de dia zero na biblioteca Java log4j amplamente usada é extremamente perigosa porque a vulnerabilidade pode ser explorada diretamente sem recarregar explicitamente o código malicioso. No entanto, se isso acontecerá imediatamente ou não, só poderá ser visto quando for tarde demais. Um endpoint pode estar comprometido, mas ainda não à vista dos hackers. No momento, está se tornando aparente a necessidade de pequenas e médias empresas pensarem na detecção e resposta de rede e na detecção e resposta de endpoint como uma estratégia de defesa abrangente. O EDR verifica se o malware foi instalado e organiza a defesa no endpoint.
Veja o passado com NDR
Com o NDR, você também pode ver nos dados de registro retrospectivamente quais sistemas os hackers tentaram acessar de fora. O NDR também vê o tráfego típico resultante dessa tentativa de acesso, como comunicação com os servidores C2C, verificação de porta e tráfego específico. O NDR também permite o bloqueio e segmentação de redes ou a quarentena de sistemas – medida que deve ser tomada em caso de dúvida. Uma solução NDR como NovaComand também analisa dados de telemetria de terminais. O NovaCommand lançou um patch e atualizou as regras para detectar esse tipo de ataque. O NovaCommand também aciona outras soluções de terceiros para bloquear e segmentar sistemas afetados e seções de rede.”
Mais em ForeNova.com
Artigos relacionados ao tema