Polygon Warrior Diálisis de seguridad de Polygon: ¿Cómo garantizar la seguridad y la estabilidad entre cadenas?

Autor: Chengdu Lian’an
Original: “Investigación sobre la seguridad de los puentes entre cadenas (3)” | Diálisis segura Polygon Warrior, ¿cómo evitar la apertura de la “caja de Pandora”?

Bienvenido a la serie de artículos sobre “Investigación de seguridad de puentes entre cadenas” producida por Chengdu Chain Security, en el artículo anterior (Investigación de seguridad de puentes entre cadenas (2) | ¿Qué nos trae el primer robo descentralizado del puente Nomad?), realizamos un análisis técnico profesional del protocolo del puente Nomad en detalle.

Hoy, el equipo de investigación de seguridad de la cadena de Chengdu llevará a cabo una diálisis segura de Polygon, un guerrero poligonal, así que sigue leyendo.

¿Quién es 1_Polygon?

Polygon es la solución de escalado de capa 2 de Ethereum, con la visión de construir la Internet blockchain de Ethereum. Polygon proporciona un marco común que permite a los desarrolladores aprovechar la seguridad de Ethereum para crear cadenas personalizadas y centradas en las aplicaciones y proporcionar una red interoperable que combina una variedad de esquemas de escalado diferentes, tales como: zk-rollup, PoS, etc. Entre ellos, Polygon PoS es actualmente la solución de escalado más madura y conocida en Polygon. Utiliza la cadena lateral para el procesamiento de transacciones para lograr el propósito de mejorar la velocidad de las transacciones y ahorrar consumo de gas, y la estructura de la red incluye principalmente las siguientes tres capas:

Capa de Ethereum:

Una serie de contratos en la red principal de Ethereum, que incluyen principalmente: contratos de Staking, Checkpoint y Reward, son responsables de las funciones de gestión de staking relacionadas con las apuestas de PoS, que incluyen: proporcionar la función de staking del token nativo MATIC, para que cualquiera que apueste el token pueda unirse al sistema como validador, verificar la conversión de la red Polygon para obtener recompensas de staking, castigar a los validadores por firmas dobles, tiempo de inactividad del validador y otros comportamientos ilegales, y guardar puntos de control.

Capa de Heimdall:

La capa validadora de prueba de participación, que consiste en un conjunto de nodos PoS Heimdall, es responsable de enviar los puntos de control de la red Polygon a la red principal de Ethereum mientras escucha un conjunto de contratos de participación implementados en Ethereum. El proceso principal es el siguiente: primero, seleccione un subconjunto de validadores activos en el grupo de validadores como productores de bloques, que serán responsables de crear bloques en la capa Bor y difundirlos, luego valide el hash raíz de Merkle y agregue firmas en función de los puntos de control enviados por Bor y, finalmente, el proponente será responsable de recopilar todas las firmas del validador para el punto de control especificado, y si el número de firmas alcanza más de 2/3, el punto de control se enviará en Ethereum.

Capa Bor:

La capa productora de bloques, que consiste en un grupo de productores de bloques seleccionados regularmente por un comité de validadores en la capa de Heimdall, es un subconjunto de validadores responsables de agregar transacciones en la cadena lateral de Polygon y generar bloques. Esta capa publica periódicamente puntos de control en la capa de Heimdall, donde el punto de control representa una instantánea de la cadena Bor, como se muestra en la imagen siguiente.

2_Polygon Interoperabilidad

2.1 Punto de control

El mecanismo de punto de control es un mecanismo para sincronizar los datos de la capa Bor con Ethereum, donde los datos sincronizados son un punto de control, es decir, una instantánea de los datos de bloque de la capa Bor contenidos en un intervalo de punto de control, el código fuente es el siguiente:

Proponente: El proponente, que también es seleccionado por los validadores, los productores de bloques y los proponentes son un subconjunto de validadores, y sus responsabilidades están determinadas por su participación en el grupo general

RootHash: es un hash de Merkle generado a partir del bloque Bor entre StartBlock y EndBlock

A continuación se muestra un pseudocódigo para que el bloque Bor numerado del 1 al n genere el valor RootHash:

En resumen, este valor es el valor hash raíz del árbol de Merkel, que se compone del número de bloque en el encabezado del bloque Bor, la marca de tiempo del bloque, el valor hash de la raíz del árbol de transacciones tx hash y el valor hash keccak256 calculado a partir del hash raíz del árbol de recibos.

AccountRootHash: Un hash de Merkle de la información de la cuenta relacionada con el validador que debe enviarse a cada punto de control en Ethereum, y el valor hash de la información de la cuenta individual se calcula de la siguiente manera:

