Primer lanzamiento | ¿Cuál es la probabilidad de encontrar un contrato DeFi vulnerable? ¿Cuál es la probabilidad de ser atacado después de la auditoría?

El editor que está en Estados Unidos con 100.000 casos confirmados de la nueva corona tiene que salir en avión por razones de fondo. Antes del viaje, siempre me preocupaba si me infectaría, pero en el camino, me engañó la turbulencia del avión que se encontraba con un flujo de aire violento.

Aunque en silencio me consolé que la probabilidad de un accidente aéreo es muy baja y la probabilidad de contraer una nueva neumonía coronaria no es tan alta, todavía recordaba cuatro palabras: "Ley de Murphy".

Bajo la tendencia del desarrollo de la tecnología moderna, los activos bloqueados en el campo de la cadena de bloques son cada vez más grandes. Con el desarrollo de la cadena de bloques, la crisis que se esconde detrás de la computadora muestra cada vez más su cara feroz.

En el contrato inteligente, cualquier pequeño error puede causar pérdidas irreparables al proyecto o a los inversores.

Bajo esta advertencia, el equipo de seguridad de CertiK usó el sistema CertiK Skynet (Skynet) para monitorear y analizar los contratos inteligentes de token recién agregados a Uniswap de 00:00 a 24:00 el 4 de diciembre de 2020, hora de Beijing.

Durante el período de tiempo de este análisis, se generaron un total de 29 proyectos de token de contrato inteligente.

¡Después del análisis de Skynet realizado por CertiK, se descubrió que un total de 16 contratos inteligentes tenían lagunas o defectos!

Alrededor del 55% de los proyectos de contratos inteligentes tienen más o menos lagunas o defectos, de los cuales alrededor del 10% tienen lagunas graves, y el 45% tiene defectos como autoridad excesiva de los propietarios del proyecto y centralización de autoridad excesiva.

El nombre del proyecto de contrato inteligente y la dirección del contrato de este análisis son los siguientes:

Los resultados del análisis son los siguientes: 

Aunque es difícil estimar la situación de seguridad de los contratos inteligentes en todos los rangos de tiempo en función de la situación de un día, es posible conocer el panorama completo de un vistazo.

El siguiente análisis se centra en tres vulnerabilidades relativamente importantes:

Figura 1: función burnFrom()

En la Figura 1, la función burnFrom está restringida por el modificador OwnerOnly y solo los administradores de proyectos pueden ejecutar esta función. La implementación lógica interna de esta función permite cualquier modificación de _totalSupply y el valor de _balances de una cuenta dada indirectamente al establecer los valores de cuenta, saldo y subtractValue.

Guarda Wallet ha soportado la recarga y retirada de BTC (TRC20-BTC) basada en la cadena TRON: Según las últimas noticias, la cartera Guarda ha soportado la recarga y retirada de BTC (TRC20-BTC) basada en la cadena TRON. Se informa que TRC20-BTC es emitido por la Fundación JUST Es otra obra maestra de los activos de la red TRON después del TRC20-USDT cuya circulación superó los 4 mil millones de dólares estadounidenses. Cualquier titular de BTC puede participar en la emisión de TRC20-BTC, y Poloniex actualmente admite el intercambio de TRC20-BTC.

El contrato TRC20-BTC ha sido auditado por SlowMist, una empresa de auditoría de código de terceros. [2020/10/20]

Figura 2: La función de reserva en el contrato powerpoolttl

La figura 2 muestra la función alternativa del contrato powerpoolttl. Cuando un usuario externo llama al contrato inteligente, si la llamada no llama a ninguna función en el contrato, o solo transfiere tokens al contrato, se llamará a la función de reserva. La lógica en la línea 70 muestra que cuando se llama a la función de reserva, los tokens transferidos al contrato durante la llamada se transferirán directamente a la dirección de teamAddress.

En este proyecto, los tokens se pueden transferir mediante la ejecución de la función transferFrom() De acuerdo con la definición de la función transferFrom() en la Figura 3, la línea 211 necesita ejecutar la función getFee para determinar la tarifa que se deducirá por cada transferencia de token. A partir de la definición de la función getFee() en la Figura 3, podemos ver que la lógica para determinar el costo depende de la definición de la función Management.getFee() llamada en la línea 241. La definición lógica de la función Management.getFee() actual se cambia de acuerdo con el valor de dirección almacenado en la variable del administrador. El valor de la dirección almacenado en la variable del administrador actual se muestra en la Figura 6.

Sin embargo, el contrato inteligente al que apunta el valor de dirección almacenado en la variable del administrador no se ha autenticado en etherscan, por lo que es imposible conocer el código fuente del contrato inteligente y, por lo tanto, es imposible conocer la definición de la administración. función getFee().

Dado que no se puede conocer la lógica detrás de la función Management.getFee(), el propietario del proyecto puede ajustar la tarifa para cada transferencia de token manipulando el valor de retorno de la función Management.getFee() y realizar operaciones maliciosas.

