Avançar para o conteúdo principal
BlogSegurançaLinode Security Digest 19-26 de Dezembro, 2021

Linode Security Digest 19-26 de dezembro de 2021

Linode Security Digest

Esta semana, falaremos sobre a evolução das vulnerabilidades de Log4j2 e algumas medidas de mitigação úteis que pode utilizar para se proteger contra elas. 

A Evolução da Vulnerabilidade

As vulnerabilidades de "Log4Shell" começaram com a descoberta de uma vulnerabilidade crítica de execução de código remoto na forma como o Log4j2 lidava com as pesquisas enquanto registava os eventos nos sistemas afectados. Esta vulnerabilidade crítica(CVE-2021-44228) teve uma pontuação de 10 em 10 no CVSS. Apache declarou que as versões Log4j 1.x eram menos susceptíveis de serem vulneráveis a esta descoberta uma vez que a JNDI teria de ser deliberadamente activada. Apache lançou a versão 2.15.0 para abordar esta vulnerabilidade.

Após Apache ter lançado métodos de mitigação para utilizadores que não conseguiram actualizar Log4j2 para a versão 2.15.0, outra vulnerabilidade foi descoberta graças à atenção que este projecto de código aberto recebeu por estar aos olhos do público. Esta vulnerabilidade(CVE-2021-45046) foi inicialmente uma vulnerabilidade DOS que teve uma pontuação de 3,7 em 10, mas mais tarde foi também declarada uma vulnerabilidade crítica de execução de código, e a pontuação foi aumentada para 9 em 10 no CVSS. Apache declarou que as versões 1.x não eram vulneráveis e recomendou aos utilizadores de Log4j2 que actualizassem para a versão 2.16.0 para abordar esta segunda questão. O método de remoção da classe JNDI Lookup foi recomendado para utilizadores que não conseguiam actualizar.

Depois veio a terceira vulnerabilidade. Embora (a partir de 22 de Dezembro) não haja qualquer menção à execução de código remoto na página de segurança do Log4j2 versão 2.16.0, esta vulnerabilidade(CVE-2021-45105) foi pontuada 7.5 em 10 no CVSS, e só poderia causar um ataque de negação de serviço em sistemas vulneráveis. Apache lançou a versão 2.17.0 e recomendou aos seus utilizadores a actualização para resolver o problema. Também partilharam novas medidas de mitigação para os utilizadores que não podem actualizar.

É importante notar que estas vulnerabilidades estavam a ser exploradas ou a ser tentadas durante as fases de descoberta e mitigação. De acordo com o 360 Netlab Blog, múltiplas famílias de malware tentaram propagar-se utilizando estas vulnerabilidades. Actores maliciosos que exploraram com sucesso a vulnerabilidade foram vistos a implantar mineiros de moedas e a instalar resgates. Estes relatórios sublinham a importância de mitigar estas vulnerabilidades o mais rapidamente possível.

Métodos Oficiais de Mitigação

De acordo com a página de segurança do Log4j2, a actualização da componente para 2,17 atenua as três questões de segurança conhecidas. Para as pessoas que não podem actualizar o seu Log4j2, Apache recomendou a remoção da classe JNDI Lookup do seu vulnerável ficheiro log4j2-core-*.jar. Contudo, isto não é suficiente para mitigar a vulnerabilidade de Negação de Serviço descoberta mais recentemente(CVE-2021-45105). Pode-se mitigar esta vulnerabilidade do DOS alterando o PatternLayout na configuração de registo. Pode ler Apache's Log4j2 security page linked at the beginning of this paragraph to find out about the details of these mitigation methods.

Encontrar Componentes Vulneráveis

Se estiver a procurar componentes vulneráveis, pode usar as Log4j-Tools feitas por jfrog. As ferramentas neste repositório são úteis quando procura por chamadas vulneráveis de Log4j JNDI Lookup numa base de código onde não tem a certeza se um pedaço de código chama Log4j para funcionar. Pode também ajudá-lo a determinar o estado de vulnerabilidade dos ficheiros locais. Pode também verificar as regras de utilização e exploração de Log4j pelos Cisco CX Security Labs para verificar os seus ficheiros locais com regras YARA para determinar se um ficheiro contém as classes Java vulneráveis; embora este método possa fornecer resultados mais rápidos, pode resultar em mais falsos positivos; no entanto, estas regras podem ajudá-lo a localizar também os componentes dependentes de Log4j. 

O repositório Log4Shell Hashes da mubix contém hashes MD5, SHA1, e SHA256 dos ficheiros log4j2-core vulneráveis à vulnerabilidade RCE crítica inicial(CVE-2021-44228). Finalmente, pode consultar a base de dados de software vulnerável da CISA (aplicável apenas ao CVE-2021-44228) para uma lista completa de software vulnerável por fornecedor.

Proteger contra ataques

Se não conseguir actualizar a sua instalação Log4j2 e se estiver a utilizar Fail2Ban no seu servidor, Fail2Ban regex contra Log4Shell por Jay Gooby pode ajudá-lo a bloquear as tentativas de Log4Shell. Se estiver a utilizar o CloudFlare, pode utilizar as suas regras WAF para se proteger contra estes ataques. No entanto, de acordo com o conselho da CISA, é encorajado a actualizar para Log4j 2.17.0 ou aplicar imediatamente as atenuações recomendadas. É também importante consultar as declarações do fornecedor sobre outros softwares que utilizam Log4j2, uma vez que alguns softwares podem vir com uma versão vulnerável do Log4j que pode precisar de atenção.

Encontrar COI & Digitalização

Se procura indicadores de compromisso nos seus registos, poderá ser difícil determinar se houve tentativas de explorar esta vulnerabilidade, principalmente porque há muitas cargas úteis diferentes que podem ser enviadas para explorar o conhecido vector de ataque JNDI. Um atacante pode codificar as cordas na carga útil, ofuscá-las ou torná-las difíceis de apanhar quando procura cargas úteis simples. É aqui que Log4Shell-Rex por back2root pode vir a ser útil. Log4Shell-Rex é uma expressão regular criada para combinar possíveis cargas úteis maliciosas codificadas com diferentes métodos. Pode utilizá-la nos seus ficheiros de registo locais ou utilizá-la no seu SIEM para fazer corresponder os resultados. No entanto, é de notar que a pesquisa com este regex (com qualquer regex para esse fim) pode gerar falsos positivos ou falsos negativos.

Também pode verificar a ferramenta Log4j-scan por FullHunt que pode ajudar a descobrir e a detectar a vulnerabilidade do RCE(CVE-2021-44228), também pode usar esta ferramenta para testar os desvios do WAF para obter resultados de varrimento mais abrangentes.

Esperamos ajudar os nossos clientes através da partilha de informações úteis nestes digestores de segurança. Como sempre, sinta-se à vontade para partilhar os seus pensamentos, deixando um comentário abaixo.


Comentários

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *