Primer lanzamiento | Opyn ETH Put logic análisis técnico de vulnerabilidad

A las cuatro de la mañana del 5 de agosto, algunos usuarios informaron en el foro de opyn que los saldos de sus cuentas desaparecieron sin ningún motivo, y algunos usuarios encontraron información de transacciones sospechosas, como se muestra en la siguiente figura:

El partido del proyecto Opyn respondió después de un análisis preliminar de la situación y dijo: los fondos han sido transferidos y se está buscando la causa del problema.

Al cierre de esta edición, el funcionario emitió una respuesta al incidente: fue pirateado y los activos que pueden ser atacados han sido transferidos, pero esta vulnerabilidad solo involucra el contrato ETH y no afecta a otros contratos. Como se muestra abajo:

LBank Blue Shell lanzó BOSON a las 16:50 el 9 de abril: Según el anuncio oficial, LBank Blue Shell lanzará BOSON (Boson Protocol) a las 16:50 el 9 de abril, abrirá transacciones en USDT y abrirá recargas a las 16:00 en abril. 9. El retiro estará disponible a las 16:00 el 12 de abril. Abra la transacción de recarga BOSON al mismo tiempo que se conecta en línea para compartir 10,000 USDT.

A las 16:50 del 9 de abril, LBank Blue Shell abrió la transacción de depósito BOSON para compartir 10,000 USDT. El monto de recarga neta del usuario no es inferior a 1 BOSON, y se puede obtener la recompensa de lanzamiento aéreo USDT equivalente al 1% de BOSON de acuerdo con el monto de recarga neta; la competencia comercial se clasificará de acuerdo con el volumen de operaciones de BOSON del usuario, y los 30 principales se pueden basar en la proporción del volumen comercial personal Divide USDT. Para obtener más información, haga clic en el anuncio oficial. [2021/4/9 20:02:26]

Chengdu Lianan-Security Lab rastreó y analizó este incidente por primera vez. La siguiente es la dirección del contrato del atacante que el sistema de conocimiento de la situación detectó el robo:

0xe7870231992ab4b1a01814fa0a599115fe94203f

Primer lanzamiento | imKey admite oficialmente Filecoin, convirtiéndose en el primer lote de billeteras de hardware de Filecoin: el 1 de diciembre, con el lanzamiento de imToken 2.7.2, imKey admite Filecoin simultáneamente, convirtiéndose en el primer lote de billeteras de hardware en la industria en admitir oficialmente FIL. Como uno de los proyectos prioritarios respaldados por la cadena múltiple de imKey, Filecoin se ha convertido en la quinta cadena pública después de las cuatro cadenas públicas de BTC, ETH, EOS y COSMOS.

Se informa que el equipo de imKey lanzó por completo el plan de soporte de cadenas múltiples en el cuarto trimestre, planeando implementar todos los proyectos de cadenas públicas que imToken ha respaldado. Esta actualización de actualización de imKey no necesita reemplazar el hardware, no implica actualizaciones de firmware y puede actualizarse automáticamente a través de la aplicación (Applet) Darse cuenta del soporte de imKey para Filecoin y la gestión de tokens de FIL. [2020/12/2 22:52:32]

0xb837531bf4eb8ebfa3e20948bd14be067c18cbd3

0xb72e60ea1d0c04605f406c158dce9ac6ae6d224c

Primer lanzamiento | Las transferencias anteriores de 18,000 BTC fueron organizadas internamente por el intercambio Bithumb: el sistema de monitoreo en cadena de Beijing Lianan encontró que una transferencia de 18,000 BTC ocurrió a las 17:07 el 24 de octubre, hora de Beijing. Después del análisis, en realidad fue el trabajo de acabado interno del intercambio Bithumb, que empaqueta una gran cantidad de UTXO de 100 a 200 BTC en 18 UTXO de 1000 BTC y los transfiere a su dirección interna. Por lo general, la clasificación de UTXO de varios "valores nominales" a nivel de número entero es una operación regular de intercambio. [2019/10/24]

Restauración del método de ataque del atacante:

1. El atacante llama al contrato para enviar n USDC al contrato para aumentar la hipoteca y obtener la moneda del contrato oETH

2. El atacante llama al contrato para enviar ETH por hipoteca y destruye oETH para canjear su propio USDC

3. El atacante rescata su ETH hipotecado.