El AccountRootHash se genera a partir del hash raíz del árbol Merkle de la cuenta de la misma manera que el valor de RootHash.

2.2 StateSync

StateSync se refiere a la sincronización de los datos de Ethereum con la cadena Polygon Matic, que se divide principalmente en los siguientes pasos:

1. Primero, el contrato en Ethereum activará la función syncState() en StateSender.sol para la sincronización de estados

2. La función syncState() emitirá un evento de la siguiente manera:

3. Todos los validadores de la capa de Heimdall recibirán el evento, y uno de los validadores empaquetará la transacción en el bloque de heimdall y la agregará a la lista de sincronización de estado pendiente;

4. El nodo de la capa bor obtendrá la lista anterior para sincronizarla a través de la API y la entregará al contrato de la capa bor para su posterior procesamiento de la lógica empresarial.

2.3 Puente de polígono

Polygon Bridge permite un canal bidireccional entre Polygon y Ethereum, lo que facilita a los usuarios la transferencia de tokens entre dos plataformas de cadena diferentes sin amenazas de terceros ni restricciones de liquidez del mercado. Hay dos tipos de Polygon Bridge, PoS y Plasma, y ambos tienen las siguientes similitudes en la transferencia de activos entre Polygon y Ethereum:

1. Primero debe asignar el token en Ethereum a Polygon, como se muestra en la imagen a continuación:

2. También se utiliza la tecnología de anclaje bidireccional (clavija bidireccional), es decir,

r: Todos los activos de tokens transferidos desde Ethereum se bloquearán primero en Ethereum, y se acuñará el mismo número de tokens asignados en Polygon;

b: Para retirar activos de tokens a Ethereum, primero debe quemar estos tokens asignados en Polygon y luego desbloquear los activos bloqueados en Ethereum;

La siguiente figura muestra la comparación entre el puente PoS y el puente de plasma:

Como se puede ver en la figura anterior, en términos de seguridad, PoS Bridge se basa en la seguridad del conjunto de validadores externos, mientras que Plasma se basa en la seguridad de la cadena principal de Ethereum. Al mismo tiempo, cuando los usuarios realizan transferencias de activos entre cadenas (como la transferencia de tokens de Polygon a Ethereum), PoS solo requiere un intervalo de punto de control, de aproximadamente 20 minutos a 3 horas, mientras que Plasma requiere un período de impugnación de disputas de 7 días. Al mismo tiempo, PoS admite más tokens estándar, mientras que Plasma solo admite tres tipos, que incluyen: ETH, ERC20, ERC721.

Mensajería de cadena 3_Cross: puente PoS

El puente PoS consta principalmente de dos funciones: Depósito se refiere a la transferencia de activos de los usuarios en Ethereum a Polygon, y Retiros se refiere al retiro de activos de Polygon a Ethereum.

Depósito

A continuación se muestra un ejemplo de la usuaria Alice que utiliza PoS Bridge para enviar activos de tokens desde su cuenta de Ethereum a su cuenta de Polygon:

1. Si los activos de token que desea transferir son ERC20, ERC721 o ERC1155, debe autorizar el token que desea transferir a través de la función approtect. Como se muestra a continuación, el número correspondiente de tokens se autoriza al contrato erc20Prefer llamando al método approtect en el contrato de tokens en Ethereum.

La función approtect tiene dos parámetros:

• Spender: La dirección de destino donde el usuario autoriza el gasto de tokens

• amount: El número de tokens que se pueden gastar

2. Una vez confirmada la transacción de autorización anterior, el usuario bloquea el token en el contrato erc20Preliminary en Ethereum llamando al método depositFor() del contrato RootChainManager. Aquí, si el tipo de activo que se va a transferir es ETH, se llama a depositEtherFor(). Los detalles son los siguientes:

La función depositFor tiene tres parámetros:

• user: La dirección del usuario que recibió los tokens de depósito en Polygon

• rootToken: La dirección del token en la cadena principal de Ethereum

• depositData: El número de tokens codificados por ABI

A continuación se muestra el código específico de la función depositFor en el contrato RootChainManager:

Analizando el código fuente, se puede ver que la función primero obtiene la dirección del contrato predicado correspondiente al token y luego llama a su función lockTokens() para bloquear el token en el contrato. Finalmente, syncState() será llamado para la sincronización de estado por _stateSender, que solo puede ser llamado por el remitente de estado establecido por admin.

3. La función syncState() en StateSender.sol enviará el evento StateSynced, específicamente:

El primer parámetro es el índice de número de secuencia del registro, el segundo parámetro se utiliza para verificar si la persona que llama es una dirección de contrato legítima registrada y el tercer parámetro son los datos que deben sincronizarse con el estado. La transacción se agrega al bloque de Heimdall y se agrega a la lista de sincronización de estado pendiente.

4. Luego, después de que el nodo bor en la cadena Polygon Matic obtenga el evento StateSynced en la lista de sincronización de estado a través de la API, el contrato ChildChainManager en la cadena llamará a la función onStateReceive(), que se utiliza para recibir los datos de sincronización cargados desde Ethereum, y continuará con el siguiente paso de acuerdo con el tipo de lógica de negocio de la sincronización de estado:

data: bytes32 syncType y bytes syncData. Cuando syncType se asigna, syncData es la dirección rootToken codificada, la dirección childToken y bytes32 tokenType, y cuando syncType es deposit, syncData es la dirección de usuario codificada. La dirección rootToken y depositData del tipo bytes. depositData es la cantidad en REC20 y tokenId en ERC721.

5. Dado que se trata de un negocio de depósito, se llamará a la función _syncDeposit(). Esta función primero decodificará syncData en el formato correspondiente para obtener el rootToken, la dirección de usuario y depositData correspondientes. A continuación, compruebe si rootToken tiene un token de asignación correspondiente en el polígono y llame a la función deposit() de childToken si lo hay.

6. Aquí tomamos el contrato de token ERC20 como ejemplo para presentar cómo depositar el contrato de token de mapeo. Esta función transfiere el número correspondiente de tokens a la cuenta del usuario.

La función tiene dos parámetros:

• usuario: La dirección del usuario que está realizando un depósito

• depositData: La cantidad codificada en ABI

Retiros

El siguiente es un ejemplo de la usuaria Alice que utiliza PoS Bridge para retirar los fondos depositados en su cuenta de Polygon a su cuenta de Ethereum:

1. Cuando el usuario se retira, necesita quemar el número correspondiente de tokens mapeados llamando a la función withdraw() del contrato de token de mapeo en la cadena Polygon.

Retirar contiene solo un parámetro: el número de tokens que se quemarán. La función withdraw() en el contrato de token correspondiente es la siguiente:

2. Las transacciones anteriores se incluirán en el punto de control después de aproximadamente 20 minutos a 3 horas, y el validador las enviará a Ethereum.

3. Una vez que la transacción se agrega al punto de control y se envía a Ethereum, se llamará a la función exit() del contrato RootChainManager en Ethereum, que confirmará la validez de la transacción de retiro en Polygon verificando el contenido del punto de control enviado y activará el contrato Predicate correspondiente para desbloquear los tokens depositados del usuario.

Los inputData de prueba de prueba pasados a la función incluyen los siguientes datos:

• headerNumber: Contiene el encabezado del bloque del punto de control para la transacción de retiro

• blockProof: Demuestra que el encabezado del bloque en la cadena hija es el nodo hoja de la raíz de merkle que se confirmó

• blockNumber: El número de bloque de la cadena hija que contiene la transacción de retirada

• blockTime: La marca de tiempo del bloque de la transacción de retiro

• txRoot: El valor raíz del árbol de transacciones de bloques

• receiptRoot: El valor raíz del árbol de recibos de bloque

• Recibo: Un recibo de una transacción de retiro

• receiptProof: Comprobante de Merck del recibo de la transacción de retiro

branchMask: la ruta de acceso al recibo representada por los 32 bits del árbol de recibos

• receiptLogIndex: El índice de registro que se lee del árbol de recibos

La siguiente es la lógica central de la función, que incluye principalmente tres partes: la primera parte es verificar la validez del recibo de la transacción de retiro, la segunda parte es verificar si el punto de control contiene el bloque de transacción y la tercera parte es llamar a la función exitTokens() en el contrato predicado para enviar los tokens bloqueados al usuario.

4. Tome como ejemplo el contrato ERC20Predicate, es decir, después de decodificar el receptor, el remitente y el número de tokens enviados desde el registro, se enviará un número determinado de tokens al usuario.

De acuerdo con el análisis del código fuente del proceso de mensajería entre cadenas PoS Bridge, las llamadas a funciones de todo el proceso solo pueden ser llamadas por el rol especificado por el validador, por lo que la seguridad de la cadena cruzada solo está garantizada por el PoS (notario).

Mensajería de 4_Cross cadenas: Puente de plasma

Plasma Bridge también incluye dos funciones: Depósito y Retiros, como se muestra en la siguiente figura:

