Quand l’oracle ne voit plus rien

1- Pourquoi un Oracle ? 

Le monde de la blockchain avait promis une révolution de la finance traditionnelle et de ses utilisations. La réinvention du cash à travers le bitcoin [1] n’était que le début d’une série de papiers scientifiques et de livres blancs décrivant plusieurs cas d’utilisation de la blockchain. 

L’un des papiers les plus importants était le livre blanc décrivant l’Ethereum Virtual Machine (EVM) [2] : la conception d’une machine décentralisée exécutant des « smart contracts » moyennant des frais appelés « carburant » ou « gas fee » payés aux mineurs pour les inciter à valider les transactions. Ce livre blanc a décrit plusieurs applications de smart contracts permettant d'importer des concepts du monde de la finance traditionnelle dans la blockchain. 

Les « smart contracts » [3] sont des programmes publiés sur la blockchain. Ces programmes mettent à disposition des utilisateurs de la blockchain une adresse contenant une liste de fonctions exécutables sous conditions. Concrètement, l’exécution d’une fonction d’un smart contract se traduit par une transaction avec cette adresse dans la blockchain en question et dont le résultat est ensuite publié dans un bloc. Cette adresse peut ainsi contenir de la monnaie utilisée sur cette blockchain. 

Cependant, la nature immuable de la blockchain fait qu’un résultat donné par un smart contract ne peut pas changer au fil du temps, ni être influencé par le monde extérieur. Ceci pose problème lorsque l’on veut utiliser des données évoluant avec le temps, comme par exemple un taux de change lors d’une transaction permettant d’échanger des Ethereums (ETH) contre des Bitcoins (BTC). En effet, il faudrait alors utiliser le même taux de change, qu’il s’agisse de sa première exécution ou de son exécution un an après, puisque la valeur fixée dans le smart contract ne peut pas évoluer. 

Par ailleurs, une transaction s’appuyant sur une simple requête HTTP pour récupérer une donnée, comme le cours de change ETH-BTC, peut mettre le mécanisme de consensus en défaut car un nœud basé en France risque d’avoir un résultat différent d’un nœud chinois, bloqué par le grand pare-feu de la Chine. 

Pour répondre à ces problématiques, une classe de smart contracts nommée oracle est apparue. 

Découvrez notre expertise sur la sécurisation de smart contracts et infrastructures blockchain

2- Les oracles  

Les oracles sont généralement considérés comme des sources d’information provenant du monde extérieur (en dehors de la blockchain). Ces sources d’information s’avèrent importantes dans des cas d’usage allant des échanges décentralisés jusqu’aux plateformes de paris sportifs. 

Les oracles utilisés par les protocoles de finance décentralisée peuvent se diviser en 4 catégories [4] en fonction de la position de la source des informations par rapport à la blockchain, et de leur degré de centralisation : 

• La source peut provenir directement de l’extérieur ou être interne à la blockchain : On-Chain ou Off-Chain. 
• La mise à jour d’un oracle peut être déclenchée soit par une entité centrale, on dit que l’oracle est centralisé, soit par n’importe qui, on parle alors d’oracle décentralisé. 

La combinaison des critères précédents conduits aux cas de figures résumé dans le tableau ci-dessous : 

Les oracles sont utilisés comme source de données par les échanges décentralisés recréant l'environnement de marché. Cet usage est actuellement très populaire, ce qui a mené de nombreux acteurs à s’intéresser à ces smart-contracts et à chercher s’ils présentent des failles. 

Il existe d’autres types d’applications des oracles (e.g. résultat de match de foot, génération de nombres aléatoires...), mais ils ne seront pas abordés dans cet article. 

3- Des millions de dollars dérobés 

En 2022, plusieurs attaques sur des protocoles de finance décentralisée ont fait la une des journaux. 

Nous allons voir ici une compilation de quelques-uns de ces cas réels d’attaques. Ils couvrent une bonne partie des types d’attaques possibles sur les oracles ou exploitant des défauts d’utilisation d'un oracle. 

3-1 Manipulation d’oracle  

