Análisis completo de los eventos de vulnerabilidad de la Red Bancor

1. Breve descripción del evento

El 18 de junio de 2020 (la hora mencionada en el artículo es la hora UTC), el contrato inteligente Bancor Network en Ethereum estuvo expuesto a tener lagunas graves. La vulnerabilidad fue descubierta primero por el equipo de Bancor Network y el white hat, e inmediatamente transfirieron fondos que estaban en riesgo de ser robados, involucrando más de 500,000 dólares estadounidenses.

En este incidente, las direcciones del contrato con vulnerabilidades incluyen principalmente las siguientes tres:

0x923cab01e6a4639664aa64b76396eec0ea7d3a5f

0x8dfeb86c7c962577ded19ab2050ac78654fea9f7

0x5f58058c0ec971492166763c8c22632b583f667f

A las 3:06:48 del 18 de junio de 2020, el equipo de la Red de Bancor utilizó esta vulnerabilidad para transferir fondos de usuarios que estaban en riesgo de ser robados. A las 6:56 del 18 de junio de 2020, el equipo de la Red de Bancor había transferido un total de aproximadamente $409,656.

Otras dos direcciones de correo electrónico públicas:

0x052ede4c2a04670be329db369c4563283391a3ea

0x1ad1099487b11879e6116ca1ceee486d1efa7b00

Al mismo tiempo, esta vulnerabilidad también se utilizó para transferir fondos de usuarios, transfiriendo fondos de $131,889 y $2346 respectivamente.

Hasta ahora (2020-06-19):

EtherScan ha marcado el contrato con esta vulnerabilidad, como se muestra en la siguiente figura

El equipo de Red Bancor también ha respondido al incidente,

Cynthia Lummis: Es probable que el proyecto de ley regulatorio de cifrado no se considere hasta el próximo año: Golden Finance informó que Watcher.Guru dijo en las redes sociales que la senadora estadounidense Cynthia Lummis dijo que es probable que el proyecto de ley regulatorio de cifrado no se considere hasta el próximo año. [2022/7/20 2:25:32]

Ver para más detalles

https://blog.bancor.network/bancors-response-to-today-s-smart-contract-vulnerability-dc888c589fe4 

E implementó un nuevo contrato de Red Bancor a las 2020-06-17 21:35:53 hora UTC, la dirección del contrato es

0x2f9ec37d6ccfff1cab21733bdadede11c823ccb0

2. Análisis de principios

Después de que estalló la vulnerabilidad, el equipo de seguridad de Chengdu Chain Security rastreó y analizó el incidente por primera vez. De acuerdo con los resultados del análisis en la cadena, se encontró que la razón principal de la vulnerabilidad en este incidente fue que el contrato inteligente Bancor Network tenía una autoridad de llamada pública.La función safeTransferFrom, al llamar a esta función, los fondos autorizados por el usuario al contrato inteligente Bancor Network se pueden transferir a cualquier dirección.

Se puede ver en el código fuente que esta función es una función pública, y el código detallado se muestra en la siguiente figura:

La función de ejecución se llama dentro de la función safeTransferFrom. La función de la función de ejecución es llamar a la función transferFrom del contrato inteligente de token _token en el parámetro safeTransferFrom para realizar transferencias de proxy. El código fuente de la función de ejecución se muestra en la siguiente figura:

Lanzamiento del grupo de trabajo de estandarización de identidad de IEEE Blockchain IoT: según las noticias del 14 de diciembre, de acuerdo con la presentación del Dr. People, están desarrollando un estándar global para la identidad descentralizada basada en blockchain. (cointelegraph) [2021/12/14 7:39:20]

Podemos ver claramente el efecto específico de llamar a esta función a través de una transacción en cadena. Por ejemplo, la dirección "0xc802" inicia una transacción, llamando a la función safeTransferFrom del contrato inteligente "0x5f58" (es decir, Bancor Network), para que el token MFG 0.000000000000000003 en la dirección "0x8a39" se envíe a "0x2955" ("Red Bancor" en la figura) : White Hat S...), tal como se muestra en la siguiente figura:

Lo anterior es el análisis del principio de la vulnerabilidad en este incidente. El principio de la vulnerabilidad es muy simple. Se debe a que la autoridad de llamada de la función está configurada incorrectamente, y la función que solo debe ser llamada por el contrato en sí es configurado para ser llamado por cualquier persona. Y cuando Bancor Network tiene la cuota autorizada del usuario, cualquiera puede transferir los fondos del usuario como agente de Bancor Network llamando a la función safeTransferFrom.

