Nouvelle branche rapport + expe attaques

docs/rapportFinal/centralisation/attaques.tex

@@ -0,0 +1,104 @@
+% Auteur Romain TESTUD
+\subsubsection{Mise en contexte}
+Les \textit{blockchains} et leurs protocoles d'échanges ne sont pas exemptes d'attaques informatiques ou bien de défaillances.
+Ces attaques peuvent cibler des portefeuilles (attaques sur des \textit{hot wallets}\footnote{portefeuille de cryptomonnaies en ligne, à différencier des \textit{Cold Wallets}, des portefeuilles hors lignes}) ou encore des \textit{bridges}. 
+Ce sont ces dernières qui nous ont intéressées dans le cadre de ce projet de recherche sur les échanges inter-blockchains. 
+Les bridges, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{blockchains} différentes.\\
+Nous avons, au cours de nos recherches, trouvés de nombreux cas d'attaques sur des protocoles d'échanges inter-blockchains. 
+De manière à illustrer les types d'attaques possibles et les points critiques de ces systèmes nous allons décrire deux attaques parmi les plus importantes : \textit{Wormhole} et \textit{Nomad}.
+
+\subsubsection{Le cas Wormhole}
+Nous vous avons présenté le protocole \textit{Wormhole} dans la partie précédente. 
+Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{Dapp} sur la chaîne Solana \cite{SolMed} \cite{SolRekt}. 
+Pour se faire l'attaquant à réussi à contourner la vérification des signatures des gardiens en exploitant
+une correction de bug ayant été publié sur le code source du projet mais n'étant pas encore effective en production.
+Ainsi il à réussi à récupérer l'équivalent de 120 000 \textit{ETH} en \textit{whETH} (\textit{Wormhole ETH}). 
+Lors d'un transfert de jetons d'une chaîne à une autre, plusieurs étapes sont réalisées par différentes fonctions.
+Après la formulation de la transaction, une fonction va se charger de récupérer les signatures des gardiens dans un \textit{SignatureSet}\footnote{Ensemble de signatures de gardiens}, ces dernières sont ensuite vérifiées. 
+Pour cela, une fonction nommée \texttt{verify\_signature} va appeler un programme de vérification de Solana permettant l'analyse du \textit{SignatureSet}. 
+L'appel à ce programme se fait de la manière suivante, en utilisant le nom \texttt{sysvarinstruction} \cite{SolGitError} dans la transaction. 
+Dès lors que les signatures sont validées, un \textit{VAA} peut être émis et transmis vers la \textit{blockchain} souhaitée. \\
+La transaction de l'attaquant étant frauduleuse, il n'aurait donc pas pu obtenir de signatures des gardiens. 
+Pour contourner cette étape de récupération des signatures la transaction de l'attaquant était dotée d'un \textit{SignatureSet} correspondant à une transaction antérieure. 
+Seulement, n'étant pas pour la bonne opération cet ensemble ne peut pas être approuvé par \texttt{verify\_signature}. 
+C'est ici que l'attaquant à utilisé un défaut d'implémentation pour valider son \textit{SignatureSet}. 
+Comme décrit précédemment, la fonction \texttt{verify\_signature} appelle un programme pour effectuer la vérification des signatures. 
+Cependant il n'y à pas de vérification faites sur le programme appelé, l'attaquant à pu donc utiliser une adresse différente lui permettant de valider sa transaction. 
+Avec le  \texttt{SignatureSet} ainsi validé, l'attaquant a pu générer un \textit{VAA} valide et pu déclencher une frappe de jeton vers son propre compte sans en avoir déposé au préalable. 
+La correction de cette faille était contenue dans la mise à jour évoquée en début de paragraphe\cite{SolGitFixed}, permettant la vérification du programme appelé pour la vérification. 
+
+\subsubsection{Le cas Nomad}
+Nomad est un protocole d'interopérabilité entre chaînes permettant de passer des actifs entre deux \textit{blockchains} différentes. 
+Pour fonctionner, ce protocole fait appel à des applications décentralisées opérant sur les chaînes du réseau. 
+Une première \textit{Dapp} appelée \textit{réplica} est déployée sur les \textit{blockchains} recevant les messages, elle fait office de "boite de réception". 
+Une seconde \textit{Dapp} appelée \textit{home} est déployé sur les \textit{blockchains} émettrices de message. \\
+Le 1\textsuperscript{er} août 2022 une attaque exploitant une erreur d'implémentation sur l'application \textit{Réplica} a engendré une perte de 190 millions de dollars en liquidité \cite{NomadMedium} \cite{NomadRekt}.
+Cette attaque s'est déroulée après le déploiement d'une mise à jour, un moyen de contourner la vérification des signatures du message étant apparu. 
+En analysant l'application \textit{Réplica} après la mise à jour, nous pouvons voir que lors d'une initialisation, la racine des messages, appelée \texttt{\_commitedRoot}, est initialisée à $0$, ce signifiant que le message n'a pas encore été validé. 
+\begin{lstlisting}[caption={Fonction \textit{initialize} de \textit{Réplica} contenant une erreur \cite{NomadGitError}}]
+    function initialize(
+        uint32 _remoteDomain,
+        address _updater,
+        bytes32 _committedRoot,
+        uint256 _optimisticSeconds
+    ) public initializer {
+        __NomadBase_initialize(_updater);
+        // set storage variables
+        entered = 1;
+        remoteDomain = _remoteDomain;
+        committedRoot = _committedRoot;
+        // pre-approve the committed root.
+        confirmAt[_committedRoot] = 1;
+        _setOptimisticTimeout(_optimisticSeconds);
+    }
+\end{lstlisting}
+
+Dans les lignes précédentes nous observons cette affectation : \texttt{confirmAt[\_commitedRoot] = 1}, le rôle de cette ligne est de pré-approuver la racine d'un message. 
+Cette fonction est utilisée pour approuver le premier message lors du déploiement du contrat sur une \textit{blockchain}. 
+Or ici, la valeur de la racine à été initialisée a $0$, donc cette racine devient une racine valide pour la fonction de vérification des messages. 
+Seulement comme nous l'avons énoncé précédemment, $0$ est la valeur par défaut pour un message n'ayant pas encore été vérifié. 
+Ainsi, lors de l'émission d'un message par la fonction \texttt{process}, tout message non vérifié sera envoyé. 
+Cette erreur d'implémentation a permis à des pirates d'effectuer plusieurs transactions frauduleuses et de retirer l'équivalent de 190 Millions de dollars dans la réserve de liquidité du bridge de Nomad. 
+Le contrat à été corrigé, dans une mise en ligne datant du 3 Septembre 2022, tel que la racine $0$ n'est plus pré-approuvée. 
+
+\begin{lstlisting}[caption={Fonction corrigée de l'application \textit{Réplica} \cite{NomadGitFixed}}]
+    function initialize(
+        uint32 _remoteDomain,
+        address _updater,
+        bytes32 _committedRoot,
+        uint256 _optimisticSeconds
+    ) public initializer {
+        __NomadBase_initialize(_updater);
+        // set storage variables
+        entered = 1;
+        remoteDomain = _remoteDomain;
+        committedRoot = _committedRoot;
+        // pre-approve the committed root.
+        if (_committedRoot != bytes32(0)) confirmAt[_committedRoot] = 1;
+        _setOptimisticTimeout(_optimisticSeconds);
+    }
+\end{lstlisting}
+
+
+%\subsubsection{DeFi hacklabs}
+%Lors de nos recherches sur des attaques sur des protocoles inter-blockchains, nous avons découvert \textit{Web3sec}, un groupe de recherche centré sur la sécurité du web3. 
+%Le groupe met à disposition des ressources indexés sur une page notion (en annexe) :
+%\begin{itemize}
+%    \item Plusieurs dépots \textit{Github} pour étudier les attaques et apprendre les vulnérabilités sur ces types de programmes.
+%    \item \textit{DeFi Hacks Analysis - Root Cause} : Une base de données d'analyses d'attaques sur des solutions et organismes traitant sur des blockchains, les analyses sont sourcées et redirigent vers le dépot \textit{GitHub} de reproduction des attaques.
+%    \item Un ensemble d'outils utilitaires tels que des outils de debug de transaction, des dashboards ou encore des newletters.
+%\end{itemize}
+%Ces outils nous ont permis d'explorer de nombreuses sources concernant les attaques sur les protocoles interblockchains.
+
+\subsubsection{Contre-mesures et solutions envisageables}
+Comme nous avons pu le voir, de nombreux cas d'attaques sont observables sur des protocoles d'échanges centralisés. 
+Dans la plupart des cas, elles résultent de problèmes d'implémentations et autres oublis dans les codes sources des protocoles utilisés. 
+Cela peut être expliqué par le fait que la \textit{blockchain} est un domaine qui évolue très vite et chaque innovation technique peut rapporter des parts de marché importantes au premier arrivé. 
+De plus, de nombreux acteurs se spécialisent dans ce domaine sans nécessairement avoir une grande culture de la cybersécurité.
+Il se peut donc que des erreurs d'implémentations paraissant évidentes ne soient pas relevés lors de la mise en production. \\ 
+Des moyens de limiter le plus possible l'apparition de tels événements sont néanmoins possibles. 
+Tout d'abord des standards de sécurité pourraient être mis en place afin de déterminer un socle minimal à atteindre. 
+Des audits et des analyses de sécurité peuvent être mis en place pendant la production ou après la publication des protocoles, en respectant un cycle de développement "classique".
+%Nous pouvons aussi nous questionner quant à l'implication du tier de confiance dans l'apparition de ces failles. 
+%En effet, les attaques les plus importantes ont comme point d'entrée une faille dans la structure de l'intermédiaire. 
+%Cette menace constante d'attaques a mené à des recherches visant à soutirer ce tiers des échanges inter-blockchain. Ce menant aux échanges décentralisés.