Purple Teaming: Como MetaMask e Agoric caçaram falhas para fortalecer o JavaScript

Neste verão, as equipes da Agoric e MetaMask deram início ao primeiro exercício colaborativo de caça a bugs focado em uma análise profunda do JavaScript reforçado, a base dos contratos inteligentes da Agoric. Este esforço de descoberta de vulnerabilidades testou as propriedades de segurança de um lockdown shim mantido pela Agoric que emula o JavaScript reforçado.

Hoje, a equipe da Agoric está empolgada em compartilhar os resultados dessa avaliação informal e colaborativa de vulnerabilidades aqui. Uma proposta para tornar esta implementação experimental oficialmente uma característica da linguagem está atualmente na proposta de Estágio 1 para o comitê ECMA TC39.

Vermelho + Azul = Roxo

Durante o engajamento, a Equipe MetaMask (com a adição de Mathieu Hofman da Agoric) assumiu a postura ofensiva de uma Equipe Vermelha, enquanto os mantenedores de módulos da Agoric adotaram a postura defensiva de uma Equipe Azul. Tipicamente, uma avaliação de vulnerabilidades desse tipo pode ser chamada de exercício de equipe vermelha/equipe azul. No entanto, enquanto esse enquadramento pode funcionar bem para exercícios militares e treinamentos, pode ter consequências não intencionais para revisões de segurança de aplicativos. Se equipes vermelhas e azuis altamente motivadas estiverem muito focadas em derrotar uma à outra, podem perder de vista o que é mais importante no final do dia: trabalhar juntas para proteger as pessoas que usam o software que pretendem segurar.

Em vez de se enfrentarem em uma batalha direta, todos os participantes adotaram técnicas da Equipe Roxa que incluíram compartilhar insights profundos sobre o conhecimento e o funcionamento do código, revisões de código colaborativas linha por linha e testes adversariais impulsionados pelo conhecimento e insights compartilhados por ambas as equipes. Ao combinar forças e perspectivas sobre a mitigação e remediação de problemas, as equipes da Agoric e MetaMask realizaram uma análise mais profunda e completa do código do que um engajamento tradicional de Equipe Vermelha/Equipe Azul teria permitido.

Descobertas: Nenhuma Vulnerabilidade Crítica

Para os fins deste engajamento de segurança, os revisores do MetaMask concentraram-se em desafiar as propriedades de segurança do JavaScript reforçado, com ênfase em identificar escapes do código de Compartimento. Os revisores também se concentraram em garantir que o código do Compartimento não pudesse conceder acesso a capacidades poderosas da plataforma (a menos que concedido), não pudesse conceder privilégios para observar o tempo de execução e não pudesse se envolver em comunicação não autorizada com outros compartimentos.

Dentro do escopo desta avaliação,

• Nenhuma vulnerabilidade crítica foi identificada pelos revisores. A maioria dos problemas identificados foi classificada como descobertas de severidade "Informativa" ou "Baixa", e o modelo de segurança e a arquitetura do código não foram comprometidos. Embora exista um problema de segurança conhecido relacionado ao uso de domínios em um nó, esse problema evitável afeta apenas o nó sob condições específicas.
• A maioria dos problemas identificados foi classificada como uma alteração de código, uma alteração de documentação ou desenvolvimento de teste. As mitigações e remediações que surgiram como resultado desta avaliação resultaram em melhorias nas defesas, usabilidade e observabilidade do código. Não foram feitas alterações significativas na arquitetura do shim.

No final das contas, os revisores do MetaMask não identificaram nenhum escape de Compartimento e constataram que o shim foi escrito com extraordinário cuidado e expertise. Pareceu claro para os revisores que a funcionalidade de bloqueio do shim proporciona uma melhoria significativa na segurança do JavaScript escrito. Além disso, eles observaram que a API de Compartimento oferece uma interface convincente para o confinamento seguro de código.

Caminhando Rumo a um Futuro de "JavaScript Reforçado"

Quando se trata de avaliações de segurança, uma boa avaliação pode fornecer insights importantes sobre a segurança de aplicativos, mas uma excelente pode ser transformadora na forma como uma equipe pensa sobre o código que constrói, mantém ou consome. Nas iterações anteriores do shim, havia um forte foco em suas capacidades de oferecer ECMAScript "seguro". No entanto, "seguro" pode ser um descritor ambíguo - contra o que o código do shim era seguro? E quais benefícios essa segurança confere a alguém que utiliza o código do shim?

Durante o engajamento, uma mudança significativa de perspectiva surgiu e não pôde ser classificada ou capturada como um problema: os revisores passaram a se referir ao código SES como "JavaScript reforçado". Porque as equipes Agoric e MetaMask viram o código sob uma nova luz durante seu processo de revisão intensiva, o foco delas mudou para uma compreensão mais aprofundada dos benefícios das capacidades de bloqueio para os usuários.

Este esforço conjunto para descobrir bugs de segurança foi mais do que uma ótima maneira de reunir duas equipes amigáveis para colaborar no código. A inteligência compartilhada entre mantenedores de código, consumidores de código e analistas de código foi inestimável para obter uma perspectiva totalmente nova que continuará a melhorar a segurança e a resiliência de seu código.

Embora as avaliações de vulnerabilidade forneçam insights importantes sobre a segurança do código que visam, essas avaliações são apenas um dos muitos componentes necessários para construir um programa abrangente de segurança que aumenta o custo de um ataque para um atacante. Para saber mais sobre a segurança do JavaScript reforçado e as alterações de código que surgiram de nossa missão de encontrar bugs com o MetaMask, leia o relatório completo [aqui](inserir o link). E fique atento ao nosso blog para mais engajamentos de Equipe Roxa da Agoric e amigos.