Résumé de gestion
L'équipe de ZenPool a contacté Sayfer Security afin d'effectuer un audit de sécurité complet pour tous leurs contrats.
Avant d'évaluer ces services, nous avons organisé une réunion de lancement avec l'équipe technique de ZenPool et avons reçu un aperçu du système et des objectifs de cette évaluation.
L'audit suivant a duré 20 jours-homme, tous les contrats de la chaîne ont été examinés ligne par ligne avec au moins 2 auditeurs par contrat. En raison de contraintes de temps côté client, nous avons examiné les composants hors chaîne et adopté une approche optimale pour nous assurer qu'ils ne contiennent aucune vulnérabilité critique.
Nous avons trouvé un total de 9 découvertes, dont 3 ont été classées comme vulnérabilités à risque « élevé » et pourraient être exploitées par des attaquants malveillants, qui pourraient vider complètement les fonds du pool.
Nous avons documenté notre processus et nos suggestions sur la façon dont chaque vulnérabilité doit être corrigée. L'équipe de ZenPool a implémenté les correctifs qui ont été documentés dans chaque section de vulnérabilité.
Présentation du système
ZenPool est un jeton open source et non dépositaire et un protocole de marché de prêt.
Les utilisateurs peuvent déposer leurs actifs cryptographiques pour gagner des intérêts ou emprunter d'autres jetons pour payer des intérêts sur le marché de ZenPool. ZenPool a son propre jeton appelé ZEN.
Le ZEN est une monnaie flottante adossée à l'offre de trésorerie stable en pièces de monnaie BUSD. Les jetons ZEN ne peuvent être frappés et brûlés que par le protocole, ce n'est qu'en réponse au prix que le protocole le fait. Chaque ZEN est supporté par au moins un BUSD.
Si le prix de ZEN tombe en dessous de 1 BUSD, le protocole achète et brûle ZEN, repoussant le prix à 1 BUSD.
ZenPool prend également en charge les obligations qui sont un autre moyen d'augmenter sa trésorerie. Le protocole vend des obligations en échange de divers actifs, et en échange, l'acheteur reçoit ZEN à un prix considérablement réduit. Cela dynamise la trésorerie et permet à ZeenPool de fournir des rendements incroyables à ses clients.
Enfin, une partie de tous les frais de produit ZenPool sera utilisée comme support supplémentaire, offrant potentiellement au jeton de ZenPool une piste infinie pour les récompenses de jalonnement.
Vulnérabilités par risque
Haute
- DoS de transaction
- perte directe de fonds
- gel permanent des fonds
Moyenne
- Attaques contre les clients légers
- Partiellement DoS
- Les attaques au gaz
Faible
- des pratiques d’excellence;
D'information
- N'endommage pas le système, et nous n'avons pas suffisamment de données ou de connaissances pour prouver qu'il causera un jour du mal, mais il est important de partager notre
Portée et contrats
Dans le cadre du cadrage du projet et pour comprendre l'orientation et les besoins de nos clients, nous avons défini les contrats que nous devrions tester lors de cet audit. Ensemble, nous avons trouvé le meilleur équilibre qui convient à ce projet spécifique.
Le périmètre est un périmètre souple par définition, ce qui signifie que nous pourrions tester sur un environnement local d'autres contrats susceptibles d'interagir avec le contrat défini comme le périmètre de l'audit. Cela nous donne la flexibilité nécessaire pour trouver des problèmes de sécurité qui pourraient être négligés autrement.
La liste des contrats et leur commit Github :
Valider le hachage
| Valider le hachage | Contract |
| 5d253cb3c544a17399e7d2f4c381a1065bcfa0a0 | https://github.com/zenpoolproject/zenpool/tree/master/contracts/createGovernor.sol |
| 3887cd307163d130477d4805e74ade11f84d7a4d | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenPoolUserManager.sol |
| a50062dfc63a0e82ec43de98865420193270236a | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenPoolManager.sol |
| c4d0db2f9fbfc3146a1a1a797e55c3f3d7a19899 | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenTickets.sol |
| 844132ae5210cb27101bf4a415d9c16e201e1afc | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenPoolFunds.sol |
| a70146c5d276f933a79c567d2e96512302a6a940 | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenGovernorAlpha.sol |
| d476137af592fe71cae2578a62e2f8f92b335d8c | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenLendingPool.sol |
| 8c5d858ad7fbfe856cd23160fd8810997f3fdf70 | https://github.com/zenpoolproject/zenpool/tree/master/contracts/ZenGovernorAlpha.sol |
Commandez l'audit de Sayfer
Résultats de l'audit des contrats intelligents
Les utilisateurs peuvent retirer des fonds d'autres soldes jusqu'à ce que le pool soit vide
| Contract | contrats/ZenPoolFunds.sol |
| Analyse | Haute |
| Fixé | Oui |
| Trouvé par | Test manuel |
Description
La withdrawFunds valide que l'utilisateur ne peut retirer que le montant maximum de son solde, vérifié par son adresse et ensuite comparé au sein du pool de jetons.
Plus tard, le montant retiré est déduit de l'emprunt maximum actuel de l'utilisateur au prix actuel. Si le montant total des fonds empruntés par l'utilisateur dépasse le nouvel emprunt maximum, la méthode échoue car l'utilisateur n'a plus assez de garantie pour soutenir sa position d'emprunt. Cette exigence, cependant, n'est vérifiée que si l'utilisateur n'est pas déjà surendetté :
Un attaquant pourrait utiliser cette fonctionnalité pour exploiter le withdrawFunds fonction pour retirer plus que le montant maximum d'emprunt.
Il pourrait le faire parce que le getMaxBorrow ne sera cochée que si l'utilisateur emprunte moins que le montant maximum qui lui est autorisé, dans une variété de scénarios, l'attaquant pourrait abuser du flux pour ignorer ce spécifique require, lui permettant d'appeler le withdrawFund plusieurs fois jusqu'à ce que la piscine se vide.
Atténuation
Changez le require à appeler avant la ligne 145 donc il ne dépend pas de l'instruction if. De cette façon le require sera toujours exécuté.
Autodestruction dangereuse dans le contrat de procuration
| Contract | contrats/ZenTickets.sol contrats/ZenPoolManager.sol |
| Analyse | Haute |
| Fixé | Oui |
| Trouvé par | Test manuel |
Description
Quand le principal ZenPoolManager est déployé, il déploie également plusieurs contrats.
L'un d'eux est le ZenTickets contrat qui est en grande partie sécurisé, à l'exception du destoryContract fonction qui n'a pas de mécanisme ACL en place comme le reste des fonctions :
En exploitant cette fonctionnalité, un attaquant non authentifié pourrait appeler le destoryContract fonction et choisissez où l'ETH du contrat sera transféré. Ceci est facile à exploiter du point de vue de l'attaquant.
Atténuation
Utilisez l'option onlyOwner modificateur comme il est utilisé dans la réinitialisation des fonctions.
Une autre solution plus spécifique serait d'utiliser un mécanisme d'ACL personnalisé comme l'ACL des rôles d'openzeppelin qui n'autorisera que des rôles spécifiques à accéder au destoryContract fonctions
Les pools d'utilisateurs sont soumis à des attaques MEV
| Contract | contrats/ZenPoolUserManager.sol |
| Analyse | Haute |
| Fixé | Non – Risque pris |
| Trouvé par | Test manuel |
Description
La principale ZenPoolUserManager gère les groupes d'utilisateurs personnalisés qui ont été créés dans le système. L'utilisateur peut appeler différentes actions sur ces pools s'il a les bonnes autorisations pour le faire, un utilisateur peut également accorder l'accès via un mécanisme de rôle basé sur les contrats de contrôle d'accès d'OpenZeppelin
La ZenPoolUserManager a un mécanisme ACL approprié, mais en même temps, il a 2 fonctions qui sont soumises à une course avant/arrière ou à toute attaque MEV.
Bien que la logique métier elle-même soit correcte et semble ne pas pouvoir faire beaucoup de mal car elle dispose d'une ACL appropriée, un utilisateur ayant le même rôle pourrait l'exploiter via des attaques MEV.
Atténuation
Utilisez l'option onlyOwner modificateur comme il est utilisé dans la réinitialisation des fonctions.
Une autre solution plus spécifique serait d'utiliser un mécanisme d'ACL personnalisé comme l'ACL des rôles d'openzeppelin qui n'autorisera que des rôles spécifiques à accéder au destoryContract fonctions.
Absence d'atténuation des tuteurs
| Contract | contrats/ZenGovernorAlpha.sol |
| Analyse | Moyenne |
| Fixé | Fixé |
| Trouvé par | Analyse du code hérité et tests manuels |
Description
Au cours de notre audit, nous avons effectué une analyse du code d'origine et comparé la base de code actuelle du client à la
projets open-source que le client a utilisés pour développer le code. Si nous constations que des modifications avaient été apportées au code open source, nous les examinions plus en profondeur pour nous assurer qu'elles avaient été effectuées à bon escient.
La plupart des clients considèrent que les projets open source tiers sont sécurisés car ils proviennent de grands fournisseurs (par exemple, pool Uniswap). Cette hypothèse est majoritairement vraie. Cependant, des bogues de sécurité majeurs surviennent lorsque les clients effectuent des modifications mineures dans le code et supposent que ces modifications n'affectent pas la sécurité globale du produit.
Au cours de notre analyse du code d'origine, nous avons constaté que ZenPool utilise le code du protocole STRIKE afin de créer un jeton de gouvernance, le code d'origine du référentiel STRIKE est :
Alors que le code dans ZenGovernorAlpha est :
La déclaration suivante a été supprimée msg.sender == guardian, cela signifie que le tuteur ne peut pas annuler les commandes si un seuil est atteint. L'élimination du pouvoir des gardiens peut provoquer des situations très dangereuses. Par exemple, si une proposition compromise qui transfère tout l'argent du contrat à un acteur malveillant a été effectuée (par un piratage de clé privée par exemple), le mécanisme de protection de seuil est redondant et ne peut pas aider, car il n'y a aucun tuteur qui peut arrêter la proposition. de se produire.
Atténuation
Ajouter msg.sender == guardian à la require .
Absence de garde de réintégration
| Contract | contrats/ZenLendingPool.sol |
| Analyse | Moyenne |
| Fixé | Fixé |
| Trouvé par | Tests glissants et manuels |
Description
La fonction d'emprunt suivante ne contient pas de garde de réentrance ni le modèle de vérifications-effets-interactions, ce n'est actuellement pas exploitable car le pool ne prend en charge que les jetons ERC20, mais si à l'avenir un nouvel ERC-777 sera ajouté, un exploit de réentrance peut se produire et provoquer le prélèvement complet des fonds du contrat.
De plus, le code ne suit pas le modèle contrôles-effets-interactions. Dans ce cas précis, le require est cochée après qu'une certaine logique métier est déjà implémentée, cela pourrait provoquer des bogues de réentrance si des effets secondaires sont ajoutés avant la require.
Atténuation
Ajoutez une protection de réentrance pour la même réentrance de fonction et utilisez également le modèle vérifications-effets-interactions pour la réentrance interfonctionnelle complexe.
Interdire les transferts de montant nul
| Contract | contrats/ZenPoolFunds.sol |
| Analyse | Faible |
| Fixé | Oui |
| Trouvé par | Test manuel |
Description
La ZenPoolFunds.sol Le contrat permet des transferts de montant nul entre les utilisateurs. Bien qu'il ne s'agisse pas en soi d'une vulnérabilité de sécurité, il s'agit d'un exemple de code qui peut étendre le vecteur d'attaque d'un attaquant malveillant.
La vulnérabilité existe parce que transfer sur ZenPool émettre des événements, en faisant un montant nul transfer un attaquant pourrait émettre plusieurs événements pouvant, dans certains scénarios, déclencher une logique métier hors chaîne, sans même détenir de jeton dans le pool.
Atténuation
Une compréhension plus approfondie de l'entreprise est nécessaire. Si possible, supprimez cette fonctionnalité.
S'il existe des cas d'utilisation où il est logique d'utiliser des transferts de montant nul, implémentez une autre couche de contrôles pour limiter l'utilisation aux utilisateurs qui font partie de ce groupe.
Journalisation insuffisante pour les fonctions privilégiées
| Contract | contrats/ZenGovernorAlpha.sol |
| Analyse | Info |
| Fixé | Oui |
| Trouvé par | Test manuel |
Description
Les privilégiés suivants onlyOwner la fonction n'émet pas d'événements.
Les événements sont une pratique courante pour les fonctions privilégiées pour annoncer au public qu'un changement a été effectué. Sans événements, les changements sont plus difficiles à détecter et les utilisateurs sont surpris par le comportement du contrat.
Le propriétaire peut appeler le chainId en exécutant setChainId() et en modifiant le chaindId paramètre sans qu'aucun événement ne soit émis dans le processus.
Atténuation
Ajoutez du code qui émet des événements.
Vérification redondante des conditions
| Contract | contrats/createGovernor.sol |
| Analyse | Info |
| Fixé | Oui |
| Trouvé par | Test manuel |
Description
Lors de la création d'un nouveau jeton de gouverneur, le _timelockDelay paramètre est validé deux fois. une fois dans tous les contrôles lorsque la fonction démarre, puis dans le cadre d'un autre require, ceci est redondant et doit être supprimé.
Le code dupliqué nécessite plus de gaz pour s'exécuter et peut entraîner de futurs bogues lorsque la logique métier change.
Atténuation
Supprimer le deuxième redondant require.
Incohérence de dénomination
| Contract | - Plusieurs - |
| Analyse | Info |
| Fixé | Risque pris |
| Trouvé par | Tests glissants et manuels |
Description
Il existe de multiples occurrences de différents styles de majuscules (minuscule camel, serpent, etc.).
Atténuation
Passez en revue le code pour le style de code.
Ajoutez un guide de style de code et appliquez-le à l'aide d'une tâche CI.