El 15 de mayo de 2024, Sonne Finance sufrió un ataque a Optimism on-chain, con pérdidas de hasta $ 2 k 0000.

Después del ataque, el usuario @tonyke_bot en X tuiteó que protegió alrededor de 100 dólares en el pool de tokens de garantía de Sonne Finance (también conocido como mercado, similar a cToken en Compound), que tenía aproximadamente 6.5 millones de dólares restantes.

（\_bot/status/1790547461611860182）

Después de descubrir el ataque, el equipo del proyecto Sonne Finance suspendió rápidamente todos los mercados en Optimism y dijo que los mercados en Base eran seguros.

（**）

Sesión informativa de ataque

Sonne Finance es un protocolo de préstamos descentralizados basado en Optimism que ha bifurcado Compound V2, proporcionando servicios financieros a individuos, instituciones y protocolos. El protocolo de Sonne Finance agrega los activos tokenizados de los usuarios para formar un pool de liquidez de préstamos, ofreciendo a los usuarios un servicio de préstamos similar al de un banco. Al igual que Compound, los participantes del protocolo pueden depositar sus tokens en el pool de liquidez de préstamos de Sonne Finance y recibir un token de certificado llamado soToken (similar a cToken). El soToken es un activo que genera intereses y obtiene recompensas en tokens SONNE a medida que avanza el bloque. Los participantes también pueden utilizar sus soTokens para pedir prestados otros tokens del pool de activos de préstamos de Sonne, por ejemplo, pueden depositar una cantidad determinada de USDC para obtener el certificado soUSDC y luego pedir prestado WETH para su posterior circulación. Los préstamos y colaterales en el protocolo Sonne Finance pueden tener relaciones de varios a varios. Durante el proceso de préstamo y colateral, el protocolo calcula automáticamente el Factor de Salud (Health Factor) de las direcciones de los participantes. Cuando el Factor de Salud cae por debajo de 1, los colaterales de esa dirección pueden ser liquidados y el liquidador también puede recibir una recompensa por la liquidación.

La relación entre el token subyacente depositado por el usuario y el número de soTokens que acuñan está relacionada principalmente con una variable llamada exchangeRate, que se puede utilizar aproximadamente para representar el valor de cada token subyacente más largo o menos. El tipo de cambio se calcula de la siguiente manera:

En la fórmula anterior, totalCash se refiere a la cantidad de tokens subyacentes en poder de soToken, totalBorrows se refiere a la cantidad de tokens subyacentes prestados en un mercado, totalReserves se refiere a la cantidad total de reservas (incluidos los intereses pagados por los prestatarios) y totalSupply se refiere a la cantidad de soTokens que acuñan.

Al canjear, el usuario puede especificar la cantidad de tokens subyacentes que se canjearán, redeemAmount, para calcular la cantidad de soTokens que deben quemarse, redeemTokens, el método de cálculo es aproximadamente "redeemTokens = redeemAmount / exchangeRat", tenga en cuenta que aquí no hay procesamiento de pérdida de precisión.

La naturaleza de este incidente de ataque es que cuando se creó el mercado (soToken), el atacante realizó la primera operación de acuñación de garantía, acuñando una pequeña cantidad de token subyacente para obtener una pequeña cantidad de soToken, lo que resulta en un valor "totalSupply" de soToken demasiado bajo. A continuación, el atacante aprovechó la vulnerabilidad de pérdida de precisión del contrato Solidity, combinado con el envío directo de token subyacente al contrato de soToken (sin acuñar soToken, lo que significa que "totalSupply" no cambia pero "totalCash" aumenta), en lugar de utilizar el método de garantía + acuñación para depositar el token subyacente. Esta operación hace que la variable "totalCash" en el contrato aumente, pero "totalSupply" se mantiene igual, lo que resulta en un aumento de la tasa de cambio. Finalmente, cuando el atacante redime el token subyacente, necesita destruir menos soToken de los que acuñó al realizar la garantía. El atacante utiliza los soToken ganados para pedir prestado el token subyacente WETH, USDC, etc. en otros soToken (como soWETH, soUSDC), obteniendo así ganancias de hasta 20 millones de dólares estadounidenses.