El debut de IMEOS, EOS Go, anuncia dos nuevas condiciones de registro: Según el informe de IMEOS, socio de Jinse Finance: Hoy, EOS Go anunció dos nuevas condiciones de registro en Steemit:

1. Plan para garantizar la seguridad: si el nodo candidato publica un artículo en Steemit para presentar el método y el plan de seguridad del nodo. El estándar del "método de seguridad" es una oportunidad para mostrar a los votantes de EOS el conocimiento de las mejores prácticas de seguridad y el plan de implementación de la organización;

2. Posición: describa la posición del nodo para compartir recompensas por inflación y/o distribuir dividendos a los poseedores de tokens EOS (los nodos candidatos se publican en Steemit). Se desarrollan principalmente los siguientes dos temas:

¿La organización proporcionará pagos a los votantes de tokens de EOS por algún motivo, incluidas las elecciones de BP y el asesoramiento de la comunidad?

¿Tiene la organización una política escrita de no pago de entradas? Si es así, proporcione un enlace. [2018/4/27]

En el paso 2, el atacante llama a la función de ejercicio y le pasa dos direcciones A (la dirección propia del atacante), B (la dirección donde otros no han canjeado el USDC) y el doble del USDC que merecen, y el programa se ejecuta normalmente. los fondos de la dirección B se verán comprometidos.

Comercio

0x56de6c4bd906ee0c067a332e64966db8b1e866c7965c044163a503de6ee6552a

Como ejemplo, el atacante pasa el contrato

0xe7870231992ab4b1a01814fa0a599115fe94203f contrato de pareja 0x951D51bAeFb72319d9FBE941E1615938d89ABfe2

Se lanzó el ataque y la ganancia total de esta transacción fue de $9907. Como se muestra abajo:

El atacante llamó primero a la función addERC20CollateralOption y envió 9900 USDC al contrato, como se muestra en la siguiente figura:

addERC20Collateral(msg.sender, amtCollateral); en esta función es responsable de la transferencia de agencia de USDC; emitOTokens(amtToCreate, receptor); en la función es responsable de acuñar oETH, esta transacción acuña 30 oETH y los envía al atacante, como se muestra en la siguiente figura:

Una vez hecho esto, se modifican los parámetros de la bóveda del atacante. bóveda.oTokensIssued y bóveda.collateral se actualizan a 300000000 y 9900000000 respectivamente, como se muestra en la siguiente figura:

Luego, el atacante procedió a intercambiar oETH.

Llame a exercise, el parámetro de construcción oTokensToExercise es 60, y vaultsToExerciseFrom son dos direcciones, una de las cuales es la dirección de otra persona que también cumple las condiciones. Como se muestra abajo:

La función Exercise ejecuta la rama _exercise(vault.oTokensIssued, vaultOwner); y envía el USDC correspondiente a 30oETH a la persona que llama, como se muestra en la siguiente figura:

Podemos notar que en la transferencia final, _exercise transfiere USDC a msg.sender, que es el atacante.

Volvamos a ver el bucle for del ejercicio: la entrada del atacante de oTokensToExercise es 60, por lo que cuando el contrato verifique que la segunda dirección cumple las condiciones, seguirá transfiriendo el saldo a msg.sender, que es el atacante. Esto le permite al atacante obtener USDC dos veces, obteniendo así una ganancia.

En este incidente, el atacante aprovechó la falla lógica de la función de ejercicio. Esta función no verifica si la persona que llama tiene derecho a canjear el USDC de esta dirección antes de realizar la transferencia final, sino que simplemente verifica si la dirección puede canjearse. Es una vulnerabilidad lógica en la capa de código y, según la respuesta oficial, este contrato ha sido objeto de una auditoría de seguridad. Chengdu Lianan recuerda por la presente a todas las partes del proyecto:

1. Se deben realizar auditorías de seguridad suficientes y efectivas antes de que el proyecto entre en línea, preferiblemente auditorías de múltiples partes.

2. Para el contrato, se deben establecer funciones como la suspensión de las transacciones del contrato para garantizar la seguridad de los fondos en caso de un incidente de seguridad.

3. La seguridad es un proceso continuo y no es suficiente garantizar la seguridad con una sola auditoría. Es muy importante establecer una cooperación a largo plazo con empresas de seguridad de terceros.

Tags：

MATIC