O relatório de bugs, janeiro de 2022

Por Kevin McGrath · 2 de fevereiro de 2022

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

Por que estou aqui?

Ômicron é a 15ª letra do alfabeto grego, usada por Donald Knuth para descrever a notação O-grande, representava o zero no Almagesto de Ptolomeu e tinha o valor de 70 na prática da isopsefia. Mas, para a maioria de nós, ela simplesmente representa a pandemia que NÃO. ACABA. DE JEITO. NENHUM. Ah, você não está interessado nas divagações filosóficas sobre a palavra mais mencionada no mundo em 2022? Sério que você veio aqui para ler sobre vulnerabilidades? Mas, mas... Ah, esquece. Bem-vindo ao relatório de bugs de janeiro: a edição do surto!

• CVE-2022-0185: Porque os desenvolvedores Java não são os únicos que se esquecem de validar entradas!
• CVE-2021-42392: O quê? Você achou que a Log4shell ia sumir?
• CVE-2022-21907: Eu não me esqueci de você, meu worm querido.
• CVE-2021-4034: PwnKit, o que acontece quando você decide que o sudo não basta.

CVE-2022-21907: bug do HTTP.sys suscetível a worms

O que é isso?

Para o “Patch Tuesday” de janeiro de 2022, a Microsoft abriu o ano com uma vulnerabilidade suscetível a worms no driver de kernel HTTP.sys. É a segunda vulnerabilidade suscetível a worms encontrada no HTTP.sys em um período de sete meses. Isso é impressionante, considerando a maturidade do código desse driver. A CVE-2021-31166 não implodiu a Internet; espero que a 21907 também não faça isso! A 21907 usa a correção incompleta da 31166, aproveitando o suporte ao trailer HTTP (metadados no final de uma mensagem em pedaços). Não está claro se essa exploração depende da presença de um cabeçalho TRAILER no pedaço final ou não, a RFC denota isso como OPCIONAL. Isso é potencialmente um problema para os criadores de assinaturas de produtos de rede se eles não puderem confiar no cabeçalho TRAILER.

Curiosidade: As PoCs estão no GitHub para isso!

Outro fato divertido: estamos começando a ver essa exploração no mundo real! Se você gostaria de receber informações atualizadas sobre ameaças atuais, o McAfee Insights é algo que você definitivamente deve considerar!

Pode parecer lógico que apenas o IIS use o HTTP.sys, mas a situação não é bem assim. O HTTP.sys é o driver do kernel que fornece código básico de manuseio de HTTP. Outros subsistemas fazem uso deste código:

• ADFS
• WinRM
• Assistente de Suporte intel

Você pode ver quais serviços usam o driver com:

PS > netsh http show servicestate

Isso listará as filas de solicitação e URLs associadas a elas em execução no sistema atual.

Felizmente para aqueles que não se preocuparam em atualizar além do Server 2019 ou Windows 10 1809, você está seguro... a menos que tenha habilitado o suporte ao trailer no registro.

Que liga para isso?

2,4 milhões de usuários do Twitter. Qualquer um com IIS em execução em seu ambiente. Qualquer um que use Docusign (isso é muito relevante, considerando-se a quantidade de contratos assinados que fluem pela Docusign, especialmente durante a pandemia). De acordo com um relatório de mercado recente, aproximadamente 7% dos sites da Internet usam IIS. Nem a Microsoft não tem tantos sistemas voltados para a Internet, o que significa que há muitos sites além dos dela usando o IIS. Ah, e qualquer um que use versões vulneráveis por padrão do Windows:

• Windows 10 2004 e posteriores (tanto ARM quanto x64)
• Windows Server 20H2 e posteriores

O que posso fazer?

Aplique o patch! A Microsoft lançou um patch para essa vulnerabilidade junto com seu anúncio. Se isso não for possível, seria melhor remover esses sistemas de funções voltadas para a Internet. Infelizmente, não há mitigação baseada em host disponível para versões atuais do Windows.

Se estiver executando o Windows Server 1909 ou o Windows 10 1809, você não está vulnerável por padrão. Para determinar o status de vulnerabilidade, execute:

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Se um valor for retornado e for diferente de zero, seu sistema está vulnerável. Para minimizar o problema, execute:

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

Ou simplesmente exclua essa chave de registro.

O padrão de ouro

A boa notícia é que há um patch disponível. Aplique-o, por favor! Se não puder aplicar o patch por... sei lá qual motivo... não se preocupe. A Trellix te dá cobertura com assinaturas NSP (Network Security Platform) para essa vulnerabilidade. Portanto, certifique-se de ter pelo menos atualizado seu banco de dados de assinaturas!

CVE-2021-42392: o H2 quer entrar na onda da Log4Shell!

O que é isso?