**Dirección crítica involucrada en el ataque

Trading listo para el ataque:

> > ** > >

Atacar operaciones rentables:

> > > ** \u003e

DIRECCIONES relacionadas con EOA de ataque:

> \u003e

0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb "\u003e " \u003e

> >

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43 "\u003e" in Chinese Simplified translates to ">" The translated text in Spanish would be ">". Translated text in Spanish

DIRECCIÓN relacionada con el atacante (contrato):

\u003e

\u003e 0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

\u003e

0x02fa2625825917e9b1f8346a465de1bbc150c5b9 > \u003e

token subyacente (VELO Token V2):

\u003e

0x9560e827af36c94d2ac33a39bce1fe78631088db > >

Contrato con agujero (soVELO, similar a cToken de Compound):

\u003e \u003e

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5 >

X 上 @tonyke_bot 用户救援交易：

> > **

\u003e

Análisis del proceso de ataque

Antecedentes

Sonne Finance recientemente aprobó una propuesta para agregar el mercado VELO a Sonne Finance () y organizó cinco transacciones que se ejecutarán en dos días a través de una billetera multifirma (). Estas cinco transacciones se utilizan para crear el mercado VELO (contrato soVELO) y configurar algunas configuraciones clave del mercado, como el modelo de tasa de interés, el oráculo de precios y el factor de colateralización. Después de crear el mercado VELO, los usuarios pueden depositar tokens VELO para acuñar tokens soVELO, que luego se pueden utilizar para prestar otros tokens soToken.

Preparación para el ataque

El ataque en la etapa de preparación se centra principalmente en que el atacante, después de que finalice el tiempo de bloqueo de dos días de la propuesta, cree un mercado VELO (contrato soVELO), configure las configuraciones clave y acuñe tokens soVELO mediante el depósito de tokens VELO en el contrato soVELO. Al mismo tiempo, el atacante también aumentará la exchangeRate enviando directamente los tokens VELO que posee al contrato soVELO, preparándose para obtener ganancias en el ataque posterior.

具体步骤如下：

1. Después de que expire el período de bloqueo de dos días, el atacante primero empaqueta las operaciones de las cuatro transacciones de la propuesta en una transacción (transacción 0x45c0cc) para crear el mercado VELO (contrato soVELO) y configurar la configuración clave. Cuando se inicializa el mercado VELO, la tasa de cambio se establece en "200,000,000,000,000,000,000,000,000".
2. El atacante llama a la función "mint" del contrato soVELO para depositar tokens VELO y acuñar tokens soVELO. El atacante especifica "mintAmount" como "400,000,001" (la cantidad de tokens VELO). Según la función "exchangeRateStoredInternal", dado que en este momento el valor de "_totalSuppl" de los tokens soVELO es 0, el tipo de cambio es igual al valor establecido en el paso 1. Según la fórmula "mintTokens = actualMintAmount / exchangeRate", en este momento se calcula que se deben acuñar 2 tokens soVELO. En resumen, en este paso el atacante deposita tokens VELO con un valor de "400,000,001" en el contrato soVELO y obtiene 2 tokens soVELO.

soVELO.mint:

3. El atacante envía directamente tokens VELO a través del contrato soVELO, enviando un valor de "2,552,964,259,704,265,837,526" tokens VELO al contrato soVELO. En este momento, el contrato soVELO posee más tokens VELO, pero debido a que no hay nuevas acuñaciones de tokens soVELO, el totalSupply permanece sin cambios, lo que implica que el exchangeRate calculado según la fórmula también aumentará. 4. El atacante transfirió múltiples veces el token soVELO que poseía y finalmente lo transfirió a otra EOA de ataque, 0xae4a.

Ataque para obtener ganancias

