Como a incompreensão sobre CORS expôs milhões de usuários do Zoom

O caso Zoom

Em 10 de julho de 2019, o consultor full-stack Chris Foster publicou uma análise técnica que expôs uma lacuna crítica de conhecimento no desenvolvimento de software moderno: a incompreensão generalizada sobre o funcionamento do CORS (Cross-Origin Resource Sharing). O estopim para essa discussão foi a revelação de uma vulnerabilidade severa no aplicativo de videoconferência Zoom, descoberta pelo pesquisador de segurança Jonathan Leitschuh. O pesquisador identificou que o instalador do Zoom configurava um servidor web local oculto rodando no endereço http://localhost:19421. Esse servidor local escutava silenciosamente a máquina do usuário, aguardando instruções vindas do site do Zoom para iniciar chamadas e abrir o aplicativo cliente nativo de forma automatizada.

A investigação detalhada conduzida por Jonathan Leitschuh expôs que, em vez de realizar uma requisição AJAX convencional para interagir com o cliente nativo, o site da empresa carregava um elemento de imagem a partir do servidor hospedado em http://localhost:19421. O pulo do gato — e o erro arquitetural — residia na forma como os dados eram retornados: o servidor web local alterava as dimensões físicas da imagem (largura e altura) para codificar códigos de erro e status do sistema. O site do Zoom lia as dimensões do arquivo de imagem carregado e, por meio de uma lógica de case-switch logic baseada nesses tamanhos, interpretava o estado do servidor para dar andamento ao fluxo de abertura da aplicação.

"I also found that, instead of making a regular AJAX request, this page instead loads an image from the Zoom web server that is locally running. The different dimensions of the image dictate the error/status code of the server. You can see that case-switch logic here." — Jonathan Leitschuh

Como funciona o CORS

A razão para os engenheiros do Zoom recorrerem a esse complexo e heterodoxo truque de imagem foi a tentativa deliberada de contornar as restrições impostas pela política de CORS. O pesquisador Jonathan Leitschuh argumentou em seu artigo que o navegador ignorava de forma explícita qualquer política de CORS quando os servidores estavam rodando sob o domínio de localhost. No entanto, o consultor Chris Foster corrigiu prontamente essa afirmação técnica, destacando que navegadores modernos, incluindo o Google Chrome, respeitam e aplicam rigorosamente as regras de CORS mesmo quando as requisições são direcionadas para servidores hospedados localmente no computador do usuário.

Essa interação entre diferentes portas de um mesmo ambiente local é uma rotina conhecida por desenvolvedores que utilizam o Create React App. Ao estruturar uma aplicação onde o frontend em React roda em uma porta do localhost e a API de backend em outra porta distinta, as requisições de origem cruzada (cross-origin) são acionadas constantemente. Todos os principais navegadores de mercado oferecem suporte a essas requisições entre origens distintas no localhost, desde que os servidores respondam com as permissões corretas. No caso do Zoom, a incapacidade de realizar requisições AJAX diretas sem bloqueio do navegador aponta para o fato de que a equipe de engenharia provavelmente não compreendeu a mecânica de configuração dos cabeçalhos de segurança adequados.

A vulnerabilidade na prática

Ao optar por contornar as proteções do navegador com o truque da imagem em vez de configurar corretamente o CORS, o Zoom acabou criando uma das falhas de segurança mais graves de sua história. A ausência de filtros de origem no servidor local de porta 19421 significava que qualquer página web visitada pelo usuário, e não apenas o domínio oficial zoom.us, podia realizar varreduras e enviar requisições silenciosas para a máquina local. Esse "hack" permitiu que qualquer site malicioso hospedado na internet pudesse interagir diretamente com o cliente nativo instalado na máquina, forçando a abertura de chamadas de vídeo e ativando periféricos sem autorização.

Como aponta o artigo de Chris Foster, o perigo de expor um servidor web em localhost com privilégios de execução de tarefas críticas — como a instalação de softwares ou manipulação de hardware — é imenso. Ao anular a barreira protetora da Same-Origin Policy do navegador sem aplicar as devidas restrições do CORS, o aplicativo descentralizou o controle de acesso, delegando a qualquer ator na internet a capacidade de interagir com o sistema operacional do usuário final. Esse cenário ilustra perfeitamente como soluções de contorno improvisadas (workarounds) criadas para fins de usabilidade imediata podem comprometer a segurança de milhões de pessoas.

