ZenGo é uma carteira Web 3 segura que usa tecnologia de computação multipartidária (MPC).
Recentemente, a equipe SkyFall da CertiK conduziu uma auditoria e pesquisa completa de inúmeras carteiras móveis e descobriu que a solução MPC da ZenGo oferece defesas de segurança mais fortes do que carteiras móveis comuns – usuários de carteiras ZenGo, especialmente aqueles com carteiras de alto valor Os usuários estão protegidos contra ataques diretos de invasores avançados: por exemplo, explorar vulnerabilidades de dia zero ou malware avançado para obter acesso root no dispositivo do usuário.
Esta ameaça é a mais recente e só foi descoberta pela equipe CertiK, portanto, os desenvolvedores de carteiras MPC devem prestar atenção aos detalhes do ataque!
A defesa contra invasores privilegiados é um desafio. Propomos um novo método de ataque e vetor de ataque para o método MPC no ZenGo nos resultados do relatório. Portanto, relatamos imediatamente esse problema de segurança ao ZenGo, e o ZenGo respondeu rapidamente e corrigiu o problema.
Neste artigo vamos nos aprofundar nos detalhes técnicos da descoberta e compartilhar como estamos trabalhando com o ZenGo para melhorar a segurança geral da carteira MPC.
Com base em nossa análise completa do design de segurança do ZenGo e em suas respostas profissionais aos problemas, a CertiK acredita que o ZenGo pode ser considerado a solução de carteira mais segura atualmente no mercado.
O que é MPC?
A computação multipartidária (MPC), às vezes também chamada de computação multipartidária segura (SMPC), é um campo da criptografia. Ele permite que várias partes assinem transações em conjunto, garantindo ao mesmo tempo que as chaves de cada parte não sejam comprometidas.
Como a tecnologia MPC pode distribuir chaves entre várias partes, eliminando assim qualquer ponto único de falha, ela permite aos usuários proteger melhor as chaves privadas da Web 3. Este método também é comumente referido como "assinatura de limite" e é atualmente usado por muitos Web 3. Adotado por. custodiantes e desenvolvedores de carteiras para proteger os ativos da Web 3. Entre eles, ZenGo é um dos desenvolvedores de carteiras MPC mais conhecidos e utilizados.
Conforme mostrado na figura abaixo, a carteira não usa uma chave privada tradicional para controlar a assinatura das transações. Em vez disso, várias chaves privadas são fragmentadas para participar do processo de assinatura da transação e gerar uma assinatura final para verificação.
Design comum de MPC que gera assinaturas
Através desta pesquisa, reconhecemos os desafios e potenciais riscos de segurança associados à abordagem MPC e a importância da proteção de ativos da Web 3. Portanto, queremos proteger melhor os usuários da Web3, explorando e resolvendo esses desafios.
Portanto, podemos pensar sobre esta questão: Por que as carteiras MPC podem fornecer maior segurança em comparação com as carteiras criptografadas tradicionais? Como isso é feito?
Design ZenGo MPC e garantia de segurança
Através desta pesquisa, reconhecemos os desafios e potenciais riscos de segurança associados à abordagem MPC e a importância da proteção de ativos da Web 3. Portanto, queremos proteger melhor os usuários da Web3, explorando e resolvendo esses desafios.
Portanto, podemos pensar sobre esta questão: por que as carteiras MPC podem fornecer maior segurança em comparação com as carteiras criptografadas tradicionais? Como isso é feito?
Depois de avaliar os designs de diferentes carteiras Web 3, analisamos as carteiras Web 3 da MPC – avaliamos uma das carteiras MPC mais respeitadas do mercado e a carteira MPC auto-hospedada líder – ZenGo.
Para esta avaliação utilizamos o mesmo modelo de ameaça descrito no estudo anterior: “Se o seu dispositivo estiver infectado com malware, esta carteira ainda protegerá os seus activos?”
Visão geral da arquitetura de segurança ZenGo
Conforme mostrado na imagem acima, a carteira ZenGo possui um design de segurança exclusivo, e a arquitetura de segurança e o processo de recuperação são mais escalonados do que as carteiras tradicionais. Os recursos de segurança fornecidos pelo ZenGo incluem, mas não estão limitados a:
Esquema de assinatura de duas partes: O design MPC do ZenGo implementa um esquema de assinatura de duas partes. Cada usuário envolve dois fragmentos de chave ao gerar uma assinatura de transação: um armazenado nos servidores ZenGo (chave mestra ①) e outro armazenado no dispositivo do usuário (chave mestra ②). Nem o ZenGo nem o usuário sabem quais chaves o outro possui.
Proteção baseada em TEE: Além disso, para evitar ataques "man-in-the-middle" e "sequestro de APP", o aplicativo ZenGo usa uma solução TEE (Trusted Execution Environment) e usa uma chave privada TEE para assinar o HTTPS conteúdo de comunicação para solicitar APIs relacionadas. Essa chave de dispositivo baseada em TEE é gerada dentro do TEE quando o usuário configura o dispositivo e não pode ser extraída nem mesmo pelo próprio sistema operacional.
Com esses recursos de segurança implementados, os invasores não podem mais roubar as chaves privadas dos usuários da memória ou dos arquivos de armazenamento e assumir o controle dos ativos dos usuários do ZenGo. ZenGo também usa TEE para proteger a interação entre o servidor e o cliente contra violações. Isso também significa que os ataques “man-in-the-middle” e “APP hijacking” são efetivamente bloqueados e defendidos.
Nossa auditoria confirmou que o ZenGo possui um design e implementação seguros que podem resistir a esses ataques, e este é o mais alto nível de design de segurança entre as carteiras auditadas com as quais tivemos contato.
O design e a implementação de segurança do ZenGo defendem com sucesso contra ataques, incluindo privilégios e os ataques acima. No entanto, lidar com todos os tipos de ataques privilegiados não é fácil, especialmente considerando que os invasores podem ler (e em alguns casos escrever) memória arbitrária.
Ao auditar toda a carteira, conseguimos descobrir um problema de implementação no ZenGo que nos permitiu agir como um invasor privilegiado e contornar certas proteções.
Mas antes de discutir os detalhes, vamos revisar o mecanismo de segurança da carteira ZenGo.
Práticas seguras para carteira ZenGo
Através desta pesquisa, reconhecemos os desafios e potenciais riscos de segurança associados à abordagem MPC e a importância da proteção de ativos da Web 3. Portanto, queremos proteger melhor os usuários da Web3, explorando e resolvendo esses desafios.
Portanto, podemos pensar sobre esta questão: por que as carteiras MPC podem fornecer maior segurança em comparação com as carteiras criptografadas tradicionais? Como isso é feito?
Uma carteira Web 3 clássica requer apenas uma chave privada. Porém, sempre existe a possibilidade de o usuário revelar a chave privada ou frase mnemônica. Assim, eles poderiam perder suas chaves privadas e ver um invasor tomar posse dos ativos.
A carteira MPC funciona de maneira diferente. A carteira não possui uma única chave privada. O usuário agora possui apenas um fragmento de chave privada e não sabe nada sobre os fragmentos de chave privada restantes. Dessa perspectiva, mesmo que o invasor obtenha a chave pessoal do usuário, ele não poderá transferir fundos diretamente. Para proteger ainda mais os usuários, o ZenGo usa uma variedade de meios para fortalecer seu design de segurança: não apenas o esquema de assinatura de duas partes mencionado acima e a proteção de dispositivos baseada em TEE, mas também a autenticação biométrica baseada em digitalização facial e criptografia de chave adicional.
Medidas de proteção durante o registro do usuário e recuperação da conta do usuário
Durante o processo de registro do usuário e recuperação de conta, a ZenGo adota as seguintes medidas de proteção para proteger os ativos do usuário.
Proteção de identificação do usuário: O esquema de assinatura de duas partes exige que os usuários só possam acessar seus fundos quando interagirem com outra parte (o lado do servidor nas configurações do ZenGo). Para poder identificar o usuário e os compartilhamentos de chaves associados armazenados no servidor, o ZenGo requer o e-mail do usuário para registrar uma conta.
Para evitar hackers de e-mail, ZenGo usa tecnologia de digitalização facial (Zoom da FaceTec) para vincular informações biométricas às contas dos usuários. Durante o processo de recuperação de conta após registro e verificação de e-mail, os usuários precisam “deslizar o rosto” para autenticação.
Proteção de comunicação entre aplicativos e servidores: Para garantir que os servidores ZenGo interajam com os dispositivos de usuários legítimos, o ZenGo gera e registra uma chave assimétrica no ambiente TEE durante o processo de registro e recuperação de conta. Todas as interações entre o aplicativo ZenGo e o servidor precisam ser assinadas por esta chave específica. Por ser protegida por uma solução de segurança apoiada por hardware, essa chave não pode ser lida diretamente por um invasor e é difícil abusar dela.
Registro de usuário ZenGo e processo de recuperação de conta
Proteção de compartilhamento de chave do usuário: permitir que os usuários armazenem e façam backup de seus fragmentos de chave é arriscado, pois pode comprometer todas as medidas de segurança fornecidas pelo ZenGo. Para resolver este problema de segurança, o ZenGo gera uma chave de criptografia durante o processo de registro. A chave de criptografia criptografa o compartilhamento de chave do usuário e armazena o texto cifrado em seu servidor.
No entanto, as chaves de criptografia não são compartilhadas com o ZenGo, forçando a sincronização com o Google Drive ou iCloud do usuário. A chave criptografada pode ser compartilhada e descriptografada posteriormente somente depois que o usuário tiver passado na verificação de e-mail e na autenticação biométrica baseada em servidor. Entre eles, a autenticação biométrica baseada em servidor (reconhecimento facial FaceTec) é quase impossível de ser “enganada” pela reconstrução facial 2D/3D convencional.
Processo de transação ZenGo de geração de assinatura de transação
Para assinar uma transação, o aplicativo ZenGo realiza uma série de interações com o servidor ZenGo. Durante a interação, o ZenGo usa sua solução de assinatura de duas partes de código aberto e fragmentação de chave do usuário para gerar assinaturas de duas partes. O servidor ZenGo dá um passo adiante para assinar e transmitir a transação. Todas as solicitações neste processo são marcadas com data e hora e assinadas no TEE para manter a integridade e a não repetibilidade das informações.
Descoberta de problemas no design ZenGo MPC
Como discutimos antes, o design de segurança do ZenGo envolve muitas chaves de criptografia, cada uma com responsabilidades diferentes. Na tabela abaixo mostramos quais chaves são utilizadas pelo ZenGo e como elas são protegidas.
Através desta tabela, podemos ver que três chaves são utilizadas no lado do cliente: chave mestra ②, chave do dispositivo e chave de criptografia. Um invasor precisa obter a chave mestra② e a chave do dispositivo para interagir com o servidor ZenGo e roubar fundos do usuário.
Conforme apresentado na seção de detalhes da transação anterior, a chave mestra ② participa da geração de assinaturas de ambas as partes como texto na memória, o que permite a um invasor ler a memória do processo e extrair a chave mestra ②. Como solução parcial, todas as solicitações de transação ao servidor ZenGo precisam ser assinadas por uma chave de dispositivo, que não pode ser lida ou extraída. Esse processo é feito no TEE e não tem controle do invasor.
No entanto, apesar dos muitos aspectos do design de segurança do ZenGo, a equipe SkyFall da CertiK ainda descobriu uma vulnerabilidade nele. Depois de realizar uma auditoria detalhada de todas as APIs do aplicativo ZenGo, percebemos que certas APIs permitem que um invasor falsifique os servidores ZenGo e gere facilmente uma nova chave de dispositivo para uso em outros dispositivos.
Esta API registrada pela chave do dispositivo não possui as proteções de segurança necessárias: um invasor pode gerar uma nova chave de curva elíptica NIST P-256 em outro dispositivo e, em seguida, o invasor pode aproveitar a API registrada pela chave do dispositivo e registrar uma nova. , finja ser um novo dispositivo de usuário e solicite uma transação.
Chamamos esse dispositivo de ataque de ataque de bifurcação.
Ataque de bifurcação de dispositivo na carteira ZenGo
Conforme mencionado acima, um invasor precisaria ter a chave mestra do usuário ZenGo ② e uma chave de dispositivo válida para roubar seus ativos.
Chave mestra ②: A chave mestra ② é uma chave fixa que é usada como texto simples na memória para participar do processo de assinatura de ambas as partes. Devido à complexidade e singularidade dos algoritmos de assinatura de ambas as partes, este processo não pode ser concluído no TEE. Portanto, um invasor privilegiado poderia simplesmente despejar a memória do processo ou sequestrar determinadas APIs do sistema para extrair a chave mestra. A captura de tela abaixo mostra a chave mestra que podemos extrair na plataforma iOS ②.
Chave do dispositivo: Durante o processo de registro ou recuperação de conta, uma chave de dispositivo válida é gerada no dispositivo do usuário no TEE como uma solução para a ameaça de extração de texto simples mencionada acima. A chave do dispositivo não pode ser lida por um invasor privilegiado. No entanto, um invasor pode usar a mesma API de registro de chave do dispositivo para registrar outro par de chaves e usá-lo.
A API de registro de chave de dispositivo possui apenas um mecanismo de autenticação muito básico: um invasor pode usar um token JWT de texto simples comum armazenado localmente e a chave mestra extraída ② para autenticação de API. Por design, o código do servidor envolvido nesta API também deve ser autenticado biometricamente pela Facetec. Porém, na prática, o código não consegue realizar esta etapa devido a falhas lógicas.
Em nosso ataque simulado, simulamos um invasor privilegiado e monitoramos continuamente o dispositivo da vítima. Assim que o aplicativo ZenGo é iniciado, extraímos a chave mestra da memória e lemos o token API do banco de dados local. E essas informações são suficientes para que o invasor roube todos os fundos do usuário!
Assim que tivermos o token da API, geramos uma nova chave de dispositivo e chamamos a API de registro de chave de dispositivo para registrar a chave do dispositivo no servidor ZenGo. Em seguida, construímos todas as solicitações de API para interagir com o servidor ZenGo para iniciar transações. Para a carteira MPC, gerar assinaturas de ambas as partes é um processo único e complexo. Felizmente, o processo de desenvolvimento do ZenGo sempre seguiu o espírito de código aberto, então fomos capazes de compilar a biblioteca de assinaturas de duas partes usada no aplicativo oficial do ZenGo e executá-la localmente.
A imagem acima mostra como extraímos a chave mestra ② e registramos uma nova chave do dispositivo em nome da vítima. Em seguida, usamos essas duas chaves para enviar 0,00222 ETH para a “conta do invasor”. Todo o processo leva apenas alguns segundos e desconhece completamente a vítima.
Para resolver esse problema, a ZenGo implementou a autenticação biométrica FaceTec no lado do servidor para registro de dispositivos. As soluções alternativas no nível da API do servidor eliminam a possibilidade desse ataque e não exigem atualizações no código do cliente.
Resumir
Na avaliação do ZenGo pela CertiK, examinamos e auditamos minuciosamente todas as medidas de segurança implementadas para proteger os ativos do usuário. Isso inclui esquemas de assinatura mútua, proteção de dispositivos baseada em TEE e biometria para registro e recuperação de contas.
Embora o ZenGo tenha um alto nível de consciência de segurança e tenha tomado muitas medidas para melhorar sua segurança, a CertiK descobriu um risco chave de autenticação de acesso à API explorável na implementação do ZenGo. A vulnerabilidade pode permitir que um invasor privilegiado contorne as medidas de segurança existentes e roube os fundos de um usuário se seu dispositivo for comprometido.
A ZenGo resolveu prontamente o problema e implantou um patch, e a CeritK posteriormente conduziu uma auditoria completa e determinou que o patch corrigiu os riscos mencionados no relatório.
Com a implantação de patches, acreditamos que o ZenGo pode impedir efetivamente que usuários privilegiados acessem ilegalmente os fundos dos usuários no futuro. A defesa contra invasores privilegiados é uma tarefa difícil, e as práticas de segurança do ZenGo nos mostram uma abordagem abrangente para proteger os usuários. Esta carteira faz mais do que a maioria das carteiras convencionais atualmente no mercado.
Estamos orgulhosos da parceria com a ZenGo e de trabalhar em conjunto com a ZenGo para proteger a segurança dos usuários da Web 3 e resolver desafios de segurança. Gostaríamos também de agradecer ao ZenGo pela sua resposta oportuna às vulnerabilidades que descobrimos e pelas suas eficientes ações de correção.
Como profissionais do setor de segurança, estamos muito felizes em ver uma das principais empresas de carteiras da Web 3 levando a segurança tão a sério e tendo um alto senso de responsabilidade pelos usuários e pelos fundos dos usuários. Esperamos que, no caminho para a segurança no futuro, possamos melhorar a segurança de mais projetos e dar “tranquilidade” aos seus usuários.