Drenaje por aprobaciones en Seneca Chamber

El 28 de febrero de 2024, el protocolo de stablecoins Seneca perdió $6,4 millones drenados de usuarios que habían concedido aprobaciones ilimitadas de tokens al contrato Chamber del protocolo. El contrato no tenía función Pausable — cuando se identificó el ataque, el equipo no tenía manera de detenerlo en curso. El atacante devolvió el 80% de los fondos robados por una recompensa de bug del 20%.

Qué ocurrió

El contrato Chamber de Seneca era una ruta privilegiada que manejaba movimientos de tokens en nombre de usuarios que habían aprobado a Seneca para gastar sus tokens. Al contrato le faltaba una validación crítica: aceptaba parámetros suministrados por el llamante que determinaban de quién mover tokens y a dónde enviarlos, sin verificar que la operación estuviera autorizada por el usuario afectado.

Para los usuarios que habían concedido al contrato Chamber de Seneca aprobaciones ilimitadas de tokens — el patrón estándar para cualquier protocolo DeFi que necesita mover tokens del usuario de forma rutinaria — la validación ausente significó que cualquier llamante podía:

1. Identificar una billetera con una aprobación ilimitada activa a Seneca.
2. Llamar a la función vulnerable de Chamber con la dirección de la víctima como origen y la dirección del atacante como destino.
3. Drenar directamente los tokens aprobados de la víctima.

El ataque barrió ~$6,4M a través de múltiples billeteras víctima en una ventana corta.

Agravando el fallo: el contrato de Seneca nunca había implementado el patrón Pausable — una primitiva estándar de OpenZeppelin que permite al admin de un protocolo pausar funciones específicas o el contrato entero en caso de emergencia. Cuando el equipo se percató del exploit en curso, no tenían manera de detenerlo. El drenaje continuó durante toda la duración que el atacante eligió operar.

Consecuencias

• Seneca interactuó públicamente con el atacante ofreciendo una recompensa de bug del 20% por la devolución de fondos.
• El 29 de febrero, el atacante devolvió aproximadamente 1.537 ETH (~$5,3M) a una dirección de recuperación controlada por Seneca, quedándose con 300 ETH (~$1M) como recompensa.
• Seneca pausó las operaciones — recomendando a los usuarios revocar todas las aprobaciones al contrato Chamber, ya que el propio protocolo no podía pausarse.
• El equipo lanzó un protocolo rediseñado con controles Pausable adecuados y validación de parámetros; la recuperación de confianza más amplia fue desigual.

Por qué importa

El incidente de Seneca es el ejemplo de libro de texto de por qué las funciones de pausa de emergencia no son opcionales para cualquier protocolo que mantenga aprobaciones de usuarios. El patrón Pausable es:

• Documentado en la biblioteca estándar de contratos de OpenZeppelin.
• Disponible como un modificador de una sola línea que protege cualquier función.
• Trivial de implementar en el momento del despliegue.

Sin embargo, había sido omitido del contrato de Seneca — muy probablemente como decisión de diseño deliberada para maximizar la "descentralización" eliminando puntos de control administrativo. El coste de esta decisión fue que el equipo se convirtió en espectador durante un drenaje activo de los fondos de sus usuarios.

Las lecciones estructurales:

1. La descentralización como justificación de diseño para saltarse controles de seguridad es un patrón recurrente que produce pérdidas recurrentes. El compromiso — "sin pausa de admin" vs "los usuarios absorben el impacto total de cada bug" — rara vez se enmarca con esta claridad al usuario en el momento del depósito.

2. Los protocolos basados en aprobaciones heredan la responsabilidad de ser pausables de forma segura porque cada usuario que los aprobó está expuesto a cada bug futuro. El estándar para estos protocolos debería ser más alto, no más bajo, que para protocolos con exposición acotada.

3. El retorno del 80% es uno de varios casos recientes en los que los atacantes han optado por negociar en lugar de blanquear — probablemente porque la forensía on-chain se ha vuelto lo suficientemente buena como para que liquidar completamente un exploit de $6M sea arriesgado y lento. La recompensa efectiva del atacante de $1M en una operación de $6,4M puede haber sido la elección racional.

Los protocolos modernos cada vez más se lanzan con Pausable + multi-firma de emergencia + interruptores controlados por la comunidad como estándar. La pérdida de Seneca es uno de varios incidentes que convirtieron estos patrones en práctica obligatoria en lugar de algo deseable.