Advertencia de seguridad Web3 丨 Un nuevo juego dentro de la cadena, descifrado del método Rug Pull a gran escala

Recientemente, el equipo de expertos en seguridad de CertiK ha detectado con frecuencia múltiples "estafas de salida" con las mismas tácticas, lo que se conoce comúnmente como Rug Pull.

Después de realizar una investigación en profundidad, descubrimos que múltiples incidentes con las mismas tácticas apuntaban a la misma pandilla y, en última instancia, estaban vinculados a más de 200 estafas de salida de tokens. Esto indica que es posible que hayamos descubierto un equipo de piratería automatizada a gran escala que recolecta activos mediante "estafas de salida".

En estas estafas de salida, el atacante creará un nuevo token ERC20 y creará un fondo de liquidez Uniswap V2 con el token preminado en el momento de la creación más una cierta cantidad de WETH.

Cuando el nuevo robot en la cadena o el usuario compra nuevos tokens en el fondo de liquidez una cierta cantidad de veces, el atacante utilizará los tokens generados de la nada para agotar todo el WETH en el fondo de liquidez.

Dado que los tokens obtenidos por el atacante de la nada no se reflejan en el suministro total (totalSupply) y no desencadenan el evento de Transferencia, no se pueden ver en etherscan, lo que dificulta que el mundo exterior los perciba.

Los atacantes no solo consideraron el ocultamiento, sino que también diseñaron un juego dentro de un juego para paralizar a los usuarios que tienen habilidades técnicas básicas y pueden leer etherscan, y usan un pequeño problema para encubrir su verdadero propósito...

Estafa más profunda

Tomemos uno de los casos como ejemplo para explicar los detalles de esta estafa de salida.

Lo que detectamos fue en realidad una transacción en la que el atacante utilizó una gran cantidad de tokens (acuñados en secreto) para drenar el fondo de liquidez y obtener ganancias. En esta transacción, la parte del proyecto utilizó un total de 416.483.104.164.831 (aproximadamente 416 billones) MUMI para exchange Se liberaron alrededor de 9.736 WETH, drenando la liquidez del pool.

Sin embargo, esta transacción es sólo el último eslabón de toda la estafa. Para comprenderla en su totalidad, debemos seguir rastreando hacia adelante.

Implementar tokens

A las 7:52 am del 6 de marzo (hora UTC, lo mismo a continuación), la dirección del atacante (0x8AF8), Rug Pull, desplegó un token ERC20 (dirección 0x4894) llamado MUMI (nombre completo MultiMixer AI) y lo preminó 420,690,000 (aproximadamente 420 millones) de tokens se asignaron y todos se asignaron a implementadores contratados.

![Advertencia de seguridad Web3 丨 Un nuevo juego dentro de la cadena, descifrado de técnicas de Rug Pull a gran escala] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-cff25d95ef-e2294f-ceda62)

La cantidad de tokens preminados corresponde al código fuente del contrato.

![Advertencia de seguridad Web3 丨 Un nuevo juego dentro de la cadena, descifrado a gran escala de la técnica Rug Pull] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-2e9fa046b5-e2294f-ceda62)

Agregar liquidez

A las 8 en punto (8 minutos después de que se creó el token), la dirección del atacante (0x8AF8) comenzó a agregar liquidez.

La dirección del atacante (0x8AF8) llama a la función openTrading en el contrato de token, crea un fondo de liquidez MUMI-WETH a través de uniswap v2 factory, agrega todos los tokens preminados y 3 ETH al fondo de liquidez y finalmente obtiene aproximadamente 1.036 tokens LP.

Se puede ver en los detalles de la transacción que de los 420.690.000 (aproximadamente 420 millones) de tokens utilizados originalmente para agregar liquidez, aproximadamente 63.103.500 (aproximadamente 63 millones) de tokens se enviaron de vuelta al contrato de token (dirección 0x4894). Se descubrió que el contrato de token cobrará una determinada tarifa de manejo por cada transferencia, y la dirección para cobrar la tarifa de manejo es el contrato de token en sí (implementado específicamente en la función "_transfer").

**Lo extraño es que la dirección fiscal 0x7ffb (la dirección para cobrar las tarifas de transferencia) se estableció en el contrato, pero la tarifa final se envió al contrato del token. **

Por lo tanto, el número final de tokens MUMI agregados al fondo de liquidez es 357.586.500 (aproximadamente 350 millones) después de impuestos, no 420.690.000 (aproximadamente 430 millones).

Bloquear liquidez

