Como evitar golpes de phishing do EVM para Solana?

IntermediárioJul 25, 2024
Este artigo descreve um caso de um utilizador que perdeu ativos devido a um golpe de phishing na Solana. Explica as diferenças entre as cadeias Solana e EVM e as suas táticas fraudulentas únicas, como a transferência de propriedade de conta de token, não necessidade de pré-autorização, permitindo múltiplas transferências de token numa única transação e usando Durable Nonce para fraude.
Como evitar golpes de phishing do EVM para Solana?

Recentemente, um usuário postou sobre a perda de milhões de RMB em ativos devido a um golpe de phishing no Solana. De acordo com a descrição, ele clicou erroneamente em um link postado por um grupo de phishing sob um tweet do projeto Maneki, levando-o a um site fraudulento.

o que o deixou confuso foi que, durante a interação, o site não parecia exigir qualquer operação de autorização de token, e o hacker conseguiu roubar os ativos diretamente. quando ele percebeu que poderia haver um problema com o site e tentou transferir tokens de sua carteira para evitar o roubo, descobriu que várias tentativas de transferência falharam e que já não podia retirar os seus ativos.

devido às informações limitadas fornecidas, não podemos recriar completamente a cena do incidente. no entanto, é claro que o usuário perdeu o controle da conta do token maneki, o que explica por que as tentativas de transferir ativos de sua carteira falharam. usuários acostumados ao EVM podem ficar confusos sobre o que significa controle de conta.

isso ocorre porque a solana usa uma implementação diferente da cadeia EVM. Continuar interagindo com a solana usando os hábitos da EVM é como usar uma espada desatualizada para lutar uma batalha moderna, o que inevitavelmente leva a riscos significativos.

Para desfrutar de jogar na solana, é essencial entender as características da solana e as táticas fraudulentas. Por esta razão, compilamos alguns dos métodos de ataque na solana que diferem dos do EVM, na esperança de ajudar os utilizadores menos familiarizados com a solana a evitarem armadilhas.

1. cuckoo no ninho: transferência de propriedade da conta de token

o protagonista do nosso caso de abertura encontrou este tipo de ataque. numa carteira solana, cada token tem uma conta separada (conta de token), semelhante a como uma conta bancária pode ter contas separadas para diferentes moedas como rmb e usd, que são independentes entre si. cada conta de token também tem um atributo de propriedade.

Por padrão, o proprietário de uma conta de token é designado como a carteira atual. No entanto, isso não está codificado. Ao chamar a operação createsetauthorityinstruction, a propriedade da conta de token pode ser alterada. Os hackers usam essa operação para enganar os usuários e transferir a propriedade de uma conta de token de sua carteira para a carteira do hacker.

uma vez bem-sucedido, mesmo que os tokens ainda estejam na carteira, o utilizador não os pode transferir, o que é essencialmente o mesmo que ter os tokens roubados.

devido ao alto risco desta operação, tanto o fantasma como @Backpack_CNas carteiras interceptam e alertam os utilizadores sobre os riscos da transação, exigindo uma segunda confirmação para a transação, a menos que o utilizador insista em aprová-la.

2. não é necessária nenhuma pré-autorização para transações na Solana

na evm, um contrato de phishing precisa que o usuário autorize o contrato no contrato do token antes que possa transferir tokens da carteira do usuário. o contrato de phishing só pode iniciar a transação para transferir os ativos do usuário após receber autorização.

no entanto, na solana, “aprovar” não significa autorização, mas sim aprovação da transação. se o usuário trata isso erroneamente como a etapa de autorização e aprova, a transação de phishing é enviada, deixando pouca chance de recuperação.

uma situação mais perigosa ocorre se o usuário for enganado a autorizar tokens na EVM, apenas o token autorizado é afetado e outros tokens não autorizados permanecem seguros. No Solana, como nenhuma autorização é necessária e apenas a aprovação do usuário é necessária para transferir tokens, combinado com o terceiro ponto que discutiremos a seguir, isso poderia resultar em perdas significativas para o usuário.

3. tenha cuidado ao ser induzido a transferir vários tokens

O design de transação da Solana permite que várias subtransações sejam incluídas em uma única transação, sendo que cada subtransação completa uma interação, como transferir um token específico. Em comparação com a EVM, onde a transferência de cada token requer uma transação separada, essa característica da Solana oferece alguma conveniência.

por exemplo, sua carteira pode conter alguns tokens com valor muito baixo, inferior a 1 usd. O sol-incinerator utiliza esse recurso para permitir que os usuários enviem em lote tokens de pequeno valor de sua carteira e os convertam de volta para sol sem a necessidade de várias conversões, o que consumiria muito gás e economizaria tempo operacional.

