Informe de auditoría de contratos inteligentes para Dimo

Resumen de gestión

Dimo se puso en contacto con Sayfer para realizar una auditoría de seguridad de su contrato inteligente.

Este informe documenta la investigación realizada por Sayfer dirigida a los recursos seleccionados definidos bajo el alcance de la investigación. En particular, este informe muestra la revisión de la postura de seguridad del contrato inteligente de Dimo.

Durante el período de investigación de 40 horas de investigación, descubrimos 14 vulnerabilidades en el contrato. Ninguno de ellos es crítico.

En conclusión, se deben implementar varias correcciones después del informe, pero la postura de seguridad del sistema es competente.

Después de una revisión por parte del equipo de Sayfer, certificamos que todos los problemas de seguridad mencionados en este informe han sido abordados por el equipo de Dimo.

Metodología de Riesgo

En Sayfer, estamos comprometidos a ofrecer auditorías de contratos inteligentes de la más alta calidad a nuestros clientes. Es por eso que hemos implementado un modelo integral de evaluación de riesgos para evaluar la gravedad de nuestros hallazgos y brindar a nuestros clientes las mejores recomendaciones posibles para la mitigación.

Nuestro modelo de evaluación de riesgos se basa en dos factores clave: IMPACTO y PROBABILIDAD. El impacto se refiere al daño potencial que podría resultar de un problema, como pérdidas financieras, daños a la reputación o un sistema no operativo. La probabilidad se refiere a la probabilidad de que ocurra un problema, teniendo en cuenta factores como la complejidad del contrato y la cantidad de atacantes potenciales.

Al combinar estos dos factores, podemos crear una comprensión integral del riesgo que plantea un problema en particular y brindar a nuestros clientes una evaluación clara y procesable de la gravedad del problema. Este enfoque nos permite priorizar nuestras recomendaciones y garantizar que nuestros clientes reciban el mejor asesoramiento posible sobre cómo proteger sus contratos inteligentes.

El riesgo se define de la siguiente manera:

Descripción general del protocolo

Introducción al protocolo

DIMO es una empresa de IoT web3 que permite a los usuarios y desarrolladores aprovechar el rico flujo de datos generados por los vehículos modernos. Su solución es un ecosistema propiedad del usuario que permite a los conductores obtener beneficios económicos de sus datos y hacer posibles aplicaciones como seguros paramétricos, uso compartido de automóviles entre pares y mercados de vehículos. La plataforma descentralizada también brinda tranquilidad a los desarrolladores, sabiendo que su acceso a los datos no está sujeto a los caprichos de un guardián centralizado. Esta solución se basa en Polygon.

Resultados de la auditoría

[H] Cambiar el tiempo de Génesis puede potencialmente alterar la distribución de recompensas

ID	DECIR-01
Estado	fijo
Riesgo	Alta
Empresa Impacto	rewardsGenesisTime es una variable crítica que rastrea el momento en que se iniciaron las recompensas y, por lo tanto, gobierna la distribución de las recompensas. La tasa de recompensas continúa disminuyendo con el tiempo, reduciéndose lentamente al 85% del ciclo anterior en algún momento en el futuro. Por lo tanto, restablecer el tiempo de génesis después de comenzar la distribución de recompensas puede alterar todo el esquema.
Destino	– Recompensa.sol; restablecerRecompensasGenesisTime() – Recompensa.sol; Establecer manualmenteRewardsGenesisTime(uint256)

Descripción

Cambiar rewardsGenesisTime Más adelante en el ciclo, esto afectará las variables cruciales currentWeek y WeekLimit y podría arruinar todo el esquema de distribución de recompensas y su cronograma proyectado.

Mitigación

Una posible mitigación es revisar estas funciones de modo que restablecer el tiempo de génesis solo sea posible antes de que haya comenzado la distribución de recompensas:

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

Si es necesario restablecer o cambiar la variable después del hecho, tal vez pueda manejarse de manera controlada y predecible en la cadena, en lugar de permitir a los administradores un control arbitrario.

 

[H] Retiro de administrador sin marcar

ID	DECIR-02
Estado	fijo
Riesgo	Alta
Impacto en el negocio	Si bien las cuentas de administrador, por definición, reciben cierta confianza, si se ven comprometidas, pueden usarse para drenar el contrato de sus fondos usando esta función.
Destino	– Recompensa.sol; administradorRetirar(dirección, uint256)

Descripción

La función adminWithdraw(address, uint256) permite a los administradores enviar fondos del contrato a los usuarios sin limitación. Según la documentación, esto se utiliza si los usuarios envían DIMO al contrato sin apostar. Sin embargo, creemos que es posible que se abuse de esta función, como se explica en la sección de impacto empresarial.

Mitigación

Una forma concebible de aumentar la seguridad es enviar una solicitud en nombre de un usuario, quizás utilizando una cuenta con el rol de Oracle. Luego, un administrador debe aprobar la transacción. Esto requiere al menos dos cuentas para aprobar dichas transacciones, lo que proporciona otra capa de seguridad.

 