En mai 2022, le protocole « fortress » a été vidé entièrement. Plus précisément, des attaquants ont réussi à subtiliser toutes les devises présentes sur le smart-contract du protocole. Des analyses post mortem ont montré que cela est dû à une manipulation de l’oracle utilisé par ce protocole : « umbrella network ». 

En effet, un commit sur le code de cet oracle, introduisant un bug permettant la manipulation de l’oracle sur cette ligne de code en la commentant, a été déployé sans que le code soit audité comme il aurait dû l’être [5]. 

Cette vulnérabilité est passée inaperçue pendant presque 9 mois avant qu’elle soit exploitée. 

3-2 L’(in)sécurité de chainlink 

Toujours en mai 2022, la crypto-monnaie $LUNA a connu un crash très violent dû à une vulnérabilité économique. Nous avions alors fait une explication plus détaillée de ce crash. 

Le crash brusque et violent de cette monnaie a activé une « sécurité » de l’oracle de chainlink qui bloquait le prix de la crypto-monnaie à 0.1$ alors que celle-ci continuait réellement à chuter. 

La sécurité implémentée par chainlink, l’un des oracles les plus utilisés dans l'écosystème, agissait comme disjoncteur dans le cas de fluctuations importantes, au-delà de seuils prédéfinis. Cela permet en théorie d’éviter la manipulation de l’oracle par un attaquant. Or ce seuil a été franchi lors du crash de $LUNA, qui valait à l'époque 0.000042$, ce qui permettait aux attaquants de multiplier leur mise par environ 2000. 

3-3 La faute n’est pas toujours celle des oracles 

Quelques jours après le crash de $LUNA, son créateur a lancé une nouvelle crypto-monnaie corrigeant les défauts de sa première expérience. Mais pour ce dernier, il était hors de question de laisser tomber le nom « LUNA ». 

Il a donc eu l’idée de changer le nom de la monnaie vulnérable en $LUNC (C pour classique) et de nommer la nouvelle $LUNA. Une telle substitution devrait être prise en compte dans tous les échanges à partir de la sortie de la nouvelle crypto-monnaie et nécessitait donc une synchronisation entre les oracles et les protocoles. 

Plusieurs oracles ont ainsi bien fait la modification de nom, mais quelques protocoles utilisant ces oracles n’ont, malheureusement, pas effectué la migration entre les deux cryptomonnaies au même moment. Certains ont ainsi été vulnérables pendant plusieurs jours, au cours desquels les attaquants pouvaient vendre des $LUNC au prix du $LUNA, ce qui était permettait la encore aux attaquants de multiplier énormément leur mise. 

En effet, lors du lancement du nouveau $LUNA, les deux monnaies n’avaient pas le même prix (1 $LUNA = 50000 $LUNC). 

4- Comment se protéger ? 

Il est évident que quel que soit le type d’oracle utilisé, une attaque est toujours possible. L’un des moyens pour se protéger en tant que développeur de smart contract, est d’utiliser plusieurs oracles réputés et bien audités afin d’éviter que les attaques sur ces derniers n’impactent directement les développeurs de smart contract. De plus, les résultats donnés par ces oracles devront être agrégés à l’aide d’une fonction résistante aux manipulations (i.e. la médiane) afin de s’assurer qu’un attaquant doive forcément compromettre une majorité d’oracles afin de parvenir à attaquer le « smart-contract ». 

5- Conclusion 

La confiance accordée aux oracles et le potentiel de profit financier (légal ou illégal) qu’ils permettent, en cas de compromission, font d’eux une cible idéale pour les attaquants. Il est donc primordial de les utiliser en connaissant les risques qui leur sont associés et en sachant comment les minimiser. 

Références 

[1] https://bitcoin.org/bitcoin.pdf 

[2] https://ethereum.org/fr/developers/docs/smart-contracts/ 

[3] https://medium.com/umbrella-network/post-mortem-chain-exploit-2022-05-08-6007801b321d 

[4] https://medium.com/beaver-smartcontract-security/defi-security-lecture-7-price-oracle-manipulation-d716cdeaaf77 

[5] https://blog.chain.link/circuit-breakers-and-client-diversity-within-the-chainlink-network/