Vulnerabilidades de intercambio descentralizado

En el último mes, las pérdidas como resultado de los ataques de piratas informáticos a la comunidad criptográfica han aumentado a $ 1.019B (24.10), superando los últimos meses (omitiendo el incidente de Terra Luna)

Al observar más de cerca, podemos ver que las principales vulnerabilidades se llevaron a cabo en plataformas DEX (intercambio descentralizado), sumando casi el 15% de las pérdidas totales solo en octubre.

Con eso en mente, profundicemos en tres casos en el mundo de la explotación de DEX e intentemos responder estas preguntas:

• ¿Cuáles son las principales causas de las vulnerabilidades DEX?
• ¿Cómo podemos evitar esto en el futuro?

Intercambio de plátano

El 28 de agosto, el intercambio de tokens $DDC, Intercambio de plátano, fue atacado. El atacante manipuló con éxito el precio de la moneda al romper la lógica interna del cálculo del precio y, como resultado, intercambió 23 $DDC por 110,105 XNUMX $BUSD.

La vulnerabilidad era bastante simple, pero el impacto tenía un enorme potencial de ganancias:

1. El ataque comenzó con una transacción de 26 $DDC a la cuenta del atacante
2. Luego se inició una búsqueda de la billetera de una víctima para encontrar una billetera que contiene una gran cantidad de tokens.
3. [Explotación] Cuando se encontró una cuenta adecuada, el atacante llamó handleDeductFee que realizó un deducción de casi todas las fichas del saldo de la víctima
4. Para finalizar la manipulación de precios, la función sync fue llamado para actualizar el valor/precio de $DDC

Como resultado, el saldo de $DDC en el grupo se redujo a 0.0003 $DDC, después de que se actualizó el valor/precio, el precio de $USD correspondiente a $DDC aumentó significativamente y se puede intercambiar una gran cantidad de $USD a través de una pequeña cantidad de $DDC. El hacker usó 23 $DDC para cambiar por 104,600 USD.

Entonces, ¿cómo era posible que un atacante manipulara el saldo de la cuenta de la víctima? ¿Cuál fue el handleDeductFee ejecutando la funcion?

Echemos un vistazo al código:

function handleDeductFee (ActionType actionType, uint256 feeAmount, address from, address user) external override {
	distributeFee(actionType, feeAmount, from, user);
}

// deduct the config fee and transfer to handle fee address which config.
// parameter from
function distributeFee (ActionType actionType, uint feeAmount, address from, address user) internal { 
	_balances [from] = _balances[from].sub(feeAmount);
	...
}

Aquí tenemos una función externa con argumentos controlables que llama a una función interna pasando los mismos argumentos como parámetros que realiza una deducción usando estos argumentos de inmediato.

El atacante pasó la dirección de la víctima como el from parámetro y el feeAmount fue ligeramente menor que el resultado de balanceOf de esta dirección.

¡Eso es todo! Ni una sola validación de los datos entrantes. No hay una teoría compleja detrás de eso en absoluto.

cibernético Seguridad 101: nunca confíe en los datos controlados por el usuario.

Se puede encontrar más información en la publicación de Twitter de Beosin Alert esta página.

A continuación, revisaremos un protocolo más complejo. Pero como ya vimos, perder una línea de código puede romper todo el sistema.

Intercambio de tránsito

Intercambio de tránsito es una plataforma de agregador DEX multicadena que se ejecuta en las cadenas Ethereum y Binance. El 1 de octubre, la plataforma fue víctima de un ataque que drenó activos por valor de casi $ 29 millones de las billeteras de los usuarios del protocolo.

El intercambio con Transit Swap implica pasar por un par de contratos que enrutan y unen a diferentes intercambiadores y hacen cumplir la administración de permisos. Cada uno de los contratos llama al otro pasando sus parámetros como argumentos al siguiente, cada uno de ellos usa los parámetros para procesar alguna lógica y ejecutar acciones.

Una versión simplificada del flujo de datos se parece a esto:

Como mencioné anteriormente, cada uno de los contratos llama al siguiente que pasa los argumentos como parámetros, entonces, ¿por qué es esto tan crítico?

