El 15 de mayo de 2024, Sonne Finance sufrió un ataque a la cadena Optimism, lo que provocó pérdidas de hasta 20 millones de dólares. Después del ataque, el usuario de Twitter @tonyke_bot tuiteó que protegieron los USD 6.5 millones restantes en el grupo de garantías de Sonne Finance (también conocido como el mercado, similar a cToken en Compound) con alrededor de USD 100.

(https://twitter.com/tonyke_bot/status/1790547461611860182)

Al descubrir el ataque, el equipo de Sonne Finance detuvo rápidamente todos los mercados en Optimism y declaró que los mercados en Base eran seguros.

(https://twitter.com/SonneFinance/status/1790535383005966554)

Descripción breve del ataque

Sonne Finance es un protocolo de préstamos descentralizado que bifurca Compound V2 en Optimism, proporcionando a individuos, instituciones y protocolos acceso a servicios financieros. El protocolo de Sonne Finance agrega los activos simbólicos de los usuarios para formar un fondo de liquidez de préstamos, proporcionando a los usuarios un negocio de préstamos similar al de un banco. Al igual que Compound, los participantes del protocolo pueden hipotecar sus tokens en el fondo de liquidez de préstamos de Sonne Finance y obtener el certificado soToken (igual que cToken). SoToken es un certificado de activos que devenga intereses, que generará una cierta cantidad de ingresos a medida que avance el bloque, y también recibirá incentivos de tokens SONE. Los participantes también pueden tomar prestados otros tokens del grupo de activos de préstamos de Sonne con el soToken en sus manos. Por ejemplo, los participantes pueden hipotecar una cierta cantidad de USDC para obtener certificados soUSDC, y luego prestar WETH para su posterior circulación. Los préstamos hipotecarios en el protocolo de Sonne Finance pueden ser una relación de activos de muchos a muchos. Durante el proceso de préstamo hipotecario, el protocolo calculará automáticamente el factor de salud (Health Factor) de la dirección del participante. Cuando el factor de salud es inferior a 1, la hipoteca de la dirección Productos soporte liquidación, y los liquidadores también pueden recibir ciertas recompensas liquidación.

La relación entre el número de tokens subyacentes depositados por los usuarios y los soTokens acuñados está relacionada principalmente con una variable llamada exchangeRate. Esta variable se puede usar aproximadamente para indicar cuánto vale cada token subyacente de cada soToken. La fórmula de cálculo de exchangeRate es la siguiente:

En la fórmula anterior, totalCash se refiere a la cantidad de tokens subyacentes que posee soToken, totalBorrows se refiere a la cantidad de tokens subyacentes prestados en un mercado determinado, totalReserves se refiere a la cantidad total de reserva (incluidos los intereses pagados por el prestatario), totalSupply se refiere a la cantidad de soToken acuñados.

Al canjear, los usuarios pueden especificar el número de tokens subyacentes que desean canjear, redeemAmount, para calcular el número de soTokens que deben destruirse, redeemTokens. El método de cálculo es aproximadamente "redeemTokens = redeemAmount / exchangeRat". Tenga en cuenta que aquí no hay pérdida de precisión. tratar con.

La esencia de este ataque es que cuando se creó el mercado (soToken), el atacante realizó la primera operación de conversión de hipotecas y acuñó muy pocos soTokens con una pequeña cantidad de tokens subyacentes, lo que resultó en que el valor "totalSupply" de soToken fuera demasiado pequeño. Luego, el atacante aprovechó la vulnerabilidad de la pérdida de precisión del contrato de Solidity y luego envió el token subyacente directamente al contrato soToken (soToken no se acuñará, lo que significa que "totalSupply" permanece sin cambios y "totalCash" se hace más grande) en lugar de apostar + método de lanzamiento para depositar el token subyacente. Una operación de este tipo hace que la variable "totalCash" en el contrato sea más grande, pero "totalSupply" permanece sin cambios, lo que hace que el tipo de cambio sea mayor. Al final, cuando el atacante canjea el token subyacente, el soToken que debe destruirse es menor que el soToken acuñado durante la hipoteca. El atacante utiliza el soToken ganado para prestar el token subyacente WETH y USDC a otros soTokens (como soWETH, soUSDC), y finalmente obtiene ganancias de hasta US $ 20 millones.

Direcciones clave involucradas en el ataque

Transacciones de preparación de ataques:

https://optimistic.etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96

Atacar transacciones rentables:

https://optimistic.etherscan.io/tx/0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0

Atacar direcciones relacionadas con EOA:

0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43

Dirección relacionada con el atacante (contrato):

0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

0x02fa2625825917e9b1f8346a465de1bbc150c5b9

token subyacente (VELO Token V2):

0x9560e827af36c94d2ac33a39bce1fe78631088db

Contrato de vulnerabilidad (soVELO, similar al cToken de Compound):

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5

@tonyke_bot Transacción de rescate de usuario en X:

https://optimistic.etherscan.io/tx/0x816f9e289d8b9dee9a94086c200c0470c6456603c967f82ab559a5931fd181c2

Análisis del proceso de ataque

Recap

El equipo del proyecto Sonne Finance aprobó recientemente una propuesta para añadir el mercado VELO a Sonne Finance (https://twitter.com/SonneFinance/status/1786871066075206044), y organizó cinco transacciones a través de la billetera multifirma que se ejecutarán dos días después ( https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7), estas cinco transacciones se utilizan para crear el mercado VELO (contrato soVELO) y establecer algunas configuraciones clave del mercado, como establecer el modelo de tasa de interés, establecer el oráculo de precios y establecer los factores hipotecarios, etc. Una vez creado el mercado VELO, los usuarios pueden depositar VELO tokens para acuñar tokens soVELO, que a su vez se pueden utilizar para tomar prestados otros soTokens.

preparación

ataque La etapa de preparación del ataque consiste principalmente en que el atacante cree un mercado VELO (contrato soVELO) basado en la información de la propuesta del proyecto Sonne Finance después de que haya expirado el período de bloqueo de dos días de la propuesta, configurar las configuraciones clave y acuñar VELO tokens en el contrato soVELO hipotecandolos. soVELO, y también envía los tokens VELO que posee directamente al contrato soVELO para aumentar el tipo de cambio y preparar para beneficiarse de los ataques posteriores.

Los pasos específicos son los siguientes:

1. Una vez finalizado el período de bloqueo de dos días, el atacante empaqueta primero las operaciones de las primeras cuatro transacciones organizadas en la propuesta en una transacción (transacción 0x45c0cc), que se utiliza para crear el mercado VELO (contrato soVELO) y establecer la configuración de claves. Cuando se inicializa VELO market, exchangeRate se establece en "200,000,000,000,000,000,000,000,000,000".

2. El atacante llama a la función "acuñar" del contrato soVELO para depositar VELO tokens y acuñar tokens soVELO. El atacante especifica "mintAmount" como "400,000,001" (el número de tokens VELO). Como se puede ver en la función "exchangeRateStoredInternal", dado que el "_totalSuppl" del token soVELO es 0 en este momento, exchangeRate es el valor establecido en el paso 1. De acuerdo con la fórmula " mintTokens = actualMintAmount / exchangeRate ", el número calculado de tokens soVELO que deben acuñarse en este momento es 2. En coro, en este paso, el atacante deposita tokens VELO con un valor de "400,000,001" en el contrato soVELO, y el atacante obtiene tokens soVELO con un valor de 2.

soVELO.acuñar:

1. El atacante envió tokens VELO con un valor de "2,552,964,259,704,265,837,526" al contrato soVELO enviando directamente tokens VELO al contrato soVELO. En este momento, la cantidad de tokens VELO en poder del contrato soVELO aumentó, pero como no había nuevos tokens soVELO, la moneda se acuña, por lo que totalSupply permanece sin cambios, lo que significa que el exchangeRate calculado de acuerdo con la fórmula de cálculo de exchangeRate será mayor en este momento.

2. El atacante transfirió los tokens soVELO retenidos varias veces y, finalmente, los transfirió a otro 0xae4a EOA de ataque.

Ataque con fines de lucro

La fase de ganancias del ataque consiste principalmente en que el atacante ejecute la quinta transacción de la propuesta y preste tokens VELO directamente al contrato soVELO a través de préstamos flash para aumentar aún más el tipo de cambio. Luego, el atacante usa el token soVELO con un valor de 2 en su mano para tomar prestados tokens subyacentes como WETH y USDC de otros contratos soToken (como soWETH, soUSDC, etc.), y estas partes se convierten en ganancias del atacante. Luego, el atacante fue a canjear su token subyacente en el contrato soVELO. Debido al aumento del tipo de cambio y a la pérdida de precisión en el cálculo de los tokens soVELO que deben destruirse para su canje, el atacante finalmente solo utilizó el token soVELO con un valor de 1. Casi todos los tokens VELO depositados previamente fueron canjeados, lo que puede entenderse como que el atacante utiliza los tokens soVELO adicionales con un valor de 1 para ganar tokens subyacentes como WETH y USDC tomando prestado de otros soTokens. El atacante utilizó la misma técnica para repetir el ataque muchas veces y, en última instancia, obtuvo grandes beneficios.

Los pasos específicos son los siguientes:

1. El atacante ejecuta la quinta transacción de la propuesta y establece el factor de préstamo especificado en la propuesta.

2. El atacante presta tokens VELO con un valor de "35,469,150,965,253,049,864,450,449" del grupo VolatileV2 AMM - USDC / VELO, que activa la función de gancho del atacante. En la función de enlace, el atacante continúa realizando la operación de ataque.

3. El atacante envía los tokens VELO que posee al contrato soVELO para aumentar aún más el tipo de cambio. Actualmente, hay un total de tokens VELO con un valor de "35,471,703,929,512,754,530,287,976" en el contrato soVELO (la suma de tokens VELO transferidos en tres veces por el atacante).

4. El atacante crea un nuevo contrato 0xa16388a6210545b27f669d5189648c1722300b8b. En el constructor, transfiere los 2 tokens soVELO que posee al 0xa163 de contrato recién creado (en lo sucesivo, el 0xa163 atacante).

5. El atacante 0xa163 utilizado los tokens soVELO que poseía para pedir prestados WETH con un valor de "265.842.857.910.985.546.929" de soWETH.

6. El atacante 0xa163 llama a la función "redeemUnderlying" de soVELO, especificando el valor de los tokens VELO canjeados como "35,471,603,929,512,754,530,287,976" (casi el número de tokens VELO que el atacante ha transferido o hipotecado previamente en el contrato soVELO). En este momento, es necesario La fórmula "redeemTokens = redeemAmountIn / exchangeRate" se utiliza para calcular la cantidad de tokens soVELO que deben destruirse para su canje.

Como se puede ver en la función "exchangeRateStoredInternal", dado que _totalSupply es 2 en lugar de 0, es necesario calcular el valor de exchangeRate. De acuerdo con la fórmula "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply", el tipo de cambio actual es "17,735,851,964,756,377,265,143,988,000,000,0 00,000,000,000,000 ", este valor es mucho mayor que el valor inicial establecido "200,000,000,000,000,000,000,000,000".

El valor de " redeemTokens " calculado en base al nuevo exchangeRate es " 1.99 ". Debido a las características de redondeo descendente de Solidity, el valor de " redeemTokens " termina siendo 1. Esto significa que el atacante 0xa163 utilizado tokens soVELO con un valor de 1 para canjear casi todos los tokens VELO depositados anteriormente. Al mismo tiempo, el atacante también 0xa163 ganado WETH con un valor de "265.842.857.910.985.546.929" prestados de soWETH.

soVELO.redeemUnderlying:

soVELO.exchangeRateStoredInternal:

1. El atacante 0xa163 transfirió todos los WETH prestados y canjeó VELO tokens al atacante de nivel superior, y luego se autodestruyó.

2. El atacante llama a la función "liquidateBorrow" de soWETH para liquidar algunos de los activos prestados del contrato recién creado 0xa163 en orden recuperar el token soVELO bloqueado con un valor de 1. Actualmente, el atacante solo posee tokens soVELO con un valor de 1.

3. El atacante llama a la función "acuñar" de soVELO y, una vez más, hipoteca y acuña tokens soVELO con el propósito de reunir suficientes tokens soVELO con un valor de 2, y luego realiza los pasos 3-8 anteriores nuevamente para beneficiarse de otros tokens sin importancia.

4. El atacante realiza la operación en el paso 9 varias veces, devuelve el préstamo flash y abandona el mercado con una ganancia.

Cómo $100 apalanca $6.5 millones

Después del ataque, el usuario @tonyke_bot on X acuñó 0.00000011 soVELO apostando 1144 tokens VELO en el contrato soVELO en la transacción 0x0a284cd. La razón por la cual esta operación puede evitar que el atacante sufra más ataques es porque esta transacción cambia el tamaño de totalSupply en soVELO y el número de tokens VELO totalCash retenidos, y el impacto del crecimiento de totalSupply en el cálculo de exchangeRate es mayor que el impacto del crecimiento de totalCash. Por lo tanto, el tipo de cambio se vuelve más pequeño, lo que hace que el atacante no pueda usar la pérdida de precisión más larga para ganar soVELO al realizar un ataque, lo que hace que el ataque no sea más largo posible.

Rastreo de dinero

El atacante transfirió los fondos poco después de apoderarse de las ganancias ilegales. La mayor parte de los fondos se transfirieron a las cuatro direcciones siguientes. Algunos cambiaron de dirección para continuar con el ataque, y otros fueron por lavado de dinero:

1、0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

El atacante transfirió 198 WETH a esta dirección, y luego la dirección utilizó el mismo método de ataque para obtener ganancias ilegales en las siguientes transacciones:

Después del ataque, la dirección transfirió las ganancias ilegales mencionadas a 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

2、0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

El atacante transfirió 724277 USDC y 2353 VELO a esta dirección e intercambió USDC por Ether. Luego, algunos fondos se transfirieron inmediatamente al cross-chain puente Stargate. La mayor parte de los fondos ilícitos permanecen en esta dirección:

3、0xbd18100a168321701955e348f03d0df4f517c13b

El atacante transfirió 33 WETH a esta dirección y utilizó la cadena de pelado para tratar de lavar dinero. El vínculo de lavado de dinero es el siguiente:

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003 093c2b4 -> 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795。

4、0x4fac0651bcc837bf889f6a7d79c1908419fe1770

El atacante transfirió 563 WETH a esta dirección y posteriormente a 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, sin que hasta el momento se hayan realizado más acciones.

El método de lavado de dinero del atacante esta vez es relativamente profesional y los métodos muestran una tendencia de diversidad. Por lo tanto, para nosotros, los participantes de Web3, debemos continuar mejorando nuestras capacidades contra el lavado de dinero en términos de seguridad y mejorar la seguridad de los proyectos Defi a través de KYT, AML y otros productos de seguridad de transacciones blockchain relacionados.

Consejos de seguridad

1、Manténgase al día con las auditorías y pruebas de contratos. Realice una auditoría exhaustiva antes de la implementación de contratos inteligentes, prestando especial atención a todas las partes que impliquen cálculos financieros. En primer lugar, utilice pruebas automatizadas y aproveche las actualizaciones en tiempo real de las bibliotecas de vulnerabilidades para realizar análisis de seguridad de contratos eficientes (la industria también ha abierto gradualmente el código de algunas herramientas de auditoría de seguridad maduras, incluido ZAN AI SCAN), al tiempo que combina la auditoría manual para solucionar problemas que requieren un conocimiento profundo de la industria.

2、La pérdida de precisión debe tomarse en serio. Los problemas de seguridad causados por la pérdida de precisión son infinitos, especialmente en los proyectos Defi, donde la pérdida de precisión a menudo conduce a graves pérdidas financieras. Se recomienda que las partes del proyecto y los auditores de seguridad revisen cuidadosamente los códigos con pérdida de precisión en el proyecto y realicen pruebas para evitar esta vulnerabilidad tanto como sea posible.

1. Se recomienda que la creación de un mercado similar a cToken en Compound y la primera operación de fundición de hipotecas sea realizada por usuarios privilegiados para evitar ser manipulados por atacantes y así manipular la tasa de intercambio.

2. Cuando hay variables clave en el contrato que dependen del valor de " this.balance " o " token.balanceOf() ", debe considerar cuidadosamente las condiciones para el cambio de la variable clave, como por ejemplo, si se permite transferir directamente la moneda nativa o tokens al contrato. para cambiar el valor de la variable, o solo se puede cambiar el valor de la variable llamando a una función específica.

Disclaimer:

1. Este artículo es una reimpresión de [ZAN]. Todos los derechos de autor pertenecen al autor original [ZAN]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.