CertiK : Comment les explorateurs de blockchain préviennent-ils les attaques par déni de service (DoS) ?
TechFlow SélectionTechFlow Sélection
CertiK : Comment les explorateurs de blockchain préviennent-ils les attaques par déni de service (DoS) ?
Un explorateur de blockchain est un moteur de recherche pour la blockchain, permettant aux utilisateurs de rechercher des informations spécifiques sur la blockchain.
Dédié à des analyses Web3 approfondiesQuand on parle de navigateurs, ce qui vient immédiatement à l'esprit sont des slogans comme « Recherche Baidu, et tu sauras » ou « Commencez votre navigation avec Sogou »...
Ces navigateurs célèbres au point que même les personnes âgées peuvent les citer incarnent le visage d'Internet, et plus encore, en constituent l'entrée principale.
Mais s’il y a bien une technologie aujourd’hui au sommet de sa gloire qui marche main dans la main avec Internet, c’est la technologie blockchain.
Alors qu’Internet transforme notre vie quotidienne, la technologie blockchain transforme Internet lui-même. Il est donc évident que, en tant qu’entrée d’Internet, les navigateurs ne peuvent être dissociés de la technologie blockchain. C’est ainsi que sont nés les navigateurs blockchain, produits concrets désormais bien connus, apportant un grand confort aux utilisateurs de la blockchain.
Quelle est la sécurité des navigateurs blockchain ?
Un navigateur blockchain est un moteur de recherche dédié à la blockchain, permettant aux utilisateurs de rechercher des informations spécifiques sur la chaîne.
Par exemple, Etherscan est un navigateur blockchain pour Ethereum. Grâce à Etherscan, les utilisateurs peuvent facilement obtenir des informations sur les blocs, adresses, transactions et autres activités sur Ethereum. En d'autres termes, un navigateur blockchain ressemble davantage à un site officiel de consultation de la blockchain.
Dans un contexte où la majorité des applications blockchain font face à des menaces de sécurité, quelle est donc la situation en matière de sécurité des navigateurs blockchain ?
Les points d'attaque potentiels des applications de navigateurs blockchain sont relativement limités. Pour deux raisons principales :
Ils ne nécessitent pas d'authentification ni d'autorisation, donc aucune information privée n'est exposée ;
L'utilisation généralisée de frameworks web (comme Vue et React) réduit considérablement la probabilité d'exploitation de vulnérabilités XSS (cross-site scripting) ;
Cela signifie-t-il que les navigateurs blockchain sont invulnérables aux attaques ?
Ou bien, même s'ils étaient attaqués, cela n'aurait aucune importance ?
La réponse est : Non.
Classification des types d’attaques sur les navigateurs blockchain
Examinons d’abord les types d’attaques auxquelles un navigateur blockchain peut être exposé.
Étant donné que la plupart des fonctionnalités d’un navigateur blockchain impliquent soit une recherche dans une base de données backend, soit une requête directe auprès d’un nœud blockchain, lorsqu’on parle de fonctions de recherche, deux vulnérabilités viennent généralement à l’esprit :
Injection SQL ;
Attaque par déni de service (DoS - Denial-of-service) ;
Or, après examen de différents navigateurs, l’équipe technique de CertiK n’a trouvé qu’un seul cas d’injection SQL, tandis que plus de 50 % des navigateurs blockchain sont exposés au risque d’attaques DoS.
Qu’est-ce qu’une attaque DoS ?
Prenons un exemple simple : un vieux monsieur à barbe blanche, voyant qu’un autre monsieur, un clown, vend de plus en plus de poulet frit, engage quelques voyous pour créer des troubles. Ceux-ci se tiennent devant le comptoir, posent toutes sortes de questions sans jamais commander, mettant le personnel dans tous ses états. Après deux heures d’attente, les clients affamés finissent par partir. Et si, en plus, le personnel du magasin est irritable, les tensions montent rapidement jusqu’à une bagarre générale, laissant le magasin en désordre…
DoS : abréviation de Denial of Service (refus de service). Une telle attaque vise à empêcher un système de fournir ses services aux utilisateurs légitimes.
Dans les serveurs, il existe un fait bien connu : un client peut envoyer des requêtes HTTP sans effort, alors que le serveur peut avoir besoin de ressources importantes pour traiter et répondre à ces requêtes. Les attaques DoS au niveau applicatif exploitent justement cette asymétrie.
Généralement, la lutte contre les attaques DoS revient à une course aux ressources : qui en possède le plus ? Toutefois, si le code backend comporte des failles, une seule requête peut suffire à faire planter le serveur.
Nous allons ici analyser plusieurs cas d’attaques DoS, leurs impacts, ainsi que des recommandations pour protéger vos applications.
Analyse de cas d’attaques DoS
Il existe divers moyens d’effectuer une attaque DoS sur un serveur. Généralement, l’attaquant cherche à :
Épuiser toutes les ressources CPU et mémoire ;
Occuper toutes les connexions réseau disponibles ;
Voici quelques exemples d’analyses de serveurs vulnérables à des attaques DoS, certaines dues à des erreurs de code, d’autres à des mauvaises configurations :
1. API d’accès aux ressources sans limite de quantité
https://fake.sample.com/api/v1/blocks?limit=10
Cette requête récupère des informations sur les blocs selon la valeur indiquée dans le paramètre « limit ». Lorsque la limite est fixée à 10, elle renvoie les informations des 10 derniers blocs. Pour de petites valeurs, tout fonctionne normalement.
Toutefois, le backend pourrait ne pas imposer de limite supérieure au paramètre « limit ». Lorsque l’équipe technique de CertiK a envoyé une requête avec « limit » fixé à 9999999, celle-ci a mis longtemps à traiter avant de retourner une erreur « 504 gateway time-out ». Pendant ce traitement, le temps de réponse des autres API a fortement augmenté.
Ce nombre dépasse même le total des blocs existants sur la chaîne.
On suppose que le backend tente de récupérer les données de chaque bloc de la chaîne. Si un attaquant envoie massivement des requêtes avec un « limit » élevé, le serveur pourrait devenir inopérant voire planter complètement.
2. Requêtes GraphQL imbriquées
Durant leur investigation, l’équipe technique de CertiK a rencontré plusieurs ressources blockchain utilisant GraphQL. GraphQL est un langage de requête pour les API. Contrairement aux API REST classiques nécessitant plusieurs appels pour récupérer différentes ressources, GraphQL permet d’obtenir toutes les données nécessaires en une seule requête. Très populaire, GraphQL peut toutefois présenter des risques de sécurité s’il n’est pas correctement protégé.
En testant un navigateur blockchain, l’équipe a découvert qu’un navigateur utilisait une interface GraphQL dont deux types se référaient mutuellement, permettant ainsi aux utilisateurs de construire des requêtes très complexes et profondément imbriquées.
Envoyer de telles requêtes peut entraîner une forte augmentation du taux d’utilisation du processeur. En général, quelques requêtes de ce type suffisent à faire passer l’utilisation du CPU à plus de 100 %, rendant le serveur incapable de répondre aux requêtes normales.
Utilisation du CPU lors du traitement de telles requêtes GraphQL
L’image suivante illustre un exemple de requête imbriquée « dos_query » :
L’impact d’une telle requête malveillante dépend de sa complexité et des performances du serveur. Le serveur peut mettre beaucoup de temps à répondre, ou carrément planter sous la charge excessive du CPU. Pour en savoir plus sur la sécurité de GraphQL, consultez le lien de référence 1 en bas de cet article.
3. API RPC Cosmos exposée directement
https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1
Cette API Cosmos recherche 100 transactions « envoi » depuis le bloc 1. À ce jour, le réseau principal de Cosmos compte déjà 2 712 445 blocs. Parmi les nœuds RPC exposés de CosmosHub, aucun ne peut traiter cette requête. Le serveur concerné retourne après un certain temps une erreur « 502 Bad Gateway », signalant l’échec de la requête.
Si le serveur RPC reçoit en quelques secondes des centaines de telles requêtes, toutes les API commencent à retourner des erreurs. Certains nœuds peuvent se remettre automatiquement, d’autres nécessitent un redémarrage.
Pour mieux illustrer ce problème, l’équipe technique de CertiK a configuré un nœud Cosmos complet entièrement synchronisé, puis a lancé l’attaque décrite ci-dessus avec la requête : « https://fake.cosmos.api.com/txs?message.action=send&limit = 100＆tx.minheight = 1 ».
Panneau d’utilisation CPU Grafana
Ce graphique se divise en trois phases :
Le nœud démarre et fonctionne normalement, utilisation CPU à 35 %
Le nœud subit une attaque DoS, utilisation CPU atteint 97 %
Le nœud plante, Grafana ne reçoit plus de données
Le graphique montre que le serveur s’est effondré en quelques minutes sous attaque DoS. Impossible ensuite de se connecter via SSH, l’opérateur a dû redémarrer manuellement le serveur.
4. Mauvais traitement des requêtes
https://fake.sample.com/api/v1?feature=Always_time_out
L’équipe technique de CertiK a rencontré une API qui charge indéfiniment avant de finalement expirer. Toutefois, envoyer plusieurs requêtes de ce type n’affecte pas le temps de réponse des autres API. On suppose que le traitement spécifique de cette API n’utilise ni CPU ni mémoire significativement. Étant donné que ce navigateur blockchain n’est pas open source, il est impossible d’examiner son code ni de comprendre précisément l’utilité de cette API.
Bien qu’une telle attaque ne risque pas de faire planter le serveur, un attaquant pourrait saturer toutes les connexions réseau en envoyant des requêtes du type « toujours en attente puis timeout », bloquant ainsi l’accès des autres utilisateurs aux API.
Par exemple, la fonction « sleep_to_handle_request » illustre parfaitement comment une requête peut consommer peu de ressources mais occuper longtemps une connexion réseau.
Comparé aux trois cas précédents où les serveurs plantent complètement ou mettent longtemps à se remettre, celui-ci retrouve immédiatement son fonctionnement normal dès que l’attaque cesse.
Impact des attaques DoS
Face à une attaque DoS, les serveurs vulnérables deviennent incapables de répondre aux requêtes normales. Certains retrouvent leur fonctionnement juste après la fin de l’attaque, d’autres nécessitent un certain temps de récupération, voire un redémarrage complet.
L’indisponibilité d’un navigateur blockchain pose de gros problèmes aux utilisateurs, qui ne peuvent plus consulter facilement les activités sur la chaîne. Pire encore, sur les blockchains basées sur Cosmos, si un nœud est victime d’une attaque DoS, non seulement le navigateur connecté ne peut plus récupérer ses données, mais les utilisateurs ne peuvent plus effectuer d’opérations comme envoyer des jetons ou déléguer à un validateur via l’API.
Recommandations
Toute application est potentiellement exposée aux attaques DoS. Il n’existe aucune solution parfaite pour s’en prémunir totalement. Toutefois, certaines mesures permettent d’augmenter le coût de l’attaque, décourageant ainsi les assaillants, et réduisent la probabilité de vulnérabilités dans les navigateurs blockchain.
Voici quelques recommandations de l’équipe technique de CertiK pour minimiser les risques d’attaque :
1. Limitation de débit (Rate limiting)
Même si une API backend est bien sécurisée, un attaquant peut l’assaillir en envoyant massivement des requêtes. Il est donc essentiel d’implémenter une limitation de débit afin de bloquer temporairement ou définitivement les adresses IP malveillantes.
Bien que cela ne résolve pas complètement le problème, c’est une mesure simple à mettre en œuvre et constitue une première ligne de défense efficace contre les attaques DoS.
2. Amélioration de la conception et de l’implémentation
Une bonne conception et un bon codage permettent d’obtenir de meilleures performances avec le même matériel, particulièrement pour les fonctions liées à la recherche dans les bases de données et au traitement des données. Mais avant toute optimisation, il faut d’abord s’assurer que le code est exempt d’erreurs.
Il est donc très utile de consacrer du temps à écrire des tests unitaires avant de déployer une API en production, afin de garantir son bon fonctionnement.
3. Validation des entrées et limitation des paramètres
Sans validation ni limitation des variables fournies par l’utilisateur, les API peuvent être détournées.
Une fois confirmé que le code fonctionne comme prévu, il faut veiller à ce qu’un attaquant ne puisse pas exploiter des entrées inhabituelles. Des requêtes demandant 9 999 999 blocs ou traitant des requêtes GraphQL à 1 000 niveaux d’imbrication doivent être refusées.
Toutes les entrées utilisateur doivent donc être considérées comme non fiables, et validées par le serveur avant traitement.
Dans les exemples cités plus haut, l’API GraphQL pourrait fixer un nombre maximal d’imbrications pour contrer efficacement les attaques DoS par requêtes cycliques, et l’API de récupération de blocs pourrait limiter le nombre maximum de blocs à une valeur raisonnable comme 50.
Les développeurs peuvent adapter ces règles selon leur architecture et leur logique métier.
4. Ne pas exposer les RPC des nœuds
Tout le code des API n’est pas nécessairement sous contrôle du développeur.
Par exemple, il n’est pas recommandé de modifier le code des API RPC Cosmos. Or, certaines requêtes de recherche dans le SDK Cosmos ont de mauvaises performances. Que faire alors ?
Une solution consiste à créer une couche intermédiaire d’API autour du RPC Cosmos, accompagnée d’une base de données stockant les données blockchain synchronisées depuis le nœud. Cette API externe, exposée au public, traite les requêtes utilisateur puis interroge soit le RPC Cosmos, soit la base locale. Cela empêche l’accès direct au RPC du nœud, protège contre les requêtes de recherche excessives, et permet d’optimiser librement la base de données.
Sur le forum Cosmos, l’utilisateur « kwunyeung » propose aussi d’utiliser un proxy HTTP (comme Nginx ou Caddy) pour protéger les ports RPC. Le message est clair : les ports RPC ne doivent pas être exposés publiquement, et des mesures de protection doivent être mises en place.
5. Respecter les exigences matérielles recommandées
Même avec toutes les protections mentionnées ci-dessus, il est crucial de respecter les exigences matérielles minimales pour exécuter un serveur d’API ou un nœud stable comme Tendermint (voir référence 2). Si le serveur peine déjà à gérer les requêtes d’utilisateurs normaux, l’administrateur doit envisager une mise à niveau matérielle.
Conclusion
Les attaques DoS peuvent provoquer l’effondrement d’applications comme les navigateurs blockchain, ce qui représente une menace critique pour la plupart des entreprises.
L’équipe technique spécialisée de CertiK possède une expertise approfondie et une solide expérience dans l’évaluation des vulnérabilités d’applications, l’audit de code (Solidity, RUST, Go), et la sécurisation de plateformes comme Ethereum, Cosmos et Substrate.
Pour toute entreprise blockchain – navigateurs, portefeuilles, exchanges, contrats intelligents ou protocoles de base – souhaitant bénéficier d’un audit de sécurité complet, CertiK, grâce à son expérience opérationnelle et à ses technologies avancées de vérification formelle, est l’expert de confiance à choisir.
Annexe
Voici un script exemple permettant de tester la vulnérabilité d’un nœud Cosmos aux attaques DoS. La variable « url » peut être modifiée pour tester différentes applications.
Ne lancez ce script que sur des applications autorisées.
import requests
import threading
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
#Modifier l'url
url ="https://fake.cosmos.api/txs?message.action=send&limit=100&tx.minheight=1"
def dos_thread():
while(1):
response = requests.request("GET", url, verify=False)
print(response.text.encode('utf8'))
if __name__ == "__main__":
for i in range(300):
t = threading.Thread(target=dos_thread)
t.start()
Liens de référence :
1. https://www.apollographql.com/blog/securing-your-graphql-api-from-malicious-queries-16130a324a6b/
2. https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/running-in-production.md#hardware
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
