Bienvenue de nouveau dans le Spotlight sur les Vulnérabilités de Sherlock, où nous mettons en lumière une vulnérabilité impactante découverte lors d'un audit de Sherlock. Cette semaine, nous avons le Spoofing de Dépôt. Il a été découvert par @0xalpharush et @bernd_eth lors du Concours Cross-Chain de @zetablockchain. 🧵

Voici le résumé de la vulnérabilité par @bernd_eth : 1. Les observateurs de ZetaChain surveillent les transactions sur des chaînes externes (par exemple, Ethereum, Solana) et les ajoutent à un traqueur centralisé des entrées pour les traiter comme des dépôts et des retraits, en supposant le succès de la transaction. 2. Contrairement à l'intégration EVM, l'implémentation de Solana omet les vérifications de succès des transactions, permettant à un observateur malveillant d'ajouter des dépôts échoués, créant ainsi des ZRC20 SOL non garantis et drainant les fonds transférés. 3. Bien que les observateurs soient explicitement autorisés par ZetaChain, il est crucial de s'assurer qu'aucune partie unique ne puisse compromettre la chaîne ou siphonner des actifs.

Normalement, les observateurs ne traitent pas les transactions échouées, mais ce chemin de code ne parvient pas à effectuer la même validation que son homologue EVM. Bien que cela nécessite un rôle "privilégié", chaque validateur est un observateur, et le consensus BFT est censé être tolérant aux Byzantins, c'est-à-dire tolérer <1/3 des parties malveillantes. Ainsi, un observateur malveillant ne devrait pas être en mesure de falsifier un dépôt et d'inciter des validateurs honnêtes à voter pour frapper des ZRC20 Sol pour des transactions échouées via le traqueur entrant, qui manque de validations pour son implémentation Solana.

La cause profonde de cette vulnérabilité : La fonction ProcessInboundEvents ne nécessite pas qu'une transaction ait réussi, contrairement à l'observateur entrant EVM, qui le fait correctement ici. Étant donné que l'instruction est décodée comme si elle avait réussi, un observateur malveillant peut simuler un dépôt pour l'intégralité du solde ZRC20-SOL, puis retirer le SOL verrouillé du côté Solana du pont, volant ainsi tous les lamports dans le pont. Cette attaque pourrait également être utilisée pour retirer des jetons SPL ou effectuer des dépôts et des appels arbitraires. Par exemple, retirer la propriété modifiable du PDA de la passerelle dans l'instruction de dépôt entraîne une transaction échouée (voir l'erreur de contrainte d'ancre dans le POC), et elle peut toujours être traitée une fois ajoutée au traqueur entrant via MsgAddInboundTracker.

Conditions préalables internes : Un observateur malveillant ou négligent ajoute une transaction Solana échouée contenant des instructions Gateway au traqueur entrant en utilisant MsgAddInboundTracker, ce qui entraîne le traitement et le vote de tous les validateurs pour frapper du ZRC20 Sol sur Zetachain. Le CCTX reçoit suffisamment de votes, et du ZRC20 Sol non garanti est frappé sur Zetachain.

Conditions préalables externes : Toute partie envoie une transaction échouée à la passerelle avec une instruction de dépôt (ou dépôt et appel). Le destinataire du ZRC20 Sol sur Zetachain le retire et reçoit des lamports sur Solana.

Le chemin d'attaque : 1) Toute partie envoie une transaction échouée à la passerelle avec une instruction de dépôt (ou dépôt et appel). 2) Un observateur malveillant ou négligent ajoute une transaction Solana échouée contenant des instructions de passerelle au traqueur entrant en utilisant MsgAddInboundTracker, ce qui entraîne le traitement et le vote de tous les validateurs pour frapper du ZRC20 Sol sur Zetachain. 3) La tâche ProcessInboundTrackers fait en sorte que le CCTX falsifié reçoive suffisamment de votes, et du ZRC20 Sol non soutenu est frappé sur Zetachain. 4) Le destinataire du ZRC20 Sol sur Zetachain le retire et reçoit des lamports sur Solana.

Quel est l'impact ? Tous les lamports et les tokens SPL déposés dans le pont Solana peuvent être volés, étant donné que les dépôts peuvent être falsifiés pour n'importe quel montant (ils sont traités malgré le fait que le programme Gateway provoque le retour des transactions).

L'atténuation : Dans le traitement du traqueur entrant de l'Observateur Solana, vérifiez si la transaction est réussie avant de voter dessus.

Nous sommes fiers d'avoir aidé à sécuriser @zetablockchain grâce à cette découverte. Quand il faut absolument que ce soit sécurisé, Sherlock est le bon choix.