pfe-blockchain/docs/rapportFinal/centralisation/attaques.tex

% Auteur Romain TESTUD
\subsubsection{Mise en contexte}
Les \textit{\gls{blockchain}s} 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-\gls{blockchain}s. 
Les \gls{bridge}s, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{\gls{blockchain}s} différentes.\\
Nous avons, au cours de nos recherches, trouvés de nombreux cas d'attaques sur des protocoles d'échanges inter-\gls{blockchain}s. 
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 : \gls{Wormhole} et \gls{Nomad}.

\subsubsection{Le cas \gls{Wormhole}}
Nous vous avons présenté le protocole \textit{\gls{Wormhole}} dans la partie précédente. 
Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{\gls{dApp}} sur la chaîne \gls{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{\gls{Wormhole} ETH}). 
Lors d'un transfert d'\gls{actif} 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{\gls{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 création d'\gls{actif} 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}
\gls{Nomad} est un protocole d'interopérabilité entre chaînes permettant de passer des \gls{actif}s entre deux \textit{\gls{blockchain}s} 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{\gls{dApp}} appelée \textit{réplica} est déployée sur les \textit{\gls{blockchain}s} recevant les messages, elle fait office de "boite de réception". 
Une seconde \textit{\gls{dApp}} appelée \textit{home} est déployé sur les \textit{\gls{blockchain}s} é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{\gls{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 \gls{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-\gls{blockchain}s, 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 \gls{blockchain}s, 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 inter\gls{blockchain}s.

\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{\gls{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 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-\gls{blockchain}. Ce menant aux échanges décentralisés.