Cosmos Vulnerability Scanner — Informe de Auditoría

La función CalculateSwapAmount realiza multiplicaciones de sdk.Int sin verificar desbordamiento antes de dividir. Con balances de pool grandes (>2^127), la multiplicación intermedia desborda silenciosamente, devolviendo un precio incorrecto que permite extraer tokens a precio cero. El flujo es alcanzable directamente desde el msg_server.Swap.

1. El atacante deposita liquidez creando un pool con balanceOut cercano a 2^127 tokens.
2. Envía un MsgSwap con amountIn = 1 satoshi para triggear la multiplicación desbordada.
3. numerator desborda a valor negativo → Quo devuelve un valor enorme.
4. El atacante recibe balanceOut completo del pool pagando 1 satoshi. Pérdida total para LPs.

El hook OnRecvPacket en el módulo DEX no valida correctamente el denom del token recibido antes de hacer acreditar fondos en el pool. Un paquete IBC malformado con un denom que contiene trazas de path múltiples puede bypasear la verificación de equivalencia y hacer que el contabilizador del pool asigne más tokens de los realmente transferidos.

1. Atacante abre canal IBC desde una cadena controlada hacia NovaCosmos.
2. Envía paquete con denom falsificado: transfer/channel-0/transfer/channel-0/uNOVA con amount = 1000000.
3. OnRecvPacket no verifica la ruta completa, acepta el paquete y acredita 1.000.000 uNOVA al pool.
4. Atacante retira liquidez del pool, extrayendo NOVA legítimo sin haberlo depositado.

La función execute_withdraw en vault_strategy.wasm actualiza el balance del usuario después de enviar los fondos via BankMsg::Send. Un contrato receptor malicioso puede re-ejecutar withdraw en el callback, drenando el vault antes de que el balance se actualice en el store. El patrón checks-effects-interactions no se aplica.

1. Atacante despliega un contrato receptor malicioso que tiene un receive handler.
2. Deposita 1000 NOVA en el vault con el contrato receptor como dirección.
3. Llama a withdraw(1000). BankMsg::Send se ejecuta antes de actualizar BALANCES.
4. El contrato receptor, al recibir fondos, llama a withdraw(1000) nuevamente — balance aún no actualizado.
5. El ciclo se repite hasta vaciar el vault. Pérdida total de todos los depósitos.

El BeginBlocker de x/liquidstaking itera sobre un mapa Go (map[string]ValidatorRecord) para calcular distribución de recompensas. En Go, la iteración sobre mapas es no-determinista por diseño. Diferentes validadores producirán distintos órdenes de iteración, resultando en state roots divergentes y una parada de cadena inmediata.

1. La cadena avanza al bloque N con 50+ validadores activos.
2. Cada validador itera el mapa en orden diferente → diferentes DistributeRewards → diferentes app hashes.
3. En el siguiente bloque, los validadores no alcanzan consenso sobre el app hash.
4. La cadena se detiene permanentemente. Requiere hard fork coordinado para recuperarse.

La función rebalanceVaults ejecutada en EndBlocker llama a k.GetStrategy(ctx, strategyID) sin comprobar si la estrategia existe. Si un vault referencia una estrategia eliminada (posible mediante gobernanza), se produce un panic no capturado que detiene todos los nodos simultáneamente.

El mensaje MsgUpdateVaultParams verifica que el signer sea el Authority del módulo (governance), pero la verificación compara un string sin normalizar contra la dirección bech32. Una dirección con diferente casing podría bypassear la verificación en algunas condiciones de SDK v0.50.