Lors de l'interaction avec les DApps, les utilisateurs doivent faire attention à contrôler le nombre de jetons autorisés, à vérifier le contenu de la signature et les situations d'autorisation anormales.
Écrit par : Lisa
arrière-plan
Le 11 mai, l'utilisateur de Twitter "pineapple.eth" a tweeté que son portefeuille avait été volé en raison d'un clic erroné sur un site Web de phishing (syncswap[.]network), et qu'il avait perdu plus de 100 $.
(
Bien que le montant des pertes ne soit pas important, il cache un énorme risque pour la sécurité. Les victimes perdent souvent d'énormes biens en raison du risque de signature « discret » de « ne pas pouvoir voir ». C'est pourquoi nous avons écrit cet article.
Selon la description de la victime, les transactions volées sont les suivantes :
(
(
A partir de ces deux transactions, l'appelant du contrat (0x00002…d0000) transfère 34,87 USDC sur l'adresse de la victime (0xA4089…82C3) vers (0x8256…D6B8) et transfère 81,36 USDC vers (0x5A69… 1C17). Si vous regardez simplement la fonction transferFrom, il n'est pas difficile de constater que la fonction de cette fonction est de permettre à un tiers d'initier une transaction pour transférer les actifs numériques pertinents du compte du propriétaire vers le compte du destinataire.
Ensuite, analysez l'adresse de l'appelant du contrat (0x00002...d0000) et découvrez qu'il existe une opération d'autorisation supplémentaire, qui ne figure pas dans les enregistrements de transaction de la victime. Quel est le rôle du permis ?
(
Qu'est-ce qu'un permis ?
Selon l'introduction officielle, le permis a été introduit dans le protocole ERC20 dans EIP-2612, et les utilisateurs peuvent interagir avec le contrat d'application en joignant une signature d'autorisation (permis) sans autorisation préalable. Plus précisément, nous savons tous que dans la transaction de la devise ERC20, A peut appeler la fonction d'approbation pour autoriser B, c'est-à-dire autoriser le jeton spécifié par A à un autre compte à fonctionner, et doit être le propriétaire de ce compte pour appeler approuver fonction. La fonction de la fonction permit est que A signe l'objet d'autorisation à l'avance sous la chaîne, et informe B de la signature obtenue, et B peut utiliser cette signature pour appeler permit afin de réaliser l'opération d'autorisation de A (utilisez transferFrom pour transférer l'autorisation ) , A peut transférer le jeton spécifié sans envoyer la transaction, et qu'il soit propriétaire du compte ou non, il peut exécuter le permis pour autoriser l'opération. De plus, Uniswap a publié une nouvelle norme d'autorisation de jeton Permit2.
Voici une comparaison entre approuver et autoriser :
fonction approuver (adresse usr, uint wad) retours externes (bool)
{
allocation[msg.expéditeur] [usr] = bourre ;
…
}
permis de fonction(
titulaire d'adresse, dépense d'adresse,
uint256 nonce, expiration uint256, bool autorisé,
uint8 v, bytes32 r, bytes32 s
) externe {
…
allocation [holder] [spender] = bourre ;
…
}
Après avoir compris les bases, puis être revenu à l'événement de phishing lui-même, vous pouvez envoyer cette fonction d'autorisation avec 7 paramètres :
propriétaire : adresse autorisée
dépensier : Qui est autorisé à
valeur : le nombre de jetons autorisés donné
date limite : est un horodatage, valable uniquement avant l'heure indiquée
v, r, s : données de signature
Parmi eux, le délai est 1714509304969 et la valeur est 116239404, ce qui signifie que l'autorisation est valable jusqu'à 0h42 le 22 août 56300 (GMT), presque indéfiniment. Et le nombre de jetons autorisés est de 116,239404 USDC, ce qui correspond au montant volé par la victime. Les valeurs de v, r et s sont les données de signature après que l'utilisateur (propriétaire) a signé sur le site Web de phishing, et la fonction d'autorisation vérifiera la validité des données de signature. Une fois la vérification de la signature réussie, le jeton de l'utilisateur sera autorisé au pirate (dépenseur).
L'ensemble du processus est très clair : la victime a signé la signature et l'a envoyée au site Web de phishing, mais ne l'a pas téléchargée sur la chaîne. Après avoir obtenu les informations de signature, le pirate a soumis le permis sur la chaîne, c'est-à-dire appelé approuver pour autorisation. . La signature se fait hors chaîne sans dépenser de gaz. Mais il doit être clair que pas de gaz ici ne signifie pas qu'il n'y a pas de consommation de gaz, mais que le signataire (victime) n'a pas besoin de payer de gaz pour l'autorisation et le transfert.
Sans aucun doute, comme pour approuver le phishing autorisé, l'autorisation est plus dangereuse que l'approbation du phishing autorisé, après tout, tant que la signature est volée, l'autorisation est obtenue. Par exemple, la fonction de commande en attente dans dex n'a besoin que de l'utilisateur pour signer un certain message, et l'utilisateur peut confier l'actif au dex pour traitement sans payer de gaz.Les actifs de l'utilisateur peuvent être perdus. Pour autant que nous le sachions, certains portefeuilles décoderont et afficheront les informations de signature du phishing d'autorisation d'approbation, mais le portefeuille n'a presque aucun avertissement pour le phishing de signature d'autorisation, et les utilisateurs courent un risque plus élevé d'être attaqués. Dans le même temps, la signature de permis est un comportement hors chaîne et il est difficile pour les utilisateurs de remarquer si leurs signatures ont été divulguées.
MistTrack
À l'heure actuelle, l'adresse du pirate a été marquée comme une adresse de phishing malveillante par MistTrack.
Les deux USDC de la victime ont été échangés contre des ETH.
En utilisant MistTrack pour analyser ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, APE, le bénéfice actuel de l'adresse 1 est d'environ 120 000 dollars américains, le bénéfice de l'adresse 2 est d'environ 200 000 dollars américains et le bénéfice d'adresse 3 Environ 2 000 $. De plus, selon l'analyse de Scam Sniffer, une plateforme anti-fraude Web3, au 9 mai, plus de 300 victimes au total se sont fait voler environ 690 000 $ US d'actifs par des signatures malveillantes basées sur Permit2. sur Uniswap au 9 mai Jusqu'à présent, près de 670 000 adresses sur le réseau principal Ethereum ont autorisé Permit2. Bien sûr, ces données ne sont que la pointe de l'iceberg pour l'ensemble de ce gang.
Résumer
Cet article commence principalement par un cas réel de vol et introduit le risque de la signature du permis. L'équipe de sécurité de SlowMist vous rappelle de ne pas ouvrir les sites Web d'origine inconnue pour fonctionner à volonté.Lorsque vous interagissez avec les DApps, veillez à contrôler le nombre de Tokens autorisés au contrat et vérifiez attentivement le contenu de la signature.Utilisez des outils d'autorisation tels que RevokeCash de temps en temps à temps (vérifiez les autorisations anormales, et vous pouvez également utiliser l'outil de gestion des autorisations pour Uniswap Permit2 (pour vérifier, s'il y a une autorisation anormale, veuillez annuler l'autorisation à temps.
Lien de référence :
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Autoriser l'analyse des signatures : les signatures hors chaîne peuvent-elles également attraper votre Token ?
Écrit par : Lisa
arrière-plan
Le 11 mai, l'utilisateur de Twitter "pineapple.eth" a tweeté que son portefeuille avait été volé en raison d'un clic erroné sur un site Web de phishing (syncswap[.]network), et qu'il avait perdu plus de 100 $.
(
Bien que le montant des pertes ne soit pas important, il cache un énorme risque pour la sécurité. Les victimes perdent souvent d'énormes biens en raison du risque de signature « discret » de « ne pas pouvoir voir ». C'est pourquoi nous avons écrit cet article.
Selon la description de la victime, les transactions volées sont les suivantes :
(
A partir de ces deux transactions, l'appelant du contrat (0x00002…d0000) transfère 34,87 USDC sur l'adresse de la victime (0xA4089…82C3) vers (0x8256…D6B8) et transfère 81,36 USDC vers (0x5A69… 1C17). Si vous regardez simplement la fonction transferFrom, il n'est pas difficile de constater que la fonction de cette fonction est de permettre à un tiers d'initier une transaction pour transférer les actifs numériques pertinents du compte du propriétaire vers le compte du destinataire.
Ensuite, analysez l'adresse de l'appelant du contrat (0x00002...d0000) et découvrez qu'il existe une opération d'autorisation supplémentaire, qui ne figure pas dans les enregistrements de transaction de la victime. Quel est le rôle du permis ?
(
Qu'est-ce qu'un permis ?
Selon l'introduction officielle, le permis a été introduit dans le protocole ERC20 dans EIP-2612, et les utilisateurs peuvent interagir avec le contrat d'application en joignant une signature d'autorisation (permis) sans autorisation préalable. Plus précisément, nous savons tous que dans la transaction de la devise ERC20, A peut appeler la fonction d'approbation pour autoriser B, c'est-à-dire autoriser le jeton spécifié par A à un autre compte à fonctionner, et doit être le propriétaire de ce compte pour appeler approuver fonction. La fonction de la fonction permit est que A signe l'objet d'autorisation à l'avance sous la chaîne, et informe B de la signature obtenue, et B peut utiliser cette signature pour appeler permit afin de réaliser l'opération d'autorisation de A (utilisez transferFrom pour transférer l'autorisation ) , A peut transférer le jeton spécifié sans envoyer la transaction, et qu'il soit propriétaire du compte ou non, il peut exécuter le permis pour autoriser l'opération. De plus, Uniswap a publié une nouvelle norme d'autorisation de jeton Permit2.
Voici une comparaison entre approuver et autoriser :
fonction approuver (adresse usr, uint wad) retours externes (bool)
{
allocation[msg.expéditeur] [usr] = bourre ;
…
}
permis de fonction(
titulaire d'adresse, dépense d'adresse,
uint256 nonce, expiration uint256, bool autorisé,
uint8 v, bytes32 r, bytes32 s
) externe {
…
allocation [holder] [spender] = bourre ;
…
}
Après avoir compris les bases, puis être revenu à l'événement de phishing lui-même, vous pouvez envoyer cette fonction d'autorisation avec 7 paramètres :
Parmi eux, le délai est 1714509304969 et la valeur est 116239404, ce qui signifie que l'autorisation est valable jusqu'à 0h42 le 22 août 56300 (GMT), presque indéfiniment. Et le nombre de jetons autorisés est de 116,239404 USDC, ce qui correspond au montant volé par la victime. Les valeurs de v, r et s sont les données de signature après que l'utilisateur (propriétaire) a signé sur le site Web de phishing, et la fonction d'autorisation vérifiera la validité des données de signature. Une fois la vérification de la signature réussie, le jeton de l'utilisateur sera autorisé au pirate (dépenseur).
L'ensemble du processus est très clair : la victime a signé la signature et l'a envoyée au site Web de phishing, mais ne l'a pas téléchargée sur la chaîne. Après avoir obtenu les informations de signature, le pirate a soumis le permis sur la chaîne, c'est-à-dire appelé approuver pour autorisation. . La signature se fait hors chaîne sans dépenser de gaz. Mais il doit être clair que pas de gaz ici ne signifie pas qu'il n'y a pas de consommation de gaz, mais que le signataire (victime) n'a pas besoin de payer de gaz pour l'autorisation et le transfert.
Sans aucun doute, comme pour approuver le phishing autorisé, l'autorisation est plus dangereuse que l'approbation du phishing autorisé, après tout, tant que la signature est volée, l'autorisation est obtenue. Par exemple, la fonction de commande en attente dans dex n'a besoin que de l'utilisateur pour signer un certain message, et l'utilisateur peut confier l'actif au dex pour traitement sans payer de gaz.Les actifs de l'utilisateur peuvent être perdus. Pour autant que nous le sachions, certains portefeuilles décoderont et afficheront les informations de signature du phishing d'autorisation d'approbation, mais le portefeuille n'a presque aucun avertissement pour le phishing de signature d'autorisation, et les utilisateurs courent un risque plus élevé d'être attaqués. Dans le même temps, la signature de permis est un comportement hors chaîne et il est difficile pour les utilisateurs de remarquer si leurs signatures ont été divulguées.
MistTrack
À l'heure actuelle, l'adresse du pirate a été marquée comme une adresse de phishing malveillante par MistTrack.
Adresse 1 : 0x00002644e79602F056B03235106A9963826d0000
Adresse 2 : 0x82563Ba592986Cb277d67B2E7c56ab3BB3FDD6B8
Adresse 3 : 0x5A697967F0791d12db8A0f92344Abc6DD07a1C17
Les deux USDC de la victime ont été échangés contre des ETH.
En utilisant MistTrack pour analyser ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, APE, le bénéfice actuel de l'adresse 1 est d'environ 120 000 dollars américains, le bénéfice de l'adresse 2 est d'environ 200 000 dollars américains et le bénéfice d'adresse 3 Environ 2 000 $. De plus, selon l'analyse de Scam Sniffer, une plateforme anti-fraude Web3, au 9 mai, plus de 300 victimes au total se sont fait voler environ 690 000 $ US d'actifs par des signatures malveillantes basées sur Permit2. sur Uniswap au 9 mai Jusqu'à présent, près de 670 000 adresses sur le réseau principal Ethereum ont autorisé Permit2. Bien sûr, ces données ne sont que la pointe de l'iceberg pour l'ensemble de ce gang.
Résumer
Cet article commence principalement par un cas réel de vol et introduit le risque de la signature du permis. L'équipe de sécurité de SlowMist vous rappelle de ne pas ouvrir les sites Web d'origine inconnue pour fonctionner à volonté.Lorsque vous interagissez avec les DApps, veillez à contrôler le nombre de Tokens autorisés au contrat et vérifiez attentivement le contenu de la signature.Utilisez des outils d'autorisation tels que RevokeCash de temps en temps à temps (vérifiez les autorisations anormales, et vous pouvez également utiliser l'outil de gestion des autorisations pour Uniswap Permit2 (pour vérifier, s'il y a une autorisation anormale, veuillez annuler l'autorisation à temps.