Cómo encontrar vulnerabilidades de contrato inteligente antes de que ocurra la explotación

Tabla de enlaces

Resumen y 1. Introducción

2. Fondo

   2.1 Ethereum Primer

   2.2 Verificación de dirección blanca

   2.3 Análisis de mancha en contratos inteligentes y modelo de amenaza 2.4

3. Ejemplo y desafíos motivadores

   3.1 Ejemplo motivador

   3.2 Desafíos

   3.3 Limitaciones de las herramientas existentes

4. Diseño de averificador y descripción de 4.1

   4.2 Notaciones

   4.3 Componente#1: Grapher de código

   4.4 Componente#2: Simulador EVM

   4.5 Componente#3: Detector de vulnerabilidad

5. Evaluación

   5.1 Preguntas experimentales de configuración e investigación

   5.2 RQ1: efectividad y eficiencia

   5.3 RQ2: Características de los contratos vulnerables del mundo actual

   5.4 RQ3: detección en tiempo actual

6. Discusión

   6.1 amenazas a validez y limitaciones 6.2

   6.3 Consideración ética

7. Trabajo relacionado

8. Conclusión, disponibilidad y referencias

5.4 RQ3: detección en tiempo actual

Nuestro objetivo es implementar avverificador como detector en tiempo actual. Por lo tanto, medimos varias métricas de rendimiento (ver §5.4.1). Además, damos un estudio de caso para ilustrar cómo un averificador puede detectar una vulnerabilidad antes de un ataque (ver §5.4.2).

5.4.1 Análisis cuantitativo

Medimos dos métricas de rendimiento del mundo actual. Primero, comparamos la tasa de creación de contratos a lo largo de la generación de bloques con el rendimiento del averificador, que puede arrojar luz sobre la capacidad de respuesta y la aplicabilidad en tiempo actual del averificador. En segundo lugar, ilustramos la correlación entre la longitud del código de byto y el tiempo consumido tomado para el análisis. Esta métrica indica la escalabilidad del averificador con la creciente complejidad y tamaño de los contratos.

Tasa de creación de contrato versus detección. Dirigimos nuestra atención a los datos de noviembre de 2022 a enero de 2023, un período

de tiempo cuando los contratos se implementan fuertemente (ilustrados en la Fig. 3). Según nuestras estadísticas, estos tres meses cubren bloques con la altura de 15,870,000 a 16,518,000, lo que representa 289,238 contratos desplegados. En otras palabras, el contrato de 0.45 se implementa en promedio dentro de cada bloque. En cuanto a BSC, según un navegador BSC ampliamente conocido, BSCSCan [15]podemos calcular que se genera un bloque cada 3s, y hay 2.1 contratos implementados en cada bloque BSC en promedio. Según los resultados en RQ1, cada contrato de Ethereum toma alrededor de 6.42s. Por lo tanto, teniendo en cuenta el número de contrato implementado en cada bloque y la velocidad de la generación de bloques en Ethereum, se puede utilizar un procesador de un solo núcleo para implementar avverificador como detector en tiempo actual. En cuanto a BSC, cada bloque gasta alrededor de 6.42s × 2.1 = 13.48smayor que el tiempo tomado por la generación de bloques. Sin embargo, las metodologías adoptadas por Avverifier pueden ser paralelas fácilmente, como analizar múltiples funciones sospechosas simultáneamente. Por lo tanto, una máquina de múltiples núcleos es suficiente.

Escalabilidad. Para evaluar la escalabilidad del averificador, mostramos aleatoriamente 1,000 contratos de los implementados en el último año. La Figura 6 presenta la relación entre la longitud del código de byto y el tiempo consumido. Claramente, no existe una correlación lineal o incluso una exponencial entre estas dos métricas. También podemos observar que la mayoría de los casos se pueden terminar dentro de los años 20. Una eficiencia de detección tan alta se puede atribuir a dos puntos. Por un lado, la lógica de detección es muy eficiente. Por ejemplo, el detector puede detectar funciones sospechosas de manera efectiva y puede detener el análisis en el tiempo cuando se encuentra una vulnerabilidad. Por otro lado, el método de detección tiene pocos cuellos de botella de rendimiento. A diferencia de las técnicas de ejecución simbólica estática, el simulador puede atravesar caminos que podrían conducir a vulnerabilidades de manera rápida y precisa. Por lo tanto, el tiempo gastado de averificador en cada caso no es directamente proporcional a la longitud del código de byto, lo que ilustra su escalabilidad.

5.4.2 Estudio de caso: un caso de advertencia temprana del mundo actual

Ilustramos un caso del mundo actual que se marca como weak cuando el averificador se implementa como un detector en tiempo actual en BSC. Como no hay código fuente para el caso, el Listado 4 ilustra su versión descompilada. Además, debido al principio de no divulgación, hacemos un ligero cambio sintácticamente sin modificar su semántica unique.

Como podemos ver, L2 indica que el VARG2 es una dirección que se pasa del entorno externo (satisfactorio P1). En L3, la función invoca slip, que toma el VARG2 como la dirección de destino (satisfactoria P2). Luego, en L4, un requerir verificación del valor devuelto (satisfactorio P3). Finalmente, en L5, el contrato invoca la transferencia a Tokens de transferencia a la dirección referida por VARG0. Por lo tanto, los atacantes pueden implementar un contrato para evitar la verificación en V0 para drenar este contrato.

En explicit, detectamos esta vulnerabilidad el 18 de mayo de 2023 a las 6:10 UTC. Se inició una transacción de ataque 1.5 horas después, a las 7:41 UTC. Tal brecha de tiempo destaca esa capacidad de averificador. Sin embargo, la ausencia de un mecanismo de respuesta de exploit automatizado dentro de Avverifier impidió una intervención oportuna, lo que llevó a una pérdida de usuario de $ 30k USD. Este incidente subraya la importancia de diseñar una herramienta de respuesta automatizada para mitigar posibles daños financieros resultó de la vulnerabilidad de verificación de direcciones.