embora este recurso forneça conveniência, também facilita grandemente as atividades de phishing. se um hacker conseguir enganar com sucesso um usuário para confirmar uma transação, ele pode esvaziar a carteira do usuário de tokens, NFTs e até sol. portanto, se você vir uma transação envolvendo a transferência de muitos tokens, seja cauteloso, pois pode ser um hacker tentando esvaziar sua carteira usando este recurso.

4. roubo de assinaturas de transações

No ecossistema EVM, as assinaturas de permissão são favorecidas por grupos de phishing devido à sua furtividade e ao fato de que não aparecem na carteira do autorizador. Atualmente, mais da metade dos ataques de phishing usam esse método. No mundo Solana, há um método semelhante: nonce durável.

a função de nonce durável funciona de forma semelhante a uma permissão. Se um usuário assinar uma transação sem saber, eles não perderão imediatamente ativos ou verão essa transação em sua carteira. Em vez disso, as informações da transação assinada são enviadas para o grupo de phishing, que então enviam a transação para o blockchain. Essa característica de transação offline é tão perigosa quanto uma permissão.

como a solana pode simular resultados de transação, o nonce durável é mais legível do que o permit, tornando mais fácil para os usuários identificar. no entanto, os grupos de phishing têm combinado o nonce durável com atualizações de contrato para roubar ativos de forma mais eficaz, ao mesmo tempo ignorando avisos de simulação de transação.

os sites de phishing primeiro interagem com os utilizadores usando contratos normais sem transações maliciosas. a funcionalidade de simulação de transações da carteira não apresenta problemas nesta fase. uma vez que o utilizador aprova a transação, o grupo de phishing não a transmite imediatamente para a blockchain. em vez disso, eles esperam e depois atualizam o contrato para uma versão com código malicioso antes de o transmitir. o utilizador então descobrirá subitamente que os seus ativos estão em falta, muitas vezes dias após assinarem a transação.

Este método de ataque atualizado é extremamente furtivo e prejudicial. As funções atuais de simulação de transações não conseguem exibir esse risco. Portanto, é crucial manter alta vigilância e não depender demasiadamente dos avisos do software da carteira ou confiar cegamente nos resultados da simulação de transações.

conclusão

O objetivo original do design dessas funcionalidades era diminuir as barreiras para os utilizadores e proporcionar mais conveniência. No entanto, como uma espada de dois gumes, as novas tecnologias também forneceram aos grupos de phishing uma gama mais ampla de métodos de ataque.

mesmo antes de escrever este artigo, a solana lançou duas novas funcionalidades: action e blink. enquanto há muita expectativa em torno destas funcionalidades, alguns também alertaram sobre o potencial de grupos de phishing as explorarem.

O phishing na Solana é caracterizado por operações de um clique e alta furtividade. Devido à instabilidade do RPC e outras razões, as funções de simulação de transação podem nem sempre funcionar, portanto, não podem ser totalmente confiáveis.

Recomenda-se que os utilizadores com os meios utilizem uma carteira de hardware Keystone para as interações. Isto adiciona uma camada extra de confirmação, impedindo transações de confirmação rápida causadas por impulso ou cliques acidentais.

Além disso, o Keystone analisa transações no final do hardware. Em casos em que as simulações de transação da carteira de software falham, o hardware ainda pode analisar o conteúdo da transação, fornecendo a última linha de defesa.

A tecnologia blockchain está em constante evolução e transformação. Enquanto nos preocupamos com os riscos associados às novas tecnologias, não podemos parar de progredir. Os grupos de phishing são como pragas que todos querem eliminar, e os profissionais, incluindo fabricantes de carteiras de hardware e empresas de segurança, estão continuamente desenvolvendo soluções para enfrentar novas ameaças.

como utilizadores comuns, é essencial lembrarmo-nos de não sermos atraídos por "ofertas gratuitas", mas de analisar cuidadosamente os detalhes da transação. Com este nível de consciencialização em segurança, as tentativas de phishing são muito menos susceptíveis de ter sucesso.

disclaimer:

  1. Este artigo é republicado de [ Keystone]. todos os direitos autorais pertencem ao autor original [ keystone]. se houver objeções a esta reimpressão, por favor entre em contato com oGate aprenderequipa e eles vão tratar disso prontamente.
  2. aviso de responsabilidade: as opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
  3. as traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da Gate. salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.

Como evitar golpes de phishing do EVM para Solana?