Polygon Plasma es ligeramente diferente de la implementación de Bitcoin Plasma MVP presentada en el primer artículo de nuestra serie de puentes entre cadenas, que utiliza principalmente el modelo Plasma MoreVP basado en cuentas. En comparación con Plasma, el algoritmo se ha mejorado parcialmente en la parte de retirada.

Dado que la transferencia de tokens de ERC20 y ERC721 se realiza a través de un registro de eventos similar a un UTXO de Bitcoin, primero presentemos el evento:

• input1: El saldo de la cuenta del remitente antes de la transferencia

• input2: El saldo de la cuenta del destinatario antes de la transferencia

• output1: El saldo de la cuenta del remitente después de la transferencia

• output2: El saldo de la cuenta del destinatario después de la transferencia

En segundo lugar, debido a que el MVP original de Plasma es generado por un solo operador o un pequeño número de productores de bloques, hay dos escenarios de ataque en Polygon:

Operador Malvado:

Artículo anterior (Investigación sobre la seguridad de los puentes entre cadenas (2) | Nomad cross-chain bridge) menciona que cuando la transacción de un usuario es empaquetada en un bloque de Plasma por el Operador, hay una falta de disponibilidad de datos fuera de la cadena. Por lo tanto, cuando un usuario realiza una transacción de salida, si comienza a retirar de una transacción anterior, el Operador puede desafiarlo con una de sus transacciones más recientes, y el desafío tendrá éxito. Al mismo tiempo, debido al mecanismo de puntos de control PoS utilizado en Plasma, si el operador se confabula con los validadores para hacer el mal, incluso puede forjar algunas transiciones de estado y enviarlas a Ethereum.

Usuario malvado:

Los usuarios continúan gastando tokens en Polygon después de iniciar una transacción de salida, similar a un doble gasto entre cadenas.

En resumen, el algoritmo Plasma MoreVp de Polygon utiliza otro algoritmo para calcular la prioridad de salida, que es salir de la transacción más reciente. Dado que este método usa un evento LogTransfer similar a UTXO, siempre que la transacción legítima del usuario use la entrada1 y la entrada2 correctas, incluso si algunas transacciones malintencionadas se empaquetan antes de la transacción del usuario, la transacción del usuario se puede controlar correctamente porque la transacción del usuario solo proviene de una entrada válida. El pseudocódigo relevante es el siguiente:

Depósito

Tomemos el ejemplo de la usuaria Alice que usa Plasma Bridge para enviar activos de tokens desde su cuenta de Ethereum a su cuenta de Polygon:

1. En primer lugar, los usuarios también deben autorizar los activos de tokens que necesitan transferir al depositManager del contrato Polygon en la cadena principal (Ethereum) a través de la función approtect.

2. Una vez confirmada la transacción autorizada, el usuario llama a la función erc20token.deposit() para activar la función depositERC20ForUser() del contrato depositManager y depositar los activos de token ERC20 del usuario.

3. Cuando la red principal de Ethereum confirme la transacción de depósito, creará un bloque que contendrá solo esta transacción y la enviará al contrato de childChain en la red Polygon utilizando el mecanismo de sincronización de estado, acuñará la misma cantidad de monedas mapeadas y las depositará en la cuenta del usuario en Polygon.

Nota: De acuerdo con el análisis del código fuente del contrato childChain, Plasma solo admite tres tipos, que incluyen: ETH, ERC20 y ERC721.

Retirar

Cuando un usuario quiera utilizar el puente de Plasma para retirar activos de Polygon a Ethereum, seguirá los siguientes pasos:

1. El usuario quema los activos de token mapeados en la cadena Polygon llamando a la función withdraw() de la moneda mapeada en Polygon:

También puede llamar a la implementación de la interfaz withdrawStart() del cliente de Plasma en Polygon.

2. El usuario puede llamar a la función startExitWithBurntTokens() en el contrato ERC20Predicate, que primero llamará a WithdrawManager.verifyInclusion() para verificar si el punto de control contiene la transacción de retiro y el recibo correspondiente, el código es el siguiente:

Una vez superada la verificación, se llamará a WithdrawManager.addExitToQueue() para insertarlo en la cola de mensajes en orden de prioridad:

Por último, addExitToQueue() llama a _addExitToQueue() para acuñar un NFT como vale de reembolso:

3. El usuario espera un período de desafío de 7 días

4. Una vez completado el período de desafío, puede llamar a la función WithdrawManager.processExits() para enviar tokens al usuario.

La función se divide en dos pasos: primero, confirme si la transacción de retiro en la cola de mensajes ha superado el período de desafío de 7 días y, si el período de desafío ha pasado, elimine la transacción de la cola:

