Ganancias:
- Capacidad para reconocer patrones de vulnerabilidad comunes, como reentrada, control de acceso, manipulación de Oracle y ejecución frontal, y escanearlos con una herramienta de análisis estático + inteligencia artificial + humana.
- Capacidad para distinguir entre las fortalezas de la IA al explicar el resultado de la herramienta y priorizar los falsos positivos y las debilidades en MEV y la lógica empresarial.
- Comprenda que un 'análisis limpio' no es un certificado de seguridad, que el escaneo es solo una capa de control
Vimos la disciplina holística de la auditoría en la unidad anterior. En esta unidad, nos centramos en un tema más técnico: el escaneo de vulnerabilidades: la búsqueda sistemática de patrones de vulnerabilidad conocidos en el código. Aquí utilizaremos la IA, junto con herramientas de análisis estático, como asistente que escanea y describe patrones de vulnerabilidad conocidos. El objetivo: conocer en profundidad las vulnerabilidades más comunes y distinguir dónde la IA es fiable y dónde es inadecuada a la hora de escanearlas.
Escaneo estático y dinámico
El escaneo es de dos tipos. Análisis estático: examinar el código sin ejecutarlo: herramientas como Slither y Mythril escanean el código del contrato y marcan patrones conocidos. El análisis dinámico/simbólico (ejecutar el código con diferentes entradas o explorarlo matemáticamente): fuzzing (bombardear con entradas aleatorias) y ejecución simbólica (explorar todos los caminos posibles) entran en este grupo.
La IA no reemplaza estas herramientas, las complementa: cuando el vehículo emite una advertencia, la IA explica la advertencia en un lenguaje sencillo; La IA puede recordar cuando la herramienta pierde un patrón; Pero la IA por sí sola no puede garantizar cuánto escanea. El flujo de trabajo adecuado: herramienta + IA + humano.
Consejo: proporcione a la IA el resultado de una herramienta de análisis estático (por ejemplo, el informe Slither) y pregunte "explica cada alerta en un lenguaje sencillo, cuáles son riesgos reales y cuáles podrían ser falsos positivos". preguntar. La IA es invaluable para hacer que los resultados de las herramientas en bruto sean comprensibles y priorizables para los humanos.
Patrones de vulnerabilidad más comunes
1. Reentrada. Si una función llama a un contrato externo sin actualizar su estado, el contrato llamado puede retroceder, activar la misma función nuevamente y retirar el fondo varias veces. Solución: orden de controles-efectos-interacciones y guardia de reentrada.
2. Falta de control de acceso. Una función crítica (retirada, retirada, actualización) se hace pública accidentalmente. Es uno de los errores más comunes y costosos.
3. Manipulación de oráculos. La confianza ciega del contrato en una fuente externa de precios (oráculo). El atacante manipula el precio instantáneamente y engaña al protocolo. Solución: precio medio ponderado en el tiempo (TWAP), multifuente.
4. Desbordamiento/insuficiencia de enteros. Cuando un número supera el valor máximo permitido y vuelve al principio. Modern Solidity detecta la mayor parte automáticamente, pero el riesgo permanece en el código de bajo nivel (ensamblado).
5. Avanzar. Las transacciones aparecen en el grupo público (mempool) antes de ser confirmadas; El atacante puede ver su transacción e insertar la suya propia delante de ella. MEV (Valor máximo extraíble: el valor extraído de la secuencia de transacciones) es el nombre general de este tema.
6. Denegación de Servicio (DoS). Un bucle se vuelve demasiado costoso y hace que la función sea inutilizable, o se bloquea la dependencia de una dirección.
7. Riesgos de actualización. Colisión de almacenamiento y abuso de autoridad en contratos actualizables.
vulnerabilidad
Confianza en el escaneo de IA
¿Por qué?
reentrada
alto
Patrón claro y conocido
control de acceso
alto
El molde se puede escanear
Operaciones enteras
alto
control estándar
Manipulación de oráculo
medio
Requiere contexto
Marcha delantera/MEV
Medio-bajo
protocolo específico
error de lógica de negocios
bajo
Auténtico, contextual
Aviso débil / Aviso fuerte
Aviso débil:
¿Existe una laguna jurídica en este código?
Potente mensaje:
Su función: asistente de control de seguridad. Analice el contrato a continuación para ver los siguientes patrones conocidos y "en riesgo/no/inseguro" para cada uno: reentrada, control de acceso, operaciones con números enteros, dependencia de Oracle, ejecución frontal, DoS, actualización de seguridad. Vincule cada determinación con la línea correspondiente y explique por qué existe un riesgo. Estas son hipótesis que SERAN VERIFICADAS con una herramienta de análisis estático y un auditor. Tenga en cuenta que puede haber falsos positivos.
Cuatro plantillas copiables
1) Descripción de salida de la herramienta:
A continuación se muestra el informe de una herramienta de análisis estático (Slither). Explica cada alerta en un lenguaje sencillo: ¿qué significa, es un riesgo real o un posible falso positivo, cuál debe ser su prioridad? No tomes una decisión firme; Priorizar para la confirmación del auditor.
2) Detección centrada en la reentrada:
Encuentre todas las funciones que realizan llamadas externas en este contrato. Examinar si se sigue el orden de controles-efectos-interacciones para cada uno de ellos y si existe guardia de reentrada. Muestre los riesgosos con una línea. Marque si no está seguro; Generando código de explotación.
3) Mapa de control de acceso:
Enumere todas las funciones externas/públicas en este contrato y especifique "quién puede llamar" (todos/propietario/rol) para cada una. Realice operaciones críticas (retirar, imprimir, actualizar) y marcar aquellas con control de acceso débil. Preséntalo con una mesa.
4) Eliminación de falsos positivos:
Considere por qué esta advertencia de análisis podría no ser un riesgo REAL (falso positivo): ¿qué contexto o condición de código invalidaría esta advertencia? Pero no digas "no hay absolutamente ningún problema"; Enumere los puntos que necesitan confirmación.
Tres mini estuches (en números)
Caso 1: Vehículo + IA duplicaron la eficiencia. Un equipo ejecutó Slither en un proyecto de 12 contratos y recibió 140 advertencias. Una vez que hicimos que la IA explicara y priorizara las alertas, resultó que 95 de las 140 alertas eran falsos positivos; El equipo se centró en 45 candidatos reales. El tiempo de clasificación disminuyó de 2 días a 5 horas. Lección: La IA es poderosa para humanizar la producción de vehículos.
Caso 2: MEV secuestrado por IA. En un contrato DEX (intercambio descentralizado), la IA encontró que los patrones estándar estaban limpios pero no pudo detectar una vulnerabilidad frontal; porque esto era específico del orden de operaciones del protocolo. Auditor humano y simulación capturados. Lección: Los riesgos específicos del protocolo como MEV/front-running son el área débil de la IA.
Caso 3: Se evitó perder el tiempo con un falso positivo. El equipo se evitó una reescritura innecesaria cuando la IA explicó que una advertencia de reentrada era en realidad un falso positivo (la función ya estaba protegida). Pero el equipo aun así lo confirmó con una sola prueba. Lección: la IA prioriza; La confirmación vuelve a llegar con las pruebas.
Límites de escaneo
El escaneo encuentra patrones conocidos. Ni la herramienta ni la IA garantizan detectar una vulnerabilidad nueva, única o específica del protocolo. Por lo tanto, la selección es parte de la auditoría; no él mismo. La idea de que "el escaneo está limpio, por lo tanto significa que es seguro" es uno de los conceptos erróneos más peligrosos en este campo. El dragado recoge la fruta madura; Para riesgos profundos y únicos, la experiencia humana, las pruebas, la confusión y la auditoría formal son esenciales.
Precaución: un informe "limpio" de una herramienta de escaneo o IA no es un certificado de seguridad. Presentarlo de esa manera (especialmente a los inversores) es engañoso y poco ético.
Errores comunes
- Sustituir el cribado por la inspección. El escaneo es una capa, no el todo.
- Usando IA sin herramientas. Análisis estático + IA + trabajo humano juntos.
- Eliminando falsos positivos sin confirmación. Cada pantalla se prueba/verifica por humanos.
- Evitar los riesgos específicos del protocolo (MEV) confiando en la IA. El área débil de la IA.
- Pensando en "análisis limpio" = "seguro". No puede encontrar lo desconocido.
- Generando código de explotación. Sólo la descripción defensiva del riesgo es legítima.
En resumen
- El escaneo de vulnerabilidades busca patrones de vulnerabilidad conocidos con vehículo + IA + humano.
- La IA es poderosa para explicar y priorizar los resultados de las herramientas de análisis estático.
- Fiable en patrones claros como reentrada y control de acceso; Débil en MEV y lógica empresarial.
- Incluso eliminar los falsos positivos requiere confirmación.
- Un "análisis limpio" no es un certificado de seguridad; No sustituye a la supervisión.
Tarea de aplicación
Ejecute una herramienta de análisis estático en un contrato de muestra (si es posible) o busque un informe Slither ya preparado. Aplique el mensaje "descripción de salida de la herramienta" a la IA. Evalúe si la IA: (1) explica correctamente las advertencias, (2) tiene sentido para distinguir entre falsos positivos y (3) pasa por alto un riesgo específico del protocolo. Complete las columnas "vehículo encontrado / IA explicada / humano confirmado" en una tabla.
lista de verificación
- [] Coloqué el sombreado como una capa del control.
- [] Utilicé una herramienta de análisis estático + IA + humanos juntos.
- [] Busqué categoría por categoría patrones conocidos.
- [ ] Eliminé los falsos positivos con la confirmación.
- [] Confié en humanos en áreas débiles como MEV/lógica empresarial.
- [ ] No ofrecí un "barrido limpio" como garantía.
- [ ] Trabajé sólo con fines de defensa; Yo no creé exploits.