[H] Los administradores pueden restablecer el registro a voluntad

ID	DECIR-03
Estado	Admitido
Riesgo	Alta
Impacto en el negocio	El registro es donde se almacenan los datos del usuario y se realizan las validaciones. Si se restablece el registro, los usuarios existentes dejarán de recibir recompensas a menos que los datos se migren al nuevo registro.
Destino	– Recompensa.sol; setRegistryContractAddress(dirección)

Descripción

setRegistryContractAddress(address) permite a los administradores restablecer la dirección de registro a voluntad.

Mitigación

Una solución es asegurarse de que esta función se revierta a menos que el registro no esté configurado en primer lugar.

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

Otra solución es configurar un procedimiento de migración de datos. Si ya existe un procedimiento de este tipo, entonces este hallazgo puede ignorarse con seguridad.

 

[I] El implementador tiene funciones de administrador y de Oracle

ID	DECIR-04
Estado	Admitido
Riesgo	Informativo
Impacto en el negocio	Decidimos calificar este hallazgo como informativo porque es principalmente un corolario de las principales preocupaciones sobre la centralización detalladas anteriormente. Con la forma actual en que está construido el sistema, es necesario que alguien asigne y administre los roles de Oracle y Administrador. Sin embargo, no es necesario que esa cuenta desempeñe estas funciones.
Destino	– Recompensa.sol:108-111; inicializar(dirección, dirección, dirección)

Descripción

Durante la inicialización, el implementador recibe los roles de administrador, administrador predeterminado y Oracle:

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

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

Mitigación

Considere otorgar solo la función de administrador predeterminada, heredada de OA. AccessControlUpgradeable, al implementador, lo que le permite administrar roles para otros usuarios.

 

[M] Usar AccessControlDefaultAdminRulesUpgradeable

ID	DECIR-05
Estado	Admitido
Riesgo	Medio
Impacto en el negocio	Dada la centralización inherente del contrato y la importancia de las funciones administrativas (y por lo tanto su gestión), decidimos calificar este hallazgo como de riesgo medio.
Destino	–

Descripción

Reward.sol Actualmente utiliza AccessControlUpgradable para otorgar y administrar el acceso a funciones críticas. En el esquema de control de acceso de OZ, la cuenta que posee DEFAULT_ADMIN_ROLE es capaz de otorgar y retirar todos los demás roles. En el estado actual del contrato, se entrega al implementador tras la inicialización.

AccessControlDefaultAdminRulesUpgradeable Se extiende AccessControlUpgradable con dos características de seguridad cruciales:

• Sólo una cuenta puede contener DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE sólo se puede transferir mediante un proceso de dos pasos. Un retraso configurable entre los dos pasos, changeDefaultAdminDelay, se aplica.

Mitigación

Cambia desde AccessControlUpgradable a AccessControlDefaultAdminRulesUpgradeable.

 

[L] Validación de entrada insuficiente en manualmenteSetRewardsGenesisTime(uint256)

ID	DECIR-06
Estado	fijo
Riesgo	Baja
Impacto en el negocio	Calificamos este problema como bajo, ya que el administrador podría rectificar un valor erróneo con la misma facilidad con la que se proporcionó.
Destino	– Recompensa.sol; Establecer manualmenteRewardsGenesisTime(uint256)

Descripción

Además de plantear un riesgo de centralización, como se detalló anteriormente, manuallySetRewardsGenesisTime(uint256) tampoco valida la marca de tiempo proporcionada por el administrador. Aceptaría felizmente un tiempo futuro, que llevaría a _getNumberOfWeeksSinceGenesis() revertir:

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

Mitigación

Asegúrese de que la entrada sea igual o menor que la marca de tiempo actual.

 

[L] Validación de entrada insuficiente en setMinimumTimeForRewards(uint256)

ID	DECIR-07
Estado	fijo
Riesgo	Baja
Impacto en el negocio	Al igual que el hallazgo anterior, decidimos calificar este hallazgo como de bajo riesgo porque se puede rectificar fácilmente llamando a la función nuevamente.
Destino	– Recompensa.sol; setMinimumTimeForRewards(uint256)

Descripción

Este hallazgo es muy similar en esencia al que está directamente encima. Un valor demasiado alto hará que los usuarios no puedan reclamar sus recompensas. Esto, junto con el hecho de que las recompensas disminuyen semanalmente por _limitForWeek(uint256), neutralizará la ventaja conferida por la adopción temprana.

Mitigación

Definir un rango aceptable de valores para minimumTimeForRewards y aplicarlo a través de la función. Debido a la influencia directa que este valor tiene en toda la estructura de recompensas de la plataforma, es fundamental gestionarlo con cuidado.

 

[L] Error no utilizado

ID	DECIR-08
Estado	fijo
Riesgo	Baja
Impacto en el negocio	Decidimos calificar este problema como bajo en lugar de informativo; esta omisión aparentemente accidental tiene cierto impacto en la lógica del contrato.
Destino	– Recompensa.sol:12

