Rapport d'audit de contrat intelligent pour Dimo

Résumé de gestion

Dimo a contacté Sayfer pour réaliser un audit de sécurité sur leur contrat intelligent.

Ce rapport documente les recherches effectuées par Sayfer ciblant les ressources sélectionnées définies dans le cadre de la recherche. En particulier, ce rapport affiche l'examen de la posture de sécurité du contrat intelligent de Dimo.

Au cours d'une période de recherche de 40 heures, nous avons découvert 14 vulnérabilités dans le contrat. Aucun d’eux n’est critique.

En conclusion, plusieurs correctifs devraient être mis en œuvre suite au rapport, mais la posture de sécurité du système est compétente.

Après examen par l'équipe Sayfer, nous certifions que tous les problèmes de sécurité mentionnés dans ce rapport ont été résolus par l'équipe Dimo.

Méthodologie des risques

Chez Sayfer, nous nous engageons à fournir à nos clients des audits de contrats intelligents de la plus haute qualité. C'est pourquoi nous avons mis en œuvre un modèle complet d'évaluation des risques pour évaluer la gravité de nos constatations et fournir à nos clients les meilleures recommandations possibles pour les atténuer.

Notre modèle d’évaluation des risques repose sur deux facteurs clés : IMPACT ainsi que PROBABILITÉ. L'impact fait référence au préjudice potentiel qui pourrait résulter d'un problème, tel qu'une perte financière, une atteinte à la réputation ou un système non opérationnel. La probabilité fait référence à la probabilité qu'un problème se produise, en tenant compte de facteurs tels que la complexité du contrat et le nombre d'attaquants potentiels.

En combinant ces deux facteurs, nous pouvons créer une compréhension globale du risque posé par un problème particulier et fournir à nos clients une évaluation claire et exploitable de la gravité du problème. Cette approche nous permet de prioriser nos recommandations et de garantir que nos clients reçoivent les meilleurs conseils possibles sur la façon de protéger leurs contrats intelligents.

Le risque est défini comme suit :

Présentation du protocole

Présentation du protocole

DIMO est une société Web3 IoT qui permet aux utilisateurs et aux développeurs d'exploiter le riche flux de données généré par les véhicules modernes. Sa solution est un écosystème appartenant aux utilisateurs qui permet aux conducteurs de tirer des avantages économiques de leurs données et de créer des applications telles que l'assurance paramétrique, le partage de voiture peer-to-peer et les marchés de véhicules. La plate-forme décentralisée offre également aux développeurs une tranquillité d'esprit, sachant que leur accès aux données n'est pas soumis aux caprices d'un contrôleur d'accès centralisé. Cette solution est construite sur Polygon.

Constatations des audits

[H] Changer l'heure de Genesis peut potentiellement perturber la distribution des récompenses

ID	DIRE-01
Statut	Fixé
Analyse	Haute
La Brochure Impact	rewardsGenesisTime est une variable critique qui suit l'heure à laquelle les récompenses ont commencé et régit ainsi la distribution des récompenses. Le taux de récompense continue de diminuer au fil du temps, pour atteindre 85 % du cycle précédent à un moment donné dans le futur. Par conséquent, réinitialiser le temps de genèse après le début de la distribution des récompenses peut perturber l’ensemble du système.
Localisation	– Récompense.sol; réinitialiserRewardsGenesisTime() – Récompense.sol; manuellementSetRewardsGenesisTime (uint256)

Description

Changer rewardsGenesisTime plus tard dans le cycle, cela aura un impact sur les variables cruciales currentWeek et weekLimit et pourrait potentiellement gâcher l'ensemble du système de distribution des récompenses et son calendrier prévu.

Atténuation

Une atténuation possible consiste à réviser ces fonctions de telle sorte que la réinitialisation du temps de genèse ne soit possible qu'avant le début de la distribution des récompenses :

 function resetRewardsGenesisTime() external onlyRole(ADMIN_ROLE) {
        require(dimoTotalSentOutByContract==0,"Reward Distribution already started");
        rewardsGenesisTime = block.timestamp;
  }