Para esta vulnerabilidad, hay dos puntos dignos de nuestro análisis en profundidad:

1. Por qué la función safeTransferFrom del contrato de red de Bancor establece el permiso como público.

2. La función principal del contrato de Red  Bancor es la conversión de tokens, no un monedero ¿Por qué los usuarios tienen autorizaciones sin usar?

Para la primera pregunta, rastreamos la llamada de la función safeTransferFrom y descubrimos que la función safeTransferFrom solo se llama en la función handleSourceToken para transferir los tokens del usuario a este contrato. El código fuente de la función handleSourceToken se muestra en la siguiente figura:

Dado que solo se llama en la función handleSourceToken, obviamente no es necesario configurarlo como un permiso público y, según el negocio, la función principal de Bancor Network es para el intercambio de tokens, y no requiere que el usuario participe activamente. llame a safeTransferFrom, por lo que no es necesario configurar safetransferFrom como permiso público. Así que comparamos varias otras funciones en el contrato, y todas estas funciones están configuradas con permisos públicos. Como se muestra abajo:

Por lo tanto, para la primera pregunta, especulamos que establecer estas funciones como permiso público puede deberse al contrato. supervisión del desarrollador. En la actualidad (2020-06-19), el contrato recién desplegado por el equipo de Red de Bancor también verificó esta especulación. Según el código de la cadena, el nuevo contrato implementado oficialmente ha cambiado todos los permisos de funciones relevantes (aunque otras funciones no tienen nada que ver con este evento). El código específico se muestra en la siguiente figura:

Para la segunda pregunta, rastreamos las direcciones a las que se transfirieron los fondos después de que estalló la vulnerabilidad y descubrimos que estos direcciones Al autorizar la cantidad de Bancor Network, muchas veces supera la cantidad de tokens que se necesita cambiar, y luego de que se completa el intercambio, la cantidad no se recupera. Como se muestra abajo:

La dirección que comienza con "0x624f" ha autorizado 9000000000000000 tokens ONG al contrato Red Bancor. Esta cantidad ha superado la circulación de ONG, lo que equivale a autorizar todos los tokens ONG propiedad de "0x624f" al contrato Red Bancor. Mientras rastreamos la transacción en la dirección que comienza con "0x624f", encontramos que después del intercambio de tokens, toda la cuota autorizada no se agotó, pero la cuota autorizada no se recuperó.

Para resumir, especulamos que el usuario puede haber autorizado todos los tokens al contrato de la Red Bancor en un momento por conveniencia en consideración de usarlos en cualquier momento. También puede ser que el front-end de Bancor Network haya establecido un valor predeterminado para el monto autorizado. Sin embargo, existe un gran riesgo en este comportamiento: una vez que surge una vulnerabilidad en el contrato inteligente, los atacantes roban fácilmente los fondos. Al analizar los nuevos contratos posteriores de la Red Bancor, se encontró que el equipo y los usuarios de la Red Bancor parecían ser conscientes de los enormes riesgos de este problema y tomaron las medidas de seguridad correspondientes. Las Figuras 9 y 10 a continuación muestran la autorización del usuario para el nuevo contrato. Comparando las dos transacciones en línea, no es difícil ver que el intervalo de tiempo entre las dos autorizaciones es muy corto. Cuando el usuario canjea con éxito los tokens, la autorización restante ser retirado

3. Conclusión

La vulnerabilidad expuesta por Bancor Network esta vez es una vulnerabilidad relativamente simple. Este tipo de vulnerabilidad es muy fácil de descubrir durante el proceso de auditoría de código. Más de 50w dólares estadounidenses. Afortunadamente, el equipo de Bancor Network descubrió y solucionó la vulnerabilidad a tiempo, de lo contrario las consecuencias serían desastrosas. El equipo de investigación de Chengdu Lianan-Security recuerda por la presente a los principales operadores de contratos inteligentes que, debido a las características inmutables de los contratos de cadena de bloques después de la implementación, en comparación con el software tradicional, es muy importante realizar una auditoría completa del código antes de conectarse. está obligado a hacer que los usuarios cuestionen la seguridad de los productos del equipo de red de Bancor. Además, también se recuerda a los usuarios y operadores que deben ser cautelosos al autorizar fondos para contratos de terceros, y no deben confiar ciegamente en las "grandes empresas". La autorización de cualquier contrato debe apegarse al principio mínimo, y no dejar que sus los fondos propios se controlen de forma segura en manos de otros.

Tags：

OKX Exchange