Hay decenas de miles de elementos de seguridad de contrato inteligente, la primera configuración de permiso de acceso

Introducción: "Aunque la gente Pao no cura a los Pao, los cadáveres y los deseos no van más allá de los Zunzu y los reemplazan".  -- "Zhuangzi·Xiaoyaoyou"

En la antigüedad, había un líder destacado llamado Tang Yao. La gente de la zona que gobernaba vivía y trabajaba en paz y contenta, pero escuchó que el ermitaño Xu You tenía mucho talento, por lo que tuvo la idea de ceder el liderazgo a Xu You. Pero Xu You se negó y dijo algo como esto: "El reyezuelo anida en la profundidad del bosque, pero solo en una rama." Hasta ahora, las generaciones posteriores también han usado el término Yuezudaidai para expresar el significado de autoridad superior.

"Yue Zu actuando como sustituto"

Hay permisos de acceso en la implementación de contratos inteligentes.Si la configuración de los permisos no es razonable, es fácil provocar que los contratos inteligentes sean atacados e incluso causar grandes pérdidas económicas. Chengdu Lianan-Security Lab tiene una gran experiencia y acumulación en la seguridad de contratos inteligentes, pero a medida que la tecnología blockchain recibe cada vez más atención, la cantidad de contratos inteligentes también aumenta y los contratos inteligentes que siguen son atacados. Cada vez hay más incidentes, lo que también nos permite sentir cuán importante es la misión corporativa de "hacer que la cadena de bloques sea más segura”, pero es difícil luchar contra todas las amenazas por nosotros mismos. A continuación, acumularemos nuestra propia experiencia en seguridad a través de la combinación con el campo de tiro CTF de contrato inteligente. ethernaut, cómo lograr códigos más seguros en el proceso de desarrollo se popularizará entre la mayoría de los desarrolladores de contratos inteligentes a través de la serialización técnica.

Ahora hablemos de la primera pregunta Fallback of the ethernaut shooting range, el evento de la función de código "sobrepasando la marca".

Vulnerabilidad de violación de autoridad significa que en un contrato inteligente, debido a una configuración de visibilidad de función incorrecta o falta de verificación efectiva de la función, los usuarios que no pudieron llamar a una determinada función llamaron con éxito a la función directamente o omitiendo la verificación. Esta vulnerabilidad se puede explotar sola o combinada con otras vulnerabilidades para ataques combinados. El método de explotación es simple y el impacto de la vulnerabilidad depende de la función con la vulnerabilidad, lo que puede causar un golpe devastador al contrato.

2.1 "Zu" y "Pa" en el contrato

¿Cómo entender el "zu" y el "pao" en el contrato? Primero mire un fragmento de código de contrato, como se muestra en la siguiente figura:

Este fragmento de código de contrato proviene de la primera pregunta Refugio del campo de tiro ethernaut. Para el problema en el campo de tiro, la idea de resolver el problema es activar el propietario = msg.sender; llamando a la función de devolución de llamada función () payable public, para que el propietario del contrato se convierta en la persona que llama. El tema es muy simple, siempre que se inicie una transacción para este contrato y se cumpla la condición de requisito, se puede activar la función de reserva.

Normalmente, en una llamada de contrato, si ninguna otra función coincide con el identificador de función dado, o si no se proporcionan datos adicionales, se ejecutará la función de reserva. Generalmente se usa como la operación predeterminada para transferir ether. Por lo tanto, generalmente no es necesario escribir propietario = msg.sender en la función de respaldo durante el desarrollo del contrato inteligente. Como se muestra abajo:

Sin embargo, own=msg.sender, que no debe ser llamado por el usuario, se llamó aquí, lo que resultó en un control de autoridad inadecuado y un exceso de autoridad, y la siguiente historia de "Zu" y "Pao" sucedió de esta manera.

2.2 Incidentes de seguridad relacionados

2.2.1 Eventos del contrato Bancor

El 18 de junio de 2020, la red de Bancor (0x5f58058c0ec971492166763c8c22632b583f667f) estuvo expuesta a tener vulnerabilidades. El motivo de la vulnerabilidad es que existe un método público safeTransferFrom en el contrato, por lo que el atacante puede llamar directamente a este método para autorizar la transferencia de tokens en el contrato de red de Bancor a cualquier cuenta.

Sus tres permisos de función sobre transferencia y autorización son públicos, lo que permite que cualquier usuario pueda llamarlos. Este incidente involucró fondos de más de 500.000 dólares estadounidenses. El código detallado se muestra en la siguiente figura:

