原文标题：《Eludir la capa cero: por qué la seguridad aislada no es seguridad》
Autor: Krzysztof Urbański, miembro del equipo L2BEAT
Compilado por: Babywhale, Foresight News
L2BEAT ha invertido un esfuerzo considerable desde sus inicios para analizar y comprender los riesgos asociados con los protocolos de Capa 2. Siempre actuamos en el mejor interés de nuestros usuarios y ecosistema, y hacemos todo lo posible para ser un supervisor imparcial e independiente, sin permitir que nuestras preferencias personales para proyectos o equipos relacionados influyan en los hechos. Por eso, aunque respetamos el tiempo y el esfuerzo que el equipo del proyecto dedica al proyecto, podemos "hacer sonar la alarma" o señalar nuestras preocupaciones sobre los riesgos potenciales de ciertos protocolos. Tener discusiones tempranas relacionadas con la seguridad permite que todo el ecosistema esté mejor preparado para riesgos potenciales y reaccione antes ante cualquier comportamiento sospechoso.
Hoy nos gustaría hablar sobre el modelo de seguridad compartida para aplicaciones entre cadenas. Actualmente existen dos modelos de seguridad: seguridad compartida y seguridad de aplicaciones independientes. La seguridad compartida es como todos los Rollups. La seguridad de aplicaciones independientes la utilizan principalmente proyectos "omnichain", que utilizan principalmente LayerZero.
Seguridad compartida versus seguridad independiente
La seguridad compartida se refiere a un token o aplicación específica que se ejecuta en una infraestructura determinada y, en lugar de elegir libremente un modelo de seguridad, deben cumplir con los requisitos de seguridad impuestos por la infraestructura. Por ejemplo, los paquetes acumulativos optimistas suelen imponer una ventana final de siete días; una aplicación que se ejecuta en dichos paquetes acumulativos no puede simplemente ignorar o acortar este período. Aunque esto pueda parecer un obstáculo, hay una razón para ello. Este período brinda a los usuarios una garantía de seguridad de que, independientemente de la política de seguridad interna de la aplicación, que debe cumplirse, la aplicación solo puede fortalecer la seguridad de los Rollups, no debilitarla.
Seguridad independiente significa que cada aplicación es responsable de definir su seguridad y no está restringida de ninguna manera por la infraestructura. Esto puede parecer una buena idea al principio; después de todo, el desarrollador de la aplicación sabe mejor qué medidas de seguridad puede necesitar la aplicación. Pero al mismo tiempo, transfiere al usuario final la responsabilidad de evaluar los riesgos asociados con cada política de seguridad de la aplicación. Además, si los desarrolladores de aplicaciones son libres de elegir sus políticas de seguridad, también pueden cambiarlas en cualquier momento. Por lo tanto, no basta con evaluar el riesgo una vez para cada aplicación; se debe evaluar cada vez que cambian las políticas de una aplicación.
Problemas
Creemos que un modelo de seguridad independiente en el que cada aplicación es libre de definir su política de seguridad crea serios problemas de seguridad. En primer lugar, aumenta el riesgo para los usuarios finales porque deben verificar el riesgo de cada aplicación que pretenden utilizar.
La seguridad independiente también aumenta los riesgos para las aplicaciones que utilizan este modelo, por ejemplo agregando riesgos adicionales relacionados con los cambios en la política de seguridad: si un atacante cambiara el modelo de seguridad de la aplicación, podría simplemente desactivarla, quedando así sin dinero o arriesgándose a perder dinero. de cualquier manera. Atacar de otras maneras. No hay capas de seguridad adicionales además de la aplicación para evitar ataques.
Además, dado que las políticas de seguridad pueden cambiar en cualquier momento y sobre la marcha, es casi imposible monitorear las aplicaciones en tiempo real e informar a los usuarios sobre los riesgos.
Nos pareció similar a la capacidad de actualización de los contratos inteligentes, sobre la que advertimos en L2BEAT. Informamos a los usuarios sobre Rollup y puentes entre cadenas que tienen mecanismos de actualizabilidad en sus contratos inteligentes, y los mecanismos exactos para gestionar la actualizabilidad en cada caso. Esto ya es bastante complejo y el uso de un modelo de seguridad independiente multiplica el número, haciendo casi imposible realizar un seguimiento eficaz.
Es por eso que consideramos que un modelo de seguridad independiente es un riesgo de seguridad en sí mismo, y asumimos que cada aplicación que utilizará este modelo de forma predeterminada debe considerarse riesgosa hasta que se demuestre lo contrario.
Demostrar que existen vulnerabilidades de seguridad
Decidimos probar nuestra hipótesis en la red principal. Se eligió el marco LayerZero para la experimentación porque es una de las soluciones independientes centradas en la seguridad más populares. Implementamos un token omnichain seguro y luego actualizamos la configuración de seguridad para permitir retiros maliciosos del token. El código del token se basa en los ejemplos proporcionados por LayerZero y es muy similar o idéntico a muchos otros tokens y aplicaciones omnichain implementados en la vida real.
Pero antes de entrar en detalles, echemos un breve vistazo a cómo es el modelo de seguridad de LayerZero.
Como señala LayerZero en su documento técnico, su "comunicación entre cadenas sin confianza" se basa en dos actores independientes (oráculos y retransmisores) que actúan juntos para garantizar la seguridad del protocolo.
LayerZero afirma en su sitio web que su concepto central es "aplicaciones de usuario que ejecutan ULN (UltraLightNode), terminales en cadena configurables". El componente dentro de la cadena de LayerZero se basa en dos componentes externos fuera de la cadena para transmitir mensajes entre cadenas: oráculos y retransmisiones.
Siempre que se envía un mensaje M de la cadena A a la cadena B, se producen las dos operaciones siguientes:
Primero, el oráculo espera hasta que se complete la transacción que envía el mensaje M en la cadena A y luego escribe información relevante en la cadena B, como el valor hash del encabezado del bloque de la cadena A que contiene el mensaje M (el valor exacto entre diferentes cadenas/oráculos). El formato puede variar).
Luego, el relé envía una "prueba" (como Merkle Proof) a la cadena B, lo que demuestra que el encabezado del bloque almacenado contiene el mensaje M.
LayerZero asume que los relevos y los oráculos son participantes independientes y honestos. Sin embargo, LayerZero también declaró en el documento técnico que si no se cumple esta suposición, por ejemplo, el relé y el oráculo se confabulan, lo que resulta en que "tanto el encabezado del bloque proporcionado por el oráculo como la prueba de transacción proporcionada por el relé no son válidos, pero todavía coinciden."
LayerZero afirma que "el diseño de LayerZero elimina la posibilidad de colusión". Pero, de hecho, esta afirmación es incorrecta (lo demostramos en los experimentos que se muestran a continuación), porque cada aplicación de usuario puede definir sus propios relés y oráculos. LayerZero no garantiza por diseño que estos componentes sean independientes y no puedan coludir; más bien, corresponde a la aplicación del usuario proporcionar estas garantías. LayerZero no tiene ningún mecanismo para detener aplicaciones si deciden romperlas.
Además, de forma predeterminada, todas las aplicaciones de usuario pueden cambiar los relés y oráculos en cualquier momento, redefiniendo por completo los supuestos de seguridad. Por lo tanto, comprobar la seguridad de una aplicación determinada sólo una vez no es suficiente, ya que puede cambiar en cualquier momento después de comprobarla, como mostraremos en nuestros experimentos.
diseño experimental
Para nuestros experimentos, decidimos crear un token omnichain simple, CarpetMoon, que se ejecuta tanto en Ethereum como en Optimism y utiliza LayerZero para comunicarse entre las dos cadenas.
Nuestro token utiliza inicialmente el modelo de seguridad predeterminado proporcionado por LayerZero, lo que lo hace idéntico a las aplicaciones LayerZero grandes (quizás no todas) implementadas actualmente. Por lo tanto, generalmente es tan segura como cualquier otra moneda que utilice LayerZero.
Primero, implementamos nuestro contrato de token en Ethereum y Optimism:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221
Luego configuramos el enrutamiento para que LayerZero sepa qué contrato corresponde a cuál en ambas cadenas.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c
El token se ha implementado y se ve exactamente como cualquier otro token omnichain que usa LayerZero, usa la configuración predeterminada y no tiene nada de sospechoso.
Proporcionamos mil millones de tokens CarpetMoon en Ethereum a nuestra "usuaria de prueba" Alice.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
Ahora Alice usa LayerZero para encadenar estos tokens con Optimism.
Bloqueamos los tokens en un contrato de depósito en garantía en Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
El mensaje que contiene la transacción se pasa a Optimism a través de LayerZero:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7nonced10d/。
Se están acuñando tokens entre cadenas en Optimism, y Alice ahora posee mil millones de tokens MoonCarpet en Optimism:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302。
Todo funciona como se esperaba, Alice cruza las cadenas de los tokens y ve que hay mil millones de tokens MoonCarpet en el contrato de depósito en garantía de Ethereum y mil millones de tokens MoonCarpet en su cuenta en Optimism. Pero solo para asegurarse de que todo estuviera bien, transfirió la mitad de sus tokens a Ethereum.
Comenzamos con una transacción sobre Optimism que quemó 500 millones de tokens:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f。
La información sobre la transacción se pasa a Ethereum:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1。
Como se esperaba, se devuelven 500 millones de tokens MoonCarpet del contrato de depósito de garantía a la dirección de Alice:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
Hasta el momento todo funciona bien y exactamente como se supone. Alice ha comprobado que puede cruzar tokens de cadena de Ethereum a Optimism y viceversa, no tiene motivos para preocuparse por sus tokens MoonCarpet.
Pero las hipótesis tienen sus propios problemas: por ejemplo, el equipo detrás de nuestro token tiene problemas y el malo Bob obtiene acceso a la configuración LayerZero de nuestra aplicación.
De esta manera, Bob puede cambiar los oráculos y relés de los componentes predeterminados a componentes que él controla.
Cabe señalar que este es un mecanismo proporcionado para cada aplicación que utiliza LayerZero y está basado en la arquitectura de LayerZero. No es una puerta trasera de ningún tipo, sino un mecanismo estándar.
Entonces Bob cambia el oráculo a una EOA bajo su control:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
El repetidor también se cambia:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
Ahora sucede algo extraño. Dado que el oráculo y el relevo están ahora bajo el control total de Bob, puede robar las fichas de Alice. Aunque no se tomó ninguna medida contra Optimism (los tokens MoonCarpet todavía estaban en la billetera de Alice), Bob pudo convencer al contrato inteligente MoonCarpet en Ethereum (usando el mecanismo LayerZero) de que destruyó los tokens en la otra cadena y pudo retire los tokens del token MoonCarpet en Ethereum.
Primero, actualiza el hash de bloque de Ethereum utilizando un oráculo que controla:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
Ahora puede retirar los tokens restantes del contrato de depósito en garantía:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
Resultados experimentales
Alice ni siquiera sabe por qué ni cuándo ocurrió el error. De repente, su token MoonCarpet en Optimism ya no estaba respaldado por tokens en Ethereum.
El contrato inteligente no se puede actualizar y funciona como se esperaba. La única actividad sospechosa son los cambios de Oracle y Relay, pero este es un mecanismo regular integrado en LayerZero, por lo que Alice ni siquiera sabe si este cambio es intencional. Incluso si Alice se entera del cambio, ya es demasiado tarde: el atacante puede agotar los fondos antes de que ella pueda reaccionar.
No hay nada que LayerZero pueda hacer: estas son efectivamente implementaciones de sus mecanismos sobre los cuales no tienen control. En teoría, las propias aplicaciones podrían evitar cambiar oráculos y retransmisiones, pero hasta donde sabemos, ninguna aplicación implementada lo ha hecho.
Hicimos este experimento para comprobar si alguien lo notó, pero como esperábamos, nadie lo hizo. Es casi imposible monitorear de manera efectiva todas las aplicaciones creadas con LayerZero para verificar si sus políticas de seguridad han cambiado y alertar a los usuarios cuando esto suceda.
Incluso si alguien logra descubrir a tiempo que los oráculos y los relés han cambiado y han creado un riesgo para la seguridad, será demasiado tarde. Dado que los nuevos oráculos y retransmisores ahora son libres de elegir qué mensajes entregar o simplemente desactivar la comunicación entre cadenas, generalmente no hay mucho que los usuarios puedan hacer al respecto. Nuestros experimentos muestran claramente que incluso si Alice nota el cambio en la configuración de la aplicación, no puede hacer mucho con sus tokens entre cadenas: los nuevos oráculos y retransmisiones ya no se aceptan en el mensaje de la cadena de comunicación original, por lo que el mensaje no se devolverá a Ethereum. .
en conclusión
Como podemos ver, aunque nuestro token se creó con LayerZero y utilizó su mecánica según lo previsto, pudimos robar fondos del depósito en garantía del token. Por supuesto, esto es culpa de la aplicación (en nuestro caso, el token CarpetMoon) y no de LayerZero en sí, pero demuestra que LayerZero en sí no ofrece ninguna garantía de seguridad.
Cuando LayerZero describe su modelo de seguridad con respecto a oráculos y retransmisores, asumen que el propietario de la aplicación (o quien tenga la clave privada) no hará nada irrazonable. Pero en un entorno conflictivo, esta suposición es incorrecta. Además, requiere que los usuarios confíen en el desarrollador de la aplicación como un tercero confiable.
Por lo tanto, en la práctica, no se pueden hacer suposiciones sobre la seguridad de las aplicaciones creadas con LayerZero: cada aplicación debe considerarse riesgosa hasta que se demuestre lo contrario.
En realidad, toda la historia comenzó con un PR de que planeábamos incluir todos los tokens omnichain en el sitio web de L2BEAT; estábamos teniendo dificultades para descubrir cómo evaluar su riesgo. Al analizar los riesgos, se nos ocurrió la idea de experimentar.
Si L2BEAT entrara en funcionamiento, la consecuencia sería que tendríamos que colocar alertas en cada aplicación creada con LayerZero para advertir sobre posibles riesgos de seguridad. Pero queríamos tener una discusión más amplia sobre los modelos de seguridad porque creemos que la seguridad independiente es un modelo que debe evitarse, especialmente en nuestro campo.
Creemos que a medida que los modelos de seguridad independientes como LayerZero se vuelven más populares, cada vez más proyectos abusarán de ellos, causando daños masivos y aumentando la incertidumbre en toda la industria.