Audit di FatCats
Sommario di gestione
FatCats ha contattato Sayfer Security per eseguire il controllo del contratto intelligente sul proprio contratto NFT sulla rete Ethereum
Durante il periodo di ricerca di 3 settimane abbiamo scoperto 6 vulnerabilità nel contratto. Una vulnerabilità è stata classificata come alta che ha consentito a un utente malintenzionato di accedere ai metadati NFT prima che venissero rivelati e fare previsioni intelligenti su lanci aerei o transazioni di conio specifiche per NFT rari.
La maggior parte delle vulnerabilità sono rilevanti solo durante il conio di nuovi NFT, quindi consigliamo vivamente di correggere le vulnerabilità rilevate in questo rapporto prima di coniarne di nuovi.
Vulnerabilità per rischio
critico – Parte immediata o continua dell'attività sfruttata con perdite dirette di attività chiave.
Alta – Minaccia diretta ai processi aziendali chiave.
Medio – Minaccia indiretta ai processi aziendali chiave o minaccia parziale ai processi aziendali.
Basso – Non esiste alcuna minaccia diretta. La vulnerabilità può essere sfruttata utilizzando altre vulnerabilità.
Informativo – Questo risultato non indica vulnerabilità, ma riporta un commento che segnala difetti di progettazione e implementazione impropria che potrebbero causare problemi a lungo termine.
Approccio
Introduzione
FatCats ha contattato Sayfer per eseguire un controllo di sicurezza sui contratti intelligenti di FatCats.
Questo rapporto documenta la ricerca svolta da Sayfer indirizzata alle risorse selezionate definite nell'ambito della ricerca. In particolare, questo rapporto mostra la revisione della posizione di sicurezza per i contratti intelligenti FatCats.
Il ciclo di vita del nostro progetto di test di penetrazione:
Panoramica dell'ambito
Panoramica tecnica
Convalida dell'ambito
Modello di minaccia
Valutazione della sicurezza
Valutazione della sicurezza
Convalida dell'ambito
Abbiamo iniziato assicurandoci che l'ambito definitoci dal cliente fosse tecnicamente logico.
Decidere quale ambito è giusto per un dato sistema fa parte della discussione iniziale.
Modello di minaccia
Abbiamo definito che la più grande minaccia attuale per il sistema è la capacità di utenti malintenzionati di rubare fondi dal contratto. Il secondo rischio più elevato per la piattaforma è la capacità dell'attacco di rubare NFT dal contratto.
Panoramica del protocollo
Introduzione al protocollo
Fat Cats è una raccolta di 5,000 NFT unici che fungono anche da token di appartenenza e quota di tutte le partecipazioni di Fat Cats. Possedere un Fat Cats NFT ti dà accesso a una quota delle intere partecipazioni di DAO a un prezzo accessibile.
Tutti i fondi liquidi saranno tenuti in un paniere di monete stabili e altre risorse crittografiche come i membri ritengono opportuno. In caso di decisioni urgenti, il Consiglio può spendere fino al 20% di tutti i fondi depositati.
FatCats Contract è un contratto di token NFT con conio in passaggi: passaggio 1, passaggio 2 e conio pubblico. I passaggi di conio sono impostati dal proprietario. Gli utenti autorizzati possono coniare NFT nel passaggio 1 e nel passaggio 2. Gli utenti autorizzati sono convalidati da Merkle proof.
Il contratto FatCats eredita MerkleProof, Ownable, Address, VRFCoordinatorV2Interface, VRFConsumerBaseV2, IERC721Receiver, Context, IERC721Metadata , Strings, ERC165, IERC721, smart contract standard dalla libreria OpenZeppelin. Questi contratti OpenZeppelin sono considerati controllati dalla comunità e testati nel tempo, e quindi non fanno parte dell'ambito dell'audit.
Grafico del protocollo
Valutazione della sicurezza
I seguenti casi di test sono stati la linea guida durante l'audit del sistema. Questa lista di controllo è una versione modificata del SCSVS v1.2, con grammatica migliorata, chiarezza, concisione e criteri aggiuntivi. Dove c'è una lacuna nella numerazione, è stato rimosso un criterio originale. I criteri contrassegnati da un asterisco sono stati aggiunti da noi.
Architettura, design e modellazione delle minacce
| Architettura, design e modellazione delle minacce | Nome del test |
| G1.2 | Ogni modifica di progettazione introdotta è preceduta dalla modellazione delle minacce. |
| G1.3 | La documentazione definisce in modo chiaro e preciso tutti i limiti di fiducia nel contratto (relazioni di fiducia con altri contratti e flussi di dati significativi). |
| G1.4 | Il SCSVS, i requisiti di sicurezza o la politica è disponibile per tutti gli sviluppatori e i tester. |
| G1.5 | Gli eventi per le operazioni (cambiamento di stato/cruciali per il business) sono definiti. |
| G1.6 | Il progetto include un meccanismo in grado di interrompere temporaneamente le funzionalità sensibili in caso di attacco. Questo meccanismo non dovrebbe bloccare l'accesso degli utenti alle loro risorse (ad esempio token). |
| G1.7 | La quantità di criptovalute inutilizzate conservate sul contratto è controllata e al livello minimo accettabile in modo da non diventare un potenziale bersaglio di un attacco. |
| G1.8 | Se la funzione di fallback può essere richiamata da chiunque, è inclusa nel modello di minaccia. |
| G1.9 | La logica aziendale è coerente. Importanti cambiamenti nella logica dovrebbero essere applicati a tutti i contratti. |
| G1.10 | Per rilevare le vulnerabilità vengono utilizzati strumenti di analisi automatica del codice. |
| G1.11 | Viene utilizzata l'ultima major release di Solidity. |
| G1.12 | Quando si utilizza un'implementazione esterna di un contratto, viene utilizzata la versione più recente. |
| G1.13 | Quando le funzioni vengono sovrascritte per estendere la funzionalità, la parola chiave super viene utilizzata per mantenere la funzionalità precedente. |
| G1.14 | L'ordine di eredità è accuratamente specificato. |
| G1.15 | È presente un componente che monitora l'attività del contratto utilizzando gli eventi. |
| G1.16 | Il modello di minaccia include transazioni di balene. |
| G1.17 | La perdita di una chiave privata non compromette la sicurezza dell'intero progetto. |
Politiche e procedure
| Politiche e procedure | Nome del test |
| G2.2 | La sicurezza del sistema è costantemente monitorata (es. il livello previsto di fondi). |
| G2.3 | Esiste una politica per tenere traccia delle nuove vulnerabilità di sicurezza e per aggiornare le librerie all'ultima versione sicura. |
| G2.4 | Il dipartimento di sicurezza può essere contattato pubblicamente e che la procedura per la gestione dei bug segnalati (ad es. bug bounty completa) sia ben definita. |
| G2.5 | Il processo di aggiunta di nuovi componenti al sistema è ben definito. |
| G2.6 | Il processo delle principali modifiche al sistema prevede la modellazione delle minacce da parte di un'azienda esterna. |
| G2.7 | Il processo di aggiunta e aggiornamento dei componenti al sistema include un controllo di sicurezza da parte di un'azienda esterna. |
| G2.8 | In caso di hack, è in atto una procedura di mitigazione chiara e ben nota. |
| G2.9 | La procedura in caso di hack definisce chiaramente quali persone devono eseguire le azioni richieste. |
| G2.10 | La procedura include allarmare altri progetti sull'hacking attraverso canali attendibili. |
| G2.11 | Viene definita una procedura di mitigazione della perdita di chiave privata. |
Aggiornabilità
| Aggiornabilità | Nome del test |
| G3.2 | Prima dell'aggiornamento, viene effettuata un'emulazione in un fork della rete principale e tutto funziona come previsto sulla copia locale. |
| G3.3 | Il processo di aggiornamento viene eseguito da un contratto multisig in cui più di una persona deve approvare l'operazione. |
| G3.4 | I timelock vengono utilizzati per operazioni importanti in modo che gli utenti abbiano il tempo di osservare i cambiamenti imminenti (si prega di notare che la rimozione di potenziali vulnerabilità in questo caso potrebbe essere più difficile). |
| G3.5 | inizializzare() può essere chiamato una sola volta. |
| G3.6 | inizializzare() può essere chiamato solo da un ruolo autorizzato tramite opportuni modificatori (es inizializzatore, onlyOwner). |
| G3.7 | Il processo di aggiornamento viene eseguito in un'unica transazione in modo che nessuno possa eseguirlo in anticipo. |
| G3.8 | I contratti aggiornabili hanno spazi riservati sugli slot per impedire la sovrascrittura. |
| G3.9 | Il numero di slot riservati (come intervallo) è stato ridotto in modo appropriato se sono state aggiunte nuove variabili. |
| G3.10 | Non ci sono cambiamenti nell'ordine in cui vengono dichiarate le variabili di stato del contratto, né i loro tipi. |
| G3.11 | I nuovi valori restituiti dalle funzioni sono gli stessi delle versioni precedenti del contratto (es proprietario(), saldoDi(indirizzo)). |
| G3.12 | L'implementazione viene inizializzata. |
| G3.13 | L'implementazione non può essere distrutta. |
Logica di business
| Logica di business | Nome del test |
| G4.2 | La logica del contratto e l'implementazione dei parametri del protocollo corrispondono alla documentazione. |
| G4.3 | La business logic procede in un ordine sequenziale e non è possibile saltare i passaggi o eseguirli in un ordine diverso da quello progettato. |
| G4.4 | Il contratto ha correttamente rispettato i limiti di business. |
| G4.5 | La logica di business non si basa sui valori recuperati da contratti non attendibili (soprattutto quando sono presenti più chiamate allo stesso contratto in un singolo flusso). |
| G4.6 | La logica aziendale non si basa sull'equilibrio del contratto (ad esempio, saldo == 0). |
| G4.7 | Le operazioni sensibili non dipendono dai dati del blocco (ad es. blocco hash, timestamp). |
| G4.8 | Il contratto utilizza meccanismi che mitigano gli attacchi di ordine delle transazioni (front-running) (ad esempio schemi di pre-commit). |
| G4.9 | Il contratto non invia fondi automaticamente, ma consente agli utenti di prelevare fondi in transazioni separate. |
Access Control
| Access Control | Nome del test |
| G5.2 | Il principio del minimo privilegio è rispettato. Altri contratti dovrebbero poter accedere solo a funzioni e dati per i quali sono in possesso di specifica autorizzazione. |
| G5.3 | I nuovi contratti con accesso al contratto verificato aderiscono automaticamente al principio dei diritti minimi. I contratti devono disporre di autorizzazioni minime o nulle fino a quando l'accesso alle nuove funzionalità non viene concesso in modo esplicito. |
| G5.4 | Il creatore del contratto rispetta il principio del minimo privilegio ei suoi diritti seguono rigorosamente quelli delineati nella documentazione. |
| G5.5 | Il contratto applica le regole di controllo degli accessi specificate in un contratto attendibile, in particolare se il controllo degli accessi lato client dApp è presente e potrebbe essere aggirato. |
| G5.6 | Le chiamate a contratti esterni sono consentite solo se necessario. |
| G5.7 | Il codice modificatore è chiaro e semplice. La logica non deve contenere chiamate esterne a contratti non attendibili. |
| G5.8 | Tutti gli attributi degli utenti e dei dati utilizzati dai controlli di accesso sono conservati in contratti attendibili e non possono essere manipolati da altri contratti se non specificamente autorizzati. |
| G5.9 | I controlli di accesso falliscono in modo sicuro, anche quando si verifica un ripristino. |
| G5.10 | Se l'input (parametri della funzione) viene convalidato, ove possibile viene utilizzato l'approccio di convalida positiva (whitelisting). |
Comunicazione
| Comunicazione | Nome del test |
| G6.2 | Vengono identificate le librerie che non fanno parte dell'applicazione (ma su cui si basa il contratto intelligente per funzionare). |
| G6.3 | La chiamata delegata non viene utilizzata con contratti non attendibili. |
| G6.4 | I contratti di terze parti non nascondono funzioni speciali (ad es. Revert). |
| G6.5 | Il contratto non controlla se l'indirizzo è un contratto che utilizza il codice operativo extcodesize. |
| G6.6 | Gli attacchi di rientro vengono mitigati bloccando le chiamate ricorsive da altri contratti e seguendo il modello Check-Effects-Interactions. Non utilizzare la funzione di invio a meno che non sia indispensabile. |
| G6.7 | Il risultato di chiamate di funzioni di basso livello (ad es invia, delegachiama, chiama) da altri contratti è controllato. |
| G6.8 | Il contratto si basa sui dati forniti dal mittente corretto e non si basa sul valore tx.origin. |
Aritmetica
| Aritmetica | Nome del test |
| G7.2 | I valori e le operazioni matematiche sono resistenti agli overflow di numeri interi. Utilizza la libreria SafeMath per le operazioni aritmetiche prima della solidità 0.8.*. |
| G7.3 | I frammenti di codice non controllati da Solidity ≥ 0.8.* non introducono under/overflow di numeri interi. |
| G7.4 | I valori estremi (es. valori massimi e minimi del tipo di variabile) sono considerati e non modificano il flusso logico del contratto |
| G7.5 | La disuguaglianza non rigorosa viene utilizzata per l'uguaglianza di equilibrio. |
| G7.6 | Nei calcoli vengono utilizzati gli ordini di grandezza corretti. |
| G7.7 | Nei calcoli, la moltiplicazione viene eseguita prima della divisione per la precisione. |
| G7.8 | Il contratto non presuppone la precisione a virgola fissa e utilizza un moltiplicatore o memorizza sia il numeratore che il denominatore. |
Denial of Service
| Denial of Service | Nome del test |
| G8.2 | Il contratto non esegue iterazioni su cicli non associati. |
| G8.3 | La funzionalità di autodistruzione viene utilizzata solo se necessario. Se è incluso nel contratto, dovrebbe essere chiaramente descritto nella documentazione. |
| G8.4 | La business logic non è bloccata se un attore (es. contratto, account, oracolo) è assente. |
| G8.5 | La logica aziendale non disincentiva gli utenti a utilizzare i contratti (ad esempio, il costo della transazione è superiore al profitto). |
| G8.6 | Le espressioni di funzioni assert o require hanno una variante passante. |
| G8.7 | Se la funzione di fallback non è richiamabile da nessuno, non sta bloccando le funzionalità del contratto. |
| G8.8 | Non ci sono operazioni costose in un ciclo. |
| G8.9 | Non ci sono chiamate a contratti non attendibili in un ciclo. |
| G8.10 | Se esiste la possibilità di sospendere l'esecuzione del contratto, è anche possibile riprenderlo. |
| G8.11 | Se vengono utilizzate whitelist e blacklist, non interferiscono con il normale funzionamento del sistema. |
| G8.12 | Non ci sono DoS causati da overflow e underflow. |
Dati Blockchain
| Dati Blockchain | Nome del test |
| G9.2 | Qualsiasi dato salvato nei contratti non è considerato sicuro o privato (anche variabili private). |
| G9.3 | Nessun dato riservato viene memorizzato nella blockchain (password, dati personali, token ecc.). |
| G9.4 | I contratti non utilizzano valori letterali stringa come chiavi per i mapping. Le costanti globali vengono utilizzate invece per prevenire l'attacco Homoglyph. |
| G9.5 | Il contratto non genera banalmente numeri pseudocasuali basati sulle informazioni dalla blockchain (ad esempio seeding con il numero del blocco). |
Utilizzo e limitazioni del gas
| Utilizzo e limitazioni del gas | Nome del test |
| G10.1 | L'utilizzo del gas è previsto, definito e ha limiti chiari che non possono essere superati. Sia la struttura del codice che l'input dannoso non dovrebbero causare l'esaurimento del gas. |
| G10.2 | L'esecuzione e la funzionalità della funzione non dipendono dalle tariffe del gas codificate (sono destinate a variare). |
Chiarezza e leggibilità
| Chiarezza e leggibilità | Nome del test |
| G11.2 | La logica è chiara e modularizzata in molteplici semplici contratti e funzioni. |
| G11.3 | Ogni contratto ha un breve commento di 1-2 frasi che ne spiega lo scopo e la funzionalità. |
| G11.4 | Vengono utilizzate implementazioni standard, questo è chiarito nel commento. Se queste implementazioni sono state modificate, le modifiche sono annotate in tutto il contratto. |
| G11.5 | L'ordine di ereditarietà viene preso in considerazione nei contratti che utilizzano più funzioni di ereditarietà e shadow. |
| G11.6 | Ove possibile, i contratti utilizzano codice testato esistente (ad esempio contratti token o meccanismi come possedibile) invece di implementarne uno proprio. |
| G11.7 | Modelli di denominazione coerenti vengono seguiti durante tutto il progetto. |
| G11.8 | Le variabili hanno nomi distintivi. |
| G11.9 | Tutte le variabili di archiviazione vengono inizializzate. |
| G11.10 | Le funzioni con il tipo restituito specificato restituiscono un valore di quel tipo. |
| G11.11 | Vengono utilizzate tutte le funzioni e le variabili. |
| G11.12 | richiedere è usato al posto di ritornare in if dichiarazioni. |
| G11.13 | I affermare La funzione viene utilizzata per verificare la presenza di errori interni e il file richiedere La funzione viene utilizzata per garantire una condizione valida in ingresso da utenti e contratti esterni. |
| G11.14 | Il codice assembly viene utilizzato solo se necessario. |
Copertura del test
| Copertura del test | Nome del test |
| G12.2 | Le narrazioni sugli abusi dettagliate nel modello di minaccia sono coperte da unit test |
| G12.3 | Le funzioni sensibili nei contratti verificati sono coperte con test in fase di sviluppo. |
| G12.4 | L'implementazione dei contratti verificati è stata verificata per le vulnerabilità della sicurezza utilizzando sia l'analisi statica che quella dinamica. |
| G12.5 | Le specifiche del contratto sono state formalmente verificate |
| G12.6 | La specifica ei risultati della verifica formale sono inclusi nella documentazione. |
Finanza decentralizzata
| Finanza decentralizzata | Nome del test |
| G13.1 | Il contratto del prestatore non presuppone che il suo saldo (utilizzato per confermare il rimborso del prestito) venga modificato solo con le proprie funzioni. |
| G13.2 | Le funzioni che modificano il saldo dei prestatori e/o prestano criptovaluta non sono rientranti se lo smart contract consente di prendere in prestito la criptovaluta della piattaforma principale (ad es. Ethereum). Blocca gli attacchi che aggiornano il saldo del mutuatario durante l'esecuzione del prestito flash. |
| G13.3 | Le funzioni di prestito flash possono chiamare solo funzioni predefinite sul contratto ricevente. Se possibile, definire un sottoinsieme attendibile di contratti da richiamare. Di solito, il contratto di invio (prestito) è quello da richiamare. |
| G13.4 | Se include operazioni potenzialmente pericolose (ad es. restituzione di più ETH/token di quelli presi in prestito), la funzione del destinatario che gestisce ETH o token presi in prestito può essere richiamata solo dal pool e all'interno di un processo avviato dal proprietario del contratto ricevente o da un'altra fonte attendibile (ad es. multiseg). |
| G13.5 | I calcoli della quota del pool di liquidità vengono eseguiti con la massima precisione possibile (ad esempio, se il contributo è calcolato per ETH dovrebbe essere fatto con una precisione di 18 cifre – per Wei, non Ether). Il dividendo va moltiplicato per 10 alla potenza del numero di cifre decimali (es. dividendo * 10^18 / divisore). |
| G13.6 | I premi non possono essere calcolati e distribuiti all'interno della stessa chiamata di funzione che deposita i token (dovrebbe essere definita anche come non rientrante). Questo protegge dalle fluttuazioni momentanee delle azioni. |
| G13.7 | I contratti di governance sono protetti dagli attacchi di prestiti flash. Una possibile tecnica di mitigazione è richiedere il processo di deposito dei token di governance e proporre una modifica da eseguire in transazioni diverse incluse in blocchi diversi. |
| G13.8 | Quando si utilizzano oracoli su catena, i contratti sono in grado di sospendere le operazioni in base al risultato degli oracoli (in caso di oracolo compromesso). |
| G13.9 | I contratti esterni (anche fidati) che sono autorizzati a modificare gli attributi di un contratto di progetto (es. prezzo del token) hanno le seguenti limitazioni implementate: soglie per la modifica (es. non più/meno del 5%) e un limite di aggiornamenti (es. un aggiornamento al giorno). |
| G13.10 | Gli attributi del contratto che possono essere aggiornati dai contratti esterni (anche fidati) vengono monitorati (ad es. utilizzando gli eventi) e viene implementata una procedura di risposta agli incidenti (ad es. durante un attacco in corso). |
| G13.11 | Operazioni matematiche complesse che consistono in operazioni sia di moltiplicazione che di divisione eseguono prima le moltiplicazioni e poi le divisioni. |
| G13.12 | Quando si calcolano i prezzi di scambio (ad es. da ETH a token o viceversa), il numeratore e il denominatore vengono moltiplicati per le riserve (vedere il getInputPrice funzione nel ScambioUniswap contrarre). |
Controllo dell'ordine da Sayfer
Risultati dell'audit
URI token indovinabili
| Stato dei servizi | Apri |
| Rischio | critico |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
Avere un vantaggio nella conoscenza dei metadati dell'NFT potrebbe consentire a un utente malintenzionato di sapere quale NFT dovrebbe coniare prima che il pubblico lo riveli. Ciò potrebbe potenzialmente consentire all'attaccante di ottenere il controllo degli NFT più preziosi del progetto.
La seguente vulnerabilità consente a un utente malintenzionato di decidere quale NFT acquistare in base ai metadati prima che il pubblico lo riveli. Questa vulnerabilità è relativamente facile da sfruttare a causa di altre vulnerabilità che abbiamo trovato. Nel tempo tra il shuffle bandiera che diventa vera requestRandomWords() e gli NFT in cui vengono rivelati revealNFT(), un utente malintenzionato può indovinare gli URI del token.
Mentre l' revealed flag è ancora falso il tokenURI() problemi hideUri, il che significa che l'utente medio vedrà solo l'URI fittizio/nascosto senza i metadati completi.
Per costruire completamente la stringa URI del token, viene eseguita un'altra transazione per eseguire il file requestRandomWords() metodo che imposta il s_randomWords via fulfillRandomWords(). Questo viene fatto tramite VRF di Chianlink.
Solo allora viene eseguito il seguente codice e restituisce la stringa URI del token completa:
La vulnerabilità è quella baseURI, maxSupply ed s_randomWords sono pubblici e un utente malintenzionato può prevedere l'URI del token senza la necessità del revealed variabile. Nella V1 del progetto abbiamo visto che la prima transazione che viene eseguita requestRandomWords():
E poi la seconda transazione che rivela l'NFT eseguendo il revealNFT():
Possiamo vedere che durante 3 ore, un utente malintenzionato avrebbe potuto visualizzare qualsiasi metadata NFT prima che fosse rivelato e fare previsioni intelligenti su lanci aerei o transazioni di conio specifiche per NFT rari.
Mitigazione
Rivelare un NFT non ha una taglia unica. Dipende fortemente dalla strategia e dall'esperienza utente che l'utente finale dovrebbe avere.
Per una maggiore sicurezza, incoraggiamo a rivelare, impostare l'URI di base e modificare lo stato di s_randomWords variabile di stato con la più breve differenza di tempo tra loro. Pur non mitigando completamente la vulnerabilità, ridurre il tempo che intercorre tra queste azioni può ridurre il rischio che malintenzionati la sfruttino.
Un modo migliore è eseguire tutti i cambiamenti di stato nella stessa transazione mentre si rivela, questo molte volte non è tecnicamente possibile.
Per un approfondimento su come implementare un airdrop NFT casuale e modi più sicuri, ti consigliamo di leggere Strategie di randomizzazione per cadute NFT.
Gli indirizzi nella lista bianca possono essere contratti
| Stato dei servizi | Apri |
| Rischio | Alta |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
Quando si conia un NFT, il contratto di conio potrebbe bloccare o consentire il conio agli indirizzi del contratto. Consentire al conio di contrarsi o avere una vulnerabilità che consente il conio di contratti potrebbe portare a una situazione in cui l'attaccante può annullare la transazione se ha una conoscenza preliminare su quale NFT dovrebbe coniare.
Il modificatore isAUser() è usato solo per publicMint().
Nel mintStep1() ed mintStep2() metodi il isWhitelisted() viene utilizzato il modificatore.
Ciò significa che il codice non verifica la presenza di indirizzi non contrattuali negli hash di prova Merkle della whitelist.
Sebbene non possiamo sapere quali sono stati i processi alla base della generazione della whitelist e quanto sia protetta, il codice stesso è vulnerabile a questo attacco. Il controllo degli indirizzi non contrattuali off-chain o non nella stessa transazione è sconsigliato in quanto è vulnerabile a più vettori di attacco.
Un utente malintenzionato potrebbe ottenere un NFT e annullare la transazione se l'NFT non è abbastanza raro. In combinazione con l'URI del token indovinabile, un utente malintenzionato può facilmente ottenere una conoscenza preliminare dei metadati dell'NFT e annullare le transazioni in base alla rarità.
Mitigazione
Aggiungere il isAUser modificatore di mintStep1() ed mintStep2() metodi.
Implementazione casuale debole e non sicura del VRF di Chainlink
| Stato dei servizi | Apri |
| Rischio | Alta |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
Gli errori di casualità insicura si verificano quando una funzione che può produrre valori prevedibili viene utilizzata come fonte di casualità in un contesto sensibile alla sicurezza.
I contratti intelligenti devono fare affidamento su soluzioni off-chain per generare numeri casuali garantiti. Fatcats utilizza il sistema VRF di Chainlink per generare un numero casuale che in seguito verrà utilizzato come ID casuale per l'URI del token utilizzando il fulfillRandomWords Metodo:
Il metodo salva il numero casuale in una variabile di stato chiamata s_randomWords che dal nome implica che è una parola casuale. In pratica il numero è modulo con maxSupply(5000), quindi è un numero casuale pseudo debole compreso tra 1 e 5000. Questo può portare gli sviluppatori a pensare di poter fare affidamento su questo numero per una casualità protetta, cosa che non è.
Mitigazione
Assegna il valore restituito proveniente da VRF alla variabile di stato globale.
Centralizzazione del Contratto e del Team Wallet
| Stato dei servizi | Apri |
| Rischio | Alta |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
I progetti che si basano su una chiave sono vulnerabili a perdite di chiavi, attacchi di phishing, manipolazioni di attori interni, morte del proprietario e altro ancora.
Quando il progetto dipende solo da una chiave. Questi tipi di attacchi sono i più comuni tra i più grandi hack.
Il progetto verifica il isOwner in più luoghi. La perdita delle chiavi di questo indirizzo di distribuzione comprometterà l'intero progetto.
Inoltre, il team wallet che otterrà l'eth utilizzando il withdraw anche la funzione è soggetta allo stesso vettore di attacco
Se i portafogli di cui sopra utilizzano multisig, questo risultato verrà risolto.
Mitigazione
A seconda del caso d'uso, del livello di sicurezza e dell'esperienza utente che il progetto desidera applicare, esistono diversi modi per mitigare questo attacco, ad esempio utilizzando multisig wallet, smart wallet o applicando più proprietari al progetto.
La funzione openPublicBurn commuta anziché aprire
| Stato dei servizi | Apri |
| Rischio | Basso |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
Il metodo openPublicBurn non solo apre la masterizzazione pubblica, ma la accende e spegne a seconda dello stato corrente della variabile.
Ciò potrebbe indurre uno sviluppatore o un operatore del progetto a pensare di aprire la fase di masterizzazione pubblica ma in realtà disattivarla causando una cattiva reputazione al progetto.
Mitigazione
Imposta la variabile di stato publicBurnFlag su true o modificare il nome del metodo in
switchPublicBurn.
Il meccanismo a gradini è difficile da mantenere
| Stato dei servizi | Apri |
| Rischio | Info |
| Dove | FatCats.sol |
| Strumenti | Test manuale |
Descrizione
Il codice utilizza variabili booleane per ogni passaggio, ciò significa che ogni volta che lo sviluppatore aggiunge un altro passaggio deve aggiungere la logica per attivare o disattivare il ripristino dei flag. Ciò potrebbe creare confusione e potenziali bug di sicurezza.
Un approccio migliore sarebbe utilizzare enum come passaggio corrente se questo offre i vantaggi di un nome di passaggio chiaro come EARLY_ADAPTERS, PUBLINK_MINT, Etc.
Se questo è troppo prolisso o confuso, potrebbe essere implementato tramite un semplice numero intero, questo ha il vantaggio matematico di if step > 2 or require(newStep < oldStep, “can not go back”.
Mitigazione
Utilizzare l'enumerazione incorporata di solidità o la semplice sintassi intera.