Bienvenido de nuevo a Spotlight de Vulnerabilidades de Sherlock, donde destacamos una vulnerabilidad impactante descubierta durante una auditoría de Sherlock. Esta semana, tenemos el Spoofing de Depósitos. Fue descubierto por @0xalpharush y @bernd_eth en el Concurso Cross-Chain de @zetablockchain. 🧵

Aquí está el resumen de la vulnerabilidad de @bernd_eth: 1. Los observadores de ZetaChain monitorean transacciones en cadenas externas (por ejemplo, Ethereum, Solana) y las añaden a un rastreador centralizado de entradas para procesarlas como depósitos y retiros, asumiendo el éxito de la transacción. 2. A diferencia de la integración EVM, la implementación de Solana omite las verificaciones de éxito de la transacción, permitiendo que un observador malicioso añada depósitos fallidos, acuñando ZRC20 SOL sin respaldo y drenando fondos puentes. 3. A pesar de que los observadores están explícitamente autorizados por ZetaChain, es crítico asegurar que ninguna parte única pueda comprometer la cadena o siphonar activos.

Normalmente, los observadores no procesan transacciones fallidas, pero este camino de código no realiza la misma validación que su contraparte en EVM. Si bien esto requiere un rol "privilegiado", cada validador es un observador, y se supone que el consenso BFT debe ser tolerante a fallos bizantinos, es decir, tolerar <1/3 de partes maliciosas. Por lo tanto, un observador malicioso no debería poder falsificar un depósito e inducir a los validadores honestos a votar para acuñar ZRC20 Sol para transacciones fallidas a través del rastreador de entrada, que carece de validaciones para su implementación en Solana.

La causa raíz de esta vulnerabilidad: La función ProcessInboundEvents no requiere que una transacción haya tenido éxito, a diferencia del observador de entrada de EVM, que lo hace correctamente aquí. Dado que la instrucción se decodifica como si hubiera tenido éxito, un observador malicioso puede falsificar un depósito por el saldo completo de ZRC20-SOL y luego retirar el SOL bloqueado en el lado de Solana del puente, robando todos los lamports en el puente. Este ataque también podría usarse para retirar tokens SPL o realizar depósitos y llamadas arbitrarias. Por ejemplo, eliminar la propiedad escribible de la PDA del gateway en la instrucción de depósito resulta en una transacción fallida (ver el error de restricción de anclaje en el POC), y aún puede ser procesada una vez que se agrega al rastreador de entrada a través de MsgAddInboundTracker.

Condiciones previas internas: Un observador malicioso o negligente agrega una transacción fallida de Solana que contiene instrucciones de Gateway al rastreador de entrada utilizando MsgAddInboundTracker, lo que resulta en que todos los validadores procesen y voten para acuñar ZRC20 Sol en Zetachain. El CCTX recibe suficientes votos, y se acuña ZRC20 Sol no respaldado en Zetachain.

Condiciones previas externas: Cualquier parte envía una transacción fallida a la puerta de enlace con una instrucción de depósito (o depósito y llamada). El destinatario del ZRC20 Sol en Zetachain lo retira y recibe lamports en Solana.

El Camino de Ataque: 1) Cualquier parte envía una transacción fallida al gateway con una instrucción de depósito (o depósito y llamada). 2) Un observador malicioso o negligente añade una transacción fallida de Solana que contiene instrucciones del Gateway al rastreador de entrada utilizando MsgAddInboundTracker, lo que resulta en que todos los validadores procesen y voten para acuñar ZRC20 Sol en Zetachain. 3) La tarea ProcessInboundTrackers hace que el CCTX suplantado reciba suficientes votos, y se acuña ZRC20 Sol no respaldado en Zetachain. 4) El destinatario del ZRC20 Sol en Zetachain lo retira y recibe lamports en Solana.

¿Cuál es el impacto? Todos los lamports y tokens SPL depositados en el puente de Solana pueden ser robados, dado que los depósitos pueden ser falsificados por cualquier cantidad (se procesan a pesar de que el programa Gateway provoca que las transacciones se reviertan).

La Mitigación: En el procesamiento del rastreador de entrada del Observador de Solana, verifica si la transacción es exitosa antes de votar sobre ella.

Estamos orgullosos de haber ayudado a asegurar @zetablockchain a través de este descubrimiento. Cuando realmente necesita ser seguro, Sherlock es la elección correcta.