Descripción

El error InvalidArrayLegnth() se declara en la línea 12, pero nunca se utiliza.

Mitigación

Nuestra hipótesis es que se suponía que este error se debía incluir en batchTransfer(TransferInfo[]) si la matriz proporcionada no tiene ocho miembros:

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

 

[L] Valor de retorno no marcado

ID	DECIR-09
Estado	fijo
Riesgo	Baja
Impacto en el negocio	La función de transferencia de tokens ERC20 devuelve el éxito o el fracaso de la transferencia como un valor booleano. Se considera una buena práctica comprobar este valor y sólo proceder si tiene éxito. Sin embargo, debido a que la documentación implica que batchTransfer(TransferInfo[]) solo se utiliza para transferir tokens Dimo, calificamos este hallazgo como bajo.
Destino	– Recompensa.sol:232; transferencia por lotes(TransferInfo[])

Descripción

En la línea indicada, se realiza una transferencia de dimoToken, pero el valor de retorno no está marcado.

Mitigación

Revertir con un error si la transferencia falla:

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

 

[L] Llamada API obsoleta

ID	DECIR-10
Estado	Admitido
Riesgo	Baja
Impacto en el negocio	Diferente a la grantRole(bytes32, address), _setupRole(bytes32, address) no realiza ninguna verificación en la cuenta de llamadas. Por lo tanto, ha quedado obsoleto.
Destino	– Recompensa.sol:108-111; inicializar(dirección, dirección, dirección)

Descripción

La función _setupRole(bytes32, address), utilizado en la ubicación especificada, ha quedado obsoleto en OpenZepplin 5.0. Vocación grantRole(bytes32, address) en su lugar ahora se recomienda.

Mitigación

Reemplazar llamadas a _setupRole(bytes32, address) grantRole(bytes32, address).

 

[I] Emisión de eventos insuficiente

ID	DECIR-11
Estado	fijo
Riesgo	Informativo
Impacto en el negocio	Muchas herramientas de monitoreo, interfaces, herramientas fuera de la cadena y servicios de informes se basan en eventos para capturar las actividades de los contratos en tiempo real. Además, los protocolos pueden reaccionar rápidamente ante emisiones de eventos sospechosos.
Destino	– Recompensa.sol; setRegistryContractAddress(dirección) – Recompensa.sol; setMinimumTimeForRewards(uint256) – Recompensa.sol; setSyntheticProxyAddress(dirección) – Recompensa.sol; restablecerRecompensasGenesisTime() – Recompensa.sol; manualmenteSetRewardsGenesisTime() – Recompensa.sol:267-268; transferencia por lotes(TransferInfo[])

Descripción

Las funciones antes mencionadas no emiten eventos para actualizaciones de estado importantes.

Mitigación

Agregue emisiones de eventos.

 

[I] Versionado de Solidez

ID	DECIR-12
Estado	Admitido
Riesgo	Informativo
Impacto en el negocio	El contrato se puede compilar y probar con diferentes versiones del compilador durante el desarrollo y la revisión y con otra versión diferente del compilador durante la implementación en la red principal. Esto puede conducir a resultados inesperados.
Destino	Recompensa.sol:2

Descripción

El contrato especifica su pragma como pragma solidity ^0.8.13;. Esto permite el uso de cualquier versión de solidity a partir de 0.8.13. Además, la 0.8.13 no es la versión más reciente.

Mitigación

Decida qué versión única de solidez utilizará. La última versión estable (y por lo tanto recomendada) es 0.8.19.

 

[I] Indexar el parámetro de semana en TokensTransferredForConnectionStreak()

ID	DECIR-13
Estado	fijo
Riesgo	Informativo
Impacto en el negocio	La indexación es útil para filtrar eventos en los registros de Ethereum. Cada parámetro indexado en un evento agrega un tema al registro de eventos, lo que facilita la búsqueda de eventos específicos utilizando esos parámetros.
Destino	– Recompensa.sol:81

Descripción

El parámetro semana representa la semana actual en la que se distribuyó el lanzamiento aéreo. Dado que la indexación facilita que las aplicaciones frontend filtren eventos específicos, la indexación de este parámetro facilitará el filtrado de usuarios que recibieron lanzamientos aéreos en una semana determinada.

Mitigación

Considere indexar el parámetro especificado.

 

[I] Adhesión a la Guía de Estilo de Solidity

ID	DECIR-14
Estado	fijo
Riesgo	Informativo
Impacto en el negocio	Este número es puramente informativo. No hay ningún impacto en la situación de seguridad del contrato o de otro tipo.
Destino	– Recompensa.sol:36

Descripción

TransferInfo[], una estructura, se define en la línea 36, ​​directamente después de las variables de estado. La guía de estilo de Solidity recomienda colocar las declaraciones de estructura antes.

Mitigación

Mueva la declaración de la estructura directamente al comienzo del contrato, antes de las variables de estado.