A las 8:01 (1 minuto después de que se creó el fondo de liquidez), la dirección del atacante (0x8AF8) bloqueó los 1.036 tokens LP obtenidos al agregar liquidez.

Después de bloquear el LP, teóricamente todos los tokens MUMI propiedad de la dirección del atacante (0x8AF8) se bloquean en el fondo de liquidez (excepto la parte utilizada como tarifas de manejo), por lo que la dirección del atacante (0x8AF8) no tiene la capacidad de eliminarla. a través de la capacidad de Liquidez para realizar Rug Pull.

Para permitir a los usuarios comprar tokens recién lanzados con confianza, muchas partes del proyecto bloquean LP, lo que significa que la parte del proyecto dice: "¡No huiré, todos pueden comprar con confianza!", Pero ¿es este realmente el caso? ? Evidentemente no, así es, sigamos con el análisis.

Tirador de alfombra

A las 8:10, apareció una nueva dirección del atacante ② (0x9DF4) y desplegó la dirección fiscal 0x7ffb declarada en el contrato del token.

Hay tres puntos que vale la pena mencionar aquí:

La dirección donde se implementa la dirección fiscal no es la misma que la dirección donde se implementan los tokens, lo que puede indicar que la parte del proyecto está reduciendo intencionalmente la correlación entre cada operación y la dirección, lo que dificulta el seguimiento del comportamiento.
El contrato de la dirección fiscal no es de código abierto, lo que significa que puede haber operaciones ocultas en la dirección fiscal que no desea exponer.
El contrato de impuestos se implementa más tarde que el contrato de token y la dirección de impuestos en el contrato de token ha sido codificada, lo que significa que la parte del proyecto puede predecir la dirección del contrato de impuestos, ya que la instrucción CREATE determina la dirección del creador. y una vez implementado, se determina la dirección del contrato, por lo que el equipo del proyecto simuló la dirección del contrato de antemano utilizando la dirección del creador.

**De hecho, muchas estafas de salida se llevan a cabo a través de direcciones fiscales, y las características del modo de implementación de las direcciones fiscales cumplen con los puntos 1 y 2 anteriores. **

A las 11 a. m. (3 horas después de que se creó el token), la dirección ② del atacante (0x9DF4) realizó un Rug Pull. Al llamar al método "swapExactETHForTokens" del contrato fiscal (0x77fb), intercambió 416.483.104.164.831 (aproximadamente 416 billones) de tokens MUMI en la dirección fiscal por aproximadamente 9,736 ETH y agotó la liquidez del pool.

Dado que el contrato de impuestos (0x77fb) no es de código abierto, descompilamos su código de bytes y los resultados de la descompilación son los siguientes:

Después de verificar el código descompilado del método "swapExactETHForTokens" del contrato de impuestos (0x77fb), encontramos que la función principal de esta función es transferir el contrato de impuestos (0x77fb) con el número "xt" (especificado por la persona que llama) a través Enrutador uniswapV2. Los tokens MUMI se intercambian por ETH y se envían a la dirección "_manualSwap" declarada en la dirección fiscal.

La dirección de almacenamiento de la dirección _manualSwap es 0x0. Después de consultar con el comando getStorageAt de json-rpc, se descubre que la dirección correspondiente a _manualSwap es el implementador del contrato de impuestos (0x77fb): atacante ② (0x9DF4).

El parámetro de entrada xt de esta transacción Rug Pull es 420.690.000.000.000.000.000.000, correspondiente a 420.690.000.000.000 (aproximadamente 420 billones) de tokens MUMI (el decimal de los tokens MUMI es 9).

En otras palabras, al final, el proyecto utilizó 420.690.000.000.000 (aproximadamente 420 billones) MUMI para drenar el WETH en el fondo de liquidez y completar toda la estafa de salida.

Sin embargo, aquí hay una pregunta crucial: ¿de dónde proviene el contrato fiscal (0x77fb) de tantos tokens MUMI?

Por el contenido anterior, sabemos que el suministro total de tokens MUMI en el momento de la implementación del contrato de tokens era 420.690.000 (aproximadamente 420 millones), y después de que terminó la estafa de salida, el suministro total que consultamos en el contrato de tokens MUMI La cantidad Todavía es 420,690,000 (que se muestra como 420,690,000,000,000,000 en la siguiente figura, debe restar 0 del dígito decimal correspondiente, que es 9). Los tokens en el contrato de impuestos (0x77fb) exceden con creces la oferta total (420,690,000,000,000, alrededor de 420 billones). Es como si surgiera de la nada, debes saber que como se mencionó anteriormente, 0x77fb, como dirección fiscal, ni siquiera se utilizó para recibir los gastos de manejo generados durante el proceso de transferencia del token MUMI, el impuesto lo recibió el contrato simbólico.

