Exploits de contratos y protocolos

Un exploit de protocolo rara vez es un bug en el sentido romántico. Es un contrato ejecutando sus reglas ante una entrada que nadie modeló: un precio movible, un patrocinador que paga cualquier cosa, una delegación que sobrevive a su propósito.

Cómo funciona este vector

Los casos comparten estructura: una suposición escrita en el código, un atacante que lee mejor que los revisores y una ventana medida en bloques. Dos son incidentes repetidos, lo que es una lección aparte sobre remediación.

  • La suposición — Se confía en un feed de precios, en quien llama, en un patrocinador de gas ilimitado. Es invisible porque nunca se escribió como suposición.
  • La manipulación — Capital de flash loan, una secuencia de llamadas diseñada o una cuenta delegada vuelven falsa esa suposición durante un bloque.
  • La reincidencia — El parche corrige el síntoma. La clase de bug permanece y semanas después el mismo protocolo cae de nuevo.

Señales de alerta que puedes comprobar en un minuto

Cualquiera de estos puntos basta para parar y verificar antes de firmar, enviar o instalar algo. El contrato funcionó perfectamente. Ese era el problema.

  • Una única fuente de precio, o un oráculo con poca liquidez detrás.
  • Patrocinio de gas o abstracción de comisiones sin límites por usuario.
  • Un alcance de auditoría que excluye el módulo que mueve el dinero.
  • Un incidente previo cuyo post-mortem prometió cambios de proceso y no de código.
  • Funciones de administración accesibles sin timelock.

Si ya ocurrió

El orden importa más que el pánico: primero contén la billetera, después conserva las pruebas y por último reporta. Los servicios de recuperación que te escriben después son la segunda estafa.

  • Retira de los pools afectados antes de que caigan las liquidaciones secundarias.
  • Revoca aprobaciones al contrato explotado, incluido cualquier router delante de él.
  • Registra tu posición en el bloque del incidente: los reembolsos se calculan por snapshot.
  • Lee el post-mortem buscando la clase de bug, no el parche: la clase predice el próximo incidente.

Vectores y herramientas relacionadas

La mayoría de los casos reales mezcla dos vectores: lee los hubs vecinos y pasa cualquier cosa sospechosa por el detector antes de actuar.