Por: Pensando

fundo

À medida que o projeto ecológico TON esquenta, as gangues de phishing Web3 também começaram a entrar no campo de batalha ecológico TON. Atualmente, o TonConnect SDK é usado no ecossistema TON para resolver o problema de conexão e interação de carteira entre plataformas/aplicativos. Essas soluções inevitavelmente encontrarão um problema: como resolver a verificação de nomes de domínio durante a comunicação entre plataformas/aplicativos?

Geralmente, para permitir que os usuários usem uma carteira para se conectar a um DApp ou confirmar se a fonte de uma solicitação de assinatura é confiável, a carteira solicitará o nome de domínio da fonte na página de aprovação da solicitação, para que os usuários possam verificar melhor e confirmar se a origem da solicitação é consistente com a origem de sua operação. Isso evita ser fraudado por solicitações de assinatura de fontes maliciosas.

A equipe de segurança do SlowMist descobriu anteriormente problemas de segurança de verificação de nome de domínio na comunicação entre plataformas/aplicativos entre carteiras e DApps. Nós nos comunicamos com as equipes de projeto do MetaMask SDK e WalletConnect Web3Modal e descobrimos que esse problema é difícil de resolver. Portanto, MetaMask e WalletConnect ainda não resolveram totalmente este problema.

Recentemente, descobrimos que o TonConnect SDK no ecossistema TON também apresenta o mesmo problema, por isso divulgamos aqui, na esperança de ajudar os usuários a identificar e prevenir tais riscos.

analisar

Normalmente, quando uma carteira de extensão de navegador interage com um DApp, um script JS (script de conteúdo) será injetado na página da web para encaminhar mensagens entre a página da web e a extensão do navegador. Quando a página da web se comunica com o script de conteúdo, window.postmessage e window.addEventListener são usados, e window.addEventListener pode processar ainda mais a mensagem obtendo a origem da mensagem. A operação específica inclui a exibição da origem da mensagem no navegador. carteira de extensão e determinar a origem da mensagem se está na lista negra, realizar autenticação e outras operações na origem da mensagem. Como a origem depende das funções fornecidas pelo navegador para obtê-la, ela não pode ser falsificada.

No entanto, ao se comunicar entre plataformas/aplicativos, as mensagens geralmente são encaminhadas através de um servidor de encaminhamento de mensagens, e é difícil para o servidor de encaminhamento de mensagens verificar o nome de domínio onde a mensagem é iniciada (porque os dados do cliente podem ser falsificados), então não há é um problema de falsificação da origem da mensagem, a seguir estão dois cenários para comunicação de mensagens entre plataformas/aplicativos:

  • Página da web do navegador <=> Servidor de encaminhamento de mensagens <=> Wallet APP

  • Outro APP <=> Servidor de encaminhamento de mensagens <=> Wallet APP

Tomemos como exemplo o TonConnect SDK. O DApp usa o TonConnect SDK como uma ferramenta para comunicação de mensagens entre a carteira e o DApp. Ele precisa configurar o dappMetadata ao acessar o TonConnect SDK. válido, modificando sites confiáveis, fraudando os usuários.

Você pode falsificar a origem para ton.org definindo manifest.json com o seguinte conteúdo:

A seguir está o PoC após a implantação do código acima. Em seguida, digitalizamos e analisamos o código QR.

O TonConnect SDK passa os dados manifestUrl para o aplicativo de carteira por meio de um código QR, ao contrário de outros SDKs que os encaminham por meio de um servidor de encaminhamento de mensagens. O aplicativo de carteira analisará os dados manifestUrl obtidos pela digitalização. Pode-se descobrir que podemos facilmente forjar a origem de qualquer DApp para se comunicar com a carteira. Em outras palavras, os invasores podem usar essa falha para forjar DApps conhecidos para realizar ataques de phishing e fraude.

https://app.tonkeeper.com/ton-connect?v=2&id=24e3f2fdbea19fcd4fe03da3bc3d534d8b988edd01736f0b127a70cf2c531661&r={"manifestUrl":"https://tonconnect.pages.dev/tonconnect-manifest.json","items":[{" nome":"ton_addr"}]}

Após a conexão ser bem-sucedida, o DApp forjado inicia um aplicativo de assinatura por meio do TonConnect. Assim que o usuário confirmar, a carteira transmitirá os dados assinados para o blockchain. Como a falsificação de origem é extremamente enganosa, é difícil para os usuários identificarem a origem das conexões e solicitações de assinatura.

No MetaMask SDK, ao modificar o dappMetadata, você pode transformá-lo em um DApp bem conhecido para realizar ataques de phishing e fraude:

Da mesma forma, em WalletConnectModalSign, basta modificar os metadados:

Resumir

Como atualmente não há uma boa solução para o problema de verificação de nomes de domínio na comunicação entre plataformas/aplicativos entre carteiras convencionais e DApps, os projetos SDK geralmente adicionam alguns métodos de verificação adicionais, como: Mecanismo de verificação do WalletConnect (https://docs.walletconnect . com/cloud/verify), depois que o DApp passar na verificação do nome de domínio, a carteira poderá usar a API Verify para determinar se o nome de domínio é confiável.

No entanto, muitos DApps convencionais não verificam nomes de domínio, portanto, esta solução é difícil de resolver ataques de phishing de origem falsa. Se a grande maioria dos DApps usar o Verify para autenticar nomes de domínio, os usuários estarão amplamente protegidos contra os ataques de phishing de origem falsa cada vez mais desenfreados. A equipe de segurança do SlowMist também recomenda que os usuários prestem atenção para identificar se o site aberto é consistente com o nome de domínio solicitado para aprovação para evitar tais ataques.