0
0
A vulnerabilidade generalizada que apareceu pela primeira vez no Apache Log4j em 2021 continuará a ser explorada , potencialmente até de maneiras piores do que vimos até agora. O aspecto mais preocupante dessas ameaças é que há uma boa chance de continuarem a ser exploradas meses ou anos no futuro.
O conselho de revisão de segurança cibernética do Departamento de Segurança Interna estreou em 2021 e, em 2022, divulgou seu relatório de segurança inaugural(PDF). Nele, o conselho chamou o Log4j de “vulnerabilidade endêmica”, principalmente porque não há uma “lista de clientes” abrangente para o Log4j, tornando o acompanhamento das vulnerabilidades uma tarefa quase impossível. Um departamento do gabinete federal gastou 33.000 horas em sua resposta Log4j.
E muitas organizações e soluções de segurança no mercado não conseguem identificar a diferença entre capacidade de exploração e vulnerabilidade, deixando uma oportunidade para os invasores realizarem atividades maliciosas.
Explorabilidade vs. Vulnerabilidade
Um dos principais problemas com segurança cibernética hoje é entender a diferença entre vulnerabilidades e sua gravidade. Quando se trata de medir a capacidade de exploração versus uma vulnerabilidade, há uma grande diferença entre se uma ameaça à segurança é explorável em sua empresa ou se é apenas “vulnerável” e não pode prejudicar os negócios ou atingir um ativo crítico. As equipes de segurança gastam muito tempo sem entender a diferença entre os dois e corrigem cada vulnerabilidade conforme ela aparece, em vez de priorizar aquelas que podem ser exploradas.
Cada empresa tem milhares de vulnerabilidades e exposições comuns (CVEs), muitas das quais pontuam alto no Common Vulnerability Scoring System (CVSS), por isso é impossível corrigir todas elas. Para combater isso, a esperança é que as ferramentas de gerenciamento de vulnerabilidades baseadas em risco (RBVM) tornem a priorização mais fácil, esclarecendo o que é explorável .
No entanto, as abordagens de priorização de segurança que combinam pontuações CVSS com informações sobre ameaças RBVM não fornecem resultados ideais. Mesmo depois de filtrar e olhar apenas para o que é explorável, as equipes de segurança ainda têm muito o que lidar porque a lista é longa e incontrolável. E só porque um CVE não tem um exploit hoje não significa que não terá um na próxima semana.
Em resposta, as empresas têm adicionado IA preditiva de risco, que pode ajudar os usuários a entender se um CVE pode ser explorado no futuro. Isso ainda não é suficiente e leva a muitos problemas para corrigir. Milhares de vulnerabilidades ainda mostrarão ter uma exploração, mas muitas terão outros conjuntos de condições que devem ser atendidas para realmente explorar o problema.
Por exemplo, com Log4j, os seguintes parâmetros precisam ser identificados:
- A biblioteca Log4j vulnerável existe?
- Ele é carregado por um aplicativo Java em execução?
- A pesquisa JNDI está habilitada?
- O Java está ouvindo conexões remotas e há uma conexão para outras máquinas?
Se as condições e parâmetros não forem atendidos, a vulnerabilidade não é crítica e não deve ser priorizada. E mesmo que uma vulnerabilidade possa ser explorada em uma máquina, e daí? Essa máquina é extremamente crítica ou talvez não esteja conectada a nenhum ativo crítico ou sensível?
Também é possível que a máquina não seja importante, mas pode permitir que um invasor continue em direção a ativos críticos de maneiras mais furtivas. Em outras palavras, o contexto é fundamental — essa vulnerabilidade está em um caminho de ataque potencial ao ativo crítico? É suficiente cortar uma vulnerabilidade em um ponto de estrangulamento (uma interseção de vários caminhos de ataque) para impedir que o caminho de ataque atinja um ativo crítico?
As equipes de segurança odeiam os processos de vulnerabilidade e suas soluções, porque há cada vez mais vulnerabilidades – ninguém pode limpar totalmente a lousa. Mas se eles puderem se concentrar no que pode causar danos a um ativo crítico , eles poderão entender melhor por onde começar.
Combatendo as vulnerabilidades do Log4j
A boa notícia é que o gerenciamento adequado de vulnerabilidades pode ajudar a reduzir e corrigir a exposição a ataques centrados no Log4j, identificando onde existe o risco de potencial exploração.
O gerenciamento de vulnerabilidades é um aspecto importante da segurança cibernética e é necessário para garantir a segurança e a integridade dos sistemas e dados. No entanto, não é um processo perfeito e as vulnerabilidades ainda podem estar presentes nos sistemas, apesar dos melhores esforços para identificá-las e mitigá-las. É importante revisar e atualizar regularmente os processos e estratégias de gerenciamento de vulnerabilidades para garantir que sejam eficazes e que as vulnerabilidades sejam abordadas em tempo hábil.
O foco do gerenciamento de vulnerabilidades não deve estar apenas nas próprias vulnerabilidades, mas também no risco potencial de exploração. É importante identificar os pontos onde um invasor pode ter obtido acesso à rede, bem como os caminhos que ele pode seguir para comprometer ativos críticos. A maneira mais eficiente e econômica de mitigar os riscos de uma vulnerabilidade específica é identificar as conexões entre vulnerabilidades, configurações incorretas e comportamento do usuário que podem ser exploradas por um invasor e abordar proativamente esses problemas antes que a vulnerabilidade seja explorada. Isso pode ajudar a interromper o ataque e evitar danos ao sistema.
Você também deve fazer o seguinte:
- Patch: Identifique todos os seus produtos vulneráveis ao Log4j. Isso pode ser feito manualmente ou usando scanners de código aberto. Se um patch relevante for lançado para um de seus produtos vulneráveis, corrija o sistema o mais rápido possível.
- Solução alternativa: nas versões Log4j 2.10.0 e superiores, na linha Java CMD, defina o seguinte: log4j2.formatMsgNoLookups=true
- Bloquear: Se possível, adicione uma regra ao firewall do aplicativo Web para bloquear: “jndi:”
A segurança perfeita é uma façanha inalcançável, portanto não faz sentido tornar o perfeito inimigo do bom. Em vez disso, concentre-se em priorizar e bloquear possíveis caminhos de ataque que melhoram continuamente a postura de segurança. Identificar e ser realista sobre o que realmente é vulnerável versus o que é explorável pode ajudar a fazer isso, pois permitirá a capacidade de canalizar recursos estrategicamente para áreas críticas que mais importam.
FONTE: DARK READING