Uma vulnerabilidade semelhante à Log4Shell no manuseio do carregamento de classe remota JNDI. Embora não se aproveite do bug presente no Log4j (o Log4j nem sequer é necessário), ela se aproveita da mesma tecnologia subjacente (JNDI). Qualquer URL controlada por atacante que consiga chegar ao banco de dados (mas você fez a limpeza de sua entrada... certo?) pode obter execução remota de código no contexto do RDBMS H2. Mas é claro que isso não vai acontecer com você porque todas as consultas contra o banco de dados passam por limpeza e são parametrizadas e armazenadas. É óbvio.

Que liga para isso?

Algumas estimativas apontam o uso do H2 em quase 7.000 projetos, incluindo o Log4j. Faz você se perguntar se o Log4j era mesmo o problema, não? Se o caso for esse, então talvez tenhamos que renomear a Log4Shell, já que até quem não usa o Log4j é afetado. A natureza sempre dá um jeito...

O que posso fazer?

As versões 1.1.100 a 2.0.204 do banco de dados H2 são impactadas. A versão 2.0.206, liberada em 5 de janeiro de 2022, corrige essa vulnerabilidade. Atualizar para pelo menos a versão 2.0.206 seria o ideal.

Você poderia trocar os mecanismos de banco de dados, mas essa parece uma solução extrema. Assim como na medicina, na TI também não é aconselhável curar uma doença matando o hospedeiro.

Você também pode parar de usar Java? Embora isso pareça o que dissemos acima, neste caso, pode ser justificado. Na verdade, essa é claramente a melhor solução. O lugar do Java não é nos servidores, mas sim na Indonésia (onde há uma ilha com esse nome).

O padrão de ouro

Se não der para aplicar patches, jogar fora todo o código Java e mudar para outra linguagem, ou trocar o mecanismo de banco de dados, a Trellix pode ajudar você. As explorações em si são muito parecidas com a Log4Shell.

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

• 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 McAfee Web Gateway (MWG) 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)
• O MVISION Endpoint Detection and Response (EDR) e o McAfee Active Response (MAR) também podem ser usados para procurar sistemas vulneráveis com consultas Real-Time Search (RTS)
• O McAfee SIEM recebeu uma atualização (a versão 4.1.0 do Exploit Content Pack) que emitirá um alarme em caso de possíveis tentativas de exploração.

CVE-2022-0185: Estouro negativo de namespace do kernel Linux...

O que é isso?

Superficialmente, a CVE-2022-0185 é um simples estouro negativo de inteiro em um caminho de código legado. Felizmente para quem usa contêineres, esse caminho de código legado está no File System Context (FSC). Embora o FSC tenha sido substituído pela File Context API (FCAPI), algumas funcionalidades foram mantidas para suporte a compatibilidade retroativa, incluindo o caminho vulnerável. O estouro negativo cria uma gravação ilimitada para um atacante no contexto do processo do contêiner em si. Um atacante com acesso a um contêiner pode aproveitar essa falha para atacar o host subjacente, ganhando acesso a todos os outros contêineres que rodam nesse nó. Dada a popularidade conquistada por ferramentas como kubernetes (k8s), isso é potencialmente preocupante para qualquer um que use contêineres para isolamento de processos na presença de usuários não confiáveis. Esse problema só afeta os contêineres que usam namespaces não privilegiados, contêineres que permitem o comando unshare ou contêineres com o privilégio CAP_SYS_ADMIN (desligado por padrão). O comando unshare é bloqueado por padrão nos contêineres Docker pelo filtro seccomp. Infelizmente para usuários do k8s, o filtro seccomp não está ligado por padrão, o que significa que qualquer cluster Kubernetes está em risco.

O passado é um garrote em torno do pescoço do progresso, estrangulando lentamente a vida de tudo o que é bom neste mundo. Em outras palavras, a compatibilidade retroativa é, muitas vezes, o motivo de não podermos ter coisas boas.

Que liga para isso?

Provavelmente, qualquer pessoa executando um contêiner. E até administradores que não executam, mas permitem que os usuários executem. Ou mesmo que usem um contêiner para armazenar sobras... Ok, aí já fomos longe demais. Qualquer pessoa que execute um contêiner em um servidor compartilhado deve estar muito preocupada com isso, potencialmente removendo qualquer coisa de missão crítica do servidor em questão até saber que o kernel subjacente foi atualizado.

Os autores escreveram uma postagem de blog detalhada e lançaram o código da PoC para essa vulnerabilidade. Então, neste momento, todos nós devemos nos importar, pois é questão de tempo até atores maliciosos usarem isso contra nós.

O que posso fazer?

Se você controlar o host, terá que atualizar o kernel. Se isso não for uma opção (ou se o proprietário se recusar), executar

# sysctl -w kernel.unprivileged_userns_clone = 0

limitará essa vulnerabilidade apenas àqueles contêineres com o privilégio CAP_SYS_ADMIN. Remover esse privilégio de seus contêineres também minimizará essa vulnerabilidade (ele está desligado por padrão).

A recomendação da Redhat para sistemas que não executam contêineres é simplesmente desativar completamente os namespaces:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

Isso também torna o host incapaz de executar contêineres. Se você não usa contêineres, isso provavelmente é uma boa ideia de qualquer maneira.

