Auditoría FatCats
Resumen de gestión
FatCats se puso en contacto con Sayfer Security para realizar una auditoría de contrato inteligente en su contrato NFT en la red Ethereum
Durante el período de investigación de 3 semanas, descubrimos 6 vulnerabilidades en el contrato. Una vulnerabilidad se clasificó como alta, lo que permitió a un atacante acceder a los metadatos de NFT antes de que se revelaran y hacer predicciones inteligentes sobre airdrops o transacciones de acuñación específicas para NFT raros.
La mayoría de las vulnerabilidades son relevantes solo cuando se acuñan nuevos NFT, por lo que recomendamos corregir las vulnerabilidades encontradas en este informe antes de acuñar otras nuevas.
Vulnerabilidades por Riesgo
Critical – Explotación de parte inmediata o en curso del negocio con pérdidas comerciales clave directas.
Alta – Amenaza directa a los procesos clave del negocio.
Medio – Amenaza indirecta a los procesos comerciales clave o amenaza parcial a los procesos comerciales.
Baja – No existe amenaza directa. La vulnerabilidad puede explotarse utilizando otras vulnerabilidades.
Informativo – Este hallazgo no indica vulnerabilidad, pero establece un comentario que notifica sobre fallas de diseño e implementación incorrecta que podría causar un problema a largo plazo.
Enfoque
Introducción
FatCats contactó a Sayfer para realizar una auditoría de seguridad en los contratos inteligentes de FatCats.
Este informe documenta la investigación realizada por Sayfer dirigida a los recursos seleccionados definidos en el ámbito de la investigación. En particular, este informe muestra la revisión de la postura de seguridad para los contratos inteligentes de FatCats.
Nuestro ciclo de vida del proyecto de pruebas de penetración:
Descripción general del alcance
Resumen técnico
Validación del alcance
Modelo de amenaza
Evaluación de seguridad
Evaluacion de seguridad
Validación del alcance
Comenzamos por asegurarnos de que el alcance que nos definiera el cliente fuera técnicamente lógico.
Decidir qué alcance es el adecuado para un sistema dado es parte de la discusión inicial.
Modelo de amenaza
Definimos que la mayor amenaza actual para el sistema es la capacidad de los usuarios malintencionados para robar fondos del contrato. El segundo riesgo más alto para la plataforma es la capacidad de ataque para robar NFT del contrato.
Descripción general del protocolo
Introducción al protocolo
Fat Cats es una colección de 5,000 NFT únicos que se duplican como un token de membresía y comparten todas las tenencias de Fat Cats. Ser propietario de un Fat Cats NFT le da acceso a una parte de todas las tenencias de DAO a un precio asequible.
Todos los fondos líquidos se mantendrán en una canasta de monedas estables y otros activos criptográficos según lo consideren conveniente los miembros. En el caso de decisiones urgentes, el Consejo puede gastar hasta el 20 % de todos los fondos depositados.
FatCats Contract es un contrato de token NFT que se acuña en pasos: paso 1, paso 2 y acuñación pública. Los pasos de acuñación los establece el propietario. Los usuarios incluidos en la lista blanca pueden acuñar NFT en el paso 1 y el paso 2. Los usuarios incluidos en la lista blanca son validados por la prueba de Merkle.
El contrato FatCats hereda MerkleProof, Ownable, Address, VRFCoordinatorV2Interface, VRFConsumerBaseV2, IERC721Receiver, Context, IERC721Metadata, Strings, ERC165, IERC721, contratos inteligentes estándar de la biblioteca OpenZeppelin. Estos contratos de OpenZeppelin se consideran auditados por la comunidad y probados en el tiempo y, por lo tanto, no forman parte del alcance de la auditoría.
Gráfico de protocolo
Evaluación de seguridad
Los siguientes casos de prueba fueron la pauta durante la auditoría del sistema. Esta lista de verificación es una versión modificada de la SCSVS v1.2, con gramática mejorada, claridad, concisión y criterios adicionales. Donde hay una brecha en la numeración, se eliminó un criterio original. Los criterios que están marcados con un asterisco fueron agregados por nosotros.
Arquitectura, Diseño y Modelado de Amenazas
| Arquitectura, Diseño y Modelado de Amenazas | Nombre de la prueba |
| G1.2 | Cada cambio de diseño introducido está precedido por el modelado de amenazas. |
| G1.3 | La documentación define de forma clara y precisa todos los límites de confianza en el contrato (relaciones de confianza con otros contratos y flujos de datos significativos). |
| G1.4 | El SCSVS, los requisitos de seguridad o la política están disponibles para todos los desarrolladores y probadores. |
| G1.5 | Se definen los eventos para las operaciones (cambio de estado/crucial para el negocio). |
| G1.6 | El proyecto incluye un mecanismo que puede detener temporalmente funcionalidades sensibles en caso de un ataque. Este mecanismo no debe bloquear el acceso de los usuarios a sus activos (por ejemplo, tokens). |
| G1.7 | La cantidad de criptomonedas no utilizadas mantenidas en el contrato está controlada y en el nivel mínimo aceptable para no convertirse en un objetivo potencial de un ataque. |
| G1.8 | Si cualquier persona puede llamar a la función de reserva, se incluye en el modelo de amenazas. |
| G1.9 | La lógica de negocios es consistente. Los cambios importantes en la lógica deben aplicarse en todos los contratos. |
| G1.10 | Se emplean herramientas automáticas de análisis de código para detectar vulnerabilidades. |
| G1.11 | Se utiliza la versión principal más reciente de Solidity. |
| G1.12 | Cuando se utiliza una implementación externa de un contrato, se utiliza la versión más reciente. |
| G1.13 | Cuando las funciones se anulan para ampliar la funcionalidad, la palabra clave super se utiliza para mantener la funcionalidad anterior. |
| G1.14 | El orden de la herencia se especifica cuidadosamente. |
| G1.15 | Hay un componente que monitorea la actividad del contrato usando eventos. |
| G1.16 | El modelo de amenaza incluye transacciones de ballenas. |
| G1.17 | La fuga de una clave privada no compromete la seguridad de todo el proyecto. |
Pólizas y Procedimientos
| Pólizas y Procedimientos | Nombre de la prueba |
| G2.2 | La seguridad del sistema está bajo control constante (por ejemplo, el nivel esperado de fondos). |
| G2.3 | Existe una política para rastrear nuevas vulnerabilidades de seguridad y actualizar las bibliotecas a la última versión segura. |
| G2.4 | Se puede contactar públicamente al departamento de seguridad y que el procedimiento para manejar los errores informados (p. ej., una recompensa completa por errores) esté bien definido. |
| G2.5 | El proceso de agregar nuevos componentes al sistema está bien definido. |
| G2.6 | El proceso de cambios importantes en el sistema implica el modelado de amenazas por parte de una empresa externa. |
| G2.7 | El proceso de adición y actualización de componentes al sistema incluye una auditoría de seguridad por parte de una empresa externa. |
| G2.8 | En caso de que se produzca un ataque, existe un procedimiento de mitigación claro y bien conocido. |
| G2.9 | El procedimiento en caso de hackeo define claramente qué personas deben ejecutar las acciones requeridas. |
| G2.10 | El procedimiento incluye alertar a otros proyectos sobre el hackeo a través de canales confiables. |
| G2.11 | Se define un procedimiento de mitigación de fugas de clave privada. |
Capacidad de actualización
| Capacidad de actualización | Nombre de la prueba |
| G3.2 | Antes de actualizar, se realiza una emulación en una bifurcación de la red principal y todo funciona como se espera en la copia local. |
| G3.3 | El proceso de actualización se ejecuta mediante un contrato multisig donde más de una persona debe aprobar la operación. |
| G3.4 | Los bloqueos de tiempo se utilizan para operaciones importantes para que los usuarios tengan tiempo de observar los próximos cambios (tenga en cuenta que eliminar posibles vulnerabilidades en este caso puede ser más difícil). |
| G3.5 | inicializar() solo se puede llamar una vez. |
| G3.6 | inicializar() solo puede ser llamado por un rol autorizado a través de modificadores apropiados (por ejemplo, inicializador, solo propietario). |
| G3.7 | El proceso de actualización se realiza en una sola transacción para que nadie pueda adelantarlo. |
| G3.8 | Los contratos actualizables tienen espacios reservados en las ranuras para evitar la sobrescritura. |
| G3.9 | El número de espacios reservados (como un espacio) se ha reducido adecuadamente si se han agregado nuevas variables. |
| G3.10 | No hay cambios en el orden en que se declaran las variables de estado del contrato, ni en sus tipos. |
| G3.11 | Los nuevos valores devueltos por las funciones son los mismos que en versiones anteriores del contrato (por ejemplo, propietario(), saldoDe(dirección)). |
| G3.12 | Se inicializa la implementación. |
| G3.13 | La implementación no puede ser destruida. |
Lógica de negocios
| Lógica de negocios | Nombre de la prueba |
| G4.2 | La implementación de la lógica del contrato y los parámetros del protocolo corresponde a la documentación. |
| G4.3 | La lógica empresarial procede en un orden de pasos secuenciales y no es posible omitir pasos o hacerlo en un orden diferente al diseñado. |
| G4.4 | El contrato ha aplicado correctamente los límites comerciales. |
| G4.5 | La lógica empresarial no se basa en los valores recuperados de contratos que no son de confianza (especialmente cuando hay varias llamadas al mismo contrato en un solo flujo). |
| G4.6 | La lógica comercial no se basa en el saldo del contrato (por ejemplo, saldo == 0). |
| G4.7 | Las operaciones sensibles no dependen de los datos del bloque (p. ej., hash de bloque, marca de tiempo). |
| G4.8 | El contrato utiliza mecanismos que mitigan los ataques de ordenación de transacciones (ejecución inicial) (por ejemplo, esquemas de compromiso previo). |
| G4.9 | El contrato no envía fondos automáticamente, sino que permite a los usuarios retirar fondos en transacciones separadas. |
Control de Acceso
| Control de Acceso | Nombre de la prueba |
| G5.2 | Se mantiene el principio del menor privilegio. Otros contratos solo deberían poder acceder a funciones y datos para los que posean autorización específica. |
| G5.3 | Los nuevos contratos con acceso al contrato auditado se adhieren al principio de derechos mínimos por defecto. Los contratos deben tener permisos mínimos o nulos hasta que se otorgue explícitamente el acceso a las nuevas funciones. |
| G5.4 | El creador del contrato cumple con el principio del mínimo privilegio y sus derechos siguen estrictamente los señalados en la documentación. |
| G5.5 | El contrato hace cumplir las reglas de control de acceso especificadas en un contrato de confianza, especialmente si el control de acceso del lado del cliente de la dApp está presente y podría omitirse. |
| G5.6 | Las llamadas a contratos externos solo están permitidas si es necesario. |
| G5.7 | El código modificador es claro y simple. La lógica no debe contener llamadas externas a contratos que no sean de confianza. |
| G5.8 | Todos los atributos de usuario y datos utilizados por los controles de acceso se mantienen en contratos confiables y no pueden ser manipulados por otros contratos a menos que se autorice específicamente. |
| G5.9 | Los controles de acceso fallan de forma segura, incluso cuando se produce una reversión. |
| G5.10 | Si se valida la entrada (parámetros de la función), se utiliza el enfoque de validación positiva (lista blanca) siempre que sea posible. |
Comunicación
| Comunicación | Nombre de la prueba |
| G6.2 | Se identifican las bibliotecas que no forman parte de la aplicación (pero de las que depende el contrato inteligente para funcionar). |
| G6.3 | La llamada de delegado no se usa con contratos que no son de confianza. |
| G6.4 | Los contratos de terceros no ocultan funciones especiales (por ejemplo, reversión). |
| G6.5 | El contrato no verifica si la dirección es un contrato usando código de operación de tamaño de código ext. |
| G6.6 | Los ataques de reingreso se mitigan bloqueando las llamadas recursivas de otros contratos y siguiendo el patrón Verificar-Efectos-Interacciones. No utilice la función de envío a menos que sea imprescindible. |
| G6.7 | El resultado de llamadas a funciones de bajo nivel (p. ej. enviar, delegar llamar, llamar) de otros contratos se comprueba. |
| G6.8 | El contrato se basa en los datos proporcionados por el remitente correcto y no se basa en el valor de tx.origin. |
Aritmética
| Aritmética | Nombre de la prueba |
| G7.2 | Los valores y las operaciones matemáticas son resistentes a los desbordamientos de enteros. Use la biblioteca SafeMath para operaciones aritméticas antes de solidity 0.8.*. |
| G7.3 | Los fragmentos de código no verificados de Solidity ≥ 0.8.* no introducen desbordamientos/desbordamientos de enteros. |
| G7.4 | Los valores extremos (por ejemplo, valores máximos y mínimos del tipo variable) se consideran y no cambian el flujo lógico del contrato. |
| G7.5 | La desigualdad no estricta se utiliza para la igualdad de equilibrio. |
| G7.6 | En los cálculos se utilizan órdenes de magnitud correctos. |
| G7.7 | En los cálculos, la multiplicación se realiza antes de la división para mayor precisión. |
| G7.8 | El contrato no asume una precisión de punto fijo y utiliza un multiplicador o almacena tanto el numerador como el denominador. |
Denegación de servicio
| Denegación de servicio | Nombre de la prueba |
| G8.2 | El contrato no itera sobre bucles no vinculados. |
| G8.3 | La funcionalidad de autodestrucción se usa solo si es necesario. Si está incluido en el contrato, debe estar claramente descrito en la documentación. |
| G8.4 | La lógica empresarial no se bloquea si un actor (por ejemplo, contrato, cuenta, oráculo) está ausente. |
| G8.5 | La lógica comercial no desincentiva a los usuarios a usar contratos (por ejemplo, el costo de la transacción es mayor que la ganancia). |
| G8.6 | Las expresiones de funciones afirmar o requerir tienen una variante de paso. |
| G8.7 | Si nadie puede llamar a la función de reserva, no está bloqueando las funcionalidades del contrato. |
| G8.8 | No hay operaciones costosas en un bucle. |
| G8.9 | No hay llamadas a contratos que no son de confianza en un bucle. |
| G8.10 | Si existe la posibilidad de suspender la vigencia del contrato, también es posible reanudarla. |
| G8.11 | Si se utilizan listas blancas y listas negras, no interfieren con el funcionamiento normal del sistema. |
| G8.12 | No hay DoS causado por desbordamientos y subdesbordamientos. |
Datos de la cadena de bloques
| Datos de la cadena de bloques | Nombre de la prueba |
| G9.2 | Los datos guardados en los contratos no se consideran seguros ni privados (incluso las variables privadas). |
| G9.3 | No se almacenan datos confidenciales en la cadena de bloques (contraseñas, datos personales, token, etc.). |
| G9.4 | Los contratos no utilizan cadenas literales como claves para las asignaciones. En su lugar, se utilizan constantes globales para evitar el ataque de homoglifos. |
| G9.5 | El contrato no genera trivialmente números pseudoaleatorios basados en la información de la cadena de bloques (p. ej., inicialización con el número de bloque). |
Uso de gas y limitaciones
| Uso de gas y limitaciones | Nombre de la prueba |
| G10.1 | El uso de gas está previsto, definido y tiene limitaciones claras que no se pueden exceder. Tanto la estructura del código como la entrada maliciosa no deberían causar el agotamiento del gas. |
| G10.2 | La ejecución de la función y la funcionalidad no dependen de las tarifas de gas codificadas (están obligadas a variar). |
Claridad y legibilidad
| Claridad y legibilidad | Nombre de la prueba |
| G11.2 | La lógica es clara y modularizada en múltiples contratos y funciones simples. |
| G11.3 | Cada contrato tiene un breve comentario de 1-2 oraciones que explica su propósito y funcionalidad. |
| G11.4 | Se utilizan implementaciones listas para usar, esto se aclara en el comentario. Si estas implementaciones han sido modificadas, las modificaciones se anotan a lo largo del contrato. |
| G11.5 | El orden de herencia se tiene en cuenta en los contratos que utilizan múltiples funciones de herencia y sombra. |
| G11.6 | Siempre que sea posible, los contratos utilizan código probado existente (por ejemplo, contratos de token o mecanismos como poseer) en lugar de implementar los suyos propios. |
| G11.7 | Se siguen patrones de nomenclatura coherentes a lo largo del proyecto. |
| G11.8 | Las variables tienen nombres distintivos. |
| G11.9 | Todas las variables de almacenamiento se inicializan. |
| G11.10 | Las funciones con un tipo de devolución especificado devuelven un valor de ese tipo. |
| G11.11 | Se utilizan todas las funciones y variables. |
| G11.12 | exigir se utiliza en lugar de revertir in if Declaraciones. |
| G11.13 | El afirmar La función se utiliza para probar errores internos y la exigir La función se utiliza para garantizar una condición válida en la entrada de los usuarios y los contratos externos. |
| G11.14 | El código ensamblador solo se usa si es necesario. |
Cobertura de prueba
| Cobertura de prueba | Nombre de la prueba |
| G12.2 | Las narrativas de abuso detalladas en el modelo de amenazas están cubiertas por pruebas unitarias |
| G12.3 | Las funciones sensibles en los contratos verificados se cubren con pruebas en la fase de desarrollo. |
| G12.4 | Se ha comprobado la implementación de contratos verificados en busca de vulnerabilidades de seguridad mediante análisis estáticos y dinámicos. |
| G12.5 | La especificación del contrato se ha verificado formalmente |
| G12.6 | La especificación y los resultados de la verificación formal se incluyen en la documentación. |
Finanzas descentralizadas
| Finanzas descentralizadas | Nombre de la prueba |
| G13.1 | El contrato del prestamista no asume que su saldo (utilizado para confirmar el pago del préstamo) se cambie solo con sus propias funciones. |
| G13.2 | Las funciones que cambian el saldo de los prestamistas y/o prestan criptomonedas no son reingresantes si el contrato inteligente permite tomar prestada la criptomoneda de la plataforma principal (por ejemplo, Ethereum). Bloquea los ataques que actualizan el saldo del prestatario durante la ejecución del préstamo flash. |
| G13.3 | Las funciones de préstamo flash solo pueden llamar a funciones predefinidas en el contrato de recepción. Si es posible, defina un subconjunto confiable de contratos para llamar. Por lo general, el contrato de envío (préstamo) es el que debe devolverse. |
| G13.4 | Si incluye operaciones potencialmente peligrosas (p. ej., devolver más ETH/tokens de los prestados), la función del receptor que maneja ETH o tokens prestados puede ser llamada solo por el grupo y dentro de un proceso iniciado por el propietario del contrato receptor u otra fuente confiable (p. ej. multigrado). |
| G13.5 | Los cálculos de la cuota del fondo de liquidez se realizan con la mayor precisión posible (por ejemplo, si la contribución se calcula para ETH, debe hacerse con una precisión de 18 dígitos, para Wei, no para Ether). El dividendo debe multiplicarse por 10 a la potencia del número de dígitos decimales (por ejemplo, dividendo * 10^18 / divisor). |
| G13.6 | Las recompensas no se pueden calcular y distribuir dentro de la misma llamada de función que deposita tokens (también debe definirse como no reingreso). Esto protege de fluctuaciones momentáneas en las acciones. |
| G13.7 | Los contratos de gobernanza están protegidos contra ataques de préstamos rápidos. Una posible técnica de mitigación es requerir que el proceso de depositar tokens de gobernanza y proponer un cambio se ejecute en diferentes transacciones incluidas en diferentes bloques. |
| G13.8 | Cuando se utilizan oráculos en cadena, los contratos pueden pausar las operaciones en función del resultado de los oráculos (en caso de un oráculo comprometido). |
| G13.9 | Los contratos externos (incluso los de confianza) que pueden cambiar los atributos de un contrato de proyecto (p. ej., el precio del token) tienen implementadas las siguientes limitaciones: umbrales para el cambio (p. ej., no más/menos del 5 %) y un límite de actualizaciones (p. ej., una actualización por día). |
| G13.10 | Los atributos del contrato que pueden ser actualizados por los contratos externos (incluso los confiables) se monitorean (por ejemplo, usando eventos) y se implementa un procedimiento de respuesta a incidentes (por ejemplo, durante un ataque en curso). |
| G13.11 | Las operaciones matemáticas complejas que consisten en operaciones de multiplicación y división primero realizan multiplicaciones y luego divisiones. |
| G13.12 | Al calcular los precios de intercambio (por ejemplo, ETH a token o viceversa), el numerador y el denominador se multiplican por las reservas (ver el obtenerPrecioEntrada en función de la Intercambio Uniswap contrato). |
Ordenar auditoría de Sayfer
Resultados de la auditoría
URI de token adivinables
| Estado | Abierto |
| Riesgo | Critical |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
Tener una ventaja inicial sobre el conocimiento de los metadatos de la NFT podría dar a un atacante saber qué NFT debe acuñar antes de revelarlo al público. Esto podría permitir que el atacante obtenga el control de los NFT más valiosos del proyecto.
La siguiente vulnerabilidad permite a un atacante decidir qué NFT comprar en función de los metadatos antes de que se revele al público. Esta vulnerabilidad es relativamente fácil de explotar debido a otras vulnerabilidades que encontramos. En el tiempo entre el shuffle la bandera se vuelve verdadera en requestRandomWords() y los NFT que se revelan en revealNFT(), un atacante puede adivinar los URI del token.
Aunque se cree que revealed la bandera sigue siendo falsa tokenURI() devoluciones hideUri, lo que significa que el usuario promedio solo verá el URI ficticio/oculto sin los metadatos completos.
Para construir completamente la cadena URI del token, se está realizando otra transacción para ejecutar el requestRandomWords() método que establece el s_randomWords vía fulfillRandomWords(). Esto se hace a través del VRF de Chianlink.
Solo entonces se ejecuta el siguiente código y devuelve la cadena URI del token completo:
La vulnerabilidad es que baseURI, maxSupply y s_randomWords son públicos y un atacante puede predecir el URI del token sin necesidad de revealed variable. En la V1 del proyecto hemos visto que la primera transacción que ejecuta requestRandomWords():
Y luego la segunda transacción que revela el NFT al ejecutar el revealNFT():
Podemos ver que durante 3 horas, un atacante podría haber visto cualquier metadato de NFT antes de que se revelara y hacer predicciones inteligentes sobre lanzamientos desde el aire o transacciones de acuñación específicas para NFT raros.
Mitigación
Revelar un NFT no tiene una talla única para todos. Depende en gran medida de la estrategia y la experiencia de usuario que debe tener el usuario final.
Para mayor seguridad, recomendamos revelar, establecer el URI base y cambiar el estado de s_randomWords variable de estado con la menor diferencia de tiempo entre ellas. Si bien no mitiga la vulnerabilidad por completo, reducir el tiempo entre estas acciones puede reducir el riesgo de que los malos actores la exploten.
Una mejor manera es hacer todos los cambios de estado en la misma transacción mientras se revela, esto muchas veces no es técnicamente posible.
Para profundizar en cómo implementar un lanzamiento aéreo NFT aleatorio y formas más seguras, recomendamos leer Estrategias de aleatorización para gotas NFT.
Las direcciones incluidas en la lista blanca pueden ser contratos
| Estado | Abierto |
| Riesgo | Alta |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
Al acuñar un NFT, el contrato de acuñación podría bloquear o permitir la acuñación de direcciones de contratos. Permitir la acuñación de contratos o tener una vulnerabilidad que permita la acuñación de contratos podría dar lugar a una situación en la que el atacante puede revertir la transacción si tiene conocimiento previo sobre qué NFT debe acuñar.
El modificador isAUser() solo se usa para publicMint().
mintStep1() y mintStep2() métodos de isWhitelisted() se está utilizando el modificador.
Esto significa que el código no busca direcciones no contractuales en los hashes de prueba de Merkle de la lista blanca.
Si bien no podemos saber cuáles fueron los procesos detrás de la generación de la lista blanca y qué tan segura es, el código en sí es vulnerable a este ataque. Se desaconseja buscar direcciones no contractuales fuera de la cadena o que no estén en la misma transacción, ya que es vulnerable a múltiples vectores de ataque.
Un atacante podría obtener un NFT y revertir la transacción si el NFT no es lo suficientemente raro. Junto con el URI del token adivinable, un atacante puede obtener fácilmente conocimiento previo sobre los metadatos del NFT y revertir las transacciones en función de la rareza.
Mitigación
Agregue la isAUser modificador a la mintStep1() y mintStep2() métodos.
Implementación aleatoria débil e insegura de VRF de Chainlink
| Estado | Abierto |
| Riesgo | Alta |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
Los errores de aleatoriedad inseguros ocurren cuando una función que puede producir valores predecibles se usa como fuente de aleatoriedad en un contexto sensible a la seguridad.
Los contratos inteligentes tienen que depender de soluciones fuera de la cadena para generar números aleatorios seguros. Fatcats usa el sistema VRF de Chainlink para generar un número aleatorio que luego se usa como una identificación aleatoria para el URI del token usando el fulfillRandomWords método:
El método guarda el número aleatorio en una variable de estado llamada s_randomWords que por su nombre implica que es una palabra aleatoria. En la práctica, el número es módulo con maxSupply(5000), por lo que es un número aleatorio pseudodébil entre 1 y 5000. Esto puede llevar a los desarrolladores a pensar que pueden confiar en este número para asegurar la aleatoriedad, lo cual no es así.
Mitigación
Asigne el valor devuelto proveniente de VRF a la variable de estado global.
Centralización del Contrato y Monedero del Equipo
| Estado | Abierto |
| Riesgo | Alta |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
Los proyectos que dependen de una clave son vulnerables a pérdidas de claves, ataques de phishing, manipulaciones de actores internos, muerte del propietario y más.
Cuando el proyecto depende solo de una clave. Este tipo de ataques son los más comunes de los mayores hacks.
El proyecto verifica la isOwner en múltiples lugares. La pérdida de las claves de esta dirección de implementación comprometerá todo el proyecto.
Además, la billetera del equipo que obtendrá el eth usando el withdraw la función también está sujeta al mismo vector de ataque
Si las billeteras anteriores usan multisig, este hallazgo se resolverá.
Mitigación
Según el caso de uso, el nivel de seguridad y la experiencia del usuario que el proyecto quiera aplicar, hay varias formas de mitigar este ataque, por ejemplo, usando una billetera multisig, una billetera inteligente o aplicando múltiples propietarios al proyecto.
La función openPublicBurn cambia en lugar de abrir
| Estado | Abierto |
| Riesgo | Baja |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
El método openPublicBurn no solo abre la grabación pública, sino que la activa y desactiva según el estado actual de la variable.
Esto podría llevar a un desarrollador oa un operador del proyecto a pensar que están abriendo el paso de grabación pública, pero en realidad lo están desactivando, lo que causa una mala reputación para el proyecto.
Mitigación
Establecer la variable de estado publicBurnFlag a verdadero o cambie el nombre del método a
switchPublicBurn.
El mecanismo de paso es difícil de mantener
| Estado | Abierto |
| Riesgo | Info |
| Destino | FatCats.sol |
| Herramientas | Prueba manual |
Descripción
El código usa variables booleanas para cada paso, esto significa que cada vez que el desarrollador agrega otro paso, debe agregar la lógica para alternar el reinicio de las banderas. Esto podría generar confusión y posibles errores de seguridad.
Un mejor enfoque sería usar enum como el paso actual si esto brinda las ventajas de un nombre de paso claro como EARLY_ADAPTERS, PUBLINK_MINT, Etc.
Si esto es demasiado detallado o confuso, podría implementarse a través de un número entero simple, esto tiene la ventaja matemática de if step > 2 or require(newStep < oldStep, “can not go back”.
Mitigación
Utilice la enumeración integrada de Solidity o la sintaxis de enteros simple.