Técnica revelada

De dónde vino el contrato fiscal

Para explorar la fuente del token del contrato de impuestos (0x7ffb), analizamos su historial de eventos de transferencia ERC20.

Se encontró que entre los 6 eventos de transferencia relacionados con 0x77fb, solo hubo eventos de transferencia del contrato de impuestos (0x7ffb) y no hubo eventos en los que se transfirieron tokens MUMI. A primera vista, los tokens del contrato de impuestos ( 0x7ffb) realmente aparecieron de la nada.

Por tanto, los enormes tokens MUMI que aparecieron de la nada en la dirección del contrato fiscal (0x7ffb) tienen dos características:

Sin impacto en la oferta total del contrato MUMI
El aumento de tokens no desencadenó el evento de Transferencia.

Entonces la idea es muy clara, es decir, debe haber una puerta trasera en el contrato del token MUMI, esta puerta trasera modifica directamente la variable de saldo, y al modificar balabce no modifica totalSupply y no desencadena el evento Transfer.

En otras palabras, se trata de una implementación de token ERC20 no estándar o maliciosa. Los usuarios no pueden detectar que el lado del proyecto está acuñando tokens en secreto a partir de cambios en el suministro total y los eventos. **

El siguiente paso es verificar la idea anterior: buscamos directamente la palabra clave "saldo" en el código fuente del contrato del token MUMI.

Como resultado, encontramos que hay una función de tipo privado "swapTokensForEth" en el contrato y el parámetro de entrada es tokenAmount del tipo uint256. En la quinta línea de la función, la parte del proyecto modifica directamente _taxWallet, que es MUMI El saldo del contrato fiscal (0x7ffb) es tokenAmount * 10**_decimals, que es 1.000.000.000 (aproximadamente mil millones) de veces el tokenAmount, y luego convierte el monto tokenAmount de MUMI en ETH del fondo de liquidez y lo almacena. en el contrato de token (0x4894).

Luego busque la palabra clave "swapTokenForEth".

La función "swapTokenForEth" se llama en la función "_transfer". Si observa detenidamente las condiciones de llamada, encontrará:

Cuando la dirección receptora de la transferencia sea el pool de liquidez MUMI-WETH.
La función "swapTokenForEth" solo se llamará cuando otras direcciones compren tokens MUMI en el fondo de liquidez por más de _preventSwapBefore (5 veces)
El tokenAmount entrante es el valor menor entre el saldo del token MUMI propiedad de la dirección del token y _maxTaxSwap.

Es decir, cuando el contrato detecta que el usuario ha intercambiado WETH por tokens MUMI en el pool más de 5 veces, acuñará en secreto una gran cantidad de tokens para la dirección fiscal, convertirá parte de los tokens en ETH y los almacenará. ellos en el contrato simbólico.

**Por un lado, la parte del proyecto aparentemente recauda impuestos y los cambia automáticamente por una pequeña cantidad de ETH regularmente y los coloca en el contrato de token. Esto es para que los usuarios lo vean, lo que hace que todos piensen que esta es la fuente del proyecto. las ganancias del partido. **

**Por otro lado, lo que realmente está haciendo el equipo del proyecto es modificar directamente el saldo de la cuenta y drenar todo el fondo de liquidez después de que el número de transacciones del usuario alcance 5 veces. **

Cómo obtener ganancias

Después de ejecutar la función "swapTokenForEth", la función "_transfer" también ejecutará sendETHToFee para enviar el ETH obtenido de la recaudación de impuestos en la dirección del token al contrato de impuestos (0x77fb).

El ETH en el contrato de impuestos (0x77fb) se puede retirar mediante la función de "rescate" implementada en su contrato.

Ahora mire nuevamente el registro de canje de la última transacción rentable en toda la estafa de salida.

En la rentable transacción se realizaron un total de dos intercambios: la primera vez fue de 4.164.831 (aproximadamente 4,16 millones) de tokens MUMI por 0,349 ETH, y la segunda vez fue de 416.483.100.000.000 (aproximadamente 416 billones) de tokens MUMI por 9,368 ETH. El segundo intercambio es el intercambio iniciado dentro de la función "swapExactETHForTokens" en el contrato de impuestos (0x7ffb). La razón por la cual el número no coincide con los 420,690,000,000,000 (aproximadamente 420 billones) de tokens representados por los parámetros de entrada es porque algunos de los tokens se utilizan. como impuesto Enviado al contrato de token (0x4894), como se muestra en la siguiente figura:

