Ferramenta Google se junta a ferocious Hunt for Log4j Bug
Serviço “fuzzing” atualizado agora investigando a vulnerabilidade mais recente (e maior?) Da Internet
Um grande bug em um software de código aberto amplamente usado chamado Log4j jogou o mundo da TI em um pandemônio. O buraco nem mesmo foi divulgado há um mês (no momento da redação deste artigo) e, no entanto, já foi classificado por analistas de segurança da Internet como uma das maiores vulnerabilidades na história da segurança cibernética.
Por algumas estimativas , por exemplo, cerca de 93 por cento dos ambientes de computação em nuvem corporativa em todo o mundo são afetados. De acordo com fontes citadas no Financial Times , em 14 de dezembro, mais de 1,2 milhão de ataques cibernéticos (a uma taxa de até 100 ataques por minuto) foram observados - sem um fim provável à vista, de acordo com essas fontes em pelo menos, “meses que virão”.
Enquanto a indústria luta para preencher as lacunas, o Google atualizou uma de suas ferramentas de segurança para ajudar os desenvolvedores de código aberto a descobrir a vulnerabilidade e outras semelhantes.
O pânico em torno desse novo bug, que foi apelidado de Log4Shell , deve-se principalmente à sua total disseminação. A ferramenta a que se destina é usada em um grande número de aplicações e a lista de serviços afetados é um quem é quem das principais empresas de tecnologia. A natureza da vulnerabilidade também torna relativamente simples para os invasores executarem um código que lhes permite assumir o controle total dos dispositivos visados.
“Fuzzing” bombardeia programas com entradas aleatórias para forçar erros que revelam vulnerabilidades de segurança. O Google agora atualizou sua ferramenta de difusão para rastrear Log4Shell - o nome da vulnerabilidade no onipresente código Log4j do Apache.
Quando o bug foi divulgado em 9 de dezembro, ele recebeu uma pontuação de gravidade de 10 em 10 pela Apache Software Foundation (ASF), a organização sem fins lucrativos cujos voluntários desenvolvem o Log4j. Embora a ASF tenha lançado patches que corrigem a falha, pode levar meses ou até anos para localizar e corrigir cada instância. O incidente reacendeu debates em torno de como dependente infraestrutura de computação crítica de hoje é em open source code, que normalmente é mantido por pequenas equipes de desenvolvedores com poucos recursos que trabalham de graça em seu tempo livre.
Embora não haja uma solução milagrosa, a equipe de segurança de código aberto do Google acredita que uma solução potencial é fornecer aos desenvolvedores de código aberto melhores ferramentas para procurar bugs. Uma abordagem promissora é chamada de “fuzzing”, que bombardeia programas com entradas aleatórias ou intencionalmente inválidas para forçar erros que revelam problemas de estabilidade ou vulnerabilidades de segurança. O Google forneceu um serviço gratuito de difusão contínua chamado OSS-Fuzz para os principais projetos de código aberto desde 2016. E agora a empresa colaborou com a empresa de segurança Code Intelligence para atualizar a ferramenta de modo que possa detectar Log4Shell e outras vulnerabilidades que dependem do mesmo modo de ataque.
“Estamos tentando expandir os recursos das ferramentas para encontrar tipos semelhantes de vulnerabilidades para que mais desenvolvedores possam proteger suas próprias bases de código”, disse Jonathan Metzman do Google . “O desenvolvedor realmente não precisa pensar sobre como o fuzzer os está detectando, apenas faz isso por eles”.
Dada a complexidade do software moderno, os desenvolvedores não têm tempo para construir todos os módulos do zero e, por isso, costumam confiar em componentes de software de código aberto como o Log4j. Como o software Java foi desenvolvido, o Log4j mantém registros de atividades nos aplicativos que podem ajudar a rastrear erros e problemas de desempenho. Por exemplo , clicar em um link morto ou digitar uma URL errada, o que normalmente produz uma mensagem de erro 404, estão entre as atividades que o Log4j controla para os administradores de sistema de um domínio da web. Log4j, portanto, desempenha uma função crítica para muitos tipos de software, que é a razão para a onipresença da ferramenta.
Construir uma solução é apenas o primeiro passo para colocar a crise sob controle; agora, os desenvolvedores e administradores de sistema em todo o setor precisam vasculhar seu código em busca de instâncias do bug.
Mas no mês passado, engenheiros da empresa de tecnologia chinesa Alibaba descobriram que poderiam fazer o Log4j registrar uma mensagem contendo uma sequência de código malicioso que aciona uma conexão com um servidor externo sob seu controle. Depois que essa conexão for estabelecida, o invasor pode executar remotamente qualquer código que quiser no sistema visado.
Os pesquisadores do Alibaba notificaram o ASF assim que encontraram o bug e deram-lhes tempo para criar uma atualização que lida com a vulnerabilidade antes de divulgá-la. Desde então, mais duas vulnerabilidades mais difíceis de explorar no Log4j também foram descobertas e corrigidas. Mas construir uma solução é apenas o primeiro passo para colocar a crise sob controle; agora, os desenvolvedores e administradores de sistema em todo o setor precisam vasculhar seu código em busca de instâncias do bug.
“A forma como o software é construído hoje é muito mais camada sobre camada sobre camada”, diz Gary Gregory, membro do comitê de gerenciamento de projetos ASF responsável pelo Log4j. “Assim, desenvolvedores, aplicativos e empresas podem nem mesmo perceber se estão ou não usando determinado software.”
Mesmo depois de encontrar o bug, algumas empresas têm processos rigorosos que regem como podem fazer atualizações, o que pode atrasar sua capacidade de resolver o problema, diz Gregory. Também é provável que existam empresas que dependem de softwares mais antigos que não têm mais suporte ou cujos fornecedores estão extintos.
E embora as atualizações feitas pelo ASF tenham removido completamente a funcionalidade que permite que a ferramenta Log4j se conecte a um servidor externo, Gregory aponta que é um recurso genérico embutido profundamente em Java. “Acabamos de arrancar isso”, diz ele. “Mas estou apostando que as pessoas vão olhar para outros programas de software para o mesmo tipo de vulnerabilidade.”
Essa funcionalidade é exatamente o que o fuzzer atualizado do Google procura, o que significa que, além de detectar o Log4shell, ele também deve ser capaz de encontrar outros bugs que usam o mesmo modo de ataque. A solução não é uma substituição para testes de segurança mais formais, mas o OSS-Fuzz já descobriu mais de 7.000 vulnerabilidades desde o seu lançamento.
Metzman diz que o grupo tem planos de expandir ainda mais os tipos de bugs que o OSS-Fuzz pode detectar e acredita que a abordagem pode ser uma ferramenta poderosa para equipes de código aberto com poucos recursos. “A aleatoriedade do fuzzing explora muitos estados do programa”, diz ele. “É muito bom alcançar esse tipo de estado obscuro que está profundamente envolvido no programa e encontrar vulnerabilidades lá.”
É difícil dizer se esse tipo de ferramenta pode ajudar a detectar a próxima grande vulnerabilidade, diz Metzman. Mas ele aponta que os pesquisadores mostraram que o fuzzing poderia ter detectado o bug Heartbleed que incendiou a Internet em 2014. Se quisermos detectar a próxima grande vulnerabilidade, porém, precisamos fornecer mais suporte para desenvolvedores de código aberto em todo o quadro, diz John Hammond, da empresa de segurança Huntress Labs. Sua empresa também lançou uma ferramenta para testar o Log4Shell após a divulgação, mas ele acredita que uma meta ainda mais importante é aumentar a educação e a conscientização sobre as questões de segurança na comunidade de código aberto. Com alguma sorte, esta crise fornecerá o ímpeto, diz ele.
“Talvez isso dê destaque ao fato de que precisamos um pouco mais de amor pela comunidade de código aberto”, acrescenta. "Porque muito do nosso mundo moderno e da tecnologia certamente depende deles."
é redator freelance de ciência e tecnologia baseado em Bangalore, Índia. Sua escrita se concentra em tecnologias emergentes em computação, engenharia, energia e biociência. Ele está no Twitter em @EddytheGent e e-mail em edd dot gent em outlook dot com. Sua impressão digital PGP é ABB8 6BB3 3E69 C4A7 EC91 611B 5C12 193D 5DFC C01B. Sua chave pública está aqui. DM para informações de sinal.
Comentários
Postar um comentário