Brecha de acceso en TempleDAO StaxLPStaking

El 11 de octubre de 2022, TempleDAO perdió aproximadamente $2,3 millones (1.831 ETH) cuando un atacante explotó una comprobación de control de acceso ausente en la función migrateStake() del contrato StaxLPStaking. La función debía migrar la posición staked propia de un usuario a un nuevo contrato — pero no verificaba que el llamante fuera dueño de la posición que se migraba.

Qué ocurrió

El contrato StaxLPStaking de TempleDAO permitía a los usuarios stakear tokens LP. Incluía una función migrateStake(address oldStaking, uint256 amount) destinada a que los usuarios movieran su propio stake a un contrato de staking actualizado.

El fallo fatal: migrateStake() confiaba en los parámetros suministrados por el llamante sin verificar que el llamante fuera realmente dueño del stake que se migraba. Llamaba al migrateWithdraw del contrato de staking antiguo para una dirección arbitraria, y luego acreditaba el resultado — lo que significa que cualquier llamante podía migrar (y por tanto retirar) la posición entera de cualquier otro staker a un destino que controlara.

El ataque fue correspondientemente trivial:

1. El atacante llamó a migrateStake() especificando un destino que controlaba y el contrato de staking de TempleDAO que mantenía todos los stakes de los usuarios.
2. La función, sin la comprobación de propiedad, migró y liberó los tokens LP staked al atacante.
3. El atacante desenvolvió la posición LP y se marchó con 1.831 ETH ($2,3M).

El exploit entero fue una única transacción explotando un solo require ausente.

Consecuencias

• TempleDAO pausó los contratos afectados y se comunicó con el atacante vía mensajes on-chain.
• El equipo publicó un post-mortem identificando la validación de propiedad del llamante ausente como única causa raíz.
• Los fondos robados fueron blanqueados a través de Tornado Cash; la recuperación fue mínima.

Por qué importa

TempleDAO es uno de los ejemplos más puros del catálogo de la clase de bug "comprobación de control de acceso ausente" — distinto de la manipulación de oráculo, la reentrada o los exploits económicos. No hubo un préstamo flash ingenioso, ni manipulación de precios, ni mecanismo novedoso. Había una función que debería haber comprobado que msg.sender era dueño de la posición y no lo hacía.

La lección estructural es casi vergonzosamente simple pero recurre constantemente:

Cada función que mueve activos de un usuario debe verificar que el llamante está autorizado a mover esos activos específicos. No "¿es el llamante un usuario válido?" — "¿es el llamante dueño de la posición exacta que esta llamada afecta?"

El patrón se repite a lo largo del catálogo: TempleDAO (migrateStake), Exactly Protocol (mercado no validado), Hedgey Finance (claimLockup sin comprobar), Seneca (drenaje de Chamber). Cada uno es una función que realiza una operación privilegiada o de movimiento de fondos basada en parámetros suministrados por el llamante, sin validar la relación del llamante con los activos afectados.

Estos bugs son detectados trivialmente incluso por una auditoría superficial o por pruebas unitarias básicas de control de acceso ("¿puede la dirección B migrar el stake de la dirección A?"). La frecuencia con la que se lanzan de todas formas — particularmente en funciones de migración y periféricas escritas rápida y tardíamente — es uno de los temas silenciosos recurrentes del catálogo.