IntermediárioJul 25, 2024
Este artigo descreve um caso de um utilizador que perdeu ativos devido a um golpe de phishing na Solana. Explica as diferenças entre as cadeias Solana e EVM e as suas táticas fraudulentas únicas, como a transferência de propriedade de conta de token, não necessidade de pré-autorização, permitindo múltiplas transferências de token numa única transação e usando Durable Nonce para fraude.
Como evitar golpes de phishing do EVM para Solana?

Recentemente, um usuário postou sobre a perda de milhões de RMB em ativos devido a um golpe de phishing no Solana. De acordo com a descrição, ele clicou erroneamente em um link postado por um grupo de phishing sob um tweet do projeto Maneki, levando-o a um site fraudulento.

o que o deixou confuso foi que, durante a interação, o site não parecia exigir qualquer operação de autorização de token, e o hacker conseguiu roubar os ativos diretamente. quando ele percebeu que poderia haver um problema com o site e tentou transferir tokens de sua carteira para evitar o roubo, descobriu que várias tentativas de transferência falharam e que já não podia retirar os seus ativos.

devido às informações limitadas fornecidas, não podemos recriar completamente a cena do incidente. no entanto, é claro que o usuário perdeu o controle da conta do token maneki, o que explica por que as tentativas de transferir ativos de sua carteira falharam. usuários acostumados ao EVM podem ficar confusos sobre o que significa controle de conta.

isso ocorre porque a solana usa uma implementação diferente da cadeia EVM. Continuar interagindo com a solana usando os hábitos da EVM é como usar uma espada desatualizada para lutar uma batalha moderna, o que inevitavelmente leva a riscos significativos.

Para desfrutar de jogar na solana, é essencial entender as características da solana e as táticas fraudulentas. Por esta razão, compilamos alguns dos métodos de ataque na solana que diferem dos do EVM, na esperança de ajudar os utilizadores menos familiarizados com a solana a evitarem armadilhas.

1. cuckoo no ninho: transferência de propriedade da conta de token

o protagonista do nosso caso de abertura encontrou este tipo de ataque. numa carteira solana, cada token tem uma conta separada (conta de token), semelhante a como uma conta bancária pode ter contas separadas para diferentes moedas como rmb e usd, que são independentes entre si. cada conta de token também tem um atributo de propriedade.

Por padrão, o proprietário de uma conta de token é designado como a carteira atual. No entanto, isso não está codificado. Ao chamar a operação createsetauthorityinstruction, a propriedade da conta de token pode ser alterada. Os hackers usam essa operação para enganar os usuários e transferir a propriedade de uma conta de token de sua carteira para a carteira do hacker.

uma vez bem-sucedido, mesmo que os tokens ainda estejam na carteira, o utilizador não os pode transferir, o que é essencialmente o mesmo que ter os tokens roubados.

devido ao alto risco desta operação, tanto o fantasma como @Backpack_CNas carteiras interceptam e alertam os utilizadores sobre os riscos da transação, exigindo uma segunda confirmação para a transação, a menos que o utilizador insista em aprová-la.

2. não é necessária nenhuma pré-autorização para transações na Solana

na evm, um contrato de phishing precisa que o usuário autorize o contrato no contrato do token antes que possa transferir tokens da carteira do usuário. o contrato de phishing só pode iniciar a transação para transferir os ativos do usuário após receber autorização.

no entanto, na solana, “aprovar” não significa autorização, mas sim aprovação da transação. se o usuário trata isso erroneamente como a etapa de autorização e aprova, a transação de phishing é enviada, deixando pouca chance de recuperação.

uma situação mais perigosa ocorre se o usuário for enganado a autorizar tokens na EVM, apenas o token autorizado é afetado e outros tokens não autorizados permanecem seguros. No Solana, como nenhuma autorização é necessária e apenas a aprovação do usuário é necessária para transferir tokens, combinado com o terceiro ponto que discutiremos a seguir, isso poderia resultar em perdas significativas para o usuário.

3. tenha cuidado ao ser induzido a transferir vários tokens

O design de transação da Solana permite que várias subtransações sejam incluídas em uma única transação, sendo que cada subtransação completa uma interação, como transferir um token específico. Em comparação com a EVM, onde a transferência de cada token requer uma transação separada, essa característica da Solana oferece alguma conveniência.

por exemplo, sua carteira pode conter alguns tokens com valor muito baixo, inferior a 1 usd. O sol-incinerator utiliza esse recurso para permitir que os usuários enviem em lote tokens de pequeno valor de sua carteira e os convertam de volta para sol sem a necessidade de várias conversões, o que consumiria muito gás e economizaria tempo operacional.

embora este recurso forneça conveniência, também facilita grandemente as atividades de phishing. se um hacker conseguir enganar com sucesso um usuário para confirmar uma transação, ele pode esvaziar a carteira do usuário de tokens, NFTs e até sol. portanto, se você vir uma transação envolvendo a transferência de muitos tokens, seja cauteloso, pois pode ser um hacker tentando esvaziar sua carteira usando este recurso.

4. roubo de assinaturas de transações

No ecossistema EVM, as assinaturas de permissão são favorecidas por grupos de phishing devido à sua furtividade e ao fato de que não aparecem na carteira do autorizador. Atualmente, mais da metade dos ataques de phishing usam esse método. No mundo Solana, há um método semelhante: nonce durável.

a função de nonce durável funciona de forma semelhante a uma permissão. Se um usuário assinar uma transação sem saber, eles não perderão imediatamente ativos ou verão essa transação em sua carteira. Em vez disso, as informações da transação assinada são enviadas para o grupo de phishing, que então enviam a transação para o blockchain. Essa característica de transação offline é tão perigosa quanto uma permissão.

como a solana pode simular resultados de transação, o nonce durável é mais legível do que o permit, tornando mais fácil para os usuários identificar. no entanto, os grupos de phishing têm combinado o nonce durável com atualizações de contrato para roubar ativos de forma mais eficaz, ao mesmo tempo ignorando avisos de simulação de transação.

os sites de phishing primeiro interagem com os utilizadores usando contratos normais sem transações maliciosas. a funcionalidade de simulação de transações da carteira não apresenta problemas nesta fase. uma vez que o utilizador aprova a transação, o grupo de phishing não a transmite imediatamente para a blockchain. em vez disso, eles esperam e depois atualizam o contrato para uma versão com código malicioso antes de o transmitir. o utilizador então descobrirá subitamente que os seus ativos estão em falta, muitas vezes dias após assinarem a transação.

Este método de ataque atualizado é extremamente furtivo e prejudicial. As funções atuais de simulação de transações não conseguem exibir esse risco. Portanto, é crucial manter alta vigilância e não depender demasiadamente dos avisos do software da carteira ou confiar cegamente nos resultados da simulação de transações.

conclusão

O objetivo original do design dessas funcionalidades era diminuir as barreiras para os utilizadores e proporcionar mais conveniência. No entanto, como uma espada de dois gumes, as novas tecnologias também forneceram aos grupos de phishing uma gama mais ampla de métodos de ataque.

mesmo antes de escrever este artigo, a solana lançou duas novas funcionalidades: action e blink. enquanto há muita expectativa em torno destas funcionalidades, alguns também alertaram sobre o potencial de grupos de phishing as explorarem.

O phishing na Solana é caracterizado por operações de um clique e alta furtividade. Devido à instabilidade do RPC e outras razões, as funções de simulação de transação podem nem sempre funcionar, portanto, não podem ser totalmente confiáveis.

Recomenda-se que os utilizadores com os meios utilizem uma carteira de hardware Keystone para as interações. Isto adiciona uma camada extra de confirmação, impedindo transações de confirmação rápida causadas por impulso ou cliques acidentais.

Além disso, o Keystone analisa transações no final do hardware. Em casos em que as simulações de transação da carteira de software falham, o hardware ainda pode analisar o conteúdo da transação, fornecendo a última linha de defesa.

A tecnologia blockchain está em constante evolução e transformação. Enquanto nos preocupamos com os riscos associados às novas tecnologias, não podemos parar de progredir. Os grupos de phishing são como pragas que todos querem eliminar, e os profissionais, incluindo fabricantes de carteiras de hardware e empresas de segurança, estão continuamente desenvolvendo soluções para enfrentar novas ameaças.

como utilizadores comuns, é essencial lembrarmo-nos de não sermos atraídos por "ofertas gratuitas", mas de analisar cuidadosamente os detalhes da transação. Com este nível de consciencialização em segurança, as tentativas de phishing são muito menos susceptíveis de ter sucesso.

disclaimer:

  1. Este artigo é republicado de [ Keystone]. todos os direitos autorais pertencem ao autor original [ keystone]. se houver objeções a esta reimpressão, por favor entre em contato com oGate aprenderequipa e eles vão tratar disso prontamente.
  2. aviso de responsabilidade: as opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
  3. as traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da Gate. salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.
Comece agora
Registe-se e ganhe um cupão de
100 USD
!