Si la réinitialisation ou la modification de la variable après coup est nécessaire, elle peut peut-être être gérée de manière contrôlée et prévisible en chaîne, plutôt que de permettre un contrôle arbitraire aux administrateurs.

 

[H] Retrait de l'administrateur non vérifié

ID	DIRE-02
Statut	Fixé
Analyse	Haute
Impact sur les entreprises	Bien que les comptes d'administrateur bénéficient par définition d'une certaine mesure de confiance, s'ils sont compromis, ils peuvent être utilisés pour vider le contrat de ses fonds en utilisant cette fonction.
Localisation	– Récompense.sol; adminWithdraw (adresse, uint256)

Description

La fonction adminWithdraw(address, uint256) permet aux administrateurs d'envoyer des fonds de contrat aux utilisateurs sans limitation. Selon la documentation, ceci est utilisé si les utilisateurs envoient DIMO au contrat sans mise. Cependant, nous pensons que cette fonction peut être sujette à des abus, comme expliqué dans la section sur l'impact commercial.

Atténuation

Une façon envisageable d'augmenter la sécurité consiste à soumettre une demande au nom d'un utilisateur, peut-être en utilisant un compte avec le rôle Oracle. Un administrateur doit ensuite approuver la transaction. Cela nécessite au moins deux comptes pour approuver de telles transactions, offrant ainsi un autre niveau de sécurité.

 

[H] Les administrateurs peuvent réinitialiser le registre à volonté

ID	DIRE-03
Statut	Reconnu
Analyse	Haute
Impact sur les entreprises	Le registre est l'endroit où les données utilisateur sont stockées et les validations sont effectuées. Si le registre est réinitialisé, les utilisateurs existants cesseront de recevoir des récompenses à moins que les données ne soient migrées vers le nouveau registre.
Localisation	– Récompense.sol; setRegistryContractAddress (adresse)

Description

setRegistryContractAddress(address) permet aux administrateurs de réinitialiser l'adresse du registre à volonté.

Atténuation

Une solution consiste à s'assurer que cette fonction est rétablie à moins que le registre ne soit pas défini en premier lieu.

  function setRegistryContractAddress(
    address registryContractAddress
  ) external onlyRole(ADMIN_ROLE) {
    require(
        registryContractAddress != address(0),
        "registryContractAddress is an invalid zero address"
    );
    require(address(registry)==address(0)),"already set, cannot be set again")
    registry = IRegistry(registryContractAddress);
  }

Une autre solution consiste à mettre en place une procédure de migration des données. Si une telle procédure est déjà en place, cette découverte peut alors être ignorée en toute sécurité.

 

[I] Le déployeur a à la fois des rôles d'administrateur et d'Oracle

ID	DIRE-04
Statut	Reconnu
Analyse	D'information
Impact sur les entreprises	Nous avons décidé de qualifier ce résultat d’informatif car il s’agit principalement d’un corollaire aux principales préoccupations de centralisation détaillées ci-dessus. Avec la manière actuelle dont le système est construit, il est nécessaire que quelqu'un attribue et gère les rôles Oracle et Administrateur. Cependant, il n’est pas nécessaire que ce compte assume lui-même ces rôles.
Localisation	– Récompense.sol : 108-111 ; initialiser(adresse, adresse, adresse)

Description

Lors de l'initialisation, le déployeur reçoit les rôles d'administrateur, d'administrateur par défaut et d'oracle :

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

_setupRole(ORACLE_ROLE, msg.sender);
_setupRole(ADMIN_ROLE, msg.sender);

Atténuation

Envisagez de donner uniquement le rôle d'administrateur par défaut, hérité des OA AccessControlUpgradeable, au déployeur, lui permettant de gérer les rôles des autres utilisateurs.

 

[M] Utiliser AccessControlDefaultAdminRulesUpgradeable

ID	DIRE-05
Statut	Reconnu
Analyse	Moyenne
Impact sur les entreprises	Compte tenu de la centralisation inhérente du contrat et de l’importance des rôles administratifs (et donc de leur gestion), nous avons décidé de qualifier ce constat de risque moyen.
Localisation	-

Description