El "traidor" del método safeTransferFrom con la autoridad pública no obtuvo el permiso del "rey" del contrato Bancor, y directamente le quitó el "poder financiero" al "país". Afortunadamente, el equipo de la red de Bancor y los sombreros blancos descubrieron primero este problema y transfirieron los fondos. La vulnerabilidad también fue reparada en el seguimiento para evitar pérdidas. Para un análisis detallado, consulte (https://mp.weixin.qq.com/s/vN1bNLqdvr8JEqq9QI0X1Q)

El mismo incidente ocurrió en otro contrato. A continuación, presentaremos el incidente de vulnerabilidad del contrato VETH a fines de junio.

2.2.2 Eventos del proyecto VETH

El 30 de junio de 2020, el proyecto VETH estuvo expuesto a vulnerabilidades. En este incidente, el protagonista de "pasar la factura" es el modificador externo del cambio de función Excluida en el contrato.

El modificador externo permite que cualquier persona llame a la función changeExcluded para omitir la verificación del monto de la transferencia autorizada dentro de la función transferFrom y robar los tokens VETH del contrato.

En este incidente, los atacantes utilizaron esta vulnerabilidad para robar 919 299 VETH y luego los vendieron en grandes cantidades, lo que resultó en una pérdida instantánea del valor de los tokens VETH. Para obtener detalles, consulte (https://mp.weixin.qq.com/s/plbSmpMfvIk_A457GoUaQA) El código de contrato involucrado se muestra en la siguiente figura:

A través de los dos casos anteriores, creo que todos se han dado cuenta del grave impacto del evento de "superar el Zu" en el contrato, entonces, ¿cómo distinguir efectivamente entre "zu" y "pao" en el proceso de redacción del código del contrato?

2.3 Secretos de la información de "Zu" y "Pao" revelada

Para eventos no autorizados, los desarrolladores de contratos primero deben comprender la visibilidad de la función.

Existen cuatro tipos de visibilidad de funciones: externa, pública, interna y privada:

Externo

Las funciones externas son parte de la interfaz del contrato, lo que significa que podemos llamarlas desde otros contratos y transacciones. Una función externa f no se puede llamar desde dentro (es decir, f no funciona, pero this.f() sí). Las funciones externas a veces son más eficientes cuando se reciben grandes cantidades de datos, ya que los datos no se copian de los datos de llamada a la memoria.

Público

Las funciones públicas son parte de la interfaz del contrato y se pueden llamar internamente o mediante mensajes. Para las variables de estado público, se genera automáticamente una función getter (ver más abajo).

Interna

Solo se puede acceder a estas funciones y variables de estado internamente (es decir, desde el contrato actual o los contratos derivados de él), no se pueden llamar usando this .

Privado

Las funciones privadas y las variables de estado solo se usan dentro del contrato en el que están definidas actualmente y no se pueden usar en contratos derivados.

Al construir una función, los desarrolladores deben seguir esta visibilidad para el desarrollo. Es necesario aclarar qué funciones son "Zu" que pueden ser llamadas por los usuarios y qué funciones son "Zu" que no pueden ser reemplazadas arbitrariamente en el contrato.

Por ejemplo, una función safeTransfer está diseñada para operaciones de transferencia.Los usuarios pueden transferir tokens emitidos por este contrato llamando a esta función. Podemos usar public y external para cumplir con los requisitos, pero desde el punto de vista de la seguridad, debemos usar external para evitar llamar a esta función en el contrato, lo que genera riesgos impredecibles. Si hay una función safeTransferFrom, el usuario puede transferir otros tokens a una dirección específica autorizando otros tokens a este contrato. Cuando _token es igual al contrato en sí, la función sadeTransfer se llamará como el contrato en sí, es decir, Transferir el dinero en el contrato a otras direcciones.

Sin embargo, no es suficiente seguir la visibilidad de la función. La visibilidad de la función solo distingue la contrato interno Los tres límites del contrato de herencia y el externo están lejos de satisfacer nuestras necesidades. Para lograr una gestión de derechos más completa, debemos introducir el concepto de "roles", tales como: administradores, usuarios ordinarios, usuarios privilegiados, etc. Almacene las direcciones de estos roles en el contrato y controle los permisos juzgando las direcciones o las variables de marca. Como se muestra abajo:

Estos "roles" diferentes se administran a través de decoradores, como usar el decorador onlyOwner para restringir direcciones específicas para llamar a esta función. Gestión de permisos correspondientes a "rol". Al usar el decorador, puede juzgar más claramente si hay un defecto.

En lo que respecta al estado actual de la cadena, existen muchas lagunas causadas por la gestión incorrecta de los permisos de contratos inteligentes, incluidos muchos "proyectos famosos", y las pérdidas causadas por tales lagunas también son enormes. Basado en años de experiencia en auditoría de contratos y seguridad de análisis en cadena, el equipo de seguridad de Chengdu Lianan brinda las siguientes sugerencias:

1. Siguiendo el principio de desarrollo de privilegios mínimos, la visibilidad debe planificarse al diseñar funciones.

2. Establezca un mecanismo de roles y utilice decoradores para administrar los permisos de cada función para evitar errores.

3. Antes de conectarse, debe encontrar una organización profesional para realizar una auditoría de código. Como dice el refrán, "una persona tiene un cerebro y no hay discusión sobre cómo hacer las cosas; diez personas tienen diez cerebros y hay muchos de los métodos".

Tags：

Tron