¿Demasiados problemas con los proyectos DeFi? Es hora de que los usuarios hagan algunas preguntas a los desarrolladores

En los últimos meses, la industria DeFi ha experimentado algunas turbulencias y se han expuesto muchos ataques y vulnerabilidades no reveladas.

Aunque los errores son inevitables, tomar algunas medidas efectivas aún puede reducir la frecuencia de los problemas y reducir el impacto negativo resultante.

Como revisores, nos gustaría proporcionar alguna ayuda en este sentido. Para que los desarrolladores den prioridad a los problemas de seguridad, los usuarios deben poder hacer algunas preguntas difíciles desde el principio. Solo cuando estas preguntas se responden satisfactoriamente pueden invertir dinero en los proyectos de protocolo correspondientes con confianza.

Para determinar la postura de seguridad del equipo de desarrollo del proyecto DeFi, este artículo enumerará algunas preguntas útiles. Las respuestas a estas preguntas no se pueden medir simplemente por "verdadero/incorrecto", porque algunos equipos (o desarrolladores independientes) pueden No hay suficientes recursos para abordar todos los problemas. De hecho, los usuarios solo pueden juzgar si están dispuestos a asumir el nivel de riesgo correspondiente en función de la información que pueden obtener.

Por supuesto, esperamos que las siguientes preguntas puedan impulsar los proyectos DeFi en la dirección correcta.

La mayoría de los protocolos DeFi conocidos se controlan de forma centralizada de alguna forma, lo que permite que "administradores" específicos intervengan de manera poderosa.

Si bien este enfoque tiene algunos beneficios de seguridad, también significa que debe confiar en que los administradores no abusen de sus privilegios. Por otro lado, si un atacante roba la clave privada del administrador y todos los privilegios que la acompañan, también aumenta el riesgo del proyecto.

Las cuentas de administrador suelen tomar varias formas posibles, que incluyen: acceso a direcciones individuales, billeteras de firmas múltiples y organizaciones autónomas descentralizadas (DAO) controladas por un proceso de votación. Las preguntas de seguridad para hacer aquí incluyen:

Se transfirieron aproximadamente USD 272 millones en USDT a Huobi Exchange: los datos de Whale Alert muestran que a las 15:38 del 12 de marzo, hora de Beijing, se transfirieron 271 302 140 USDT desde una billetera desconocida que comienza con 0x0de84 a Huobi Exchange, por un valor aproximado de USD 272 millones. El hash de la transacción es: 0x54a1b288b2457de97748287c82ec7e1acee766b0efe30ab4438c21cc150e0ad8. [2021/3/12 18:39:29]

     ¿Qué acciones especiales pueden realizar los administradores?

¿Se puede pausar el sistema?

¿Puedo modificar mi saldo?

¿Se pueden incluir tokens/usuarios en la lista blanca/negra?

¿Se puede actualizar un subconjunto del sistema?

¿Se pueden actualizar todos los sistemas (igual a la omnipotencia)?

¿Es capaz de implementar otras medidas especiales?

Entre los comportamientos anteriores, ¿cuáles se retrasarán y cuáles no?

Si hay un retraso, ¿cuánto tiempo se extenderá?

¿Cuántas personas tienen privilegios de administrador?

¿Cuántas aprobaciones de administrador se deben obtener antes de que se puedan realizar ciertas acciones?

¿Existe alguna acción administrativa controlada por la gobernanza en cadena, como una DAO?

¿Dónde puedo encontrar el estado más reciente de los cambios de protocolo propuestos?

Parte de la información anterior ya se puede rastrear en DefiWatch.

El banco central alemán habilita el protocolo Ocean Protocol en un proyecto de red descentralizado: El banco central alemán (Deutsche Bundesbank) ha habilitado el protocolo de intercambio de datos descentralizado Ocean Protocol en un proyecto de red descentralizado. El Bundesbank lanzó Ocean como un "servicio de consultoría de integración de software", según un anuncio traducido en un suplemento del Diario Oficial de la Unión Europea. El Bundesbank dijo que Ocean Protocol era el único contratista posible para el trabajo. (El diario Hodl)[2020/10/30 11:16:30]

La cadena de bloques de Ethereum está llena de actores adversarios y, en general, los desarrolladores deben tratar de evitar hacer suposiciones sobre el comportamiento de los contratos en otros sistemas. Sin embargo, en muchas aplicaciones DeFi, esto es casi imposible, porque el servicio en sí se basa en contratos existentes.

Entonces, cuando se trata de riesgos relacionados con dependencias externas, las siguientes preguntas pueden ser útiles:

¿En qué oráculos se basa su sistema?

