Por: 九九

fondo

El 5 de diciembre de 2023, la plataforma de desarrollo básico Web3, Thirdweb, declaró que se encontró un problema de seguridad en el contrato inteligente prediseñado y que todos los tokens ERC20, ERC721 y ERC1155 implementados mediante el contrato inteligente prediseñado se vieron afectados. (Para conocer las versiones específicas del código de contrato afectadas, consulte: https://blog.thirdweb.com/security-vulnerability/)

Según la inteligencia del equipo de seguridad de SlowMist, el 7 de diciembre de 2023, el token Time en la red principal de ETH fue atacado precisamente debido a esta vulnerabilidad, y el atacante obtuvo una ganancia de aproximadamente 190.000 dólares estadounidenses. Todavía hay muchos contratos simbólicos con vulnerabilidades que están siendo atacados. El equipo de seguridad de SlowMist intervino inmediatamente en el análisis y compartió los resultados de la siguiente manera:

conocimientos previos

1. ERC-2771 es el estándar para metatransacciones. Los usuarios pueden delegar la ejecución de transacciones a un reenviador externo, a menudo llamado retransmisor o reenviador.

Por lo general, la dirección de la persona que llama directamente en el contrato se obtiene usando msg.sender, pero en el caso de usar ERC-2771, si msg.sender es la función de reenvío, los datos de la llamada entrante se truncarán y se obtendrán las últimas 20 palabras. . sección como la dirección de la persona que llama directamente de la transacción.

2. Multicall es una biblioteca de contratos inteligentes que permite ejecutar múltiples llamadas a funciones en lotes, reduciendo así los costos de transacción. Esta biblioteca se utiliza a menudo para optimizar el rendimiento y la experiencia del usuario de las DApps, especialmente cuando se requieren múltiples operaciones de lectura.

Como se puede ver en el código, la biblioteca Multicall utilizada por el contrato vulnerable en el proyecto de ThirdWeb ejecuta otras funciones en el contrato que hace referencia a la biblioteca llamando cíclicamente a la función DelegateCall.

causa principal

La causa principal de la vulnerabilidad es que el contrato de token utiliza las bibliotecas ERC-2771 y Multicall. El atacante llama a la función de llamada múltiple del contrato de token a través de la función de ejecución del contrato de reenviador para ejecutar otras funciones en el contrato (como quemar tokens). Este método pasa con éxito el juicio isTrustedForwarder de ERC-2771 y finalmente resuelve la persona que llama a la función en los últimos 20 bytes de los datos de llamada maliciosos. Por lo tanto, el atacante logró engañar al contrato haciéndole creer que la persona que llama era la dirección de otro usuario, lo que a su vez provocó la quema de los tokens de otros usuarios.

Análisis de los pasos del ataque.

Aquí tomamos la transacción de ataque 0xecdd11...f6b6 como ejemplo para el análisis:

1. El atacante utilizó por primera vez 5 WETH para intercambiarlos por 345.539.9346 tokens de tiempo en el grupo Uniswap V2.

2. Luego llame a la función de ejecución del contrato de reenvío para construir datos maliciosos para llamar a la función de llamada múltiple del contrato de token. En este momento, el contrato de token delegará la llamada para ejecutar la función de grabación del contrato de token en función de los datos maliciosos pasados. por el atacante, quemando la dirección del grupo 62,227,259,510 tokens de tiempo.

3. Dado que el paso anterior quemó una gran cantidad de tokens de Tiempo en el grupo, lo que provocó que el precio de los tokens de Tiempo aumentara instantáneamente, el atacante finalmente puede invertir el intercambio de los tokens de Tiempo obtenidos en el primer paso, vaciando el grupo.

Análisis del principio de ataque.

En la función de ejecución del contrato Forward, después de verificar la firma de req.from, se utilizará la llamada para interactuar con req.to (dirección del token). Los datos solicitados pasados ​​por el atacante son

Debido a que 0xac9650d8 es la firma de la función de llamada múltiple, se llamará a la función de llamada múltiple del contrato de token y el valor de datos pasado por la función de llamada múltiple es 0x42966c68000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc 1 e043d99394a10605b2fa08f123d60faf84.

¿Por qué no hay ningún req.from en el valor de datos pasado a la función multicall? Esto se debe a que la capa inferior de EVM truncará el valor requerido según el desplazamiento al procesar la llamada. El desplazamiento establecido en el valor de datos de llamada pasado por el atacante es 38 y la longitud del valor es 1, por lo que simplemente intercepta el valor de los datos. 42966c680000000000000000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf84.

Para obtener más información, consulte la descripción de la llamada en el código de operación de EVM (https://www.evm.codes/?fork=shanghai).

Dado que 0x42966c68 es la firma de la función de grabación, la función de grabación del contrato de token se llamará a través de una llamada delegada en función del valor de datos construido por el atacante.

La función _msgSender() es anulada por la biblioteca ERC-2771.

Dado que la llamada múltiple se llama a través de la llamada delegada, el msg.sender pasado por isTrustedForwarder es en realidad la dirección del contrato de reenvío, por lo que se pasa el juicio y, en última instancia, el valor devuelto por _msgSender() son los últimos 20 bytes de los datos de llamada pasados. es decir, la dirección del grupo es 0x760dc1e043d99394a10605b2fa08f123d60faf84.

en conclusión

La causa principal de este ataque es que el contrato hace referencia tanto a Multicall como a ERC2771Context. El atacante puede insertar datos de llamada maliciosos en la solicitud de reenvío, usar la función de llamada delegada de Multicall para emitir el juicio del reenviador confiable y manipular _msgSender() en el. subllamada.Análisis, para que el token de cualquier usuario pueda ser manipulado.

El equipo de seguridad de SlowMist recomienda que las partes del proyecto no utilicen Multicall y ERC2771Context al mismo tiempo al escribir contratos de token. Si la demanda esperada requiere referencia simultánea, debe verificar si la longitud de los datos de llamada cumple con las expectativas o usar la última versión oficial de Openzeppelin. ERC2771Contratos contextuales.

referencia

Dirección del atacante: 0xfde0d1575ed8e06fbf36256bcdfa1f359281455a

Contrato de ataque: 0x6980a47bee930a4584b09ee79ebe46484fbdbdd0

Transacciones de ataque relacionadas: https://etherscan.io/tx/0xecdd111a60debfadc6533de30fb7f55dc5ceed01dfadd30e4a7ebdb416d2f6b6

Detalles de la versión afectada: https://blog.thirdweb.com/security-vulnerability/

Herramienta de mitigación: https://mitigate.thirdweb.com/