Rapporto di audit del contratto intelligente per Dimo

Sommario di gestione

Dimo ha contattato Sayfer per eseguire un controllo di sicurezza sul loro contratto intelligente.

Questo rapporto documenta la ricerca condotta da Sayfer mirata alle risorse selezionate definite nell'ambito della ricerca. In particolare, questo rapporto mostra la revisione della posizione di sicurezza per il contratto intelligente di Dimo.

Durante il periodo di ricerca di 40 ore di ricerca, abbiamo scoperto 14 vulnerabilità nel contratto. Nessuno di loro è critico.

In conclusione, a seguito del rapporto dovrebbero essere implementate diverse soluzioni, ma il livello di sicurezza del sistema è adeguato.

Dopo una revisione da parte del team Sayfer, certifichiamo che tutti i problemi di sicurezza menzionati in questo rapporto sono stati risolti dal team Dimo.

Metodologia del rischio

Noi di Sayfer ci impegniamo a fornire ai nostri clienti audit di contratti intelligenti della massima qualità. Ecco perché abbiamo implementato un modello completo di valutazione del rischio per valutare la gravità dei nostri risultati e fornire ai nostri clienti le migliori raccomandazioni possibili per la mitigazione.

Il nostro modello di valutazione del rischio si basa su due fattori chiave: IMPATTO ed PROBABILITÀ. L'impatto si riferisce al danno potenziale che potrebbe derivare da un problema, come una perdita finanziaria, un danno alla reputazione o un sistema non operativo. La probabilità si riferisce alla probabilità che si verifichi un problema, tenendo conto di fattori quali la complessità del contratto e il numero di potenziali aggressori.

Combinando questi due fattori, possiamo creare una comprensione completa del rischio posto da un particolare problema e fornire ai nostri clienti una valutazione chiara e attuabile della gravità del problema. Questo approccio ci consente di dare priorità alle nostre raccomandazioni e garantire che i nostri clienti ricevano la migliore consulenza possibile su come proteggere i loro contratti intelligenti.

Il rischio è definito come segue:

Panoramica del protocollo

Introduzione al protocollo

DIMO è una società IoT web3 che consente agli utenti e agli sviluppatori di attingere al ricco flusso di dati generato dai veicoli moderni. La sua soluzione è un ecosistema di proprietà degli utenti che consente ai conducenti di trarre vantaggi economici dai propri dati e rendere possibili applicazioni come assicurazioni parametriche, car sharing peer-to-peer e mercati di veicoli. La piattaforma decentralizzata offre inoltre agli sviluppatori la massima tranquillità, sapendo che il loro accesso ai dati non è soggetto ai capricci di un gatekeeper centralizzato. Questa soluzione è basata su Polygon.

Risultati dell'audit

[H] La modifica dell'orario di Genesi può potenzialmente interrompere la distribuzione delle ricompense

ID	DIRE-01
Stato dei servizi	Fissa
Rischio	Alta
Affari Impact	rewardsGenesisTime è una variabile critica che traccia il momento in cui sono state avviate le ricompense e quindi governa la distribuzione delle ricompense. Il tasso di ricompensa continua a diminuire nel tempo, riducendosi lentamente all'85% del ciclo precedente in un momento futuro. Pertanto, reimpostare il tempo di genesi dopo l'inizio della distribuzione della ricompensa potrebbe interrompere l'intero schema.
Dove	– Premio.sol; resetRewardsGenesisTime() – Premio.sol; manualmenteImpostaRicompenseGenesisTime(uint256)

Descrizione

Cambiare rewardsGenesisTime più avanti nel ciclo avrà un impatto sulle variabili cruciali currentWeek e weekLimit e potrebbe potenzialmente rovinare l'intero schema di distribuzione delle ricompense e il suo programma previsto.

Mitigazione

Una possibile mitigazione è quella di rivedere queste funzioni in modo tale che il ripristino del tempo di genesi sia possibile solo prima dell'inizio della distribuzione della ricompensa:

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