El primer intercambio corresponde al segundo proceso de intercambio. Cuando el token se envía desde el contrato de impuestos (0x7ffb) al contrato del enrutador, se cumple la condición de activación de la función de puerta trasera en el contrato del token, lo que provoca que se active "swapTokensForEth". por la función no es una operación crítica.

La guadaña detrás

Como se puede ver en lo anterior, todo el ciclo de estafa de salida, desde el despliegue hasta la creación del fondo de liquidez y la extracción de tokens MUMI, solo toma aproximadamente 3 horas, pero a un costo de menos de aproximadamente 6,5 ETH (se usan 3 ETH para Para agregar liquidez, se usaron 3 ETH para intercambiar MUMI del fondo de liquidez por incentivos, y se usaron menos de 0,5 ETH para implementar contratos e iniciar transacciones) y se obtuvieron 9,7 ETH, con una ** ganancia de más del 50%. **

Hubo 5 transacciones en las que el atacante intercambió ETH por MUMI, las cuales no fueron mencionadas en el artículo anterior, la información de la transacción es la siguiente:

Al analizar las direcciones EOA que operan en liquidez, encontramos que una parte considerable de las direcciones son "nuevos robots" en la cadena. Combinado con las características de toda la estafa, que entra y sale rápidamente**, tenemos razones para creer A qué se dirige toda esta estafa. Los objetivos son todo tipo de nuevos robots y nuevos scripts que están muy activos en la cadena. **

Por lo tanto, ya sea el diseño del contrato, la implementación del contrato y el proceso de bloqueo de liquidez del token, aparentemente innecesario pero complicado, o el comportamiento sospechoso de la dirección relacionada del atacante que intercambia activamente ETH por tokens MUMI, se puede entender que el atacante está tratando de Un disfraz elaborado para intentar engañar a los programas antifraude de varios nuevos bots de la cadena. **

Al rastrear el flujo de capital, descubrimos que todas las ganancias del ataque finalmente se enviaron a la dirección de liquidación del fondo ** (0xDF1a) ** por la dirección de ataque ② (0x9dF4).

De hecho, la fuente inicial de fondos y el destino final de los fondos para muchas estafas de salida que hemos detectado recientemente apuntan a esta dirección, por lo que hemos realizado un análisis aproximado y estadísticas sobre las transacciones en esta dirección.

Finalmente se descubrió que la dirección se activó hace aproximadamente 2 meses y ha iniciado más de 7000 transacciones hasta el día de hoy y que la dirección ha interactuado con más de 200 tokens.

Analizamos alrededor de 40 registros de transacciones de tokens y descubrimos que en los fondos de liquidez correspondientes a casi todos los tokens que analizamos, eventualmente habría una transacción de intercambio con una cantidad de entrada que era mucho mayor que el suministro total del token. El ETH entrante se agota y el período completo de salida de la estafa es más corto.

Las transacciones de implementación de algunos de los tokens (Mingyan China) son las siguientes:

Por lo tanto, podemos concluir que esta dirección es en realidad una cosechadora automatizada de "estafa de salida" a gran escala, y el objetivo de la cosecha es el nuevo robot de la cadena.

**Esta dirección aún está activa. **

Escribe al final

Si un token no modifica el suministro total durante la acuñación y no activa el evento Transfer, entonces será difícil para nosotros detectar si el lado del proyecto está acuñando tokens en secreto, lo que también exacerbará el problema de si el token es seguro o no. No depende enteramente del lado del proyecto: "consciente o no" status quo.

**Por lo tanto, es posible que debamos considerar mejorar el mecanismo de tokens existente o introducir una solución eficaz de detección de la cantidad total de tokens para garantizar la apertura y transparencia de los cambios en la cantidad de tokens. **No es suficiente capturar los cambios de estado de los tokens con eventos ahora.

Y a lo que debemos estar alerta es a que, aunque la conciencia antifraude de todos está mejorando, los métodos antifraude de los atacantes también están mejorando. Este es un juego sin fin. Necesitamos seguir aprendiendo y pensando para poder hacer esto. Protégete en el juego.

Ver originales

1 me gusta

Recompensa
1
Comentar
Compartir

Comentar

0/400

Sin comentarios

Tema
#BTC#
151k publicaciones
#ETH#
92k publicaciones
#GateioInto11#
71k publicaciones
4#ContentStar#
61k publicaciones
5#BOME#
58k publicaciones
6#SLERF#
50k publicaciones
7#MAGA#
50k publicaciones
8#DOGE#
47k publicaciones
9#PIGCOIN#
45k publicaciones
10#比特币#
45k publicaciones