CertiK analiza la incidencia con Axion Community y la posterior bajada de precios

[ad_1]

El 2 de noviembre, Axion Community lanzó su nuevo token llamado AXN. El proyecto promocionó el activo como un nuevo vehículo de inversión, alegando que period la cadena de bloques más rentable de su tipo hasta la fecha. Durante la preparación provisional del Airdrop de AXN, cinco equipos separados supuestamente examinaron el código del token. Los expertos de la industria como CertiK y Hacken estaban entre los que realizaron las auditorías.

Sin embargo, unas horas después del evento Freeclaim del registro, quedó claro que algo había salido mal. Un actor no autorizado acuñó inesperadamente AXN 79 mil millones y lo arrojó al mercado. El precio se desplomó más del 99% y les valió a los atacantes 1.300 ETH geniales, valorados en un estimado de 500.000 dólares en el momento de la publicación.

En las horas que siguieron, el equipo detrás del proyecto Axion alentó a los participantes a mantenerse alejados de comerciar o interactuar con el activo, indicando en el canal oficial de Telegram de la plataforma:

“No compre AXN ahora, no interactúe con el tablero”.

La cuenta de Twitter de la crimson Axion continuó publicando actualizaciones que incluyen:

A pesar de estas garantías, CertiK está dando un paso adelante para brindar a la comunidad una explicación más clara de lo que creen que salió mal e información sobre cómo se podrían prevenir ataques similares en el futuro. Cointelegraph envió un correo electrónico a “Jack Durden”, quien nos fue descrito como CEO de Axion Community, pero no recibió respuesta inmediata. Ningún miembro del equipo aparece en el documento técnico ni en el sitio net del proyecto, y el nombre “Jack Durden” se le da al narrador invisible de la película. Membership de la lucha.

Tenga en cuenta que el resto de este artículo se reproduce palabra por palabra como un servicio público con permiso de CertiK para ayudar a educar a los lectores sobre la comprensión del equipo de auditoría de lo sucedido. Cointelegraph no ha revisado el código y, por lo tanto, las vistas que se enumeran a continuación son solo las de CertiK.

Los empleados de CertiK informan sobre la caída de precios de Axion

El 2 de noviembre de 2020, alrededor de las 11:00 a.m. + UTC, un pirata informático logró acuñar alrededor de 80 mil millones de tokens AXN utilizando la función de participación del contrato de participación de Axion.

Luego, el hacker colocó los tokens en el intercambio Uniswap de AXN por ether y repitió este proceso hasta que el intercambio Uniswap estuvo vacío y el precio del token se redujo a 0.

Fuimos notificados del incidente minutos después del ataque y nuestros analistas de seguridad comenzaron a evaluar la situación de inmediato.

Hemos concluido que el ataque probablemente fue diseñado desde adentro y, en el momento en que se implementó el código, estaba inyectando código malicioso modificando el código de las dependencias de OpenZeppelin.

La función explotada no fue parte de la auditoría que realizamos, ya que se agregó después de que el código de Axion se “aplanara” con el código de OpenZeppelin y se insertara en el código de OpenZeppelin antes de la implementación.

planificación

El hacker utilizó fondos anónimos obtenidos de twister.money el día antes del hack, lo que indicó un ataque temporal. Presuntamente para ahorrar dinero en caso de que el ataque fracasara, se pusieron en circulación 2.1 ethers inmediatamente después de recibir el dinero en twister.money.

Para completar la configuración del ataque, el pirata informático compró alrededor de 700,000 tokens HEX2T del intercambio Uniswap. Sin embargo, estos recursos en última instancia no fueron parte del ataque y actuaron como una cortina de humo en relación con la evolución del ataque.

Instalar

El pirata informático inició su ataque creando un despliegue “vacío” para el contrato de despliegue de la crimson Axion llamando a la función de despliegue con un despliegue de Zero y una duración de despliegue de 1 día alrededor de las 09:00 + UTC. Esto creó una entrada de sesión para el atacante con un valor de Zero y un valor de autorización de Zero para el ID de sesión 6.

Luego, el atacante aprobó una cantidad ilimitada de AXN para el intercambio Uniswap antes de que el ataque tuviera éxito. Como resultado, aprobaron el contrato NativeSwap de Axion por la cantidad de fondos que querían convertir en tokens AXN.

Invocaste la función de depósito del contrato NativeSwap alrededor de las 10:00 a.m. + UTC. Sin embargo, el hacker nunca llamó a la función inversa del contrato para reclamar su AXN intercambiado, como se puede ver en la función swapTokenBalanceOf del contrato NativeSwap. Después de eso, hicieron otra llamada fallida a la función de depósito antes de lanzar el ataque.

ejecución

Estas transacciones no fueron más que una cortina de humo para la implementación actual del ataque sin participación. Dado que las transacciones realizadas por el atacante no cambiaron el mapeo de sessionDataOf, concluimos que se trataba de un ataque de múltiples direcciones.

Examinamos el código fuente del contrato en el repositorio de GitHub que se compartió con nosotros para identificar un error que daría como resultado que el mapeo sessionDataOf se vea comprometido.

No pudimos identificar ninguna asignación a él ni a ningún miembro fuera de las funciones de estaca, lo que nos llevó a cuestionar si los contratos se estaban utilizando correctamente.

Vector de ataque

Después de analizar el código fuente del contrato de participación proporcionado, identificamos una inyección de código en la biblioteca AccessControl OpenZeppelin entre L665-L671 del código fuente proporcionado por el contrato de participación. La función checkRole asociada no forma parte de la implementación de OpenZeppelin v3.0.1, que se incluyó como una dependencia en el repositorio de GitHub del proyecto.

El siguiente bloque de ensamblaje existe dentro de la función checkRole:

Esta función especial permite a una dirección específica realizar cualquier escritura en el contrato en función de las variables de entrada, que complementa mediante llamadas de bajo nivel. Comentó que el bloque de ensamblaje se vería así:

esta función fue inyectado durante el uso Dado que no está presente en la implementación de OpenZeppelin AccessControl, los miembros de la crimson Axion que participaron en el suministro del token actuaron de forma maliciosa.

Conclusión

El ataque utilizó código que se insertó intencionalmente antes de que se implementara el registro. Este incidente no está relacionado con las auditorías realizadas por CertiK y la parte responsable del ataque fue alguien que parecía estar involucrado en la entrega de los contratos de Axion Community.

Como nivel adicional de seguridad, los informes de prueba deben estandarizarse de tal manera que contengan direcciones de contrato inteligentes proporcionadas, cuyo código fuente sea idéntico al verificado.

El oráculo de seguridad actúa como un retransmisor en cadena para la información de seguridad y realiza revisiones de seguridad, incluida la revisión de los contratos inteligentes implementados para compararlos con las versiones revisadas.