Se è necessario reimpostare o modificare la variabile dopo il fatto, forse può essere gestito in modo controllato e prevedibile sulla catena, anziché consentire agli amministratori un controllo arbitrario.

 

[H] Ritiro dell'amministratore non controllato

ID	DIRE-02
Stato dei servizi	Fissa
Rischio	Alta
Impatto sul business	Sebbene agli account amministratore per definizione venga data una certa fiducia, se vengono compromessi, possono essere utilizzati per prosciugare il contratto dei suoi fondi utilizzando questa funzione.
Dove	– Premio.sol; adminPrelievo(indirizzo, uint256)

Descrizione

La funzione adminWithdraw(address, uint256) consente agli amministratori di inviare fondi contrattuali agli utenti senza limitazioni. Secondo la documentazione, questo viene utilizzato se gli utenti inviano DIMO al contratto senza staking. Tuttavia, riteniamo che questa funzione possa essere soggetta ad abusi, come spiegato nella sezione sull'impatto aziendale.

Mitigazione

Un modo possibile per aumentare la sicurezza è inviare una richiesta per conto di un utente, magari utilizzando un account con il ruolo Oracle. Un amministratore deve quindi approvare la transazione. Ciò richiede almeno due account per approvare tali transazioni, fornendo un ulteriore livello di sicurezza.

 

[H] Gli amministratori possono reimpostare il registro a piacimento

ID	DIRE-03
Stato dei servizi	Riconosciuto
Rischio	Alta
Impatto sul business	Il registro è il luogo in cui vengono archiviati i dati dell'utente e vengono eseguite le convalide. Se il registro viene reimpostato, gli utenti esistenti non riceveranno più i premi a meno che i dati non vengano migrati nel nuovo registro.
Dove	– Premio.sol; setRegistryContractAddress(indirizzo)

Descrizione

setRegistryContractAddress(address) consente agli amministratori di reimpostare l'indirizzo del registro a piacimento.

Mitigazione

Una soluzione è assicurarsi che questa funzione venga ripristinata a meno che il registro non sia impostato in primo luogo.

  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);
  }

Un'altra soluzione è impostare una procedura di migrazione dei dati. Se tale procedura è già in atto, allora questo risultato può essere tranquillamente ignorato.

 

[I] Il Deployer ha sia il ruolo di amministratore che quello di Oracle

ID	DIRE-04
Stato dei servizi	Riconosciuto
Rischio	Informativo
Impatto sul business	Abbiamo deciso di considerare questo risultato come informativo perché è principalmente un corollario delle principali preoccupazioni di centralizzazione sopra descritte. Con il modo attuale in cui è costruito il sistema, è necessario che qualcuno assegni e gestisca i ruoli Oracle e Admin. Tuttavia, non è necessario che l'account ricopra questi ruoli.
Dove	– Ricompensa.sol:108-111; inizializza(indirizzo, indirizzo, indirizzo)

Descrizione

Durante l'inizializzazione, il distributore riceve i ruoli di amministratore, amministratore predefinito e Oracle:

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

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

Mitigazione

Considera l'idea di assegnare solo il ruolo di amministratore predefinito, ereditato dagli OA AccessControlUpgradeable, al distributore, consentendogli di gestire i ruoli per altri utenti.

 

[M] Utilizza AccessControlDefaultAdminRulesUpgradeable

ID	DIRE-05
Stato dei servizi	Riconosciuto
Rischio	Medio
Impatto sul business	Considerata la centralizzazione intrinseca del contratto e l’importanza dei ruoli amministrativi (e quindi della loro gestione), abbiamo deciso di valutare questo risultato come a rischio medio.
Dove	-

Descrizione

Reward.sol attualmente utilizza AccessControlUpgradable per concedere e gestire l'accesso alle funzioni critiche. Nello schema di controllo degli accessi di OZ, l'account che possiede DEFAULT_ADMIN_ROLE è in grado di concedere e revocare tutti gli altri ruoli. Allo stato attuale del contratto viene consegnato al distributore al momento dell'inizializzazione.

