A última hora de la noche del domingo 5 de Junio de 2022, se comenzó a informar sobre una gran cantidad de actividad sospechosa en la red principal de Elrond, incluidas grandes transferencias de EGLD y grandes intercambios en Maiar Exchange. El equipo se reunió rápidamente para investigar esta actividad, en lo que se convertiría en una larga y transcedental noche . Ahora que esta todo asentado, las vulnerabilidades se arreglaron, la mayoría de los fondos faltantes se recuperaron y todos los sistemas están en funcionamiento, vale la pena mirar hacia atrás y rastrear lo que realmente ha estado sucediendo en los últimos 5 días.
¿Que ocurrio realmente?
Todo comienza con la implementación de una nueva función de VM en la red principal. El punto final en cuestión se llama "ejecutar en el contexto de destino por la persona que llama", "executeOnDestContextByCaller" como lo ven los contratos. Es muy similar al más común "ejecutar en el contexto de destino", que usamos para interacciones sincrónicas del mismo fragmento entre contratos , pero con una advertencia: la acción ocurre como si la enviara directamente la persona que llama de la transacción original.
Desglosémoslo paso a paso: digamos que el usuario A llama al contrato B, que a su vez llama al contrato C usando "executeOnDestContextByCaller". El contrato C recibe una transacción de B que parece haber sido enviada directamente por el usuario A. ¿Por qué querríamos esta funcionalidad? Digamos, por ejemplo, que el Usuario A está tratando de acuñar un NFT para sí mismo usando un contrato de minador de NFT (Contrato B), pero quiere ser el creador del NFT. Normalmente, el contrato B es el creador, ya que llama a la función de menta de NFT en sí, pero al usar "executeOnDestContextByCaller", parece que el NFT fue acuñado directamente por el usuario A.
Todo bien hasta ahora. Ven la semana pasada, un pequeño grupo de desarrolladores de la comunidad está tratando de construir un contrato de lotería que pueda soportar todo tipo de vulnerabilidades. El problema es que, en principio, los usuarios de esta lotería pueden cancelar cualquier transacción en la que no ganen usando un contrato inteligente, ganando efectivamente el 100% de las veces (esta es una falla más amplia en el diseño de ese contrato de lotería en particular, pero esta discusión es fuera del alcance de este artículo). El contrato está parcheado para no permitir llamadas de otros contratos, pero alguien encuentra una solución al usar "executeOnDestContextByCaller". Ahora se podría engañar al contrato de lotería para que crea, que una billetera normal, envió una transacción que realmente proviene de otro contrato.
Se produce una ráfaga de actividad en el canal de desarrollo oficial, mientras la comunidad juega con esta función, hasta que alguien nota algo preocupante. El contrato B también puede transferir fondos a nombre de la persona que llama (usuario A) mediante el uso de esta función. Se podría engañar a un usuario para que envíe cualquier transacción a un contrato malicioso, sin fondos, solo para ver su billetera agotada por dicho contrato.
Para asegurarse de que no veamos una ola de estafas usando este exploit, el equipo de Elrond emite rápidamente un parche, prohibiendo todas las transferencias de valor a través de "executeOnDestContextByCaller". La actualización de la red es un proceso complejo y delicado, por lo que para hacerlo correctamente, normalmente se necesita al menos una semana para que un parche llegue a la red principal. La razón es que se necesitan de 2 a 4 días para validar el parche, más varios días para proponerlo y dar a los validadores tiempo suficiente para adoptarlo y actualizarlo. Se supone que el parche entrará en vigor el lunes 8, en el cambio de época. En este punto, el tiempo restante es bastante corto para que un estafador normal cree e implemente una dApp maliciosa, y siempre se puede advertir a los usuarios que se mantengan alejados, por lo que el peligro parece mínimo.
Llegado el fin de semana, la comunidad continúa jugando con la funcionalidad y accidentalmente tropieza con algo más amenazante. Podría decirse que la fragmentación es lo más importante de Elrond, y para que la fragmentación sea realmente una cosa, necesita contratos para comunicarse correctamente entre las fragmentaciones. Las llamadas síncronas de estilo EVM no son suficientes para esto, por lo que los contratos en Elrond la mayoría de las veces envían las llamadas llamadas asíncronas a otros contratos y esperan una devolución de llamada para confirmar si las cosas en el otro lado salieron bien o no. Las llamadas asincrónicas funcionan de manera similar en el mismo fragmento, en este caso, la devolución de llamada se produce inmediatamente después de que finaliza la llamada asincrónica. La comunidad descubrió que podía llamar a "executeOnDestContextByCaller" en una devolución de llamada, en cuyo caso un contrato malicioso podría realizar acciones que no están en el nombre de la persona que llama.
Así es, al usar "executeOnDestContextByCaller" en una devolución de llamada asincrónica, un atacante puede drenar EGLD de cualquier contrato que desee, y el contrato de la víctima no puede hacer nada al respecto.
Hay algunas advertencias: el ataque solo funciona si el contrato malicioso y el objetivo están en el mismo fragmento, por lo que todo el EGLD está fuera de alcance, ya que reside en la metacadena. Los tokens ESDT también son seguros, ya que para transferirlos, el contrato malicioso debe llamar a una función integrada, como "ESDTTransfer", que la VM prohíbe en este caso. Pero esas son todas las buenas noticias.
Desconcertantemente, estos descubrimientos se discuten con bastante indiferencia en el canal público de desarrolladores de Elrond durante el fin de semana, sin plantear ningún problema de seguridad. Dado que se sabe que un parche llega a la red en 2 días, se presta poca atención a la divulgación responsable y la acción inmediata.
El ataque
El atacante aún desconocido elige el domingo por la noche como el momento del ataque, menos de 36 horas antes de que se cierre la ventana de oportunidad.
Él (¿o ella/ellos?) apunta al probablemente mayor punto de EGLD: el contrato egld-esdt-swap. Este es el contrato que crea e intercambia Wrapped EGLD (WEGLD) hacia y desde EGLD. Es un contrato muy simple y seguro: todos los usuarios que necesitan WEGLD deben depositar la misma cantidad de EGLD en este contrato, por lo que la cantidad de EGLD almacenada aquí es igual a todos los WEGLD que hay.
Hay uno de estos contratos de intercambio implementado en cada uno de los 3 fragmentos regulares, el atacante los apunta a todos. Para llegar a los fondos, crea monederos en todos los fragmentos y despliega una copia del contrato malicioso en cada uno.
Uno de estos contratos se puede encontrar aquí:
https://explorer.elrond.com/accounts/erd1qqqqqqqqqqqqqpgq8urd3mza45z6th63h52e00zpgvrc5zxll9cshfqmhg
No tenemos las fuentes originales, pero en principio debe haber sido muy similar a esto:
A ~ 1 am EEST comienza el ataque. Envía las transacciones cuyas devoluciones de llamada drenan EGLD de los contratos de intercambio, de la siguiente manera:
- En Fragmento 0: 400k EGLD
- En Fragmento 1: 800k EGLD
- En Fragmento 2: 450k EGLD
Ahora, las cosas son un poco más complicadas que eso. Si no está interesado en la descripción técnica del ataque, puede saltarse los siguientes párrafos.
El atacante, de hecho, implementa un contrato adicional además del malicioso en cada fragmento, presumiblemente para ocultar las transacciones o el contrato malicioso. Esto eleva el total a 6 contratos desplegados. También usa 2 billeteras diferentes en cada fragmento, una para iniciar la llamada y otra para sacar el EGLD.
Todos los pequeños fondos iniciales para el ataque se originan en la billetera "caliente" de Binance; erd16x7le8dpkjsafgwjx0e5kw94evsqw039rwp42m2j9eesd88x8zzs75tzry
Desafortunadamente, la transferencia dentro del fragmento que drena los fondos actualmente no está visible en el explorador, pero pronto estará disponible una nueva actualización. Esto parece haber generado cierta confusión en la comunidad sobre cómo el atacante obtuvo los fondos.
Ahora el atacante está tratando de sacar este tesoro de la cadena de Elrond.
Su plan es usar Maiar Exchange para cambiarlo por algo que pueda conectarse a Ethereum. El primer paso para hacer esto es envolver el EGLD robado, que, irónicamente, debe tener lugar en los mismos contratos que acaba de hackear. Esta vez utiliza las funciones de los contratos correctamente, tal como se diseñaron, enviando el EGLD robado de vuelta al contrato y recibiendo WEGLD nuevo en su lugar. Pero debido a que usó EGLD robado para hacer esto, el WEGLD que recibe ya no está debidamente respaldado 1:1 con EGLD en el grupo, por lo que podemos considerarlo como "WEGLD pirateado" que ahora se propagará a través de la red.
Luego convierte una gran parte a USDC en Maiar Exchange, pero el fondo de liquidez, aunque grande, no es rival para una suma tan gigantesca. Por lo tanto, él solo sumerge el precio de EGLD en el grupo de liquidez a alrededor de $ 4, vendiendo su WEGLD pirateado con una gran pérdida. Los bots de arbitraje que se ejecutan en el LP a esta hora obtienen grandes ganancias, pero no tienen el volumen para recuperar el precio antes de que el equipo detenga el intercambio.
No centraliza los fondos robados en una sola billetera, sino que continuará usando las segundas billeteras de cada fragmento (ver en la tabla) para interactuar con Maiar Exchange en paralelo. Hay un límite de transacción de $ 200k en el puente y, por alguna razón, no solo divide la cantidad cuando usa el puente, sino también cuando interactúa con el intercambio. Esto da como resultado muchas interacciones con los fondos de liquidez, demasiadas para enumerarlas aquí, pero los lectores curiosos pueden echarles un vistazo en el explorador:
Fragmento 0: https://explorer.elrond.com/accounts/erd16syfkds2faezhqa7pn5n8fyjkst70l5qefpmc0r960467snlgycq4ww0rt
Fragmento 1:
https://explorer.elrond.com/accounts/erd1cura2qq8skel5fsxrpxyysjkaw6durengtkencrezkw78y6y2zhscf854j
Fragmento 2:
https://explorer.elrond.com/accounts/erd1yrf9qeuqkcjeh5c4xn628mags7cse4r9ra2p2ggmlgfqq3l3v6pqxfu950
Al ver que derrumbó el precio de EGLD en el grupo EGLD-USDC y que está vendiendo con una gran pérdida, también convierte parte del monto a UTK, parte del cual también une a Ethereum.
Una nota técnica: los tokens ETHUSDC y ETHUTK que ve en las transacciones son tokens intermedios utilizados por el puente. USDC y UTK, respectivamente, deben convertirse a ellos antes de que puedan conectarse.
La cantidad total que logra conectar a Ethereum antes de que el puente se desactive temporalmente es de alrededor de 4 millones de USDC y 1 millón de UTK. El equipo congela otros 1,4 millones de USDC en el puente, antes de que el atacante tenga la oportunidad de sacarlos.
Toda esta actividad en el intercambio y en el puente pronto comienza a hacer sonar las alarmas, y el equipo se reúne rápidamente para investigar el incidente.
El ataque es contrarrestado
La primera prioridad es limitar el daño tanto como sea posible. El intercambio, el intercambio Wrapped EGLD y el puente se pausan inmediatamente. Tenga en cuenta que la actividad en el puente solo puede suspenderse en circunstancias excepcionales, de vida o muerte, y con el acuerdo de los repetidores de confianza del puente.
La API pública se mantiene activada, pero la función de envío está desactivada, por lo que no pueden pasar transacciones a través de ella. Sin embargo, el atacante no confía en la puerta de enlace pública, por lo que no se deja intimidar por esto.
Finalmente, muchos ESDT tienen una función de congelación si así se configura en el momento de la acuñación o creación. Tenga en cuenta que todas las monedas estables, por ejemplo, tienen esta función habilitada en todas las cadenas, por razones obvias de seguridad. Usándolo, el equipo puede congelar temporalmente todas las transferencias de USDC y UTK. EGLD, por otro lado, no se puede congelar, por lo que el atacante es libre de moverlo.
Mientras tanto, el equipo también está en contacto con todos los principales intercambios, pasando una lista negra para evitar que el atacante extraiga el EGLD allí. Al mismo tiempo se está teniendo conversaciones con las agencias de aplicación de la ley para iniciar varias investigaciones.
La siguiente es la tarea principal de parchear la vulnerabilidad lo antes posible. Está claro que esperar el parche regular a las 6 p. m. EEST es inaceptable dada la gravedad de la situación. Un parche de emergencia está listo a las 7:07 am EEST y en unos minutos los mensajes comienzan a circular por los canales del validador.
Dado que el equipo actualmente solo controla una minoría de los nodos de validación, la amplia participación de la comunidad de validadores, a través de un consenso aproximado y una gobernanza fuera de la cadena, es necesaria e importante incluso para una actualización de parche de emergencia. Esto significa comunicar el parche, la propuesta y la adopción. En principio, más del 66 % de los nodos son necesarios para implementar un cambio de manera segura, por lo que la mayoría de las agencias de participación deben estar de acuerdo con esto.
Se decide parchear las cosas en el lugar, en la época actual. Para evitar cualquier complicación durante la actualización, la comunidad debe actuar con la máxima celeridad. El equipo tiene planes de contingencia para cualquier posible evento durante la actualización, pero es más fácil si no llega a eso. Una vez que al menos ~67% de los nodos se han actualizado, se evita cualquier posible peligro.
Milagrosamente, a las 7 am EEST gran parte de la comunidad de validadores está despierta y lista para la acción. El equipo realiza las pruebas finales de la compilación y, 20 minutos después, comienza la actualización. La mayor parte de la red tarda aproximadamente media hora en ejecutar la nueva versión. Todo transcurre sin problemas y sin incidentes ni tiempo de inactividad de la red, para alivio de todos. La respuesta de los validadores es irreprochable. Los contratos vuelven a estar seguros.
Consecuencias inmediatas
Es temprano en la mañana del lunes, se evitó la crisis inmediata, pero aún faltan los fondos y el equipo no está seguro de si el parche de la mañana es una solución completa o si puede haber más vulnerabilidades ocultas.
Parte del equipo usa el día para probar más escenarios y pensar en más explotaciones potenciales. Si bien no parece haber más vulnerabilidades ocultas en el código, el equipo todavía se siente incómodo con la existencia continua de la función "executeOnDestContextByCaller". Para disipar más sospechas, finalmente se decide tener otro segundo parche el mismo día, en el que se elimina por completo "executeOnDestContextByCaller". Los beneficios de tener esta función ya no superan los riesgos. Este parche llega el lunes por la noche, y esta vez la actualización se realiza de acuerdo con el protocolo y relativamente sin preocupaciones.
Otra parte del equipo está investigando soluciones para recuperar los fondos. Mientras tanto, la mayoría de los fondos han sido recuperados de los atacantes, pero dado que esta es todavía una investigación abierta, por razones legales, haremos un seguimiento con una descripción más detallada tan pronto como se cierre la investigación.
Las aguas se calman
Para el martes por la mañana, la mayoría de los fondos se recuperan y el equipo comienza a restaurar el estado anterior al ataque.
En primer lugar, el fondo de liquidez de EGLD-USDC todavía está desequilibrado. Para recuperar completamente lo que se perdió, es el equipo de Elrond el que necesita volver a comprar el EGLD que vendió el atacante y devolverlo al precio justo de mercado.
Todavía no existe un mecanismo de lista blanca en el DEX, por lo que el equipo debe implementarlo primero. Esta es la única forma en que el equipo puede realizar los intercambios antes de reabrir los contratos al público. No se aceptan atajos: la nueva versión del contrato de LP se prueba minuciosamente durante varias horas antes de la implementación.
Lo mismo ocurre con el par EGLD-UTK, el equipo necesita vender el UTK robado de la misma manera que lo compró el atacante para recuperar el WEGLD explotado.
En segundo lugar, el contrato de swap Wrapped EGLD debe reequilibrarse. En circunstancias normales, siempre hay una proporción de 1:1 entre EGLD en el contrato y WEGLD, pero debido al ataque, este equilibrio se rompe. El exceso de WEGLD debe quemarse.
Esto es más complicado de lo esperado. El atacante convirtió gran parte del EGLD robado en WEGLD y luego desechó la mayor parte en el intercambio. Parte de ese WEGLD se ha perdido por las tarifas y los bots de arbitraje que estaban operando en ese momento, por lo que todavía hay un exceso de WEGLD repartido por toda la red.
El equipo logra recuperar algunos fondos del hacker. Más específicamente, los fondos que aún no estaban vinculados a Ethereum. Los fondos recuperados se envían a la siguiente dirección:
https://explorer.elrond.com/accounts/erd1pml9k2tsqsnvtmmalglt2su0sn3cguvr8e8jq0gy69zw2ldcej2qapml9a
Así puede comenzar el proceso de recuperación. El equipo comienza por deshacer el daño causado a los fondos de liquidez y los contratos de intercambio de WEGLD.
Al volver a comprar WEGLD de los grupos al precio que vendió el atacante, se puede recuperar parte de la pérdida. El equipo realiza esto en varios pasos más pequeños, hasta que el precio de EGLD coincida con el precio de EGLD actual en Binance ($68,5 en ese momento). Tenga en cuenta que este precio es un poco más bajo que durante el ataque.
Esto, por desgracia, no devuelve al equipo todo el “WEGLD explotado” que se ha extendido por la red. El equipo solo puede comprar 728k WEGLD con el USDC y el UTK devueltos por el atacante.
Ahora llega el momento de los contratos swap. El atacante robó 1650k EGLD de los contratos, pero solo convirtió 917k EGLD a WEGLD. Los bots de arbitraje vendieron parte de este WEGLD de doble acuñación después de obtener ganancias. Aunque esto no es tan importante. Lo importante es que hay 1650k más WEGLD que EGLD en contratos.
Hay 2 formas de eliminar esta diferencia: quemar WEGLD o agregar EGLD faltante a los contratos.
El equipo hace ambas cosas:
1) Los 728k WEGLD comprados en el intercambio se queman en la siguiente transacción:
2) Los 922k EGLD restantes se incorporan a los contratos directamente, sin acuñar más WEGLD. Esto se hace a través de un punto final de "reequilibrio" escrito específicamente para esta ocasión. 200k de la EGLD utilizada en esta operación provienen de la reserva de la Fundación Elrond. Las transacciones de rebalanceo son las siguientes:
Finalmente, después de muchas más rondas de verificación y prueba, Maiar Exchange no está en pausa y los servicios reanudan su funcionamiento normal el miércoles 8 de Junio.
Conceptos erróneos comunes
Después del ataque, la comunidad estaba llena de teorías y suposiciones de lo que había sucedido. Hubo unos pocos que entendieron los eventos correctamente, pero muchos más sucumbieron a la confusión y la desinformación.
Para disipar los conceptos erróneos más comunes:
- “Fue un ataque DEX” . No fue así, el DEX funcionó como se esperaba todo el tiempo. Dos de los fondos de liquidez se desequilibraron durante la venta masiva, pero el DEX no fue el objetivo de este ataque.
- “Era un tema de liquidez/algo parecido a UST/LUNA”. No, este exploit no tiene nada en común con el reciente colapso del ecosistema Terra. En ningún momento fue un problema de subcolateralización, fue un robo puro.
- “Fue un ataque a un puente” . No, el puente funcionó como se esperaba. Algunos de los fondos se conectaron a Ethereum, tiempo durante el cual el puente funcionó como se esperaba. Luego se desactivó a propósito, para evitar que más fondos salieran del ecosistema.
- “Fue un ataque de contrato inteligente” . El atacante no explotó ninguna vulnerabilidad de código de contrato inteligente, el problema estaba en la máquina virtual. No había ningún error en el contrato egld-esdt-swap en sí.
- “El atacante logró acuñar EGLD de la nada” . No, todo el EGLD fue robado directamente del saldo del contrato inteligente egld-esdt-swap. Ya estaba allí.
- “El atacante logró acuñar WEGLD de la nada” . Esto es parcialmente cierto. Si bien el atacante no explotó WEGLD directamente, al envolver el EGLD robado, el resultado fue que había más WEGLD en circulación de lo que debería haber sido, 900k WEGLD para ser precisos. Esto es equivalente a acuñar ilegalmente WEGLD sin respaldo. El equipo logró recuperar este WEGLD ilegal y lo quemó, por lo que en este momento cada token WEGLD está nuevamente respaldado por 1 EGLD.
- "La cadena de bloques de Elrond se apagó" . En ningún momento la cadena de bloques estuvo apagada o inactiva. Se siguieron agregando bloques e incluso algunas transacciones durante todo el tiempo. Solo se desactivó el extremo de la transacción de envío de la API pública.
- “Este fue un «trabajo interno»” . Una de las piezas de desinformación más atroces es la teoría de que alguien del equipo lo había hecho. Es absurdo creer que alguien que trabaja en un proyecto durante años lo ponga en peligro, además de arriesgar su propia libertad personal por una ganancia rápida.
- “La piratería de sombrero negro vale la pena”. Incluso si logra un truco con éxito, es muy difícil sacar los fondos. Incluso los piratas informáticos más hábiles dejan rastros en todas partes, todos los CEX tienen KYC y es casi imposible evadir la ley. Si encuentra una vulnerabilidad de software, lo más inteligente que puede hacer es informar al equipo. Esto te dará una buena recompensa mientras te mantiene en el lado correcto de la ley, libre para explorar el mundo fuera de prisión.
Lecciones aprendidas y pasos adelante
El software es difícil . La cadena de bloques es difícil . Escribir una VM desde cero también es muy difícil, pero vale la pena si realmente busca velocidad, seguridad y escalabilidad, y un impacto significativo en el mundo.
Las cosas salen mal de vez en cuando. Obviamente, esto no es algo que debamos aceptar, es algo que debemos superar. La descentralización es lo que todos buscamos, pero no se lleva bien con los errores y las vulnerabilidades.
No podríamos mantener la red tan descentralizada sin una comunidad de validadores tan receptiva y comprometida. Realmente han brillado en el momento de máximo desafío.
Los creadores de contratos y tokens ESDT pueden optar por otorgarse el poder de detener temporalmente dichos contratos y tokens ESDT en momentos de crisis. En tales eventos desafortunados, la importancia y la necesidad de precauciones auxiliares pueden entenderse claramente. A medida que la tecnología madure, veremos que este poder se abandona de manera gradual y segura a través de diferentes formas de gobierno.
En cuanto al código en sí, hay 3 formas de garantizar que funcione correctamente: pruebas, tiempo y matemáticas. Evidentemente, las pruebas no son suficientes para infraestructuras complejas y críticas. El tiempo finalmente revela y elimina todas las vulnerabilidades ocultas, pero es un proceso doloroso y lleno de trampas. El mejor enfoque es pensar profundamente al respecto, modelarlo matemáticamente, simularlo y auditarlo, y esto es algo en lo que debemos invertir más en el futuro. Ya tenemos modelos parciales de la VM y muchas herramientas para probar la corrección de nuestro código, solo necesitamos sacarles más provecho y desarrollarlas más. Eventos como este son una evaluación intensa de nuestros estándares y metodologías de ingeniería.
Por desgracia, esta semana comienza un nuevo capítulo en la historia de Elrond. Hemos decidido re-pensar no solo nuestra arquitectura de seguridad, sino toda nuestra filosofía de creación de software.
Ya esta semana, hemos estado destacando varios frentes en los que se llevará a cabo la lucha para eliminar las vulnerabilidades. Ya hay varios equipos al acecho de problemas en el protocolo, VM, servicios y el frontend. También hemos estado analizando qué herramientas pueden brindar los resultados más completos y más rápido, y ya hemos comenzado a desarrollar algunas de ellas.
También se ha reiterado y simplificado el proceso interno de plantear posibles preocupaciones de seguridad, sacar a la luz problemas y procesarlos con la máxima rapidez y minuciosidad. El proceso externo de divulgación de seguridad responsable , mediante el envío de un correo electrónico a security@elrond.com , y la recepción de una gran recompensa por cualquier error válido y significativo, se llamará constantemente la atención de todos en la comunidad, para ayudar a reforzar este comportamiento constructivo.
Decir que han sido unos días difíciles es quedarse corto. Al final, nada de importancia se puede construir sin dificultades. Dado que las dificultades siempre vendrán, haremos todo lo posible para prepararnos, fortalecer nuestra resolución y fortalecer nuestra respuesta frente a ellas.
Después de todo esto, el Maiar DEX está completamente en vivo. Las API están completamente activas. Los intercambios son completamente en vivo.
Todos los fondos están seguros, todos los usuarios están seguros.
Qué obstinada fuerza y alegría transmiten estas palabras.
Con estas nuevas lecciones aprendidas, abriremos un nuevo capítulo para Elrond.
Ven a construir con nosotros. Fortalezcamos esta red juntos.