El ataque de ganancias se produce principalmente cuando el atacante ejecuta la quinta transacción de la propuesta y presta tokens VELO directamente al contrato soVELO a través de préstamos relámpago, con el fin de aumentar aún más la exchangeRate. Luego, el atacante utiliza los tokens soVELO con valor 2 en su poder para pedir prestados tokens subyacentes como WETH, USDC, etc. de otros contratos de tokens como soWETH, soUSDC, etc. Estas partes se convierten en las ganancias del atacante. A continuación, el atacante canjea sus tokens subyacentes en el contrato soVELO. Debido al aumento de la exchangeRate y a la pérdida de precisión al calcular los tokens soVELO que deben ser destruidos durante el canje, el atacante logra canjear casi todos los tokens VELO que depositó anteriormente utilizando solo tokens soVELO con valor 1. Se puede entender que el atacante utiliza los tokens soVELO con valor 1 para obtener ganancias en forma de tokens subyacentes como WETH, USDC, etc., mediante préstamos de otros tokens soToken. El atacante repite este mismo método de ataque varias veces, obteniendo finalmente grandes ganancias.

Pasos específicos a seguir:

1. El atacante realiza la quinta transacción especificada en el caso, estableciendo el factor de préstamo definido en la propuesta.
2. El atacante realiza un préstamo relámpago desde el pool VolatileV2 AMM - USDC/VELO con un valor de "35,469,150,965,253,049,864,450,449" tokens VELO, lo cual activa la función hook del atacante. Dentro de la función hook, el atacante continúa ejecutando la operación de ataque.
3. El atacante envía los tokens VELO que posee al contrato soVELO para aumentar aún más la tasa de cambio. Actualmente, el contrato soVELO cuenta con un total de tokens VELO con un valor de "35,471,703,929,512,754,530,287,976" (que incluye los tokens VELO transferidos por el atacante en tres ocasiones).
4. El atacante crea un nuevo contrato 0xa16388a6210545b27f669d5189648c1722300b8b y, en el constructor, transfiere los 2 tokens soVELO que posee al nuevo contrato creado 0xa163 (en adelante referido como atacante 0xa163).
5. El atacante 0xa163 presta un WETH con el valor de "265.842.857.910.985.546.929" del Token soWETH que posee.
6. El atacante 0xa163 llama a la función "redeemUnderlying" de soVELO, especificando el valor de redención de tokens VELO como "35.471.603.929.512.754.530.287.976" (casi la cantidad de tokens VELO que el atacante ha transferido o bloqueado anteriormente en el contrato soVELO). En este momento, se debe calcular la cantidad de tokens soVELO que deben ser destruidos para la redención según la fórmula "redeemTokens = redeemAmountIn / exchangeRate".

Desde la función "exchangeRateStoredInternal", se puede ver que, dado que en este momento "\_totalSupply" es 2 en lugar de 0, es necesario calcular el valor de "exchangeRate" utilizando la fórmula "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply". Actualmente, el valor de "exchangeRate" es "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000", lo cual es mucho mayor que el "exchangeRate" inicial establecido en "200,000,000,000,000,000,000,000,00".

Según el nuevo cálculo de "redeemTokens" según el tipo de cambio, el valor es "1.99", debido a la característica de redondeo hacia abajo en Solidity, el valor final de "redeemTokens" es 1. Esto significa que el atacante 0xa163 ha utilizado 1 token soVELO para canjear casi todos los tokens VELO depositados anteriormente. Al mismo tiempo, el atacante 0xa163 también ha ganado una cantidad de WETH prestados de soWETH, con un valor de "265,842,857,910,985,546,929".

soVELO.redeemUnderlying:

soVELO.exchangeRateStoredInternal: 7. El atacante 0xa163 transfiere todos los WETH prestados y VELO Token canjeados al atacante superior, y luego se autodestruye. 8. El atacante llama a la función "liquidateBorrow" de soWETH para liquidar parte de los activos prestados por el contrato 0xa163 creado anteriormente, con el objetivo de recuperar el token soVELO con un valor bloqueado de 1. Actualmente, el atacante solo posee el token soVELO con un valor de 1. 9. El atacante llama a la función "mint" de soVELO para volver a acuñar tokens soVELO, con el objetivo de alcanzar un valor de 2 tokens soVELO, luego realiza nuevamente los pasos 3-8 mencionados anteriormente para obtener ganancias de otros tokens subyacentes. 10. El atacante realiza el paso 9 varias veces, paga los préstamos flash y sale del mercado con una ganancia.

