El 2 de noviembre, Axion Network lanzó su nuevo token, conocido como AXN. El proyecto promocionó el activo como un nuevo vehículo de inversión, alegando que sería la cadena de bloques más rentable de su tipo hasta la fecha. Durante el tiempo que llevó al airdrop de AXN, cinco equipos separados supuestamente examinaron el código del token; los consentidos de la industria como CertiK y Hacken estuvieron entre los involucrados en las auditorías.

Sin embargo, pocas horas después del evento para recbir gratuitamente el token del protocolo, quedó claro que algo salió mal. Un actor no autorizado acuñó inesperadamente 79 mil millones de AXN y los vertió en el mercado. El precio se desplomó en más del 99%, lo que hizo que los atacantes obtuvieran unos asombros 1,300 ETH, aproximadamente USD 500,000 dólares para el momento de la publicación de este artículo.

En las horas posteriores, el equipo detrás del proyecto Axion animó a los participantes a mantenerse alejados del comercio o de cualquier interacción con el activo, declarando a través del canal de Telegram oficial de la plataforma:

"No compren AXN ahora mismo, no interactúen con el tablero".

La cuenta de Twitter de Axion Network continuó publicando actualizaciones, incluyendo esta:

A pesar de estas garantías, CertiK está dando un paso al frente para ofrecer a la comunidad una explicación más clara de lo que salió mal, y una idea de cómo se podrían prevenir ataques similares en el futuro. Cointelegraph contactó por correo electrónico a "Jack Durden", quien nos fue descrito como el CEO de Axion Network, pero no recibimos una respuesta inmediata. Ningún miembro del equipo aparece en el libro blanco del proyecto o en el sitio web, y el nombre "Jack Durden" es el mismo del narrador invisible de la película El club de la pelea.

Nótese que el resto de este artículo fue redactado palabra por palabra, cortesía de CertiK, como un servicio público para educar a los lectores sobre la comprensión del equipo de auditoría de lo que sucedió. Cointelegraph no auditó el código y por lo tanto los puntos de vista que serán expresados a continuación son exclusivamente los de CertiK.

El personal de CertiK informa sobre la caída del precio de Axion

El 2 de noviembre de 2020, aproximadamente a las 11:00 AM +UTC, un hacker logró acuñar alrededor de 80 mil millones de tokens AXN utilizando la función de unstake del contrato de Axion Staking.

El hacker procedió a verter los tokens AXN por Ether en Uniswap, repitiendo este proceso hasta secar el exchange de Uniswap y llevar el precio del token a 0.

Nos informaron del incidente a los pocos minutos de producirse el ataque y nuestros analistas de seguridad comenzaron a evaluar la situación inmediatamente.

Llegamos a la conclusión de que el ataque fue probablemente planeado desde el interior, implicando una inyección de código malicioso en el momento en que el código fue desplegado, alterando el código de las dependencias de OpenZeppelin.

La función aprovechada no fue parte de la auditoría que realizamos ya que fue añadida luego de unir el código de Axion con el de OpenZeppelin mediante "aplanamiento" e inyectándolo dentro del código de OpenZeppelin antes de que fuese lanzado.

Planeando el ataque

El hacker usó fondos anónimos obtenidos de Tornado.Cash el día antes de que ocurriera el ataque, insinuando un ataque premeditado. Presuntamente para salvar algunos fondos en caso de que el ataque fracasara, 2.1 ETH fueron depositados de vuelta en Tornado.cash justo después de que la cuenta recibiera los fondos.

Para finalizar la preparación del ataque, el hacker compró alrededor de 700,000 tokens HEX2T en el exchange de Uniswap. Sin embargo, estos fondos no fueron utilizados finalmente en el ataque y sirvieron como una cortina de humo con respecto a cómo se desarrolló el ataque.

Preparación

El hacker comenzó a abrirse paso hasta su ataque creando un stake "vacío" en el contrato de staking de Axion Network, iniciando la función de stake con una cantidad de 0 y una duración de 1 día aproximadamente a las 09:00 AM +UTC. Esto creó una entrada de sesión para el atacante con una cantidad de 0 y un valor de 0 acciones en la sesión ID 6.

Luego, el atacante preaprobó una cantidad ilimitada de AXN para el exchange de Uniswap previendo de que su plan tendría éxito. Consecuentemente, aprobaron el contrato de NativeSwap de Axion por la cantidad de fondos que pretendían convertir en tokens AXN.

Iniciaron la función de depósito del contrato de NativeSwap aproximadamente a las 10:00 AM + UTC, sin embargo,  el hacker nunca inició a la función de retiro del contrato para reclamar su AXN intercambiado como se evidencia en la swapTokenBalanceOf de NativeSwap. Después, intentaron iniciar fallidamente la función de depósito antes de ejecutar el ataque.

Poniéndolo en marcha

Estas transacciones eran simplemente cortinas de humo para ver cómo se llevaba a cabo el ataque de unstake. Como las transacciones que el atacante realizó no resultaron en ningún cambio en la datos de la sesión de mapeo, concluimos que se trataba de un ataque de múltiples direcciones.

Investigamos el código fuente del contrato en el repositorio GitHub que había sido compartido con nosotros para identificar una falla que causaría que los datos de la sesión de mapeo se vieran afectados.

No pudimos detectar ninguna asignación a ella o a sus miembros fuera de las funciones de stake, lo que nos llevó a cuestionar si el despliegue de los contratos se llevó a cabo de la manera adecuada.

Vector de Ataque

Tras analizar el código fuente del contrato de staking desplegado, localizamos una inyección de código en la biblioteca AccessControl OpenZeppelin entre L665-L671 del código fuente desplegado del contrato de staking. La función checkRole vinculada no forma parte de la implementación de OpenZeppelin v3.0.1, la cual fue listada como una dependencia en el repositorio GitHub del proyecto.

Dentro de la función checkRole, existe el siguiente bloque de ensamblaje:

Esta función en particular permite a una dirección específica llevar a cabo una escritura arbitraria del contrato basada en las variables de entrada que complementa a través de llamadas de bajo nivel. Anotado, el bloque de ensamblaje se vería así:

Esta función se inyectó en el momento de despliegue, ya que no existe en la implementación de OpenZeppelin AccessControl, lo que significa que los miembros de Axion Network que participaron en el despliegue del token actuaron malintencionadamente.

En conclusión

El ataque utilizó un código que fue inyectado deliberadamente antes del lanzamiento del protocolo. Este incidente no tiene relación alguna con las auditorías realizadas por CertiK y la parte responsable del ataque fue una persona que al parecer estaba involucrada en el despliegue de los contratos de la Axion Network.

Como un grado adicional de seguridad, los informes de auditoría deberían estandarizarse para incluir las direcciones de contratos inteligentes desplegados cuyo código fuente verificado sea el mismo que el auditado.

Security Oracle sirve como un retransmisor en cadena de inteligencia de seguridad, realizando controles de seguridad que incluyen la verificación de contratos inteligentes implementados para que coincidan con las versiones auditadas.

Sigue leyendo: