Boletim semanal de cibersegurança 8-14 Janeiro

Boletim de Segurança da Microsoft

A Microsoft divulgou seu boletim de segurança de janeiro, onde corrigiu um total de 97 bugs entre os quais foram 6 vulnerabilidades de 0 day e 9 bugs classificados como críticos. Considerando o 0 day, nenhuma exploração ativa destes teria sido detectada, mas deve-se notar que várias têm provas públicas de conceito, por isso é provável que sua exploração ocorra no curto prazo. Em referência às falhas de segurança classificadas como críticas, o CVE-2022-21907 (CVSS 9.8) se destaca, o que afeta as versões mais recentes do Windows em suas versões desktop e servidor. Esta é uma vulnerabilidade na pilha de protocolos HTTP, a exploração da qual resultaria em execução remota de código e que foi rotulada como «wormable«. O outro bug a ser revisado é outra execução remota de código neste caso no Microsoft Office(CVE-2022-21840 CVSS 8.8), corrigido para versões do Windows, mas ainda não para dispositivos macOS. Como foi o caso dos 0 dias, de acordo com a Microsoft, nenhuma exploração foi detectada para essas duas vulnerabilidades.

Nova vulnerabilidade no JNDI no console de banco de dados H2

Os pesquisadores da JFrog descobriram uma vulnerabilidade crítica da execução remota de código não autenticado no console de banco de dados H2, que compartilha sua origem com a vulnerabilidade Log4Shell (carregamento remoto de classe JNDI) e que recebeu o identificador CVE-2021-42392. H2 é um banco de dados java SQL de código aberto muito popular amplamente utilizado em diferentes projetos. Apesar de ser uma vulnerabilidade crítica e recursos de compartilhamento com o Log4Shell, os pesquisadores indicam que seu impacto é menor por várias razões. Em primeiro lugar, essa falha tem um impacto direto, já que o servidor que processa a solicitação inicial é o mesmo que é afetado pela falha, por isso é mais fácil detectar os servidores vulneráveis. Em segundo lugar, a configuração padrão do H2 é segura, ao contrário do Log4Shell, onde as configurações padrão eram vulneráveis. E, finalmente, muitos fornecedores usam o banco de dados H2, mas não o console, então, embora existam vetores para explorar a falha além do console, esses outros vetores dependem do contexto e são menos propensos a serem expostos a ataques remotos. Embora essa nova falha seja atribuída menos risco do que o Log4Shell, os pesquisadores alertam que para todos aqueles que executam um console H2 exposto à LAN, a falha é crítica e eles devem atualizar para a versão 2.0.206 urgentemente. Além disso, a empresa compartilhou indicações aos administradores de rede para que eles possam verificar se estão vulneráveis a essa nova falha.

Cinco novas falhas de confusãona análise de URL

Pesquisadores da Team82 e Snyk publicaram um artigo de pesquisa no qual estudaram a fundo como diferentes bibliotecas analisam URLs, e como essas diferenças na maneira como as analisam podem ser exploradas por invasores; ou seja, analisaram falhas de confusão de análise de URL tipo. No total, eles analisaram 16 bibliotecas diferentes de análise de URL (Uniform Resource Locator) e detectaram cinco tipos de inconsistência presentes em algumas delas, que poderiam ser exploradas para causar condições de negação de serviço, exposição de informações ou mesmo, sob certas circunstâncias, execução remota de código. As cinco inconsistências observadas são: confusão de esquema, confusão de cortes, confusão de barras traseiras, confusão de dados codificada por URL e mixagem de esquemas). Além da identificação dessas inconsistências, apontam para a detecção de oito vulnerabilidades que afetam diretamente diferentes frameworks ou mesmo linguagens de programação e que já foram corrigidas, exceto em algumas versões não suportadas de Flask: Flask-security (Python, CVE-2021-23385), Flask-security-too (Python, CVE-2021-32618),Flask-User (Python, CVE-2021-23401),Flask-unchained (Python,  CVE-2021-23393), Belledonne’s SIP Stack (C, CVE-2021-33056), Vídeo.js (JavaScript, CVE-2021-23414), Nagios XI (PHP, CVE-2021-37352) e Clearance (Ruby, CVE-2021-23435). Em seu estudo, eles dão uma alta relevância para esse tipo de erros na análise de URLs usando o Log4Shell como exemplo para isso, uma vez que o bypass para a correção apache inicial da falha foi alcançado graças à presença de dois analisadores diferentes de URL dentro do processo de pesquisa JNDI, cada um dos quais analisados de uma forma.

MuddyWater: ligação com o Irã e aspectos técnicos

A Força Nacional Cibernética de Missões (CNMF) do comando de cibersegurança dos EUA publicou uma nota ligando a APT conhecida como MuddyWater com o Ministério de Inteligência e Segurança do Irã (MOIS) e detalha alguns aspectos técnicos que foram associados ao grupo. A MuddyWater foi identificada pela primeira vez em 2017, com metas localizadas principalmente nas regiões do Oriente Médio, Europa e América do Norte, e nos setores de telecomunicações, governo e indústria petrolífera. Em sua publicação, algumas ferramentas de código aberto usadas por este ator malicioso são identificadas, entre as quais estão variantes do PowGoop, amostras do backdoor mori ou DLLs de carregamento lateral para enganar programas legítimos para executar malware.

Vulnerabilidades de 0 day detectado em AWS CloudFormation e AWS Glue

Pesquisadores de segurança da Orca Security detectaram duas vulnerabilidades de 0 day em diferentes serviços da Amazon Web Services (AWS). A primeira das falhas foi no serviço AWS CloudFormation e consistia em uma vulnerabilidade XXE (Entidade Externa XML), que permitia aos agentes de ameaças divulgar arquivos confidenciais localizados na máquina de serviço vulnerável, bem como a divulgação de credenciais de serviços internos da infraestrutura AWS. A segunda vulnerabilidade descoberta afetou o serviço AWS Glue, que veio de um recurso explorável que permitiu obter as credenciais necessárias para acessar a API do serviço interno, podendo obter permissões de administrador. O porta-voz da AWS disse que os dados de qualquer cliente não foram afetados devido às vulnerabilidades de ambos os serviços. Deve-se notar que ambas as vulnerabilidades foram corrigidas  pela equipe de segurança da AWS após sua comunicação pelos pesquisadores.