Audit FatCats
Résumé de gestion
FatCats a contacté Sayfer Security afin d'effectuer un audit de contrat intelligent sur leur contrat NFT sur le réseau Ethereum
Au cours de la période de recherche de 3 semaines, nous avons découvert 6 vulnérabilités dans le contrat. Une vulnérabilité a été classée comme élevée, ce qui a permis à un attaquant d'accéder aux métadonnées NFT avant qu'elles ne soient révélées et de faire des prédictions intelligentes sur les parachutages ou les transactions de frappe spécifiques pour les NFT rares.
La plupart des vulnérabilités ne sont pertinentes que lors de la création de nouveaux NFT, nous vous recommandons donc fortement de corriger les vulnérabilités trouvées dans ce rapport avant d'en créer de nouvelles.
Vulnérabilités par risque
Critical – Une partie immédiate ou continue de l'entreprise exploitée avec des pertes commerciales clés directes.
Haute – Menace directe sur les processus métier clés.
Moyenne – Menace indirecte sur les processus métier clés ou menace partielle sur les processus métier.
Faible – Aucune menace directe n'existe. La vulnérabilité peut être exploitée à l'aide d'autres vulnérabilités.
D'information – Cette constatation n'indique pas de vulnérabilité, mais énonce un commentaire qui signale des défauts de conception et une mise en œuvre incorrecte qui pourraient causer un problème à long terme.
Approche
Introduction
FatCats a contacté Sayfer afin d'effectuer un audit de sécurité sur les contrats intelligents FatCats.
Ce rapport documente les recherches mené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é pour les contrats intelligents FatCats.
Cycle de vie de notre projet de test d'intrusion :
Aperçu de la portée
Présentation technique
Validation de la portée
Modèle de menace
Évaluation de la sécurité
Évaluation de sécurité
Validation de la portée
Nous avons commencé par nous assurer que le périmètre qui nous était défini par le client était techniquement logique.
Décider quelle portée convient à un système donné fait partie de la discussion initiale.
Modèle de menace
Nous avons défini que la plus grande menace actuelle pour le système est la capacité des utilisateurs malveillants à voler les fonds du contrat. Le deuxième risque le plus élevé pour la plate-forme est la capacité d'une attaque à voler NFT du contrat.
Présentation du protocole
Présentation du protocole
Fat Cats est une collection de 5,000 XNUMX NFT uniques qui servent également de jeton d'adhésion et de partage de tous les avoirs de Fat Cats. Posséder un Fat Cats NFT vous donne accès à une part de l'ensemble des avoirs de DAO à un prix abordable.
Tous les fonds liquides seront détenus dans un panier de pièces stables et d'autres actifs cryptographiques selon ce que les membres jugent approprié. Dans le cas de décisions urgentes, le Conseil peut dépenser jusqu'à 20 % de tous les fonds entiercés.
Le contrat FatCats est un contrat de jeton NFT dont la frappe se fait par étapes - étape 1, étape 2 et frappe publique. Les étapes de frappe sont fixées par le propriétaire. Les utilisateurs de la liste blanche peuvent frapper NFT à l'étape 1 et à l'étape 2. Les utilisateurs sur liste blanche sont validés par la preuve Merkle.
Le contrat FatCats hérite des contrats intelligents standard MerkleProof, Ownable, Address, VRFCoordinatorV2Interface, VRFConsumerBaseV2, IERC721Receiver, Context, IERC721Metadata , Strings, ERC165, IERC721 de la bibliothèque OpenZeppelin. Ces contrats OpenZeppelin sont considérés comme audités par la communauté et testés dans le temps, et ne font donc pas partie de la portée de l'audit.
Graphique de protocole
Évaluation de la sécurité
Les cas de test suivants ont été la ligne directrice lors de l'audit du système. Cette liste de contrôle est une version modifiée de la SCSVS v1.2, avec une grammaire améliorée, de la clarté, de la concision et des critères supplémentaires. Lorsqu'il y a une lacune dans la numérotation, un critère d'origine a été supprimé. Les critères marqués d'un astérisque ont été ajoutés par nous.
Architecture, conception et modélisation des menaces
| Architecture, conception et modélisation des menaces | Nom du test |
| G1.2 | Chaque modification de conception introduite est précédée d'une modélisation des menaces. |
| G1.3 | La documentation définit clairement et précisément toutes les frontières de confiance dans le contrat (relations de confiance avec les autres contrats et flux de données importants). |
| G1.4 | Le SCSVS, les exigences ou la politique de sécurité sont disponibles pour tous les développeurs et testeurs. |
| G1.5 | Les événements pour les opérations (changement d'état/cruciales pour l'entreprise) sont définis. |
| G1.6 | Le projet inclut un mécanisme qui peut stopper temporairement les fonctionnalités sensibles en cas d'attaque. Ce mécanisme ne doit pas bloquer l'accès des utilisateurs à leurs actifs (par exemple, les jetons). |
| G1.7 | La quantité de crypto-monnaies non utilisées conservées sur le contrat est contrôlée et au niveau minimum acceptable afin de ne pas devenir une cible potentielle d'attaque. |
| G1.8 | Si la fonction de secours peut être appelée par n'importe qui, elle est incluse dans le modèle de menace. |
| G1.9 | La logique métier est cohérente. Des changements importants dans la logique doivent être appliqués dans tous les contrats. |
| G1.10 | Des outils d'analyse de code automatique sont utilisés pour détecter les vulnérabilités. |
| G1.11 | La dernière version majeure de Solidity est utilisée. |
| G1.12 | Lors de l'utilisation d'une implémentation externe d'un contrat, la version la plus récente est utilisée. |
| G1.13 | Lorsque les fonctions sont remplacées pour étendre les fonctionnalités, le mot-clé super est utilisé pour conserver les fonctionnalités précédentes. |
| G1.14 | L'ordre d'héritage est soigneusement spécifié. |
| G1.15 | Il existe un composant qui surveille l'activité du contrat à l'aide d'événements. |
| G1.16 | Le modèle de menace inclut les transactions de baleines. |
| G1.17 | La fuite d'une clé privée ne compromet pas la sécurité de l'ensemble du projet. |
Les politiques et les procédures
| Les politiques et les procédures | Nom du test |
| G2.2 | La sécurité du système fait l'objet d'une surveillance constante (par exemple, le niveau de financement attendu). |
| G2.3 | Il existe une politique pour suivre les nouvelles vulnérabilités de sécurité et mettre à jour les bibliothèques vers la dernière version sécurisée. |
| G2.4 | Le service de sécurité peut être contacté publiquement et que la procédure de traitement des bogues signalés (par exemple, une prime de bogue approfondie) est bien définie. |
| G2.5 | Le processus d'ajout de nouveaux composants au système est bien défini. |
| G2.6 | Le processus de modifications majeures du système implique la modélisation des menaces par une société externe. |
| G2.7 | Le processus d'ajout et de mise à jour des composants du système comprend un audit de sécurité par une société externe. |
| G2.8 | En cas de piratage, une procédure d'atténuation claire et bien connue est en place. |
| G2.9 | La procédure en cas de piratage définit clairement quelles personnes doivent exécuter les actions requises. |
| G2.10 | La procédure consiste à alerter d'autres projets sur le piratage via des canaux de confiance. |
| G2.11 | Une procédure d'atténuation des fuites de clé privée est définie. |
Évolutivité
| Évolutivité | Nom du test |
| G3.2 | Avant la mise à jour, une émulation est faite dans un fork du réseau principal et tout fonctionne comme prévu sur la copie locale. |
| G3.3 | Le processus de mise à niveau est exécuté par un contrat multisig où plus d'une personne doit approuver l'opération. |
| G3.4 | Les timelocks sont utilisés pour les opérations importantes afin que les utilisateurs aient le temps d'observer les changements à venir (veuillez noter que la suppression des vulnérabilités potentielles dans ce cas peut être plus difficile). |
| G3.5 | initialiser() ne peut être appelé qu'une seule fois. |
| G3.6 | initialiser() ne peut être appelé que par un rôle autorisé via des modificateurs appropriés (par exemple initialiseur, seul propriétaire). |
| G3.7 | Le processus de mise à jour est effectué en une seule transaction afin que personne ne puisse l'exécuter en amont. |
| G3.8 | Les contrats évolutifs ont réservé un espace sur les créneaux horaires pour éviter l'écrasement. |
| G3.9 | Le nombre d'emplacements réservés (en tant qu'écart) a été réduit de manière appropriée si de nouvelles variables ont été ajoutées. |
| G3.10 | Il n'y a aucun changement dans l'ordre dans lequel les variables d'état du contrat sont déclarées, ni leurs types. |
| G3.11 | Les nouvelles valeurs renvoyées par les fonctions sont les mêmes que dans les versions précédentes du contrat (par exemple propriétaire(), balanceOf(adresse)). |
| G3.12 | L'implémentation est initialisée. |
| G3.13 | L'implémentation ne peut pas être détruite. |
Logique métier
| Logique métier | Nom du test |
| G4.2 | La mise en œuvre de la logique du contrat et des paramètres du protocole correspond à la documentation. |
| G4.3 | La logique métier procède dans un ordre d'étape séquentiel et il n'est pas possible de sauter des étapes ou de le faire dans un ordre différent de celui conçu. |
| G4.4 | Le contrat a correctement appliqué les limites commerciales. |
| G4.5 | La logique métier ne repose pas sur les valeurs récupérées à partir de contrats non approuvés (en particulier lorsqu'il y a plusieurs appels au même contrat dans un seul flux). |
| G4.6 | La logique métier ne repose pas sur le solde du contrat (par exemple, solde == 0). |
| G4.7 | Les opérations sensibles ne dépendent pas des données de bloc (par exemple, bloc de hachage, horodatage). |
| G4.8 | Le contrat utilise des mécanismes qui atténuent les attaques de commande de transaction (front-running) (par exemple, les schémas de pré-engagement). |
| G4.9 | Le contrat n'envoie pas de fonds automatiquement, mais permet aux utilisateurs de retirer des fonds dans des transactions distinctes à la place. |
Contrôle d'accès
| Contrôle d'accès | Nom du test |
| G5.2 | Le principe du moindre privilège est respecté. Les autres contrats ne devraient pouvoir accéder qu'aux fonctions et données pour lesquelles ils disposent d'une autorisation spécifique. |
| G5.3 | Les nouveaux contrats ayant accès au contrat audité respectent le principe des droits minimaux par défaut. Les contrats doivent avoir un minimum ou aucune autorisation jusqu'à ce que l'accès aux nouvelles fonctionnalités soit explicitement accordé. |
| G5.4 | Le créateur du contrat respecte le principe du moindre privilège et ses droits suivent strictement ceux décrits dans la documentation. |
| G5.5 | Le contrat applique les règles de contrôle d'accès spécifiées dans un contrat de confiance, en particulier si le contrôle d'accès côté client dApp est présent et peut être contourné. |
| G5.6 | Les appels à des contrats externes ne sont autorisés qu'en cas de nécessité. |
| G5.7 | Le code modificateur est clair et simple. La logique ne doit pas contenir d'appels externes à des contrats non approuvés. |
| G5.8 | Tous les attributs d'utilisateur et de données utilisés par les contrôles d'accès sont conservés dans des contrats de confiance et ne peuvent pas être manipulés par d'autres contrats, sauf autorisation spécifique. |
| G5.9 | Les contrôles d'accès échouent en toute sécurité, y compris lorsqu'un retour se produit. |
| G5.10 | Si l'entrée (paramètres de la fonction) est validée, l'approche de validation positive (liste blanche) est utilisée dans la mesure du possible. |
Communication
| Communication | Nom du test |
| G6.2 | Les bibliothèques qui ne font pas partie de l'application (mais dont le contrat intelligent dépend pour fonctionner) sont identifiées. |
| G6.3 | L'appel délégué n'est pas utilisé avec les contrats non approuvés. |
| G6.4 | Les contrats de tiers n'occultent pas les fonctions spéciales (par exemple, revenir). |
| G6.5 | Le contrat ne vérifie pas si l'adresse est un contrat utilisant l'opcode extcodesize. |
| G6.6 | Les attaques de réentrance sont atténuées en bloquant les appels récursifs provenant d'autres contrats et en suivant le modèle Check-Effects-Interactions. N'utilisez pas la fonction d'envoi sauf si c'est indispensable. |
| G6.7 | Le résultat d'appels de fonction de bas niveau (par exemple envoyer, déléguer appeler, appeler) d'autres contrats est cochée. |
| G6.8 | Le contrat repose sur les données fournies par le bon expéditeur et non sur la valeur tx.origin. |
Arithmétique
| Arithmétique | Nom du test |
| G7.2 | Les valeurs et les opérations mathématiques résistent aux débordements d'entiers. Utilisez la bibliothèque SafeMath pour les opérations arithmétiques avant Solidity 0.8.*. |
| G7.3 | Les extraits de code non cochés de Solidity ≥ 0.8.* n'introduisent pas de sous/débordements entiers. |
| G7.4 | Les valeurs extrêmes (par exemple, les valeurs maximales et minimales du type de variable) sont prises en compte et ne modifient pas le flux logique du contrat |
| G7.5 | L'inégalité non stricte est utilisée pour l'égalité d'équilibre. |
| G7.6 | Les ordres de grandeur corrects sont utilisés dans les calculs. |
| G7.7 | Dans les calculs, la multiplication est effectuée avant la division pour plus de précision. |
| G7.8 | Le contrat ne suppose pas une précision en virgule fixe et utilise un multiplicateur ou stocke à la fois le numérateur et le dénominateur. |
Déni de service
| Déni de service | Nom du test |
| G8.2 | Le contrat n'itère pas sur des boucles non liées. |
| G8.3 | La fonctionnalité d'autodestruction n'est utilisée que si nécessaire. S'il est inclus dans le contrat, il doit être clairement décrit dans la documentation. |
| G8.4 | La logique métier n'est pas bloquée si un acteur (par exemple contrat, compte, oracle) est absent. |
| G8.5 | La logique métier ne décourage pas les utilisateurs d'utiliser des contrats (par exemple, le coût de la transaction est supérieur au profit). |
| G8.6 | Les expressions de fonctions assert ou require ont une variante passante. |
| G8.7 | Si la fonction de secours ne peut être appelée par personne, elle ne bloque pas les fonctionnalités du contrat. |
| G8.8 | Il n'y a pas d'opérations coûteuses en boucle. |
| G8.9 | Il n'y a pas d'appels à des contrats non approuvés dans une boucle. |
| G8.10 | S'il existe une possibilité de suspendre l'exécution du contrat, il est également possible de le reprendre. |
| G8.11 | Si des listes blanches et des listes noires sont utilisées, elles n'interfèrent pas avec le fonctionnement normal du système. |
| G8.12 | Il n'y a pas de DoS causé par les débordements et les débordements. |
Données de la chaîne de blocs
| Données de la chaîne de blocs | Nom du test |
| G9.2 | Toutes les données enregistrées dans les contrats ne sont pas considérées comme sécurisées ou privées (même les variables privées). |
| G9.3 | Aucune donnée confidentielle n'est stockée dans la blockchain (mots de passe, données personnelles, token etc.). |
| G9.4 | Les contrats n'utilisent pas de littéraux de chaîne comme clés pour les mappages. Les constantes globales sont utilisées à la place pour empêcher l'attaque homoglyphe. |
| G9.5 | Le contrat ne génère pas trivialement des nombres pseudo-aléatoires basés sur les informations de la blockchain (par exemple, l'ensemencement avec le numéro de bloc). |
Utilisation du gaz et limites
| Utilisation du gaz et limites | Nom du test |
| G10.1 | L'utilisation du gaz est anticipée, définie et a des limites claires qui ne peuvent pas être dépassées. La structure du code et les entrées malveillantes ne doivent pas provoquer d'épuisement des gaz. |
| G10.2 | L'exécution et la fonctionnalité des fonctions ne dépendent pas des frais de gaz codés en dur (ils sont susceptibles de varier). |
Clarté et lisibilité
| Clarté et lisibilité | Nom du test |
| G11.2 | La logique est claire et modularisée en plusieurs contrats et fonctions simples. |
| G11.3 | Chaque contrat comporte un court commentaire de 1 à 2 phrases qui explique son objectif et sa fonctionnalité. |
| G11.4 | Des implémentations prêtes à l'emploi sont utilisées, cela est clairement indiqué dans les commentaires. Si ces implémentations ont été modifiées, les modifications sont notées tout au long du contrat. |
| G11.5 | L'ordre d'héritage est pris en compte dans les contrats qui utilisent plusieurs fonctions d'héritage et de duplication. |
| G11.6 | Dans la mesure du possible, les contrats utilisent du code testé existant (par exemple, des contrats de jeton ou des mécanismes tels que propriétaire) au lieu d'implémenter les leurs. |
| G11.7 | Des modèles de dénomination cohérents sont suivis tout au long du projet. |
| G11.8 | Les variables ont des noms distinctifs. |
| G11.9 | Toutes les variables de stockage sont initialisées. |
| G11.10 | Les fonctions avec le type de retour spécifié renvoient une valeur de ce type. |
| G11.11 | Toutes les fonctions et variables sont utilisées. |
| G11.12 | exigent est utilisé au lieu de revenir in if Déclarations. |
| G11.13 | La affirmer La fonction est utilisée pour tester les erreurs internes et le exigent La fonction est utilisée pour garantir une condition valide dans les entrées des utilisateurs et des contrats externes. |
| G11.14 | Le code d'assemblage n'est utilisé que si nécessaire. |
Couverture de test
| Couverture de test | Nom du test |
| G12.2 | Les récits d'abus détaillés dans le modèle de menace sont couverts par des tests unitaires |
| G12.3 | Les fonctions sensibles dans les contrats vérifiés sont couvertes par des tests en phase de développement. |
| G12.4 | La mise en œuvre des contrats vérifiés a été vérifiée pour les vulnérabilités de sécurité à l'aide d'analyses statiques et dynamiques. |
| G12.5 | La spécification du contrat a été formellement vérifiée |
| G12.6 | La spécification et les résultats de la vérification formelle sont inclus dans la documentation. |
Finance décentralisée
| Finance décentralisée | Nom du test |
| G13.1 | Le contrat du prêteur ne suppose pas que son solde (utilisé pour confirmer le remboursement du prêt) soit modifié uniquement avec ses propres fonctions. |
| G13.2 | Les fonctions qui modifient le solde des prêteurs et/ou prêtent de la crypto-monnaie sont non réentrantes si le contrat intelligent permet d'emprunter la crypto-monnaie de la plateforme principale (par exemple Ethereum). Il bloque les attaques qui mettent à jour le solde de l'emprunteur lors de l'exécution du prêt flash. |
| G13.3 | Les fonctions de prêt Flash ne peuvent appeler que des fonctions prédéfinies sur le contrat de réception. Si cela est possible, définissez un sous-ensemble de contrats de confiance à appeler. Habituellement, le contrat d'envoi (d'emprunt) est celui à rappeler. |
| G13.4 | Si cela inclut des opérations potentiellement dangereuses (par exemple, renvoyer plus d'ETH/tokens qu'emprunté), la fonction du destinataire qui gère les ETH ou les tokens empruntés ne peut être appelée que par le pool et dans le cadre d'un processus initié par le propriétaire du contrat destinataire ou une autre source de confiance (par exemple multisig). |
| G13.5 | Les calculs de la part du pool de liquidités sont effectués avec la plus grande précision possible (par exemple, si la contribution est calculée pour ETH, elle doit être effectuée avec une précision de 18 chiffres - pour Wei, pas Ether). Le dividende doit être multiplié par 10 à la puissance du nombre de chiffres décimaux (par exemple dividende * 10^18 / diviseur). |
| G13.6 | Les récompenses ne peuvent pas être calculées et distribuées dans le même appel de fonction qui dépose des jetons (il doit également être défini comme non réentrant). Cela protège des fluctuations momentanées des actions. |
| G13.7 | Les contrats de gouvernance sont protégés contre les attaques de prêts flash. Une technique d'atténuation possible consiste à exiger que le processus de dépôt de jetons de gouvernance et de proposition d'un changement soit exécuté dans différentes transactions incluses dans différents blocs. |
| G13.8 | Lors de l'utilisation d'oracles en chaîne, les contrats peuvent suspendre les opérations en fonction du résultat des oracles (en cas d'oracle compromis). |
| G13.9 | Les contrats externes (même ceux de confiance) qui sont autorisés à modifier les attributs d'un contrat de projet (par exemple, le prix du jeton) ont les limitations suivantes mises en œuvre : des seuils pour le changement (par exemple, pas plus/moins de 5 %) et une limite de mises à jour (par exemple une mise à jour par jour). |
| G13.10 | Les attributs de contrat pouvant être mis à jour par les contrats externes (même ceux de confiance) sont surveillés (par exemple à l'aide d'événements) et une procédure de réponse aux incidents est mise en place (par exemple lors d'une attaque en cours). |
| G13.11 | Les opérations mathématiques complexes qui consistent à la fois en opérations de multiplication et de division effectuent d'abord des multiplications, puis des divisions. |
| G13.12 | Lors du calcul des prix d'échange (par exemple ETH à jeton ou vice versa), le numérateur et le dénominateur sont multipliés par les réserves (voir le getInputPrice fonction de l' UniswapExchange Contrat). |
Commandez l'audit de Sayfer
Constatations des audits
URI de jetons devinables
| Statut | Ouvert |
| Analyse | Critical |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Avoir une longueur d'avance sur les métadonnées du NFT pourrait permettre à un attaquant de savoir quel NFT il devrait frapper avant la révélation publique. Cela pourrait potentiellement permettre à l'attaquant de prendre le contrôle des NFT les plus précieux du projet.
La vulnérabilité suivante permet à un attaquant de décider quel NFT acheter en fonction des métadonnées avant la révélation publique. Cette vulnérabilité est relativement facile à exploiter en raison d'autres vulnérabilités que nous avons trouvées. Dans le temps entre le shuffle drapeau devenant vrai dans requestRandomWords() et les NFT révélés dans revealNFT(), un attaquant peut deviner les URI du jeton.
Tandis que le revealed le drapeau est toujours faux tokenURI() Retours hideUri, ce qui signifie que l'utilisateur moyen ne verra que l'URI factice/caché sans les métadonnées complètes.
Pour construire entièrement la chaîne URI du jeton, une autre transaction est en cours pour exécuter le requestRandomWords() méthode qui définit le s_randomWords via fulfillRandomWords(). Cela se fait via le VRF de Chianlink.
Ce n'est qu'alors que le code suivant est exécuté et renvoie la chaîne URI complète du jeton :
La vulnérabilité est que baseURI, maxSupply ainsi que s_randomWords sont publics et un attaquant peut prédire l'URI du jeton sans avoir besoin du revealed variable. Dans la V1 du projet, nous avons vu que la première transaction qui s'exécute requestRandomWords():
Et puis la deuxième transaction qui révèle le NFT en exécutant le revealNFT():
Nous pouvons voir que pendant 3 heures, un attaquant aurait pu visualiser toutes les métadonnées NFT avant qu'elles ne soient révélées et faire des prédictions intelligentes sur les parachutages ou les transactions de frappe spécifiques pour les NFT rares.
Atténuation
Révéler un NFT n'a pas de taille unique. Cela dépend fortement de la stratégie et de l'expérience utilisateur que l'utilisateur final devrait avoir.
Pour une meilleure sécurité, nous vous encourageons à révéler, définir l'URI de base et modifier l'état de s_randomWords variable d'état avec la différence de temps la plus courte entre eux. Sans atténuer complètement la vulnérabilité, réduire le temps entre ces actions peut réduire le risque que des acteurs malveillants l'exploitent.
Une meilleure façon est de faire tous les changements d'état dans la même transaction tout en révélant, ce n'est souvent pas techniquement possible.
Pour une plongée plus profonde dans la façon de mettre en œuvre un airdrop NFT aléatoire et des moyens plus sûrs, nous vous recommandons de lire Stratégies de randomisation pour les gouttes NFT.
Les adresses sur liste blanche peuvent être des contrats
| Statut | Ouvert |
| Analyse | Haute |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Lors de la frappe d'un NFT, le contrat de frappe peut bloquer ou autoriser la frappe des adresses contractuelles. Permettre à la frappe de se contracter ou avoir une vulnérabilité qui permet la frappe de contrat pourrait entraîner une situation dans laquelle l'attaquant peut annuler la transaction s'il a une connaissance préalable du NFT qu'il doit frapper.
Le modificateur isAUser() n'est utilisé que pour publicMint().
Pour mintStep1() ainsi que mintStep2() méthodes le isWhitelisted() modificateur est utilisé.
Cela signifie que le code ne vérifie pas les adresses non contractuelles dans les hachages de preuve Merkle de la liste blanche.
Bien que nous ne puissions pas savoir quels étaient les processus à l'origine de la génération de la liste blanche et à quel point elle est sécurisée, le code lui-même est vulnérable à cette attaque. La vérification des adresses non contractuelles hors chaîne ou non dans la même transaction est déconseillée car elle est vulnérable à plusieurs vecteurs d'attaque.
Un attaquant pourrait obtenir un NFT et annuler la transaction si le NFT n'est pas assez rare. En conjonction avec l'URI Guessable Token, un attaquant peut facilement acquérir des connaissances préalables sur les métadonnées du NFT et annuler les transactions en fonction de la rareté.
Atténuation
Ajoutez le isAUser modificateur au mintStep1() ainsi que mintStep2() méthodes.
Implémentation aléatoire faible et non sécurisée du VRF de Chainlink
| Statut | Ouvert |
| Analyse | Haute |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Des erreurs aléatoires non sécurisées se produisent lorsqu'une fonction qui peut produire des valeurs prévisibles est utilisée comme source d'aléa dans un contexte sensible à la sécurité.
Les contrats intelligents doivent s'appuyer sur des solutions hors chaîne pour générer des nombres aléatoires sécurisés. Fatcats utilise le système VRF de Chainlink pour générer un nombre aléatoire qui sera ensuite utilisé comme identifiant aléatoire pour l'URI du jeton en utilisant le fulfillRandomWords méthode:
La méthode enregistre le nombre aléatoire dans une variable d'état appelée s_randomWords ce qui, par son nom, implique qu'il s'agit d'un mot aléatoire. En pratique, le nombre est modulo avec maxSupply(5000) il s'agit donc d'un pseudo nombre aléatoire faible compris entre 1 et 5000. Cela peut amener les développeurs à penser qu'ils peuvent compter sur ce nombre pour un caractère aléatoire sécurisé, ce qui n'est pas le cas.
Atténuation
Affectez la valeur renvoyée provenant de VRF à la variable d'état globale.
Centralisation du contrat et du portefeuille d'équipe
| Statut | Ouvert |
| Analyse | Haute |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Les projets qui reposent sur une clé sont vulnérables aux pertes de clés, aux attaques de phishing, aux manipulations d'acteurs internes, à la mort du propriétaire, etc.
Lorsque le projet ne dépend que d'une seule clé. Ces types d'attaques sont les plus courants des plus gros hacks.
Le projet vérifie la isOwner à plusieurs endroits. La perte des clés de cette adresse de déploiement compromettra l'ensemble du projet.
De plus, le portefeuille de l'équipe qui obtiendra l'eth en utilisant le withdraw la fonction est également soumise au même vecteur d'attaque
Si les portefeuilles ci-dessus utilisent multisig, ce problème sera résolu.
Atténuation
Selon le cas d'utilisation, le niveau de sécurité et l'expérience utilisateur que le projet souhaite appliquer, il existe plusieurs façons d'atténuer cette attaque, par exemple en utilisant un portefeuille multisig, un portefeuille intelligent ou en appliquant plusieurs propriétaires au projet.
La fonction openPublicBurn change plutôt que s'ouvre
| Statut | Ouvert |
| Analyse | Faible |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Procédé openPublicBurn ne se contente pas d'ouvrir la gravure publique, il l'allume et l'éteint en fonction de l'état actuel de la variable.
Cela pourrait amener un développeur ou un opérateur du projet à penser qu'il ouvre l'étape de gravure publique mais qu'il la désactive en fait, ce qui cause une mauvaise réputation au projet.
Atténuation
Définir la variable d'état publicBurnFlag à true ou changez le nom de la méthode en
switchPublicBurn.
Le mécanisme d'étape est difficile à maintenir
| Statut | Ouvert |
| Analyse | Info |
| Localisation | FatCats.sol |
| Outils | Test manuel |
Description
Le code utilise des variables booléennes pour chaque étape, cela signifie que chaque fois que le développeur ajoute une autre étape, il doit ajouter la logique pour basculer la réinitialisation des drapeaux. Cela pourrait entraîner une confusion et des bogues de sécurité potentiels.
Une meilleure approche serait d'utiliser enum comme étape actuelle si, cela donne les avantages d'un nom d'étape clair comme EARLY_ADAPTERS, PUBLINK_MINT, Etc.
Si cela est trop verbeux ou déroutant, il pourrait être implémenté via un simple entier, cela a l'avantage mathématique de if step > 2 or require(newStep < oldStep, “can not go back”.
Atténuation
Utilisez l'énumération intégrée Solidity ou la syntaxe d'entier simple.