Cet article est compilé et organisé par BlockWeeks
La plateforme Ostium a été exploitée par un attaquant, environ 24 millions de dollars USDC ont été volés, impliquant huit transactions. L'attaquant, en détenant simultanément les clés de signature des oracles autorisés et le rôle de préposé PriceUpKeep, a soumis des rapports de prix signés correctement pour des dates futures, et a ouvert et fermé à plusieurs reprises des paires de trading, créant ainsi des profits fictifs sans aucune exposition réelle au marché.
L'attaque s'est produite en huit transactions, chaque fonds étant transféré vers le même portefeuille 0x321Df1…8bfD9, dont le plus grand transfert unique était une opération d'ouverture-fermeture cyclique exécutée dans un lot atomique. Ostium fonctionne sur Arbitrum, permettant aux utilisateurs de négocier des dérivés sous forme de contrats à terme qui suivent le prix des actifs sous-jacents, mais sans livraison de l'actif sous-jacent ni date d'échéance fixe.
Le problème provient de la manière dont le système d'oracles d'Ostium autorise les données de prix. Le validateur reçoit les rapports de prix, dérive l'identité du signataire à partir de la signature, et vérifie si le signataire est dans la liste autorisée. Il ne vérifie que l'identité du signataire, et non l'exactitude du prix lui-même. L'attaquant, détenant à la fois les clés de signature des oracles autorisés et le rôle de préposé PriceUpKeep enregistré (responsable de l'exécution des ordres en attente), a utilisé cette combinaison pour soumettre des rapports de prix signés correctement pour des dates futures, puis a ouvert et fermé à plusieurs reprises des paires de trading qui se compensaient. Cela leur a permis de générer des profits commerciaux du point de vue du système, sans aucune exposition réelle au marché.
L'incident d'Ostium est l'une des nombreuses vulnérabilités majeures au niveau des applications cette année, y compris les cas de Drift et de rsETH de KelpDAO. Un thème commun est que les contrats intelligents et leur logique restent robustes, les attaquants ciblant principalement l'infrastructure opérationnelle et la confiance humaine - dans le cas d'Ostium, des identifiants de signataire compromis, dans le cas de Drift, une prise de contrôle pré-signée par ingénierie sociale, et dans le cas de KelpDAO, une infrastructure RPC empoisonnée.
Après ces exploits très médiatisés, certains appellent à des mesures de protection des fonds des utilisateurs au niveau des applications, telles que des restrictions de retrait, pour dissuader les comportements malveillants et limiter les pertes en cas de vulnérabilité. De telles suggestions devraient être rejetées.
Restreindre les retraits introduirait un risque direct de censure au niveau de l'application. Une fois qu'un protocole peut unilatéralement retarder ou limiter les dépôts ou retraits des utilisateurs, le concept d'auto-conservation de cette couche d'application ne serait plus absolu, mais conditionnel. Dans ce cas, c'est l'application, et non l'utilisateur, qui décide de la disponibilité et de l'utilisation des fonds. Une telle pratique brouillerait également la frontière entre attaquants et utilisateurs ordinaires, car les mesures de protection conçues pour dissuader les attaques s'appliqueraient nécessairement à tous les utilisateurs de l'application.
Le risque d'« effet de pente glissante » aggrave encore ce problème. Une fois qu'un protocole a techniquement la capacité de restreindre ou de geler les dépôts/retraits, cette capacité devient un précédent. Les régulateurs pourraient citer cela comme preuve que ces applications disposent déjà des outils pour répondre aux ordres de gel, aux exigences de KYC ou à d'autres demandes, et devraient donc être obligées de le faire. Les mesures de protection construites pour dissuader les attaques pourraient devenir un crochet tirant les protocoles vers des obligations qu'ils ne pourraient autrement pas assumer.
De plus, les participants innocents du marché seraient incités à contourner les frictions causées par ces mesures. Par exemple, les utilisateurs restreints cherchant des moyens de sortir de leur exposition économique signifient généralement l'émergence d'un objet de réclamation négociable pour combler le vide (comme des jetons de reçu, des IOU, des substituts enveloppés de crypto). Cette réclamation elle-même devient une nouvelle dépendance avec son propre profil de risque - au niveau du marché (ancrages pouvant se briser, décotes élargies en période de panique) et au niveau technique (nouveaux contrats, nouveaux oracles, nouvelles entités exploitables indépendamment de l'application). Les mesures de protection destinées à contenir un point de défaillance unique finissent par exacerber la vulnérabilité qu'elles tentent de prévenir.
Ce type de contenu ne signifie pas que les protocoles ne devraient pas renforcer ce qui échoue effectivement (par exemple, la gestion des clés de signature, la redondance des validateurs). Mais la façon de remédier aux faiblesses de l'infrastructure opérationnelle et de la confiance humaine est de renforcer ces aspects, et non d'ajouter un contrôle arbitraire sur les fonds des utilisateurs, ce qui affaiblirait la proposition de valeur centrale de ce qui est protégé.
