O relatório de bugs, dezembro de 2021

Por Philippe Laulheret · 19 de janeiro de 2022

Seu alívio cômico na segurança cibernética

Por que estou aqui?

Se você está lendo estas palavras, PARABÉNS! Você chegou vivo a 2022! E mais, você caiu bem no resumo mensal de segurança ATR, onde tratamos de suas vulnerabilidades favoritas dos últimos 30 dias. Pode dar uns tapinhas nas próprias costas, pegar um cafezinho, um chá, uma LaCroix (você escolhe!) ou, se quiser partir logo para a violência, avance direto na bebida energética. Agora que estamos todos bem à vontade e cheios de energia, vamos começar!

Travessia de caminho Grafana: CVE-2021-43798

O que é isso?

De acordo com a entrada na Wikipédia, o Grafana é um aplicativo Web multiplataforma e de código aberto para análise e visualização interativa, amplamente utilizado no setor, com clientes pagantes como Bloomberg, eBay, PayPal, etc. No início de dezembro, foi revelado que uma vulnerabilidade de travessia de caminho permitia a um invasor acessar arquivos locais devido a uma limpeza inadequada de “../../../” em seu caminho de plug-ins. Isso nos levou a uma das sequências de divulgações mais rápidas da história da humanidade:

Que liga para isso?

Tá bom, não vamos culpar você por não ter ouvido falar de qualquer vulnerabilidade além da Log4Shell nos últimos 30 dias. Mas, se sua organização usa esse software, você deveria ter acompanhado essa divulgação no mês passado. Do contrário, a Internet inteira já deve conhecer de cor seus arquivos “/etc/passwd”. Além disso, há dois pontos interessantes para você considerar enquanto agita sua gemada alcoólica no copo (queixas fora de contexto sobre a repugnância das gemadas alcoólicas removidas pelo editor). Considerando-se a facilidade de exploração, o mero fato de o fornecedor ter corrigido o bug pelo GitHub público parece ter sido suficiente para atrair a atenção para o caso, resultando em POCs públicas e funcionais para a vulnerabilidade menos de três dias depois da correção. Caso você esteja curioso sobre como bases de código aberto mais maduras lidam com esse risco, projetos como o Chromium dependem de uma infraestrutura separada de rastreamento de bugs que pode restringir quem acessa os relatórios de bugs (que explicarão os riscos de segurança e casos de teste), combinada com mensagens de commits (envios) públicos com frases simples destinadas a evitar atrair a atenção para os commits de segurança.

Outro detalhe interessante: a causa raiz do bug é o uso indevido de uma API Go para limpar caminhos, conforme visto nesta discussão no Twitter. Acontece que a função filepath.Clean usada para limpar a entrada processada pelo código vulnerável só remove o “../../” excedente se o caminho for absoluto. Esse é um caso comum de uma API que se comporta conforme o esperado, mas leva a consequências perigosas. Você pode afirmar com certeza que a base de código da sua organização está livre de problemas assim? O impacto de vulnerabilidades que não tenham recebido patches aqui pode ser o acesso a ou o vazamento de dados extremamente confidenciais. *aqui as reflexões se tornam frenéticas*

O que posso fazer?

Obviamente atualize o software se você o estiver usando, e use também as regras Sigma para detectar tentativas de ataque. Em um mundo ideal, sua plataforma de análise não deveria estar amplamente exposta na Internet, ao contrário destas 87 mil instâncias, das quais 16 mil continuam vulneráveis, de acordo com o Shodan. Pelo menos certifique-se de que sua instância do Grafana esteja protegida por um prompt .htaccess ou algo parecido. Do ponto de vista do desenvolvimento, testes de segurança e testes de unidades devem ser utilizados para garantir que a filtragem que você emprega esteja funcionando da maneira que deveria. E no grande esquema das coisas, se você vai processar entrada não confiável de usuários, não facilite na filtragem e aplique padrões de código devidamente auditados em vez de desativar os avisos da sua ferramenta de segurança...

