BADGERS DIGG SUSHI

Los badgers son conocidos por tomar las mismas rutas en sus búsquedas de comida por las noches. Esto crea caminos bien marcados por los campos y bosques.

Cuando uno de los caminos habituales del badger se encuentra interrumpido o bloqueado de alguna manera, el animal se confunde y acaba rebasing al pairing equivocado.

Fuimos alertados de un trade que, al parecer, mostró a un experimentado usuario DeFi convertir 0.001 a 81.68 ETH vía el token DIGG de Badger DAO.

Después de una investigación más extensa, encontramos que aunque hubo un exploit, el daño ya estaba contenido, y lo que había sido percibido como una amenaza al protocolo entero de SushiSwap fue simplemente un smart scavenger recogiendo las sobras olvidadas.

Una wallet ya conocida se estaba aprovechando de un loophole viejo que se reabrió durante un momento de descuido del equipo SushiSwap.

Aunque la transacción que nos llamó la atención al principio parecía alarmante, una vez que hablamos con el equipo de Sushi, quedó claro que no había grandes motivos de preocupación.

La transacción muestra a SushiMaker intentando convertir 0.05% de los gastos de canje DIGG/WBTC (durante ~24hrs) a través de una pool de DIGG/ETH con poca liquidez y sufriendo un alto slippage, y resultando en la obtención de grandes comisiones para los proveedores de liquidez en la misma pool.

El monto generado de estos gastos habría sido pagado a los holders de xSUSHI, pero en su lugar fue a dar al agresor.

¿Cómo ha pasado esto?

Aunque se había creado una solución unas semanas antes, tenía que ser aplicada manualmente en cada pool nueva. Dado que en ésta no se había aplicado, el scavenger pudo entrar a hurtadillas y tomar las comisiones que debían de haber ido a los holders de xSUSHI.

Cuando nuevos pairs fueron añadidos al Onsen de SushiSwap, añadieron también algunos pairs non-ETH, pero ningún “bridge” fue establecido dentro del SushiMaker para DIGG/WBTC.

SushiMaker es el contrato que toma 0.05% de los gastos de trading y los pasa a los usuarios que tienen staked su SUSHI como xSUSHI, para ganar SUSHI adicional en recompensa y sin una impermanent loss.

Por default, SushiMaker vende los gastos acumulados (y sus pairs) por ETH y luego por SUSHI.

El bridge permite que cuando SushiMaker vende los gastos de un activo que no tenga pair con ETH, puede hacerlo a un activo diferente a ETH que tenga la liquidez adecuada.

Sin un bridge, se podría aportar liquidez para crear un pair ETH, mediante el cual SushiMaker intentaría convertir los gastos asociados con el activo y subsecuentemente sufrir un alto price impact debido al bajo nivel de liquidez.

Esto resulta en que los gastos acumulados por SushiMaker hasta determinado “serving” son la recompensa para los proveedores de ese pair ETH, en lugar de para los participantes de xSUSHI.

Afortunadamente ningún proveedor de liquidez subyacente ni posiciones xSUSHI fueron afectadas, solo las ganancias del activo afectado (los gastos de 0.05% de los canjes DIGG/WBTC: 81 ETH) el día anterior fueron perdidas.

Un bridge ha sido establecido para DIGG a través del maker contract para resolver este asunto para los participantes de xSUSHI. El bridge también está incluido en SushiMaker.

Una conversación dentro del Discord de Sushiswap nos dio más detalles de las mecánicas del exploit:

Analizamos la dirección del scavenger y descubrimos que es un conocido usuario de bots y flash loans.

Datos de Nansen

Encontramos varias transacciones mostrando que este actor había intentado aprovecharse de este loophole y así robar sus recompensas a los proveedores de liquidez.

0x90fb0c9976361f537330a5617a404045ffb3fef5972cf67b531386014eeae7a9

0x0af5a6d2d8b49f68dcfd4599a0e767450e76e08a5aeba9b3d534a604d308e60b

0xcec93808a657d00cbb0245711e9419d0ea278b3a60a9a6d0a8c3353523c0e982

0xe0527f7befaea54257113a09c8b3f4cd416e11a0e196cd2ba2e5e07c47767ddf

Lo que pudo haber sido un desastre resultó una ligera humillación para el equipo de Sushi.

Aunque el agresor tuvo éxito en su exploit, podemos considerarlo una escapada por los pelos para SushiSwap, quien actualmente tiene $1.9B TVL para proteger.

La conversación en Discord, declarando que no van a automatizar este arreglo y que continuarán confiando en recordar aplicarlo cada vez, es bastante preocupante.

¿Por qué dejar al alcance errores humanos si no es necesario?

Aunque el código esté descentralizado, los desarrolladores tienen una responsabilidad enorme cuando trabajan en protocolos con TVL tan grandes. Los efectos del estrés son frecuentemente menospreciados y vemos a muchos desarrolladores ser víctimas de un “burn out”. Hay muchas cosas que pueden salir mal cuando se hace coding, así que tal vez a SushiSwap le haría bien un poco de automatización aquí.

Esta historia sirve como recordatorio de que los protocolos están bajo constante vigilancia por parte de los hackers y arbitrajistas, quienes los siguen a cada movimiento e intentan robarles los bolsillos o eliminarlos totalmente.

Sin embargo, esta inspección va en ambas direcciones - incluso amateurs como el usuario de Twitter “simp2win” puede vigilar a los hackers desde lejos. Su esfuerzo es admirable, pero quizá deben dejar el análisis para los expertos.

Nos encanta un hacker que tiene algo que decir, así que nos dió gusto verlos enviar el siguiente mensaje vía Ethereum call data.

¿Quién es este tipo simp2win en Twitter diciendo que hice 10 mil? lol Ojalá

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.