Figura 3: función TransferFrom()

Figura 4: función getFee() en el contrato StandardToken 

Figura 5: Interfaz de gestión de contrato inteligente e interfaz de función getFee

Figura 6: El valor de la dirección almacenado en la variable del administrador actual

Figura 7: El contrato inteligente al que apunta el valor de la dirección almacenado en la variable del administrador actual

Todo el mundo conoce uno de los ejemplos más conocidos en 2020: después del lanzamiento del proyecto DeFi Yam a las 3:00 del 12 de agosto, hora de Beijing, aunque la publicación del blog del proyecto advirtió que no se había realizado ninguna auditoría en su contrato, el loco Yield agricultores $76 millones fueron depositados en el proyecto en menos de una hora.

Como se esperaba más tarde, Yam perdió cientos de millones de dólares en solo 36 horas debido a una pequeña laguna.

Las auditorías de seguridad ahora son estándar para proyectos DeFi de alta calidad. El auge actual de los proyectos DeFi continúa sin cesar. Con el fin de aprovechar los puntos calientes y las oportunidades, muchos proyectos se han lanzado en línea sin pruebas ni auditorías rigurosas.

En estos proyectos, la mayoría de las vulnerabilidades no se pueden encontrar mediante métodos y herramientas de prueba comunes. Esta vulnerabilidad solo se puede descubrir buscando expertos en auditoría profesionales que realicen pruebas rigurosas de modelos matemáticos. La verificación formal es actualmente el único método de verificación de software probado para producir pruebas matemáticas creíbles.

Por lo tanto, el uso de herramientas de detección de blockchain basadas en métodos formales de verificación para verificar las vulnerabilidades de seguridad en los proyectos debería convertirse en un paso necesario para cada proyecto antes de pasar a la cadena.

Cada una de las razones por las que un proyecto es atacado o pierde activos se debe a un error de código muy pequeño.

En el campo de la informática, en promedio, habrá de 1 a 25 errores en cada 1000 líneas de código. En otras palabras, esta probabilidad oscila entre uno en mil (0,1%) y dos y medio por ciento (2,5%).

¿Qué pasa con los proyectos que se han sometido a auditorías de seguridad y han pasado?

CertiK seleccionó tres empresas de seguridad que divulgan información de auditoría para estadísticas de datos.

En esta ocasión, se contabilizaron un total de 377 proyectos auditados (incluidos proyectos de auditoría repetidos) de las tres empresas.

Ocho de estos proyectos fueron pirateados a pesar de haber sido auditados al menos una vez.

Estos 8 proyectos auditados pero atacados perdieron un total de 69 millones de dólares estadounidenses.

Según los datos de estas tres empresas auditoras, se calcula la proporción de hackeados después de la auditoría: 8/377 = 2,12%

La probabilidad de un error en el código y la probabilidad de que el proyecto haya pasado la auditoría pero aún sea atacado es aproximadamente igual al 2 % Aquí hay un ejemplo simple:

Según estadísticas de SquareTrade, en Estados Unidos murieron 5.761 pantallas de teléfonos móviles en tan solo una hora. Suponiendo que el estadounidense promedio tiene un teléfono móvil, y no existe la costumbre de dejar caer el mismo teléfono móvil repetidamente. Luego, dentro de los 50 días, un chico estadounidense tiene un 2% de posibilidades de romper la pantalla de su teléfono móvil.

Pero la vida útil de un teléfono móvil debe ser de más de 50 días ¿Qué pasa si se usa durante un año? ¡Esta probabilidad ha aumentado repentinamente al 15%! ¡Después de más de tres años y medio de uso, la probabilidad supera el 50%!

Esto confirma la Ley de Murphy anterior: la inevitabilidad de los eventos de pequeña probabilidad: cuando la base de tiempo es lo suficientemente larga, las cosas malas siempre serán tu turno.

Las probabilidades de un accidente aéreo son de una en cinco millones (0,00002%).

Por el contrario, la probabilidad de que un código tenga una vulnerabilidad y la probabilidad de que un proyecto haya pasado una auditoría pero aún así sea atacado es 125 000 veces mayor que la de un accidente aéreo.

Si tiene miedo de un accidente aéreo cuando el avión está turbulento, también podría usar 100,000 veces más preocupación para proteger su proyecto.

Después de tal comparación, ¿sigues pensando que el proyecto no necesita protección adicional?

Hazlo por el futuro, gobierna el caos.

Además de la auditoría estática, la protección de seguridad dinámica puede prevenir mejor los ataques. La herramienta de seguridad dinámica desarrollada por CertiK: escaneo rápido - oráculo de seguridad - CertiKShield, desde la alerta temprana hasta la evaluación en tiempo real y el plan de seguro, puede proporcionar seguridad integral para las partes del proyecto.

Tags：

Precio de Bitcoin