O padrão de ouro

No momento, corrigir ou aplicar minimizações são suas melhores opções. Uma vez que os contêineres são usados como um mecanismo de isolamento, um processo externo com visibilidade em um contêiner em execução é improvável. Certifique-se de executar um host corrigido com o patch ou habilite o filtro seccomp no k8s.

CVE-2021-4034: PwnKit

O que é isso?

A CVE-2021-4034, carinhosamente chamada de PwnKit, aproveita um bug lógico no PolKit (anteriormente conhecido como PolicyKit). PolKit é um kit de gerenciamento de políticas em todo o sistema que fornece a processos não privilegiados acesso (supostamente) seguro a processos privilegiados. O bug existe especificamente na ferramenta pkexec (porque, por alguma razão, o sudo não era suficiente, e sentimos a necessidade de outro programa setuid para fazer... precisamente a mesma coisa que o sudo): uma suposição é feita de que a variável argc seja pelo menos 1. Na invocação típica do programa, isso é obviamente verdade. Há maneiras... e quase todas são indícios de comprometimento e deveriam ser rejeitadas pelo tempo de execução, mas, ei, aqui estamos nós!

Normalmente, quando o pkexec é usado, uma janela pop-up aparece pedindo credenciais. Essa vulnerabilidade contorna essa verificação de credencial e simplesmente opera como root. Porque claramente, a maneira certa de lidar com o fracasso é entregar as chaves do castelo e dar uns tapinhas nas suas próprias costas!

Essa é a segunda vulnerabilidade do polkit em seis meses. A CVE-2021-3560 também contornou a verificação de credenciais usando o mecanismo dbus para invocar o polkit. Ambos parecem ter aproveitado a mesma falha raiz. Ainda nesse assunto, a causa raiz foi inicialmente relatada em 2013, mas o autor não viu um caminho direto para a exploração. E assim, o patch seguiu se arrastando esquecido pela sarjeta, esperando seu dia de brilhar. Foram nove longos anos, mas brilhe, doce patch! Aproveite seu momento ao sol!

Que liga para isso?

Seria difícil argumentar que este não é o maior bug de escalada de privilégios locais do ano passado (entendeu?). A vulnerabilidade funciona na maioria das principais distribuições Linux que executam binários desatualizados do polkit, então qualquer pessoa executando Linux não corrigido desde 25 de janeiro está vulnerável. Os números de versão do polkit são um pouco confusos, porque o Debian mantém sua própria bifurcação, mas se você estiver executando uma versão

• inferior a 0.105-26ubuntu1.2 no Ubuntu 20.04 (LTS),
• inferior a 0.105-31ubuntu0.1 no Ubuntu 21.10,
• inferior a 0.105-31+deb11u1 no Debian bullseye, ou
• inferior a polkit-0.115-11.el8_4.2 no RedHat Enterprise Linux (RHEL) 8.4 EUS

então você está vulnerável. Mais uma vez, você está vulnerável se não tiver aplicado patches desde 25 de janeiro. Também há código de PoC circulando, então não vai demorar para isso ser ativamente explorado.

Ah, você confia em todos os seus usuários? In that case, you have nothing to worry about. Compromised accounts are readily available. Seja através de phishing, cracking, contas comprometidas em outros lugares que compartilham as mesmas credenciais, ou alguma outra via de comprometimento de conta, confiar nos usuários não é uma indicação de que você deva confiar nas contas dos usuários.

Embora o bug tenha sido encontrado no Linux, outras distribuições UNIX usam o polkit, incluindo BSDs. O OpenBSD, pelo menos, sempre teve minimizações para isso: ele se recusa a executar um programa com um argc de 0. O Solaris também usa o polkit, mas a Oracle mantém tanto sigilo em torno do Solaris que até os boletins de segurança ficam por trás de um muro com entrada paga. Isso porque, obviamente, essa é a melhor maneira de fidelizar os clientes!

O que posso fazer?

Atualize! Há patches disponíveis para todos os principais fornecedores de Linux, e eles devem ser aplicados. Não é necessário reinicializar. Se optar por não aplicar patches, você pode remover o bit de setuid no pkexec:

# chmod 0755 /usr/bin/pkexec

Infelizmente, isso também vai impedir o pkexec de fazer o que foi projetado para fazer. Mas antes isso do que um comprometimento, certo?

A RedHat tem um guia de minimização específico para o RHEL em seu boletim de segurança.

O padrão de ouro

Como esse foi um lançamento coordenado de todas as distribuições Linux, ele realmente deve ser aplicado. Vale ressaltar que os pontos de origem anômalos de login devem ser registrados, sinalizados e possivelmente bloqueados sem alguma outra forma de autenticação. Você usa autenticação multifator, não usa? A autenticação multifator impediria ameaças não internas de explorar isso, pois elas não seriam capazes de acessar o sistema. Quanto às ameaças internas, bem, isso fica como um exercício para a mente do leitor.