Google vs Microsoft; Equipe de Pesquisa do Google Torna Públicas Mais Duas Vulnerabilidades do Windows 7/8

A guerra entre Google e Microsoft esquenta à medida que o Google revela mais duas vulnerabilidades do Windows 7 e Windows 8.

A Equipe de Pesquisa do Google tornou públicas mais duas vulnerabilidades não corrigidas do Windows na quinta-feira, após a expiração do período de espera de 90 dias autoimposto do Google Project Zero antes de divulgar os detalhes do bug.

A Microsoft, que não tem recebido bem esse tipo de divulgação pública, afirmou que corrigirá uma das duas vulnerabilidades em seu próximo boletim de segurança do Patch Tuesday de fevereiro. A segunda falha, ao que parece, não é um grande problema de segurança.

Os leitores podem se lembrar de que a equipe de pesquisa do Google havia tornado pública uma vulnerabilidade de escalonamento de privilégios no Windows 7 após a expiração do período de espera autoimposto de 90 dias. A divulgação do Google em 29 de dezembro reviveu debates sobre divulgação entre entusiastas de segurança e acendeu animosidade e posturas públicas de ambas as empresas.

A Microsoft quer que o Google siga um programa coordenado de divulgação de vulnerabilidades e pediu ao Google que retivesse sua divulgação da vulnerabilidade até os boletins de segurança de janeiro, que foram lançados esta semana. O Google, por outro lado, confia em seu moratório autoimposto de 90 dias, então se recusou e seguiu em frente com sua divulgação.

Chris Betz, da Microsoft, afirmou que: “Embora seguir em frente mantenha o cronograma anunciado pelo Google para divulgação, a decisão parece menos princípios e mais como um ‘pegadinha’, com os clientes sendo os que podem sofrer como resultado. O que é certo para o Google nem sempre é certo para os clientes. Exortamos o Google a fazer da proteção dos clientes nosso objetivo coletivo principal.”

A guerra entre os gigantes da tecnologia está longe de acabar, pois a equipe de pesquisa do Google tornou públicas mais duas vulnerabilidades do Windows. Ambas as vulnerabilidades estão reproduzidas abaixo:

Problema nº 127 relatado à Microsoft em 17 de outubro de 2013, tornado público em 15 de janeiro de 2014

Plataforma: Windows 7 32/64 bits, Windows 8+ não vulnerável
Classe: Bypass de Segurança A chamada de sistema NtPowerInformation realiza uma verificação se o chamador é um administrador antes de executar algumas funções específicas de energia. A verificação é feita na função PopUserIsAdmin. A implementação aproximada é: BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
} No Windows 7, essa verificação pode ser contornada porque a função SeTokenIsAdmin não leva em conta o nível de impersonação do token e o restante do código também não leva isso em conta. Portanto, você pode impersonar o token de um administrador como um usuário normal (por meio de token vinculado ou sequestrando um token de sistema) e chamar as funções protegidas. No Windows 8+, o método SeTokenIsAdmin foi alterado para verificar o nível de impersonação, portanto, não é vulnerável. Não está claro se isso tem um impacto sério na segurança ou não, portanto, está sendo divulgado como está. Algumas funções também são verificadas por uma verificação de privilégio, no entanto, o contexto do sujeito é capturado separadamente, então existe uma janela TOCTOU entre as verificações que poderia ser explorada. Para fins de PoC, escolhi usar a função 45 “PopRequestPowerListInfo” (que não requer nenhum truque especial. Além disso, essa função tem uma vulnerabilidade teórica de estouro de inteiro, dependendo de quanto você pode empurrar o tamanho de PopPowerRequestObjectCount. Anexo está um PoC simples que demonstra o problema para execução no Windows 7. Para reproduzir, siga os passos. 1) Certifique-se de estar executando como um administrador de token dividido, isso porque o PoC usa o token vinculado para obter um token de administrador. Para um usuário normal, você poderia apenas capturar um token de um serviço.

2. Execute o PoC, ele deve fazer chamadas, uma sem impersonação e uma com. Resultado Esperado:
   Ambas as chamadas devem retornar STATUS_ACCESS_DENIED (0xC0000022) Resultado Observado:
   A primeira verificação falha com STATUS_ACCESS_DENIED enquanto a segunda tem sucesso com STATUS_SUCCESS. PoC para download => 1 2

Problema nº 128 relatado à Microsoft em 17 de outubro de 2013, tornado público em 15 de janeiro de 2014

Plataforma: Windows 7, 8.1 Update 32/64 bits
Classe: Bypass de Segurança/Divulgação de Informação A função CryptProtectMemory permite que um aplicativo criptografe a memória para um dos três cenários: processo, sessão de logon e computador. Ao usar a opção de sessão de logon (flag CRYPTPROTECTMEMORY_SAME_LOGON), a chave de criptografia é gerada com base no identificador da sessão de logon, isso é para compartilhar memória entre processos que estão sendo executados dentro da mesma sessão de logon. Como isso também pode ser usado para enviar dados de um processo para outro, ele suporta a extração do id da sessão de logon do token de impersonação. O problema é que a implementação em CNG.sys não verifica o nível de impersonação do token ao capturar o id da sessão de logon (usando SeQueryAuthenticationIdToken), então um usuário normal pode impersonar no nível de Identificação e descriptografar ou criptografar dados para essa sessão de logon. Isso pode ser um problema se houver um serviço que seja vulnerável a um ataque de plantio de pipe nomeado ou que esteja armazenando dados criptografados em uma seção de memória compartilhada legível por todos. Esse comportamento, é claro, pode ser design, no entanto, não tendo participado do design, é difícil dizer. A documentação afirma que o usuário deve impersonar o cliente, o que eu interpreto como significando que deve ser capaz de agir em nome do cliente, em vez de se identificar como o cliente. Anexo está um PoC simples que demonstra o problema. Para reproduzir, siga os passos. 1) Execute Poc_CNGLogonSessionImpersonation.exe a partir da linha de comando

2. O programa deve imprimir “A criptografia não corresponde” para indicar que as duas criptografias dos mesmos dados não foram correspondentes, implicando que a chave era diferente entre elas. Resultado Esperado:
   Ambas as chamadas devem retornar os mesmos dados criptografados, ou a segunda chamada deve falhar Resultado Observado:
   Ambas as chamadas têm sucesso e retornam dados criptografados diferentes PoC download => Arquivo Zip

A Microsoft corrigirá apenas uma das vulnerabilidades em seu Patch Tuesday de fevereiro, afirmando que a outra vulnerabilidade não é um risco de segurança. Tanto a Microsoft quanto o Google afirmaram que não têm provas de que nenhuma das três vulnerabilidades tornadas públicas tenha sido explorada na prática.