Re: “Stake falso” Ataques en blockchains que hacen uso de Proof-of-Stake
Un grupo de investigadores en el Laboratorio de Sistemas Descentralizados de la UIUC descubrió “una serie de vulnerabilidades de agotamiento de recursos” que afectan a numerosas redes de prueba de staking, incluida Qtum.
Para ser claros, los fondos nunca estuvieron en riesgo. El ataque ilustrado por el equipo es un tipo de ataque de denegación de servicio (DoS) que solo se puede ejecutar contra un solo nodo a la vez.
Sin embargo, hemos estado en contacto con estos investigadores por varios meses haciendo seguimiento del manejo responsable de esa falla. Apreciamos la investigación del Laboratorio de Sistema Descentralizado y la forma en que nos informaron para poder solucionar el problema antes de que se hiciera público la semana pasada.
Los investigadores presentaron dos tipos de ataques:
- “No stake” — ataque de spam de cabecera
- “stake gastada”: bloqueos completos de spam (no es posible en Qtum)
Como se indicó en el artículo original, solo la vulnerabilidad “Sin Stake” afectó a Qtum; sin embargo, ya hemos mitigado los riesgos de un ataque de este vector en nuestra versión 0.16.2.
El ataque “No Stake” consistió en dos vectores de ataque similares pero distintos que podrían permitir que un atacante haga que un nodo se quede sin memoria en el caso del primer vector de ataque o espacio en disco en el caso del segundo vector de ataque.
El primero de estos vectores de ataque fue causado por una validación insuficiente antes de almacenar los encabezados en la memoria. Un atacante potencial podría, por lo tanto, causar que sus compañeros se queden sin memoria al inundarlos con encabezados inválidos. La razón por la que esto fue posible fue que Qtum hereda la característica de encabezados de Bitcoin que se introdujo en la versión 0.10.0 de Bitcoin. En Bitcoin, la prueba de trabajo del encabezado (PoW) se valida antes de que el encabezado se almacene en la memoria. Sin embargo, no existe ningún PoW en el protocolo de prueba de estaca (PoS) de Qtum y el PoS en Qtum solo se puede validar completamente una vez que se recibe el bloque completo, ya que la transacción de coinstalación se encuentra en el bloque. Por lo tanto, un ataque potencial podría haber sido capaz de crear una gran cantidad de encabezados no válidos y enviarlos a compañeros para que se queden sin memoria.
El segundo de estos vectores de ataque se relacionó con cómo / cuándo Qtum realiza la validación de bloque completo. En Qtum, la validación de bloque completo y la validación conjunta se realizan cuando se recibe un nuevo bloque que tiene más trabajo en cadena total que el trabajo en cadena del consejo anterior. En efecto, esto significa que la comprobación completa del PoS se realiza solo cuando se agrega un nuevo bloque a la punta actual o cuando se recibe la punta de una horquilla que tiene más cadena total que la punta actual y, por lo tanto, desencadena una reorganización del bloque. Sin embargo, en versiones anteriores de Qtum, los nuevos bloques se confirmaban en el disco si un nodo recibía un bloque con trabajo en cadena igual o mayor que el trabajo en cadena de la punta actual. Por lo tanto, un atacante podría hacer que los pares envíen bloques al disco sin que los compañeros validen completamente el PoS y que se queden sin espacio en el disco.
El v0.16.2 de Qtum, que era una actualización recomendada, incluía mejoras en la seguridad de la red y correcciones de errores en forma de:
- Implementar protección de spam en la red.
- Solo solicite bloques a sus compañeros cuando su trabajo en cadena es estrictamente más significativo que el consejo actual
- Agrega chequeos de cabecera adicionales para la marca de tiempo de PoS, indices de bloques, tipos de firma (LowS), puntos de chequeo sincronizados y moviles.
- Agregar puntos de control recientes
- Actualice nMinimumChainWork, defaultAssumeValid y chainTxData
- Actualizar BLOCK_CHAIN_SIZE
- Arregla tests de QT que fallaban al hacer “make check” en OSX Mojave
- Arreglar getPC de plantilla RPC para bloques de PoS
- Corrija los mensajes de ayuda para Walletpassphrase y getnetworkhashps RPC.
El ataque de bloque/disco requirio solo un ligero ajuste a cuando Qtum gudarda los bloques en el disco. Los bloques ahora se guardan solamente si el bloque es parte de una cadena cuya punta de trabajo es mayor que la punta activa de trabajo.
El ataque de encabezado / memoria se mitigó al implementar la detección de spam potencial de encabezado y desconectar y prohibir a cualquier interlocutor ofensor. Varias comprobaciones que antes solo se realizaban cuando se recibían los bloques completos también se agregaron a la comprobación de encabezado independiente. Por ejemplo, asegurarse de que la firma contenida en el encabezado esté en el formato correcto antes de guardar el encabezado en la memoria, se podrían utilizar grandes firmas no válidas para amplificar el spam de encabezado.
La protección contra correo no deseado de la red implementada en v0.16.2 detecta a los compañeros que están tratando de ejecutar tales ataques de “No stake” y los prohíbe. Ahora, los nodos solo solicitan bloques a sus pares cuando su trabajo en cadena es estrictamente mayor que la punta actual. Además de estas contramedidas, agregamos comprobaciones de encabezado adicionales para las marcas de tiempo de PoS, los índices de bloque, el tipo de firma (LowS) y los puntos de control sincronizados y continuos.
Creemos que estos parches deberían hacer que cualquier ataque sea casi imposible de ejecutar debido a la complejidad agregada y las características de seguridad implementadas. A pesar de esto, estamos trabajando en una solución más completa que ha superado nuestras pruebas iniciales, pero como es un cambio comparativamente más sustancial en el protocolo, necesitamos más pruebas.