Reward.sol utilise actuellement AccessControlUpgradable pour accorder et gérer l'accès aux fonctions critiques. Dans le système de contrôle d'accès d'OZ, le compte possédant DEFAULT_ADMIN_ROLE est capable d'accorder et de retirer tous les autres rôles. En l'état actuel du contrat, il est remis au déployeur lors de l'initialisation.

AccessControlDefaultAdminRulesUpgradeable S'étend AccessControlUpgradable avec deux fonctionnalités de sécurité cruciales :

• Un seul compte peut détenir DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE ne peut être transféré qu’en deux étapes. Un délai paramétrable entre les deux étapes, changeDefaultAdminDelay, est appliqué.

Atténuation

Passer de AccessControlUpgradable à AccessControlDefaultAdminRulesUpgradeable.

 

[L] Validation d'entrée insuffisante dans manualSetRewardsGenesisTime (uint256)

ID	DIRE-06
Statut	Fixé
Analyse	Faible
Impact sur les entreprises	Nous considérons ce problème comme faible, car une valeur erronée pourrait être rectifiée par l'administrateur aussi facilement qu'elle a été donnée.
Localisation	– Récompense.sol; manuellementSetRewardsGenesisTime (uint256)

Description

En plus de poser un risque de centralisation, comme détaillé ci-dessus, manuallySetRewardsGenesisTime(uint256) ne parvient pas non plus à valider l'horodatage donné par l'administrateur. Il accepterait volontiers une date future, conduisant à _getNumberOfWeeksSinceGenesis() revenir:

  function _getNumberOfWeeksSinceGenesis()
    private
    view
    returns (uint256 unixTimeDiff)
  {
    unixTimeDiff = (block.timestamp - rewardsGenesisTime) / 7 days;
  }

Atténuation

Assurez-vous que l'entrée est égale ou inférieure à l'horodatage actuel.

 

[L] Validation d'entrée insuffisante dans setMinimumTimeForRewards (uint256)

ID	DIRE-07
Statut	Fixé
Analyse	Faible
Impact sur les entreprises	Tout comme le résultat ci-dessus, nous avons décidé de considérer ce résultat comme étant à faible risque car il peut facilement être rectifié en appelant à nouveau la fonction.
Localisation	– Récompense.sol; setMinimumTimeForRewards(uint256)

Description

Cette constatation est très similaire en substance à celle qui se trouve juste au-dessus. Une valeur trop élevée empêchera les utilisateurs de réclamer leurs récompenses. Ceci, en tandem avec le fait que les récompenses sont diminuées sur une base hebdomadaire de _limitForWeek(uint256), neutralisera l’avantage conféré par une adoption précoce.

Atténuation

Définir une plage de valeurs acceptable pour minimumTimeForRewards et appliquez-le via la fonction. En raison de l’influence directe de cette valeur sur l’ensemble de la structure de récompense de la plateforme, il est primordial de la gérer avec soin.

 

[L] Erreur inutilisée

ID	DIRE-08
Statut	Fixé
Analyse	Faible
Impact sur les entreprises	Nous avons décidé de noter ce problème comme étant faible plutôt qu'informatif. Cette omission apparemment accidentelle a un certain impact sur la logique du contrat.
Localisation	– Récompense.sol : 12

Description

L'erreur InvalidArrayLegnth() est déclaré à la ligne 12, mais jamais utilisé.

Atténuation

Nous émettons l'hypothèse que cette erreur était censée être générée batchTransfer(TransferInfo[]) si le tableau fourni ne comporte pas huit membres :

if(transferInfos.length != 8) revert InvalidArrayLength();

 

[L] Valeur de retour non cochée

ID	DIRE-09
Statut	Fixé
Analyse	Faible
Impact sur les entreprises	La fonction de transfert des jetons ERC20 renvoie le succès ou l'échec du transfert sous forme booléenne. Il est considéré comme une bonne pratique de vérifier cette valeur et de ne continuer qu'en cas de succès. Cependant, comme la documentation implique que batchTransfer(TransferInfo[]) n'est utilisé que pour transférer des jetons Dimo, nous considérons ce résultat comme faible.
Localisation	– Récompense.sol : 232 ; transfert par lots(TransferInfo[])

