Dan U décortique cette chaîne et révèle toute l’ampleur du piratage de Binance, avec des détails effrayants :
1. Quatre heures avant de passer à l’action, l’attaquant a fait une répétition avec 2,54 USDT. Même EOA, même fonction sweep(), même boîte à outils : il a d’abord testé toute la procédure d’attaque avec un petit portefeuille, pour vérifier qu’il n’y avait aucun bug, avant de s’en prendre au portefeuille chaud n° 14 de Binance.
2. Chronologie : à 20:20:59, le portefeuille a été placé sous délégation EIP-7702. Il a fallu attendre trois minutes et demie avant que les actifs commencent à être transférés.
En réalité, la surveillance de eth_getCode aurait permis de repérer cette anomalie depuis longtemps, mais personne n’y prêtait attention.
3. Le point essentiel : il ne s’agissait pas d’une seule signature, mais d’un tapis de signatures couvrant 50 nonce consécutifs.
La clé privée du portefeuille chaud de Binance avait signé à l’avance 50 autorisations. L’attaquant les a diffusées en masse, en misant sur le fait que l’un des nonce corresponde à l’état actuel du portefeuille. La clé privée n’a pas directement servi à envoyer des transactions : elle a simplement signé cette série d’autorisations.
4. Un retournement de situation spectaculaire : Binance a désamorcé la bombe sans le vouloir.
Les 50 signatures préparées par l’attaquant auraient pu être réutilisées à plusieurs reprises. Mais le robot de retrait de Binance a automatiquement exécuté 44 transactions ordinaires, consommant les nonce suivants et invalidant toutes les autorisations restantes qui n’avaient pas été utilisées. Binance ignorait totalement l’existence de ce piège : par hasard, elle a neutralisé les possibilités d’action restantes.
5. Le danger n’est pas écarté : ce portefeuille reste un piège actif.
La délégation malveillante est toujours associée à l’adresse du portefeuille ; eth_getCode permet de repérer le code malveillant.
De nouveaux dépôts d’utilisateurs continuent d’arriver sur ce portefeuille. À ce moment-là, il contenait environ 1,1 million de dollars et, en théorie, pouvait être vidé à nouveau à tout moment.
L’attaque a été soigneusement conçue, répétée à l’avance, préparée avec un tapis de nonce, puis Binance a neutralisé les possibilités restantes par un heureux hasard. Et le portefeuille contient toujours une bombe à retardement.
C’est bien plus qu’un simple vol de cryptomonnaies : c’est une attaque EIP-7702 digne d’un cas d’école.$BTC $ETH $LINK
1. Quatre heures avant de passer à l’action, l’attaquant a fait une répétition avec 2,54 USDT. Même EOA, même fonction sweep(), même boîte à outils : il a d’abord testé toute la procédure d’attaque avec un petit portefeuille, pour vérifier qu’il n’y avait aucun bug, avant de s’en prendre au portefeuille chaud n° 14 de Binance.
2. Chronologie : à 20:20:59, le portefeuille a été placé sous délégation EIP-7702. Il a fallu attendre trois minutes et demie avant que les actifs commencent à être transférés.
En réalité, la surveillance de eth_getCode aurait permis de repérer cette anomalie depuis longtemps, mais personne n’y prêtait attention.
3. Le point essentiel : il ne s’agissait pas d’une seule signature, mais d’un tapis de signatures couvrant 50 nonce consécutifs.
La clé privée du portefeuille chaud de Binance avait signé à l’avance 50 autorisations. L’attaquant les a diffusées en masse, en misant sur le fait que l’un des nonce corresponde à l’état actuel du portefeuille. La clé privée n’a pas directement servi à envoyer des transactions : elle a simplement signé cette série d’autorisations.
4. Un retournement de situation spectaculaire : Binance a désamorcé la bombe sans le vouloir.
Les 50 signatures préparées par l’attaquant auraient pu être réutilisées à plusieurs reprises. Mais le robot de retrait de Binance a automatiquement exécuté 44 transactions ordinaires, consommant les nonce suivants et invalidant toutes les autorisations restantes qui n’avaient pas été utilisées. Binance ignorait totalement l’existence de ce piège : par hasard, elle a neutralisé les possibilités d’action restantes.
5. Le danger n’est pas écarté : ce portefeuille reste un piège actif.
La délégation malveillante est toujours associée à l’adresse du portefeuille ; eth_getCode permet de repérer le code malveillant.
De nouveaux dépôts d’utilisateurs continuent d’arriver sur ce portefeuille. À ce moment-là, il contenait environ 1,1 million de dollars et, en théorie, pouvait être vidé à nouveau à tout moment.
L’attaque a été soigneusement conçue, répétée à l’avance, préparée avec un tapis de nonce, puis Binance a neutralisé les possibilités restantes par un heureux hasard. Et le portefeuille contient toujours une bombe à retardement.
C’est bien plus qu’un simple vol de cryptomonnaies : c’est une attaque EIP-7702 digne d’un cas d’école.$BTC $ETH $LINK