Furucombo - REKT

Más vale esperar que lanzar el golpe y fallar.

Nos enteramos de Furucombo pero teníamos las manos atadas - los equipos pequeños no siempre entregan a tiempo, especialmente cuando los hackers trabajan horas extras. Si eres un detective DeFi con talentos por compartir, ponte en contacto con nosotros y cuéntanos un poco de tu experiencia - puede que tengamos un puesto para ti aquí en rekt.news.

Un hacker lanzó un contraataque, rompió Furucombo y noqueó $14 millones de varias wallets que habían dado a la app “aprobación infinita”.

Aprobación infinita significa confianza ilimitada - algo que sabemos que no debemos de hacer en DeFi.

“No confíes, verifica”, pero ¿quién tiene el tiempo o el cash para el gas que cuesta aprobar montos fijos cada vez que hace transacciones?

La gente que usaba Furucombo tenía que darle cierta aprobación, pero parece que muchos usuarios dieron demasiada, y recibieron una dura lección a cambio.

En lo que se conoce como un exploit de tipo “evil contract”, el agresor hizo al contrato proxy de Furucombo pensar que Aave V2 tenía una nueva implementación.

La nueva implementación fue, por supuesto, maliciosa, y tuvo el poder de transferir todos los tokens aprobados a direcciones controladas por el agresor, ya que los usuarios habían aprobado que los contratos de Furucombo usaran sus tokens en su representación.

Kurt Barry aportó un análisis:

Una de las transacciones que robó fondos fue enviada al proxy de Furucombo, especificando como “handler” el Lending Pool proxy de AAVE v2, para la primera y única acción.

Se puede ver abajo el rastro de la ejecución, tal como aparece en ethtx.info. Nótense las delegatecalls anidadas.

Los handlers deben ser aprobados en un registro; a la hora de la transacción (pero no ahora), este proxy fue un handler válido.

El proxy de FC hace delegatecall al proxy de AAVE v2, lo que luego lee la dirección de implementación de una storage slot especial, pero ya que ésta es una delegatecall, lee del storage del FC proxy, y la dirección extraída es el contrato exploit del hacker.

Si nos fijamos en la transacción previa del hacker:

Vemos que el hacker usó su contrato malicioso para hacer la delegatecall del FC proxy al AAVE v2 proxy, invocando la función initialize, definiendo la slot de implementación.

Una vez que la delegatecall ejecutó el código del hacker en el contexto del FC proxy, todo acabó. La víctima había aprobado el FC proxy para mover su stETH, y el código del exploit lo envió todo al hacker.

Repetir las veces que sea necesario para el resto.

Resumen:

• FC proxy hizo delegatecalls caller-especificadas a handlers de confianza, dejando que su storage sea modificado
• un handler hizo delegatecalls caller-especificadas a una dirección leída del storage
• el handler expuso una función para fijar esta dirección

Lo que hemos aprendido:

• una "lista de confianza" es útil pero no es ninguna garantía
• los desarrolladores deberían auditar cómo las funciones del que recibe una delegatecall pueden afectar el storage del que la llamó.
• hay que considerar restringir las funciones o parámetros de los que las reciben
• Hay que tener cuidado de inputs aportados por usuarios

No solo fueron individuos quienes tuvieron pérdidas, incluso Cream Finance sufrió una pérdida ya que el agresor tomó un “préstamo” directamente de su tesorería.

Igor Igamberdiev proporcionó una lista de los activos robados.

• 3,9k stETH
• 2.4M USDC
• 649k USDT
• 257k DAI
• 26 aWBTC
• 270 aWETH
• 296 aETH
• 2.3k aAAVE
• 4 WBTC
• 90k CRV
• 43k LINK
• 7.3k cETH
• 17.2M cUSDC
• 69 cWBTC
• 142.2M BAO
• 38.6k PERP
• 30.4k COMBO
• 75k PAID
• 225k UNIDX
• 342 GRO
• 19k NDX

Hablamos con el entusiasta de DeFi Limzero (@pleyuh) después de enterarnos que fue uno de los peores afectados.

rekt:

¿Cómo fue la situación para ti?

¿Cómo te diste cuenta que Furucombo estaba bajo ataque y en qué momento tomaste acciones?

Limzero:

Estaba descansando en casa con unos amigos. Abrí Telegram desde el móvil para ver qué pasaba y vi en el canal de Darren "The daily ape" que había un exploit relacionado a Furucombo.

Revisé una de mis direcciones desde las que había usado Furucombo y noté la transferencia de mi aAAve y de aETH.