"La razón principal de este ataque es que el protocolo Transit Swap no valida estrictamente los datos que el usuario pasa durante el intercambio de tokens, lo que da como resultado una llamada externa arbitraria". – Análisis de SlowMist

Ninguno de los contratos validó adecuadamente los datos utilizados para realizar la transacción. Como resultado, el atacante manipuló con éxito toda la cadena pasando datos específicamente elaborados para cada paso de la transacción.

Este es otro caso más de validación de datos con una vulnerabilidad a mayor escala. Avancemos hacia una de las mayores pérdidas de este año:

Intercambio Maiar – Red Elrond

El tercer ataque DEX más rentable de todos los tiempos se llevó a cabo en el Maiar DEX. Los piratas informáticos explotaron una función vulnerable recientemente implementada en la red principal. Vaciaron con éxito las reservas del protocolo, robando $ 113 millones de activos.

El exploit comenzó con una función. executeOnDestByCaller que permitió que el contrato A realizara acciones en el contrato C a través del proxy B. El contrato A llamará a una función dentro de B que le permite a B realizar acciones en C en nombre del contrato A.

Para ilustrar esto, ilustraremos los contratos A, B y C. El contrato A llama foo eso esta dentro de b foo llamadas executeOnDestByCaller que permite a B ejecutar la función bar del Contrato C como impostor de A.

En la práctica, el contrato B puede ejecutar todas las funciones en nombre de A si A hizo la primera llamada a B. Esta idea ya suena un poco sospechosa.

Para crear un exploit usando esta función, uno necesita descubrir cómo hacer que la víctima llame al contrato y luego uno puede hacer lo que quiera con ese contrato usando las funciones externas que proporciona como transferFrom.

Afortunadamente para los hackers, Elrond tiene un concepto llamado Devoluciones de llamada. Al usar estas devoluciones de llamada, se puede pasar una función maliciosa como devolución de llamada a la víctima, que no tendrá otra opción que ejecutar la devolución de llamada y el resto es historia.

Si desea profundizar más, consulte Informe oficial de Elrond y Desglose del ataque de Arda.

Así que no había vulnerabilidad en el código, sino más bien una falla lógica. El público ha encontrado múltiples problemas de seguridad con esta función después de la implementación, pero el parche y la corrección podrían entregarse solo una semana después, exponiendo así todos los contratos a una vulnerabilidad potencial durante toda una semana.

respondiendo las preguntas

Sabiendo lo que sabemos ahora, podemos abordar esas preguntas.

Los incidentes discutidos comparten una causa común: la vulnerabilidad del contrato inteligente. Todos estamos familiarizados con los términos vulnerabilidades y exploits en otros escenarios, entonces, ¿qué lo hace diferente en el escenario del contrato inteligente?

1. De código abierto: como todos sabemos, la 'D' en DEX significa Descentralizado, lo que significa que el producto es impulsado por los usuarios y eso hace que el código sea accesible para el mundo. Esto hace que las vulnerabilidades sean más fáciles de encontrar.
2. Difícil de actualizar: el costo de encontrar y actualizar una vulnerabilidad es mucho mayor que en una aplicación fuera de la cadena. A medida que los contratos se cargan en la cadena, parchear una vulnerabilidad significa cargar una nueva copia del contrato y redirigir todas las direcciones de la antigua a la nueva si no se está utilizando ningún contrato de proxy.

Por lo tanto, no tenemos una segunda oportunidad. Debemos asegurarnos de que el contrato esté libre de errores y sea seguro antes de subirlo a la cadena.

Las auditorías de seguridad antes de la carga y el monitoreo constante de las amenazas de seguridad son medidas cruciales en el mundo de las aplicaciones descentralizadas.

Conclusión

Estos ejemplos cubren solo una parte de las vulnerabilidades y los problemas que se encuentran en los contratos inteligentes. A medida que avance el desarrollo de la Web 3, se introducirán en el mundo algoritmos más complejos, algoritmos que pueden desempeñar un papel importante en el próximo exploit y causar pérdidas de fondos.

Analizar exploits pasados ​​y mitigar, auditar y verificar el código puede evitar bajas en los fondos y marcar una gran diferencia en el futuro de las aplicaciones descentralizadas.