Pickle Finance - REKT

La fermentación de las finanzas continúa. Incluso los pickles tienen fecha de caducidad.

El jarrón cDAI de Pickle Finance fue hackeado por 19.7 DAI tras una vulnerabilidad que involucró falsos “Pickle Jars”.

Pickle Finance se ha convertido en la última víctima de la epidemia de hacks.

Sin embargo, esta vez, algo es distinto…

Mientras Twitter intentó lidiar con otra fatalidad financiera, rekt comenzó a investigar.

Contactamos al equipo de Stake Capital, quien vio el código y nos advirtió que otros jarrones podrían estar en riesgo.

Contactamos entonces rápidamente al equipo Pickle Finance y montamos un war room entre miembros de Stake Capital (@bneiluj, @vasa_develop), de Yearn (@bantg), de Pickle Finance y desarrolladores experimentados (@samczsun, @emilianobonassi).

Conforme trabajábamos se volvió claro que estábamos viendo algo muy diferente a los últimos hacks de estilo DeFi lego de las semanas pasadas.

Esto no fue un arb.

El agresor tenía excelente conocimiento de Solidity y EVM, y probablemente había estado prestando atención al código de Yearn por bastante tiempo, ya que la vulnerabilidad fue similar a la descubierta en el código de Yearn un mes antes.

Pickle Jars son, en esencia, un fork de los yVaults de Yearn. Estos Jars son controlados por un contrato llamado el Controller, que tiene una función que permite a los usuarios canjear sus activos entre Jars.

Desafortunadamente, no hay una whitelist para aquellos Jars que tienen permiso para usar esta función de canje.

El hacker había creado un Pickle Jar falso y canjeó los fondos del jarrón original. Esto fue posible porque swapExactJarForJar no revisó los jarrones “whitelisted”.

El equipo de Pickle Finance sabía que necesitaba ayuda, y estaban más que dispuestos a trabajar con los otros para prevenir cualquier daño futuro.

Pickle había intentado llamar “withdrawAll”, pero la transacción falló.

La solicitud de retirada tuvo que pasar a través de la Governance DAO que tenía un timelock de 12 horas.

Solo uno de los miembros del multisig de Pickle tenía el poder de saltarse el timelock, y estaba dormido.

Esto significó que los admins no podían vaciar los Pickle Jars, pero esto no los protegió de otro hack.

Pickle Finance y Curve emitieron alertas diciendo a sus usuarios que retiraran inmediatamente sus fondos de Pickle, aun así, $50 millones permanecieron en Pickle Jars que fueron potencialmente vulnerables, mientras el equipo white hat investigaba el exploit y verificaba la seguridad de los fondos remanentes.

El equipo de rescate tenía que despertar al admin dormido, o vaciar los jarrones ellos mismos.

El equipo tenía que superar cinco grandes desafíos.

1. Juntar el equipo Pickle Finance tras varios husos horarios para comenzar a rescatar los fondos poniendo las transacciones hacia un timelock de 12h (vía 3 de 6 multisig) para retirar fondos.
2. Lograr que miles de inversores retiraran sus fondos (y disuadirlos de redepositar una vez que el TVL de la pool bajó y el APY se infló a 1000+% APY).
3. Realizar revisiones de seguridad en los otros jarrones para ver si había alguna posibilidad de otros ataques.
4. Replicar el ataque y whitehacking antes de que alguien pudiera hackear los jarrones de nuevo.
5. Evitar ser front-runned al tratar de rescatar los 50k restantes.

¿Cuánto más podemos seguir dependiendo en los pseudoanónimos white hat hackers para ayudarnos?

Los incentivos son claramente más alineados hacia los agresores que a los protectores; ¿por qué coordinarían un contraataque tan extenuante?

La gloria va para los whitehacks, y el dinero va para los hackers. Esto no es sustentable.

¿Cuánto tardará la tentación en convertir a estos white hats en black?

Análisis

Al lanzar esta información técnica somos conscientes de que podríamos estar provocando nuevos hacks. Discutimos las consecuencias potenciales con Pickle Finance y otros desarrolladores, y confirmamos que no sabemos de ningún fork operacional que podría ser afectado por ataques imitadores.

La revelación selectiva introduciría un aspecto de responsabilidad, así que decidimos publicar libremente esta información. Si algún protocolo está operando un fork del código de Pickle, ya deben de ser conscientes de los eventos en proceso y estar tomando acciones preventivas en contra de ataques imitadores.

El siguiente esquema fue creado por @vasa_develop.

El archivo original puede encontrarse aquí.

Para más detalles, puedes ver el post-mortem completo del equipo aquí.

Será interesante ver como el relativamente nuevo primitivo de seguro “Cover Protocol” maneja este incidente; una gran cantidad para su primera reclamación. El voto en snapshot para la reclamación del seguro puede encontrarse aquí.

El pickling es un proceso lento.

Por décadas, evangelistas del ágil desarrollo han dicho a los desarrolladores que aceleren, fallen rápido, y lancen el producto viable mínimo. Estas ideas no aplican cuando desarrollas en un ambiente hostil.

Fallar rápidamente en DeFi implica un gran costo.

No necesitamos simplemente otra metodología. Necesitamos un cambio de paradigma que permita la iteración rápida mientras reduce la probabilidad de quedarse rekt a la vez.

Eliminemos la idea de que una auditoría es garantía de seguridad. Es - la mayoría de las veces - un panorama limitado de medidas genéricas de seguridad aplicadas a objetivos dinámicos que en muchas ocasiones han evolucionado en algo más inmediatamente después de que el proyecto llega a mainnet.

Las auditorías de MixBytes (3 de octubre) y Haechi (20 de octubre) fueron completadas antes de la adición de ControllerV4 (23 de octubre), que fue uno de los vectores clave del ataque.

Los grandes equipos en el futuro de las finanzas serán aquellos capaces de manejar los dilemas entre lanzar rápido y lanzar seguro, continuamente auditando y probando rigurosamente sus robots de dinero componibles con regularidad.

Las auditorias deben de ser un proceso regular y continuo, no solo poner palomitas en una lista antes del lanzamiento. Los nuevos protocolos DeFi son sujetos a constantes cambios y adaptaciones y las auditorías de seguridad deben de reflejar esto.

Los pickles sólo se conservan frescos dentro del jarrón…

foto @martinkrung

FE DE ERRATAS - 18 Julio 2021

Haechi nos contacto con la siguiente declaración:

Auditamos una parte de los contratos de Pickle, pero el exploit ocurrió en smart contracts ya actualizados. El smart contract con el exploit fue “swapExactJarForJar” en “controller-v4.sol”, y nuestro rango de investigación de la auditoría fue “controller-v3.sol” sin “swapExactJarForJar”. Se pueden encontrar los detalles aquí. Para que sepas, confirmé que tu equipo mencionó que nuestro auditoría para pickle finance fue completada antes de la adición del ControllerV4 que fue el vector de ataque para este hack.

Se pueden encontrar los detalles aquí.

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.