¿De qué intercambios depende su sistema?

¿Qué contratos inteligentes de terceros se utilizan para construir su sistema (como OpenZeppelin)?

¿Qué tokens admite su sistema? ¿Qué suposiciones hizo sobre la funcionalidad de estos tokens?

Para aquellos hackers con alto coeficiente intelectual, atacar el protocolo DeFi puede permitirles obtener enormes beneficios económicos. Por lo tanto, puede intentar crear un programa de recompensas para proporcionar algunas recompensas financieras para aquellos que proporcionan vulnerabilidades del sistema, de modo que los piratas informáticos puedan reducir las vulnerabilidades. Reportar errores a través de programas de recompensas en realidad es bueno para la reputación de los piratas informáticos, ya que no tienen que usar medios ilegales para ganar dinero.

Con el fin de proteger los fondos de los clientes, cualquier empresa que ejecute un protocolo DeFi debe considerar un programa de recompensas para piratas informáticos. Aquí hay algunas preguntas que podemos hacer sobre el programa relacionado y el proceso de divulgación:

¿El código fuente de su contrato está disponible públicamente?

¿Puede encontrar rápidamente la información de contacto de seguridad en su sitio web y en el repositorio de GitHub?

¿Tiene un programa de recompensas en su contrato?

¿Qué contratos están incluidos en el programa de recompensas?

¿Cuál es el rango de montos de las recompensas?

¿Alguna vez has pagado una recompensa?

¿Se ha negado anteriormente a pagar recompensas por informes de errores?

¿Puede encontrar rápidamente los detalles del programa de recompensas en su sitio web y en el repositorio de GitHub?

Idealmente, esta información se puede encontrar en la página/sección de seguridad del sitio web oficial del proyecto, o mediante el uso de la función SECURITY.md de GitHub.

Cuando se encuentra con un incidente de seguridad, con todo tipo de información nueva que llega constantemente, a menudo es difícil para los desarrolladores ordenar sus pensamientos, porque habrá una gran cantidad de usuarios que harán todo tipo de preguntas difíciles en Twitter, Telegram, Discard. ..

Por lo tanto, debe desarrollar un plan para garantizar que los incidentes de seguridad se desarrollen en una dirección saludable. Aunque puede que no tenga mucho sentido que el equipo del proyecto DeFi revele el plan completo, es mejor que puedan responder las siguientes preguntas:

¿Tiene un plan escrito que describa cómo se manejarán los incidentes de seguridad?

¿Qué opciones consideró su plan?

Si su sistema es escalable, ¿están documentados todos los pasos para realizarlo?

Si se descubre una vulnerabilidad que pone en riesgo los fondos, ¿se adelantará al problema para proteger los fondos?

La auditoría no es una panacea y no todas las auditorías reciben el mismo trato. Sin embargo, para los contratos de DeFi, sigue siendo un paso crucial realizar auditorías de seguridad antes del despliegue oficial.

Aunque no todas las preguntas pueden tener una "respuesta correcta", los comentarios y las respuestas proporcionadas por el equipo de desarrollo del proyecto pueden al menos permitir que los miembros de la comunidad comprendan su postura de seguridad. Los siguientes problemas merecen atención:

¿Cuándo fue la última vez que su proyecto fue auditado?

¿Cuánto esfuerzo (persona/hora) se requiere para el trabajo de auditoría?

¿Qué empresa te auditó?

¿Los informes de auditoría están disponibles públicamente?

¿Qué partes de su sistema se excluyeron de la auditoría?

¿Se ha actualizado su contrato desde su última auditoría? Si se actualizó, ¿qué cambió?

¿Tiene una relación a largo plazo con una empresa de seguridad?

¿Los desarrolladores verifican las solicitudes de extracción de los demás (al menos en los archivos de Solidity) en GitHub antes de fusionar el código?

¿Qué partes del código del contrato estarán cubiertas por las pruebas unitarias?

¿Se utilizaron otras herramientas de análisis de seguridad en el proceso?

Para los usuarios de DeFi interesados ​​en hacer un seguimiento de estos problemas, otro proyecto a tener en cuenta es DeFi Score de ConsenSys, que está realizando la difícil tarea de evaluar la calidad de las auditorías y otros procesos de seguridad en varios proyectos importantes de DeFi.

Finalmente, gracias a Emilio y Ernesto (@eboado en Telegram), ambos desarrolladores de Aave, y Jack de DeFi Score por sus comentarios sobre un borrador inicial de este artículo.

Enlace fuente: diligence.consensys.net

Escrito por: John Mardlin, ingeniero de seguridad de ConsenSys Diligence Traducido por: Lu Jiangfei

Tags：

Uniswap