Me asustó un poco porque tenía algunos préstamos activos y no quería que mis depósitos fueran liquidados. Me di cuenta que mi health factor había bajado a 1.15, así que devolví los préstamos rápido.

Lo que noté es que el agresor sacó todo mi aAAVE pero solo un 1/3 de mi aETH. Imagino que el bajo HF le bloqueó de transferir más de mis fondos. Puede ser que tuve suerte de haber tenido préstamos activos.

Después de devolver los préstamos para proteger los depósitos, revoqué todos los permisos de tokens que había dado desde esa dirección.

Esa fue una acción que llevaba semanas posponiendo (para cuando hubiera gastos más bajos). Aparentemente fue un retraso costoso.

Me enteré de la transferencia de mis fondos por el hacker 90 minutos después de que el hack sucedió.

rekt:

¿Fue una pérdida grande para ti?

¿Cómo se sintió psicológicamente?, ¿te sientes más cauteloso o menos confiado usando DeFi después del ataque?

Limzero:

Fue una gran pérdida en números absolutos pero nada que mi portafolio no pueda soportar.

Estuve muy asustado por unos minutos porque temía que todos mis aTokens pudieran haber sido liquidados, cuando vi mi health factor arriba de 1.1 me sentí aliviado.

Veo la experiencia entera como una cara lección de seguridad - haber tenido aprobaciones infinitas activas desde una dirección con grandes cantidades fue un error muy tonto de mi parte. Todo considerado, fue un ape tax que tuve que pagar eventualmente. Es el primer hack/exploit de un smart contract que me ha afectado después de tantos años en el espacio. Me siento afortunado de que situaciones más graves no me hayan tocado todavía.

De hecho, el primer exploit después de lo de COVER, pero se me olvidó :P

No me siento menos seguro usando DeFi. Estos tipos de riesgos eran conocidos.

Sin embargo, he tomado medidas para aumentar mi ciberseguridad.

rekt:

¿Qué nos puedes contar sobre estas medidas?

Limzero:

Prefiero no decir, disculpa.

Es parte de las medidas :P

rekt:

¿Cuáles medidas recomendarías a nuestros lectores tomar para mejorar su seguridad?

Limzero:

1. usar hardware wallets
2. evitar windows
3. tener un dispositivo dedicado de web 3 para las interacciones con contratos
4. contraseñas únicas o un gestor de contraseñas + VPN
5. un perfil bajo en redes sociales
6. usar varias direcciones para distribuir el riesgo
7. direcciones nuevas para nuevas farms
8. revocar aprobaciones de direcciones usadas con frecuencia

No soy un experto en seguridad para nada. Estas son pautas generales sugeridas por gente más informada en el mundo crypto.

9. leer REKT xD

rekt:

¿Algún mensaje final para nuestros lectores?

Limzero:

“Por favor, no me hackees de nuevo”

También, a menos que tengas mucha confianza en tu seguridad, considera guardar un pequeño porcentaje de tus activos en los CEXs top-tier como Kraken, Coinbase, Gemini, Binance en caso que tus wallets personales sean hackeadas.

Eso es todo de mi parte.

rekt:

Gracias por hablar con nosotros.

Limzero:

¡Gracias! Espero que nunca volvamos a hablar lol.

Un ataque simple con un arreglo simple - no uses “aprobación infinita” a menos que tengas confianza infinita. Las aprobaciones individuales no son un gasto pequeño, pero mejor no cortar gastos en lo relativo a la seguridad.

Sitios como Debank o Etherscan te dejan monitorear y revocar las aprobaciones de tu wallet, y como dijo Limzero, es una tarea que no debe dejarse para mañana.

Nunca bajes la guardia, los hackers siempre están buscando un hueco, y estos ataques suceden con más frecuencia de lo que imaginas.

No hay réferi en este ring; estás a cargo de tu propia seguridad, pero una vez que le pilles el truco, el premio vale la pena el riesgo.

FE DE ERRATAS: 18 Julio 2021

Haechi nos contactó con la siguiente declaración:

Aunque su contrato (proxy) estuvo dentro del rango de investigación de la auditoría, el exploit que infectó el proxy no estuvo dentro del rango de investigación de la auditoría.

Lo que el equipo de furucombo nos entregó fueron solamente dos contratos; furucombo proxy y compound adapter. Así que la situación que el equipo presentó fue acceder al protocolo compound utilizando el compound adapter con proxy, nada más.

Pero, como ya sabes, el exploit fue causado por la situación de haber utilizado AAVE. No fuimos capaces de encontrar este caso dado que ya tenían funcionalidad whitelist que debía de haber funcionado como una protección ante este tipo de situación.

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.