Il existe un nouveau schéma intéressant de la part des escrocs pour rendre les portefeuilles compromis complètement inutilisables, de sorte que vous ne puissiez envoyer aucun fonds pour des sauvetages. TL;DR : Si vous _auto-déléguez_ votre adresse de portefeuille avec EIP-7702, vous bridez complètement votre portefeuille. Alors, comment cela fonctionne-t-il ? Si vous définissez votre propre portefeuille EOA comme adresse de délégation, le code défini à votre portefeuille est `0xef0100 || votre_adresse`. Maintenant, selon l'EIP-7702, l'indicateur de délégation utilise l'opcode _interdit_ `0xef` pour indiquer que le code doit être traité différemment du code normal. Donc tout va bien ? Vous pourriez même penser que cela va créer une chaîne/une boucle de délégations potentiellement infinie, mais non, selon les spécifications : "les clients doivent récupérer uniquement le premier code et ensuite arrêter de suivre la chaîne de délégation." Donc, ce qui se passe, c'est que lorsque vous vous auto-déléguez à votre propre adresse, vous invoquez effectivement l'opcode invalide `0xef` pour chaque transaction passant par votre portefeuille et la transaction sera annulée.

c'est la découverte de sécurité la plus fascinante de 2025 selon moi : un "zero‑day" sur lequel les hackers se positionnaient discrètement, pariant qu'il resterait caché pendant que le bénéfice futur grandissait. heureusement, cela a été attrapé juste à temps par les gentils. travail exceptionnel de @deeberiroz @pcaversaccio @dedaub

RT @dobsec : « Aucune personne normale n'utilise un VPN » montre qu'il n'a clairement pas vu les milliards de créateurs faisant la promotion de VPN dans chaque vidéo.

BlockThreat - Semaine 28, 2025 💙 Sponsorisé par @SecurityOak 🔥 Exploitation massive de contrats proxy découverte par @deeberiroz et whitehatted par @pcaversaccio @dedaub et @_SEAL_Org 💸 @GMX_IO hack de réentrance de 42M$ (37M$ récupérés) 💸 @KintoXYZ proxy non initialisé. 1,55M$

Leçons pour les experts en sécurité : Auditez les proxys de manière rigoureuse. Surveillez les chaînes d’appels délégués (facile à faire dans notre application) et assurez l’intégrité du stockage avec des modèles de proxy complexes. Les accessoires vont à @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Restez vigilant.

J'ai donc découvert que c'est encore plus sophistiqué. J'ai observé que la transaction de frontrunning (par les attaquants) appelle `initialize` et que les protocoles appellent également _avec succès_ `initialize` après (ainsi ils pensent que tout est normal). Mais attendez, comment est-ce même possible ? J'ai dû examiner très en profondeur les changements de slot de stockage et devinez ce que j'ai trouvé : ils _réinitialisent_ la valeur du slot de stockage `_initialized` à la fin de la transaction de frontrunning (après avoir échangé avec le contrat d'implémentation malveillant). Cela signifie que le stockage du proxy semble maintenant comme s'il n'avait jamais été initialisé. Le slot de stockage pertinent à examiner est `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` C'est du mal de niveau supérieur.

Plus tôt cette semaine, une vulnérabilité potentielle dans le contrat de gestion inter-chaînes d'Orderly sur la chaîne BNB a été identifiée. En réponse, notre coffre BNB pour les dépôts et les retraits a été immédiatement suspendu, les contrats ont été migrés et les dépôts/retraits ont repris dans les 2 heures. ✅ Aucun fonds utilisateur n'est en danger, ni n'a été perdu. Un grand merci à @deeberiroz, @VennBuild, @seal_911, @pcaversaccio, et au reste de l'équipe qui a aidé à signaler cela ! Plus sûrs ensemble 🤝

[5/5] Appel à la gratitude • @SlowMist_Team pour le triage et les correctifs sans relâche • @dedaub, @pcaversaccio, et la salle de guerre @seal_911 pour un balayage de code de 36 heures • @etherscan pour un nettoyage de l'interface utilisateur ultra-rapide • Et encore une fois, merci @deeberiroz, @VennBuild, @davidberiro—votre alerte a sauvé la mise 💙

C'est encore plus sophistiqué : la façon dont Etherscan a été trompé en affichant le mauvais contrat d'implémentation repose sur la définition de 2 slots de proxy différents dans la même transaction de frontrunning. Ainsi, Etherscan utilise une certaine heuristique qui incorpore différents slots de stockage pour récupérer le contrat d'implémentation. Il existe un ancien proxy par OpenZeppelin qui utilisait le slot suivant : `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Nous avons maintenant aussi le slot standard EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Ce qui s'est passé, c'est que l'ancien slot de proxy OpenZeppelin a été écrit avec l'adresse d'implémentation bénigne _et_ le slot standard EIP-1967 a également été écrit avec l'adresse d'implémentation malveillante. Puisqu'Etherscan interroge d'abord l'ancien slot de proxy, il a récupéré le premier qui semblait bénin et l'a donc affiché.

RT @devops199fan: .@seal_911 sert essentiellement de centre d'opérations de sécurité global (GSOC) bénévole pour la crypto. Nous avons de la chance d'avoir des gens comme…