A continuación, determine si el NFT del vale de reembolso se ha eliminado durante el período del desafío y, si no es así, el NFT se destruirá y se devolverán los activos correspondientes al usuario:

5_Polygon Vulnerabilidad de doble gasto de Plasma Bridge

El 5 de octubre de 2021, el sombrero blanco Gerhard Wagner presentó una vulnerabilidad de Polygon que podría conducir a un ataque de doble gasto que involucraba 850 millones de dólares, por lo que White Hat recibió una recompensa oficial de 2,000,000 de dólares por errores de Polygon.

En la introducción de Plasma Bridge anterior, sabemos que el proceso completo de transacción de retiro es el siguiente:

- El usuario inicia una transacción de retiro en Polygon, que quema los tokens del usuario en Polygon;

- Después de un intervalo en el punto de control (aproximadamente 30 minutos), espere a que la transacción de retiro se incluya en el punto de control;

- Más de 2/3 de los validadores firman y lo envían a Ethereum, momento en el que el usuario llama a startExitWithBurntTokens() en el contrato ERC20PredicateBurnOnly para verificar si el punto de control contiene transacciones de quema;

- Si se pasa la verificación, se acuñará un cupón de reembolso NFT y se enviará al usuario

- Los usuarios esperan un período de desafío de 7 días

- Llame a WithdrawManager.processExits() para destruir el NFT y reembolsar al usuario

Nota: Para evitar la repetición de transacciones (ataques de doble gasto), Polygon utiliza NFT como prueba de reembolso para identificar de forma única una transacción de retirada. Sin embargo, debido al defecto de generación de ID de NFT, los atacantes pueden construir parámetros para generar múltiples NFT con diferentes ID utilizando la misma transacción de retiro válida, y luego usar estos NFT para transacciones de reembolso, logrando así un “ataque de doble gasto”.

A continuación, te explicamos cómo generar NFT:

1. A partir del análisis del código fuente anterior, se puede ver que addExitToQueue() llamará a _addExitToQueue() para acuñar un NFT:

De acuerdo con el análisis de parámetros, exitid = prioridad, entonces el ID del NFT se genera por el desplazamiento a la izquierda de la prioridad de edad en Plasma Bridge.

2. Como se puede ver en el análisis del código fuente anterior, la edad es el valor de retorno de la función WithdrawManager.verifyInclusion(), que primero verificará la validez de la transacción de retiro y luego generará la edad correspondiente si se pasa la verificación. En la lógica de validación, el valor descodificado por los datos del parámetro controlable es branchMaskBytes:

Este valor también se utiliza al generar age:

3. Rastree la función MerklePatriciaProof.verify() llamada en la lógica de verificación de transacciones y descubra que la función llama a _getNibbleArray() para transcodificar branchMaskBytes:

4. Continúe realizando un seguimiento de la función de decodificación, que descarta parte del valor al transcodificar branchMaskBytes, y esta forma de perder el valor hará que se transcodifiquen diferentes valores para obtener el mismo valor decodificado. En concreto, si el primer bit hexadecimal (medio byte) del valor b codificado en hp entrante es 1 o 3, se analiza el segundo bit hexadecimal. De lo contrario, el primer byte simplemente se ignora.

Si un atacante construye un parámetro branchMaskBytes de modo que el primer bit hexadecimal no sea igual a 1 y 3, hay 14*16 = 224 formas de obtener el mismo valor transcodificado.

El proceso de ataque específico es el siguiente:

- Deposita una gran cantidad de ETH/tokens en Polygon a través de Polygon Plasma

- Inicie una operación de retiro en Polygon y espere un período de desafío de 7 días

- Modifique el primer byte del parámetro branchMaskBytes en la transacción de retirada (la misma transacción válida se puede volver a enviar hasta 223 veces) e inicie la transacción de retirada repetidamente

En resumen, esta vulnerabilidad se debe principalmente a un problema en el diseño del algoritmo de identificación del NFT que genera el comprobante de reembolso para evitar la repetición, lo que da como resultado que una misma transacción de reembolso pueda generar diferentes NFT, lo que resulta en un ataque de doble gasto. Resulta que el primer byte de la máscara de rama codificada siempre debe ser 0x00. La solución consiste en comprobar si el primer byte de la máscara de rama codificada es 0x00 y no tratarlo como una máscara incorrecta.

Bueno, el intercambio de hoy ha terminado, en el próximo número, el Equipo de Investigación de Seguridad de Seguridad de la Cadena de Chengdu presentará la investigación de seguridad de otro proyecto de cadena cruzada, espérelo.