O padrão de ouro

“Será que o andarilho escolhe o caminho, ou o caminho escolhe o andarilho?”, questionaria Garth Nix em seu romance “Sabriel”. Uma coisa é certa: o caminho descrito acima não será “percorrido” ou transposto por um atacante para clientes do Network Security Platform (NSP). Esses sortudos já estão protegidos contra ataques transversais de caminho por meio de uma regra genérica e podem até obter proteção extra com a criação de regras de “ataque personalizado”.

CVE-2021-44228: Log4Shell

O que é isso?

Quem poderia imaginar que analisar (e às vezes até executar) entrada não confiável fosse uma má ideia™? Bem, acontece que o código de registro Log4j do Apache faz exatamente isso, e se a sequência registrada contiver os caracteres mágicos $(jndi:..), pode até buscar e executar código Java não confiável. Iterações sobre esse ataque também destacaram a possibilidade de vazamento de segredos locais armazenados em variáveis de ambiente, como chaves AWS, e dada a recursividade do processamento, também há muitas maneiras de se evitar a detecção da correspondência de padrões.

Que liga para isso?

Basicamente, todo mundo. Você programa em Java e curte registrar coisas? Então, sim, é melhor se inteirar dessa história. Você usa aplicativos/servlets baseados em Java? Bom, então tem algum registro de entrada não confiável de usuários aí. Seu patrão corporativo usa appliances ou serviços baseados em Java? Dê uma ajudinha aos seus camaradas do centro SOC e da TI que devem estar curtindo muito a “folga” de fim de ano. Você já entendeu, é um problema que afeta o setor inteiro, e é muito provável que seus efeitos sigam ecoando por anos. Para piorar as coisas, o bug é bem fácil de explorar. De testadores de penetração a analistas do centro SOC, de jovens criadores de scripts até nações inteiras, quase todo mundo já começou a explorar esse vetor de ataque. Observamos ataques imensos em andamento com uma vasta gama de cargas, que variam de criptomineradores a “rm -rf /*” e até mesmo uma tentativa fracassada de espalhar o worm Mirai. O pior ainda está por vir.

O que posso fazer?

“Stranger Things” nos ensinou que “não dá para escrever América sem Érica”. Da mesma forma, não para escrever “Apache” sem “Patch”. Quer dizer, mais ou menos. Faça um upgrade! Aplique um micropatch. Monitore o tráfego. Dica: se o seu aplicativo exclusivamente interno subitamente fizer solicitações LDAP a um servidor remoto em um país no qual você não opera, talvez algo suspeito esteja acontecendo...

Se você gosta de caos e/ou está tendo dificuldade em convencer a TI da importância desse bug, consiga permissão para fazer uma demonstração! Depois, defina sequências de caracteres que você pode controlar (agente de usuário, nome do twitter, SSID do Wi-Fi...) com o valor mágico $(jndi:ldap...) e faça-o apontar para uma IP:Port que você controla (ou um serviço de terceiros como Canarytoken, caso confie neles). Se você detectar batidas nesse endereço, pode começar a ter uma conversa divertida sobre a necessidade de um upgrade na pilha de tecnologia deles com os proprietários dos endereços de entrada. É por isso que pedir permissão primeiro é extremamente importante. Se você colocar indiscriminadamente a sequência de caracteres mágica por toda parte para ver o que acontece (como você já deve ter visto em várias plataformas de mídia social), provavelmente alguém vai entrar em contato com você para ter uma conversa e perguntar sobre esse seu agente de usuário malandrinho. Obviamente, antes de fazer um truque desses, lembre-se de que a última coisa que você vai querer ganhar de Natal é uma queixa baseada na lei CFAA contra fraude e abuso digitais fincada na sua porta.

O padrão de ouro

Os clientes da Trellix estão protegidos sob muitos ângulos diferentes (para saber de detalhes específicos, acesse este artigo da base de conhecimentos):

• As regras de especialistas no Endpoint Security (ENS) podem detectar padrões perigosos na memória, conforme descrito neste blog.
• Endpoint Security (ENS), VirusScan Enterprise (VSE) e Web Gateway (WG) podem fornecer detecção genérica sob a Exploit-CVE-2021-44228.C através de uma detecção de “software potencialmente indesejado”. Essa detecção é ampliada por uma lista de hashes de amostras relacionadas a campanhas em curso que exploram essa vulnerabilidade.
• A Network Security Platform (NSP) também pode detectar o ataque através de assinatura definida pelo usuário (fornecida no artigo do centro de conhecimento vinculado anteriormente)
• Endpoint Detection and Response (EDR) e Active Response (AR) também podem ser usados para procurar sistemas vulneráveis com consultas Real-Time Search (RTS)
• O SIEM recebeu uma atualização (a versão 4.1.0 do pacote de conteúdo de exploração) que emitirá um alarme em caso de possíveis tentativas de exploração. O Insights também está fornecendo informações valiosas sob a campanha de ameaça “Log4Shell: uma vulnerabilidade Log4j, CVE-2021-44228”. Consulte Prévia do Insights.

CVE-2021-43527: Big Sig

O que é isso?

Big Sig pode parecer um apelido que a mãe de Freud deu a ele. E o bug é igualmente implacável. No início de dezembro, o Google Project Zero blogou sobre uma vulnerabilidade que encontrou nos serviços de segurança de rede (NSS, Network Security Services) da Mozilla, com uma pontuação CVSS de 9,8, de acordo com a página do banco de dados nacional de vulnerabilidades do NIST. Há um estouro de heap no processamento de certas assinaturas (assinaturas RSA-PSS e DSA codificadas por DER). Simplificando, os NSS são uma coleção de bibliotecas criptográficas que permitem aos desenvolvedores usar implementações mais seguras/fortemente testadas de primitivas e padrões criptográficos (para criptografia de comunicações, verificação da autenticidade dos dados e assim por diante). O recurso onde o bug foi encontrado é responsável pela verificação de assinaturas que comprovam a autenticidade dos dados usando vários esquemas públicos de criptografia. Esse tipo de função normalmente é usado para assinar e-mails ou documentos para confirmar seus autores reais. Algo realmente interessante sobre esse bug é sua relativa simplicidade, mas também sua longa existência; de acordo com o blog do Project Zero, o bug era explorável desde 2012. Simplesmente calhou de o caminho de código vulnerável cair entre as rachaduras onde vários fuzzers usados pela Mozilla se sobrepõem.

Que liga para isso?

Se você prefere que suas assinaturas sejam verificadas e depende da biblioteca NSS para fazer isso, então você definitivamente deveria dar uma olhada no aviso e usar a versão mais recente do software (NSS versão 3.73/3.681 ESR ou posterior). Parece que o Firefox não é afetado, mas qualquer outro software que analise assinaturas pode ser afetado, incluindo Thunderbird, LibreOffice, Evolution, Evince e outros.

O que posso fazer?

Como sempre, certifique-se de que todo o software que você usa e que possa ser vulnerável esteja atualizado com sua versão mais recente. O patch foi lançado em 1º de dezembro. Então, para começar, certifique-se de que software potencialmente vulnerável tenha recebido uma atualização após essa data. Também ajudaria saber qual software depende dessa biblioteca. Embora não exista bala de prata, referências a arquivos como nss3.dll no Windows ou libnss3.so no Linux são bons pontos de partida. Além disso, a melhor opção é dar uma olhada nas notas de versão e na lista de possíveis bibliotecas de terceiros usadas nos aplicativos que você usa. Se você usar a biblioteca vulnerável em seu próprio produto, atualize o código ou adapte o patch.

O padrão de ouro

Você já conferiu nossos boletins? Eles são uma ótima fonte de informação para as vulnerabilidades críticas que você pode ter perdido! Isso pode incluir aplicativos que distribuirão correções para a CVE-2021-43527.