AccessControlDefaultAdminRulesUpgradeable si estende AccessControlUpgradable con due caratteristiche di sicurezza cruciali:

• Può contenere un solo account DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE possono essere trasferiti solo utilizzando un processo in due fasi. Un ritardo configurabile tra i due passaggi, changeDefaultAdminDelay, viene applicato.

Mitigazione

Passa da AccessControlUpgradable a AccessControlDefaultAdminRulesUpgradeable.

 

[L] Convalida input insufficiente in manualmenteSetRewardsGenesisTime(uint256)

ID	DIRE-06
Stato dei servizi	Fissa
Rischio	Basso
Impatto sul business	Riteniamo che questo problema sia basso, poiché un valore errato potrebbe essere corretto dall'amministratore con la stessa facilità con cui è stato fornito.
Dove	– Premio.sol; manualmenteImpostaRicompenseGenesisTime(uint256)

Descrizione

Oltre a comportare un rischio di centralizzazione, come spiegato sopra, manuallySetRewardsGenesisTime(uint256) inoltre non riesce a convalidare il timestamp fornito dall'amministratore. Accetterebbe felicemente un tempo futuro, che porta a _getNumberOfWeeksSinceGenesis() per ripristinare:

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

Mitigazione

Assicurati che l'input sia uguale o inferiore al timestamp corrente.

 

[L] Convalida input insufficiente in setMinimumTimeForRewards(uint256)

ID	DIRE-07
Stato dei servizi	Fissa
Rischio	Basso
Impatto sul business	Proprio come il risultato precedente, abbiamo deciso di classificare questo risultato come a basso rischio perché può essere facilmente corretto richiamando nuovamente la funzione.
Dove	– Premio.sol; setMinimumTimeForRewards(uint256)

Descrizione

Questo risultato è molto simile nella sostanza a quello direttamente sopra. Un valore troppo alto impedirà agli utenti di richiedere i propri premi. Ciò, insieme al fatto che i premi vengono ridotti su base settimanale _limitForWeek(uint256), neutralizzerà il vantaggio conferito dall'adozione anticipata.

Mitigazione

Definire un intervallo accettabile di valori per minimumTimeForRewards e applicarlo tramite la funzione. A causa dell'influenza diretta che questo valore ha sull'intera struttura dei premi della piattaforma, gestirlo attentamente è fondamentale.

 

[L] Errore non utilizzato

ID	DIRE-08
Stato dei servizi	Fissa
Rischio	Basso
Impatto sul business	Abbiamo deciso di considerare questo problema come basso piuttosto che informativo, questa omissione apparentemente accidentale ha un certo impatto sulla logica del contratto.
Dove	– Ricompensa.sol:12

Descrizione

L'errore InvalidArrayLegnth() è dichiarato alla riga 12, ma mai utilizzato.

Mitigazione

Ipotizziamo che questo errore dovesse essere inserito batchTransfer(TransferInfo[]) se l'array fornito non ha otto membri:

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

 

[L] Valore restituito non selezionato

ID	DIRE-09
Stato dei servizi	Fissa
Rischio	Basso
Impatto sul business	La funzione di trasferimento dei token ERC20 restituisce il successo o il fallimento del trasferimento come valore booleano. È considerata buona pratica verificare questo valore e procedere solo se l'operazione ha esito positivo. Tuttavia, poiché la documentazione lo implica batchTransfer(TransferInfo[]) viene utilizzato solo per trasferire token Dimo, consideriamo questo risultato basso.
Dove	– Ricompensa.sol:232; batchTrasferimento(InformazioniTrasferimento[])

Descrizione

Sulla riga indicata viene effettuato un trasferimento dimoToken, ma il valore restituito viene lasciato deselezionato.

Mitigazione

Ripristina con un errore se il trasferimento fallisce:

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

 

[L] Chiamata API deprecata