Soluções seguras

A correção ideal para esse cenário de risco, conforme detalhado por Chris Foster, exigiria que o servidor local do Zoom na porta 19421 implementasse uma REST API padronizada. Em vez de retornar imagens manipuladas para ler status, o servidor deveria responder a requisições de controle emitindo de forma explícita o cabeçalho HTTP Access-Control-Allow-Origin com o valor estrito configurado para https://zoom.us. Esse ajuste simples no cabeçalho de resposta instruiria o mecanismo do navegador a permitir apenas que scripts JavaScript originados do domínio oficial da empresa pudessem ler ou enviar dados para o servidor local.

Adicionalmente, para mitigar o risco de explorações silenciosas, o domínio zoom.us deveria adotar de forma obrigatória o cabeçalho de Content Security Policy (CSP) configurado para bloquear a renderização de suas páginas em elementos de iframe de terceiros. Isso impediria que atacantes embutissem o fluxo de inicialização do Zoom de forma invisível em sites externos. Chris Foster reconhece que, mesmo com essas proteções, um site ainda poderia redirecionar o navegador do usuário para um link de reunião indesejado, mas essa seria uma decisão de experiência de usuário (UX) adotada pela empresa, e não uma falha de segurança ou uma vulnerabilidade de software ativa.

O autor também pondera que a própria premissa de contornar os diálogos nativos do navegador para acelerar a inicialização do aplicativo é questionável do ponto de vista de usabilidade. De acordo com os preceitos de design de experiência de usuário, um software robusto precisa ser previsível. O ato de clicar em um link não deveria resultar na ativação imediata e inesperada da câmera e do microfone do usuário para estranhos. Como exemplo positivo de implementação de permissões, Foster cita o Google Meet, que mantém o controle e a validação de acesso às conferências diretamente na interface da própria aplicação web, sem exigir servidores locais intrusivos ou vulneráveis.

O problema na comunidade

A análise técnica de Chris Foster baseia-se em sua vasta vivência prática como consultor full-stack em empresas de múltiplos tamanhos e setores. O autor relata que a incompreensão sobre as regras de CORS e a política de mesma origem é um problema universal que afeta desenvolvedores seniores e iniciantes de forma equivalente. Para além do caso específico do Zoom, outros fornecedores de software de mercado já foram detectados contendo exatamente a mesma classe de vulnerabilidade de servidor local sem proteção, evidenciando uma falha sistêmica na educação de segurança da informação dentro do ecossistema de desenvolvimento.

Essa vulnerabilidade educacional é amplificada pela disseminação de respostas e tutoriais inseguros em plataformas de comunidade como o Stack Overflow. Foster aponta que perguntas populares sobre problemas de CORS frequentemente trazem como soluções sugeridas o uso de configurações padrão extremamente perigosas. Um exemplo clássico ocorre em templates do framework Express para Node.js, onde respostas copiadas literalmente instruem os desenvolvedores a habilitar o acesso de qualquer origem de forma indiscriminada. Quando replicados em sistemas de produção reais, esses trechos de código criam brechas idênticas à do Zoom, deixando serviços e APIs inteiramente desprotegidos.

Por fim, ao avaliar as alternativas técnicas que a equipe do Zoom possuía na época, Foster menciona discussões promovidas na rede social Reddit pelo usuário lerunicorn. A postagem sugeria que a escolha do truque das imagens poderia ter sido motivada por uma restrição do Firefox de bloquear requisições de origens seguras (HTTPS) para origens não seguras (HTTP). Contudo, Foster reitera que o Firefox suporta esse fluxo quando o destino é o localhost. Adicionalmente, aplicações locais poderiam gerar certificados autoassinados exclusivos ou estruturar a comunicação por meio de browser extensions dedicadas. Qualquer uma dessas opções seria mais segura do que ignorar completamente o filtro de origens, demonstrando que o desconhecimento técnico continua sendo o maior vetor de riscos em segurança de software.