Atacado de nuevo ¿Cómo robó el contrato inteligente VETH $ 900,000?

Prólogo

El 1 de julio de 2020, el contrato de VETH fue pirateado. Después de recibir la inteligencia, el equipo de seguridad de SlowMist realizó un análisis exhaustivo del ataque. El siguiente es un análisis técnico detallado del ataque.

Detalles del ataque

La transacción de ataque es la siguiente 0xdd1120a90ed4112b634266d6a244b93ca86785317bc75f0e170ab0cd97c65224

A través de la descripción general de la transacción, podemos ver que el atacante usó 0.9 ETH para intercambiar por VETH en Uniswap, y luego usó VETH para operar en el contrato de Vether, y finalmente robó una gran cantidad de VETH.

Ahora use el navegador de contratos OKO para analizar los detalles específicos del ataque (la siguiente figura solo muestra una parte)

Al analizar los detalles específicos de la transacción, se puede encontrar que: el atacante primero creó un contrato 0x47Ed415006C6F8052Fff05fe983f31D6D24B8fDB  a través de este contrato para llamar a la función  changeExcluded(unknown37217349)  y la función  transferFrom  en el contrato de Vether.

Ministerio de Finanzas de Corea del Sur: los lanzamientos aéreos de tokens también pueden estar sujetos al impuesto sobre donaciones, y la implementación depende de las circunstancias específicas: el 22 de agosto, según informes de medios extranjeros, el Ministerio de Planificación y Finanzas de Corea del Sur explicó la ley fiscal que los lanzamientos aéreos simbólicos también pueden estar sujetos al impuesto sobre donaciones. Recientemente, el Ministerio de Finanzas y Economía de Corea del Sur respondió a una consulta sobre la interpretación de la ley fiscal con respecto a las transacciones en las que los emisores de activos encriptados proporcionan activos encriptados similares o diferentes a los miembros que poseen activos específicos. Según el Ministerio de Hacienda, de acuerdo con la Ley del Impuesto sobre Sucesiones y Donaciones, la transferencia gratuita de activos es un regalo, por lo que la transferencia gratuita de activos cifrados, como los airdrops, es una transacción sujeta al impuesto sobre donaciones; las donaciones de terceros de activos cifrados están gravados.

Pero la posición del gobierno es que la tributación real de los impuestos sobre donaciones debe determinarse caso por caso. El Ministerio de Planificación y Finanzas declaró: "El hecho de que una transacción específica de activos virtuales esté sujeta al impuesto sobre donaciones se determina de acuerdo con la situación de la transacción, como si se han transferido o no bienes reales y ganancias". Los impuestos sobre las ganancias de los activos cifrados comenzarán en 2025, pero el impuesto sobre donaciones de activos virtuales todavía está vigente. (Agencia de noticias Yonhap) [2022/8/22 12:39:50]

A continuación, analice el código específico de estas dos funciones:

Se puede ver que en la función  transferFrom , se realiza un juicio si en  mapAddress_Excluded[msg.sender]  primero. La lógica específica es que cuando mapAddress_Excluded[msg.sender] es falso, la autorización del El contrato del atacante se verificará Cuota y luego llamará a la función _transfer para transferir. Y esta lógica obviamente no funciona, el contrato del atacante no tiene ninguna cuota de autorización. Por lo tanto, mapAddress_Excluded[msg.sender] solo puede ser verdadero y luego llamar directamente a la función _transfer para transferir.

A continuación, analice cómo establecer mapAddress_Excluded[msg.sender] en verdadero:

Puede averiguarlo consultando el contrato:

Cuando se inicializa el contrato, solo address(this) y mapAddress_Excluded de burnAddress se establecen en verdadero, por lo que es seguro que hay otras lógicas que pueden establecer mapAddress_Excluded. Al analizar el contrato de  Vether, se puede encontrar que la función changeExcluded puede darse cuenta de la configuración de mapAddress_Excluded.

Al analizar la función changeExcluded se puede encontrar que su visibilidad es externa, por lo que el contrato del atacante puede llamar directamente a la función changeExcluded, en este momento el mapAddress_Excluded del contrato del atacante es falso, por lo que entrará en la lógica de if.

A continuación, analice el código en la lógica if en detalle:

Después de realizar la lógica if, primero debe pagar la tarifa de manejo, específicamente la línea 3 en el bloque de código anterior, entonces, ¿de dónde proviene la tarifa de manejo? La respuesta son los 0,9 ETH que el atacante transfirió inicialmente al contrato.

Como se puede ver en la figura, 0,9 ETH se convierte en unos 138 VETH.

Al calcular mapEra_Emission/16 en el código, podemos obtener la tarifa de transacción que el atacante debe pagar: leemos  mapEra_Emission en el contrato y sabemos que mapEra_Emission es 2048.

En este momento, la tarifa de manejo obtenida al calcular mapEra_Emission/16 es 2048/16 = 128 VETH, y el atacante intercambió alrededor de 138 VETH es suficiente para pagar la tarifa de manejo, por lo que el contrato del atacante se puede convertir para establecer mapAddress_Excluded en verdadero.

Cree un contrato de ataque y convierta 0.9 ETH en aproximadamente 138 VETH a través de Uniswap (aquí, el cambio de moneda es para el pago posterior de las tarifas de manejo)

Llame a la función changeExcluded en el contrato de Vether y use los 138 VETH intercambiados previamente en Uniswap para pagar la tarifa de manejo de 128 VETH, y luego establezca mapAddress_Excluded en verdadero

Llame a la función  transferFrom , use mapAddress_Excluded para que sea verdadero y realice directamente la operación de transferencia

Toma el dinero y vete

0xfa2700e67065bc364136b5e7f57112083cb2a0cd

0x75572098dc462f976127f59f8c97dfa291f81d8b

Soluciones sugeridas

Este ataque utiliza principalmente la visibilidad de la función changeExcluded en el contrato de Vether como externa y no tiene restricciones de permisos, los usuarios pueden hacer llamadas externas directamente para crear las condiciones necesarias para el ataque. Por lo tanto, el permiso o la visibilidad de la función changeExcluded debe restringirse para evitar que cualquier usuario llame directamente a la función changeExcluded externamente.

Tags：

SOL