ID	DIRE-10
Stato dei servizi	Riconosciuto
Rischio	Basso
Impatto sul business	a differenza di grantRole(bytes32, address), _setupRole(bytes32, address) non effettua alcun controllo sul conto chiamante. È stato quindi deprecato.
Dove	– Ricompensa.sol:108-111; inizializza(indirizzo, indirizzo, indirizzo)

Descrizione

La funzione _setupRole(bytes32, address), utilizzato nella posizione specificata, è stato deprecato in OpenZepplin 5.0. Chiamando grantRole(bytes32, address) invece ora è consigliato.

Mitigazione

Sostituisci le chiamate a _setupRole(bytes32, address) con grantRole(bytes32, address).

 

[I] Emissione di eventi insufficiente

ID	DIRE-11
Stato dei servizi	Fissa
Rischio	Informativo
Impatto sul business	Molti strumenti di monitoraggio, frontend, strumenti fuori catena e servizi di reporting si affidano agli eventi per acquisire le attività dei contratti in tempo reale. Inoltre, i protocolli possono reagire rapidamente alle emissioni di eventi sospetti.
Dove	– Premio.sol; setRegistryContractAddress(indirizzo) – Premio.sol; setMinimumTimeForRewards(uint256) – Premio.sol; setSyntheticProxyAddress(indirizzo) – Premio.sol; resetRewardsGenesisTime() – Premio.sol; manualmenteSetRewardsGenesisTime() – Ricompensa.sol:267-268; batchTrasferimento(InformazioniTrasferimento[])

Descrizione

Le funzioni sopra menzionate non emettono eventi per importanti aggiornamenti di stato.

Mitigazione

Aggiungi emissioni di eventi.

 

[I] Versionamento della solidità

ID	DIRE-12
Stato dei servizi	Riconosciuto
Rischio	Informativo
Impatto sul business	Il contratto può essere compilato e testato con diverse versioni del compilatore durante lo sviluppo e la revisione e un'altra versione diversa del compilatore durante la distribuzione sulla mainnet. Ciò può portare a risultati inaspettati.
Dove	Ricompensa.sol:2

Descrizione

Il contratto specifica il suo pragma come pragma solidity ^0.8.13;. Ciò consente l'utilizzo di qualsiasi versione di Solidity a partire dalla 0.8.13. Inoltre, la 0.8.13 non è la versione più recente.

Mitigazione

Decidere un'unica versione di solidità da utilizzare. L'ultima versione stabile (e quindi consigliata) è la 0.8.19.

 

[I] Indicizzare il parametro della settimana in TokensTransferredForConnectionStreak()

ID	DIRE-13
Stato dei servizi	Fissa
Rischio	Informativo
Impatto sul business	L'indicizzazione è utile per filtrare gli eventi nei log di Ethereum. Ogni parametro indicizzato in un evento aggiunge un argomento al registro eventi, semplificando la ricerca di eventi specifici utilizzando tali parametri.
Dove	– Ricompensa.sol:81

Descrizione

Il parametro week rappresenta la settimana corrente in cui è stato distribuito l'airdrop. Poiché l'indicizzazione semplifica il filtraggio di eventi specifici da parte delle applicazioni frontend, l'indicizzazione di questo parametro consentirà di filtrare facilmente gli utenti che hanno ricevuto airdrop in una determinata settimana.

Mitigazione

Considerare l'indicizzazione del parametro specificato.

 

[I] Adesione alla Solidity Style Guide

ID	DIRE-14
Stato dei servizi	Fissa
Rischio	Informativo
Impatto sul business	Questo problema è puramente informativo. Non vi è alcun impatto sulla posizione di sicurezza del contratto o altro.
Dove	– Ricompensa.sol:36

Descrizione

TransferInfo[], una struttura, è definita alla riga 36, ​​direttamente dopo le variabili di stato. La guida allo stile Solidity consiglia di posizionare prima le dichiarazioni struct.

Mitigazione

Sposta la dichiarazione della struttura direttamente all'inizio del contratto, prima delle variabili di stato.