A versão web do Ever Surf armazenava dados sensíveis no localStorage e derivava a chave de proteção de um PIN de 6 dígitos com salt previsível, permitindo ataque offline contra carteiras coletadas do navegador.
| Componente | Versão web do Ever Surf, carteira não custodial, mensageiro e navegador de blockchain usado com a rede Everscale. |
| Vetor | Extração do keystore criptografado do localStorage do navegador por acesso local, malware coletor de informações ou extensão com capacidade de ler dados da página, seguida de tentativa offline contra o PIN de 6 dígitos. |
| Impacto | Descriptografia da frase-semente e das chaves privadas armazenadas localmente, com possibilidade de restaurar a carteira em outro dispositivo e assinar transações. |
| Prioridade | Não usar a versão web para contas com valor real, migrar para a versão desktop mitigada e tratar frases-semente expostas no navegador como material sensível potencialmente comprometido. |
| Artefatos | Dados de carteira eram armazenados na chave surf.ton.wallet; a derivação usava Scrypt, SHA-256, DeviceInfo.getUniqueId e decriptação com nacl_secret_box_open. |
| Mitigação | A versão desktop foi lançada como mitigação e a versão web foi declarada depreciada, devendo ficar restrita a uso de desenvolvimento. |
A vulnerabilidade afetava a versão web do Ever Surf, aplicação associada à blockchain Everscale e anteriormente relacionada ao ecossistema Free TON. O produto combina funções de mensageiro, navegador de blockchain e carteira de criptomoedas, com operação não custodial. Nesse modelo, as chaves usadas para assinar transações não ficam em um serviço centralizado: elas são geradas e preservadas no dispositivo do usuário. Essa arquitetura reduz dependência de servidor, mas aumenta a exigência sobre a proteção local de material criptográfico, porque a perda da frase-semente ou da chave privada equivale à perda do controle exclusivo da carteira.
O problema central estava na combinação entre armazenamento local acessível pelo navegador e uma derivação de chave baseada em segredo fraco. Ao criar a carteira, o aplicativo gerava frase-semente, chave pública e chave privada, e pedia ao usuário um PIN de 6 dígitos. Esse PIN era usado para autenticação na aplicação e para confirmar transações. Embora houvesse bloqueio temporário após cinco tentativas incorretas na interface, essa proteção só valia para a interação normal com o aplicativo. Quando o keystore criptografado era retirado do navegador, o atacante podia testar PINs offline sem depender do mecanismo de bloqueio visual da aplicação.
A falha se tornava grave porque a versão web guardava dados de carteira no localStorage, dentro da chave surf.ton.wallet. O armazenamento local do navegador pode ser lido por JavaScript no contexto da origem e também pode ficar disponível, em formato não criptografado pelo próprio navegador, em bases locais como SQLite ou LevelDB, dependendo do navegador. Isso significa que o material criptografado da carteira podia ser alcançado por alguém com acesso ao computador, por software malicioso com capacidade de ler perfis de navegador ou por uma extensão posicionada para capturar dados carregados pela aplicação.
A correção operacional indicada para o caso foi abandonar a versão web como ambiente para valores reais. Os desenvolvedores lançaram uma versão desktop que mitiga a vulnerabilidade, enquanto a versão web passou a ser considerada depreciada e adequada apenas para desenvolvimento. Em carteiras não custodiais, a janela de resposta é diferente de sistemas bancários tradicionais: transações em blockchain são irreversíveis, e uma frase-semente exposta permite restaurar a carteira em outro ambiente. Por isso, qualquer conta que tenha usado frase-semente real na versão web deve ser avaliada como exposição de segredo criptográfico, não apenas como falha de autenticação.
O fluxo de criação de carteira no Ever Surf web começava com a geração local da frase-semente e do par de chaves. Como a aplicação opera sem backend para assinar transações, a lógica crítica de proteção, validação do PIN e descriptografia ficava no cliente. O keystore armazenado no navegador continha valores criptografados e metadados necessários para a recuperação do segredo após a digitação do PIN. A interface impunha bloqueio temporário depois de erros consecutivos, mas esse controle não protegia a cópia do keystore quando ela era obtida fora do fluxo normal da aplicação.
A análise da lógica JavaScript minificada mostrou que a recuperação da frase-semente passava por funções responsáveis por solicitar e validar a senha local. Durante a validação, a aplicação derivava uma chave a partir do PIN e de um salt, usando Scrypt. Em seguida, a chave derivada era usada para tentar abrir o conteúdo criptografado com nacl_secret_box_open, a partir dos campos criptografados e do nonce presentes no keystore. Esse desenho depende de dois fatores para resistir a força bruta: o PIN precisa ter entropia suficiente e o salt precisa variar adequadamente entre dispositivos ou usuários.
No caso observado, o PIN tinha apenas 6 dígitos, o que limita o espaço de busca a um milhão de combinações. O fator que deveria aumentar a resistência prática, o salt, era calculado a partir de um identificador de dispositivo obtido por DeviceInfo.getUniqueId, do pacote react-native-device-info. O problema é que esse recurso não era suportado no navegador da forma esperada. Na versão web, o valor retornava como desconhecido, levando a um salt determinístico derivado de uma string fixa. O resultado prático era que carteiras diferentes podiam compartilhar o mesmo parâmetro de derivação, reduzindo a proteção contra ataques em lote.
Com uma cópia do keystore, o atacante não precisava mais interagir com a tela de PIN. Ele podia testar combinações localmente, derivar a chave candidata e verificar se a abertura do conteúdo criptografado era bem-sucedida. Em experimento descrito no contexto técnico, a tentativa contra uma carteira alcançou 95 PINs por segundo em um processador Intel Core i7 de quatro núcleos, e o pior caso para um PIN de 6 dígitos foi estimado em cerca de 175 minutos. Em uma amostra criada para teste, a recuperação ocorreu em 38 minutos. Para várias carteiras, a reutilização do salt permitia amortizar a parte custosa da derivação, com desempenho observado de 79 PINs por segundo contra 100 frases-semente criptografadas simultaneamente.
Esse comportamento muda o risco de uma falha local para um cenário escalável. Um coletor de informações que obtenha perfis de navegador, extensões maliciosas ou acesso físico ao sistema não precisa descriptografar imediatamente a carteira no endpoint da vítima. Ele pode coletar keystores criptografados e processá-los depois, em infraestrutura separada. Como o segredo final é a frase-semente, a posse desse dado permite reconstruir as chaves em outro dispositivo e preparar transações sem depender do navegador original.
A superfície afetada se concentra na versão web do Ever Surf executada em navegador. A aplicação também existe como software móvel em lojas oficiais e foi descrita como escrita em React Native, mas a vulnerabilidade discutida envolve especificamente o comportamento web, onde o armazenamento local e a ausência de suporte adequado ao identificador de dispositivo criaram a condição explorável. A versão desktop foi indicada como mitigação, e a versão web foi rebaixada para uso de desenvolvimento.
O ponto sensível é o perfil de navegador do usuário. No Firefox, o armazenamento local pode residir em banco SQLite não criptografado pelo navegador; no Chrome, pode ficar em LevelDB dentro do perfil. A proteção real, portanto, não pode depender apenas do fato de o dado estar dentro do navegador. Qualquer processo com permissão suficiente para ler esses arquivos, qualquer extensão capaz de observar a página do Ever Surf ou qualquer malware coletor de informações com foco em dados locais pode transformar o keystore em material para ataque offline.
Usuários que criaram carteiras na versão web, restauraram uma frase-semente existente nesse ambiente ou mantiveram contas com valor real associadas ao fluxo web estão no grupo de maior risco. A falha não exige que o invasor quebre a blockchain, comprometa um nó da rede Everscale ou ataque um backend centralizado. O alvo é o segredo local usado para assinar operações. Por isso, a exposição deve ser entendida no limite correto: o impacto confirmado é controle da carteira a partir da recuperação da frase-semente ou da chave privada, não um comprometimento genérico de toda a rede.
- Versão web do Ever Surf com dados de carteira gravados em
localStorage. - Perfis de navegador contendo a chave
surf.ton.walletcom keystore criptografado. - Contas em que frases-semente reais foram criadas ou restauradas no ambiente web.
- Ambientes onde extensões de navegador, acesso físico ou malware coletor de informações possam ler armazenamento local.
A busca defensiva deve priorizar sinais de extração do perfil de navegador e acesso anômalo ao armazenamento local. Como o ataque pode ocorrer fora do fluxo de autenticação do Ever Surf, os logs da própria aplicação podem não registrar tentativas repetidas de PIN. O dado mais relevante é a obtenção do keystore e sua possível saída do endpoint. Em estáções onde a carteira web foi usada, a equipe deve inspecionar eventos de leitura em massa de diretórios de perfil, execução de processos desconhecidos com acesso a arquivos de navegador e instalação recente de extensões sem justificativa operacional.
Em EDR, o foco deve estar em processos que leem bancos SQLite, LevelDB ou diretórios de armazenamento local associados a navegadores e, em seguida, realizam conexão de rede incomum ou gravação de arquivo compactado. A presença de extensões com permissões amplas, alterações recentes em políticas de navegador e carregamento de extensões fora de canais confiáveis também merece análise. Para usuários que lidam com criptoativos, essa telemetria deve ser correlacionada com qualquer transação não reconhecida, mas a ausência de transação não elimina o risco, porque a frase-semente pode ter sido copiada e usada posteriormente.
No navegador, artefatos úteis incluem histórico de acesso ao domínio da aplicação web, dados do localStorage contendo surf.ton.wallet e alterações no conjunto de extensões instaladas perto do período de uso da carteira. Em resposta a incidente, a preservação desses artefatos deve ser feita de forma forense, sem publicar ou manusear a frase-semente em ferramentas compartilhadas. A equipe deve tratar o keystore, mesmo criptografado, como segredo sensível, já que o PIN de 6 dígitos e o salt previsível tornam viável a tentativa offline.
Na camada de identidade e administração de endpoint, vale procurar contas locais que tiveram acesso interativo ao computador, softwares de acesso remoto não esperados, agentes de sincronização que copiam diretórios de perfil e ferramentas de backup que possam ter replicado os arquivos de navegador para locais menos protegidos. O problema não depende de privilégio administrativo em todos os cenários: uma extensão com permissões suficientes ou um processo rodando no contexto do usuário pode alcançar dados que pertencem ao próprio perfil.
- Leitura ou cópia de bases SQLite e LevelDB de navegadores logo após uso da carteira web.
- Presença da chave
surf.ton.walletem armazenamento local de perfis de navegador. - Instalação recente de extensões com permissões amplas sobre páginas visitadas.
- Processos desconhecidos acessando diretórios de perfil e estabelecendo comunicação externa.
- Arquivos compactados ou sincronizados contendo dados de navegador de usuários que operavam Ever Surf web.
A medida principal é remover a versão web do caminho operacional de qualquer carteira com valor real. A versão desktop foi disponibilizada como mitigação, enquanto a web ficou depreciada e restrita a desenvolvimento. Para usuários que já utilizaram frase-semente real no navegador, a abordagem prudente é considerar o segredo como exposto a coleta local e planejar migração para uma carteira criada e mantida em ambiente mitigado. Em criptoativos, a rotação não é equivalente à troca de senha: quando a frase-semente pode ter sido vista, o controle do ativo depende de mover os fundos para um novo segredo não exposto.
A contenção deve começar pelo endpoint. Antes de qualquer operação sensível, é necessário avaliar se há malware coletor de informações, extensão suspeita ou acesso não autorizado ao perfil de navegador. Migrar fundos a partir de um computador ainda comprometido preserva o risco. A limpeza deve incluir revisão de extensões, verificação de processos persistentes, análise de conexões recentes e remoção de software não reconhecido. Depois disso, a carteira deve ser operada fora da versão web depreciada, seguindo o cliente mitigado indicado.
Do ponto de vista de engenharia, a lição técnica é que localStorage não deve ser tratado como cofre. Ele é uma interface conveniente para estado de aplicação, mas não oferece proteção criptográfica própria contra leitura por código no mesmo contexto, extensões autorizadas ou processos locais com acesso ao perfil. Quando uma aplicação web precisa preservar segredo de alto valor, a segurança precisa considerar isolamento de origem, redução de dados persistidos, uso de armazenamento mais adequado, derivação de chave com parâmetros robustos e salt único, além de UX que não incentive PINs de baixa entropia para proteger material irrecuperável.
Organizações que permitem uso de carteiras em estáções corporativas devem criar controles específicos para esse tipo de risco. Isso inclui inventário de extensões, bloqueio de extensões não aprovadas, monitoramento de acesso a perfis de navegador, alertas para coletores de informação e separação entre estáções de navegação comum e ambientes usados para chaves de alto valor. A investigação não deve publicar frases-semente, keystores completos ou dados recuperados em tíquetes e chats internos. Esses artefatos devem ser manipulados como credenciais críticas.
- Interromper o uso da versão web do Ever Surf para contas com valor real.
- Usar a versão desktop mitigada indicada para o aplicativo.
- Tratar frases-semente usadas no navegador como segredo potencialmente exposto.
- Revisar extensões, processos e acessos a diretórios de perfil antes de movimentar ativos.
- Monitorar leitura anômala de
localStorage, SQLite e LevelDB de navegadores em endpoints sensíveis. - Evitar armazenar keystores, frases-semente ou capturas de tela com segredos em ferramentas de suporte e colaboração.
0 Comentários