Description

Sur la ligne indiquée, un transfert dimoToken est effectué, mais la valeur de retour n'est pas cochée.

Atténuation

Revenir avec une erreur si le transfert échoue :

if (!dimoToken.transfer(user, amount)) revert TokenTransferFailed();

 

[L] Appel API obsolète

ID	DIRE-10
Statut	Reconnu
Analyse	Faible
Impact sur les entreprises	Contrairement à grantRole(bytes32, address), _setupRole(bytes32, address) n'effectue aucune vérification sur le compte appelant. Il est donc obsolète.
Localisation	– Récompense.sol : 108-111 ; initialiser(adresse, adresse, adresse)

Description

La fonction _setupRole(bytes32, address), utilisé à l'emplacement spécifié, est obsolète dans OpenZepplin 5.0. Appel grantRole(bytes32, address) à la place est maintenant recommandé.

Atténuation

Remplacer les appels à _setupRole(bytes32, address) comprenant grantRole(bytes32, address).

 

[I] Émission d'événement insuffisante

ID	DIRE-11
Statut	Fixé
Analyse	D'information
Impact sur les entreprises	De nombreux outils de surveillance, frontends, outils hors chaîne et services de reporting s'appuient sur des événements pour capturer les activités en temps réel des contrats. De plus, les protocoles peuvent réagir rapidement aux émissions d’événements suspects.
Localisation	– Récompense.sol; setRegistryContractAddress (adresse) – Récompense.sol; setMinimumTimeForRewards(uint256) – Récompense.sol; setSyntheticProxyAddress (adresse) – Récompense.sol; réinitialiserRewardsGenesisTime() – Récompense.sol; manuellementSetRewardsGenesisTime() – Récompense.sol : 267-268 ; transfert par lots(TransferInfo[])

Description

Les fonctions susmentionnées n'émettent pas d'événements pour les mises à jour d'état importantes.

Atténuation

Ajoutez des émissions d’événements.

 

[I] Gestion des versions Solidity

ID	DIRE-12
Statut	Reconnu
Analyse	D'information
Impact sur les entreprises	Le contrat peut être compilé et testé avec différentes versions du compilateur pendant le développement et la révision et avec une autre version différente du compilateur lors du déploiement sur le réseau principal. Cela peut conduire à des résultats inattendus.
Localisation	Récompense.sol:2

Description

Le contrat précise son pragma comme pragma solidity ^0.8.13;. Cela permet d'utiliser n'importe quelle version de Solidity à partir de la 0.8.13. De plus, la 0.8.13 n'est pas la version la plus récente.

Atténuation

Choisissez une seule version de Solidity à utiliser. La dernière version stable (et donc recommandée) est la 0.8.19.

 

[I] Indexer le paramètre de la semaine dans TokensTransferredForConnectionStreak()

ID	DIRE-13
Statut	Fixé
Analyse	D'information
Impact sur les entreprises	L'indexation est utile pour filtrer les événements dans les journaux Ethereum. Chaque paramètre indexé dans un événement ajoute une rubrique au journal des événements, ce qui facilite la recherche d'événements spécifiques à l'aide de ces paramètres.
Localisation	– Récompense.sol : 81

Description

Le paramètre week représente la semaine actuelle au cours de laquelle le largage a été distribué. Étant donné que l'indexation permet aux applications frontales de filtrer plus facilement des événements spécifiques, l'indexation de ce paramètre facilitera le filtrage des utilisateurs ayant reçu des parachutages au cours d'une semaine donnée.

Atténuation

Pensez à indexer le paramètre spécifié.

 

[I] Adhésion au guide de style Solidity

ID	DIRE-14
Statut	Fixé
Analyse	D'information
Impact sur les entreprises	Ce problème est purement informatif. Il n’y a aucun impact sur la posture de sécurité du contrat ou autre.
Localisation	– Récompense.sol : 36

Description

TransferInfo[], une structure, est définie à la ligne 36, directement après les variables d'état. Le guide de style Solidity recommande de placer les déclarations struct avant.

Atténuation

Déplacez la déclaration de la structure directement au début du contrat, avant les variables d'état.