Cómo aprovechar $100 para obtener $6.5 millones

Después del ataque, el usuario @tonyke_bot en X realizó una transacción en 0x0a284cd, donde apostó 1144 tokens VELO en el contrato soVELO, acuñando 0.00000011 tokens soVELO. La razón por la cual esta operación evita futuros ataques es porque modifica el tamaño del totalSupply en soVELO y la cantidad de tokens VELO en totalCash. El crecimiento del totalSupply tiene un impacto mayor en el cálculo de exchangeRate que el crecimiento de totalCash, lo cual hace que el exchangeRate disminuya. Como resultado, el atacante ya no puede aprovechar las pérdidas de precisión para obtener beneficios con soVELO, lo que impide que el ataque continúe.

Seguimiento de fondos

Los atacantes transfirieron los fondos poco después de apoderarse de las ganancias ilegales, la mayoría de las cuales fueron transferidas a las siguientes 4 direcciones, algunas para continuar el ataque en otra dirección y otras para blanqueo de capitales:

1. 0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

El atacante transfirió 198 WETH a la dirección, y luego la dirección utilizó las mismas tácticas de ataque para obtener ganancias ilegales en las siguientes transacciones:

Después del ataque, el DIRECCIÓN transfirió las ganancias a 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

2. 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

El atacante transfirió 724277 USDC y 2353 VELO a esta dirección, y luego intercambió los USDC por Ether. Luego, inmediatamente transfirió parte de los fondos al puente cross-chain Stargate, mientras que la mayor parte de los fondos ilegales permanecen en esta dirección.

3. 0xbd18100a168321701955e348f03d0df4f517c13b

El atacante transfirió 33 WETH a la dirección y utilizó la cadena de pelado para intentar el blanqueo de capitales, el enlace de blanqueo de capitales es el siguiente:

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003093c2b4 -> * 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795*。

4. 0x4fac0651bcc837bf889f6a7d79c1908419fe1770

El atacante transfirió 563 WETH a esta dirección y luego lo transfirió a 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68. Actualmente no hay más acciones.

Los métodos utilizados por los atacantes para el blanqueo de capitales en esta ocasión son relativamente profesionales, con una diversidad de técnicas. Por lo tanto, como participantes de Web3, debemos seguir mejorando constantemente nuestras capacidades de prevención del blanqueo de capitales y aumentar la seguridad de los proyectos DeFi mediante el uso de productos de seguridad de transacciones en blockchain como KYT y AML.

Consejos de seguridad

1. Hay que prestar atención a la pérdida de precisión. Los problemas de seguridad causados por la pérdida de precisión surgen uno tras otro, especialmente en los proyectos Defi, donde la pérdida de precisión a menudo conduce a graves pérdidas financieras. Se recomienda que el equipo del proyecto y los auditores de seguridad revisen cuidadosamente el código con pérdida de precisión en el proyecto y hagan un buen trabajo probándolo para evitar la vulnerabilidad tanto como sea posible.
2. Se recomienda que las operaciones de creación y primer staking de acuñación de un mercado similar a cToken en Compound sean realizadas por usuarios privilegiados para evitar ser manipulados por atacantes, a fin de manipular la tasa de cambio.
3. Cuando existen variables clave en el contrato que dependen de los valores de "this.balance" o "token.balanceOf()", es necesario considerar cuidadosamente las condiciones en las que estas variables clave pueden cambiar. Por ejemplo, si se permite cambiar el valor de esta variable directamente mediante la transferencia de moneda nativa o tokens al contrato, o si solo se puede cambiar el valor de esta variable llamando a una función específica.

Este artículo fue escrito por Cara (cuenta X @Cara6289) y XiG (cuenta X @SHXiGi) del equipo ZAN.