Revisión histórica: captura de una de las principales vulnerabilidades de Bitcoin
Antecedentes
Desde el lanzamiento de la red principal de Bitcoin en 2009, ha sido “segura” durante 11 años y se han producido “muy pocas” brechas de seguridad importantes. Este es también el valor de Bitcoin. Sin embargo, la “seguridad” es siempre un concepto relativo. Después de todo, Bitcoin es un conjunto de software y el software tendrá problemas.
El equipo de desarrollo de Qtum había descubierto de forma independiente en 2018 e informado al equipo de seguridad de Bitcoin un problema adicional que podría haber destruido Bitcoin: CVE-2018–17144. Esta vulnerabilidad es uno de los agujeros de seguridad más importantes en la historia de Bitcoin. Este artículo presentará el impacto de esta vulnerabilidad y algunos detalles técnicos, y revisará el descubrimiento independiente de la vulnerabilidad por parte del equipo de Qtum.
Vulnerabilidad de Bitcoin CVE-2018–17144
La vulnerabilidad Bitcoin CVE-2018–17144 puede bloquear algunas versiones anteriores de los nodos de Bitcoin, en un ataque DoS (Denegación de servicio) CVE (Common Vulnerabilities and Exposures) es la lista internacional de vulnerabilidades de ciberseguridad conocidas públicamente y se utiliza para informar problemas con todos tipos de software). Aún más aterrador es que esta vulnerabilidad se puede utilizar para emitir Bitcoins adicionales. Esto significa que si se explota esta vulnerabilidad, el límite de 21 millones de bitcoins se romperá y los atacantes pueden “crear” bitcoins nuevos a partir de la nada. También habría un número ilimitado de entradas de Bitcoin en el mercado, lo que sin duda causaría un golpe devastador al ecosistema de Bitcoin.
La vulnerabilidad se introdujo a partir de la versión 0.14.x de Bitcoin en 2017, y no se reparó hasta la versión 0.16.3 de septiembre de 2018 y se reveló por completo el 20 de septiembre. Afortunadamente, nadie ha aprovechado esta laguna durante este tiempo, de lo contrario, la historia de Bitcoin puede ser completamente diferente hoy.
Secuencia
Según la información divulgada en [1], el equipo de desarrollo de Bitcoin Core recibió un informe de vulnerabilidad DoS de desarrolladores anónimos el 17 de septiembre de 2018, y los desarrolladores de Bitcoin Core descubrieron que había un problema adicional. El problema de DoS fue menos grave, mientras que el problema adicional fue un problema crítico porque podría usarse para atacar Bitcoin. Por lo tanto, el equipo de desarrollo de Bitcoin Core solucionó este problema el 18 de septiembre y ocultó el hecho de que se descubrieron vulnerabilidades adicionales. Le dijeron a la comunidad que esto era solo una solución de vulnerabilidad DoS y se pusieron en contacto con los principales grupos de minería para actualizar. Hasta el 20 de septiembre, David Jaenson, un desarrollador de Qtum, descubrió e informó de forma independiente los detalles de una vulnerabilidad adicional [4], y el equipo de Bitcoin Core tuvo que revelar toda la información sobre las vulnerabilidades.
Las acciones del proceso de divulgación de vulnerabilidades también son suficientes para probar su gravedad. Solo para los problemas que amenazan a todo el ecosistema de Bitcoin, el equipo central de Bitcoin optará por ocultar temporalmente.
Introducción a la vulnerabilidad
El equipo de desarrollo de Bitcoin Core ha revelado los detalles de la vulnerabilidad CVE-2018–17144 en detalle [1], y muchos desarrolladores de la comunidad también han realizado un análisis técnico detallado después del evento [2] [3], los lectores interesados pueden consultar las referencias. para más detalles. Aquí hay una breve introducción a su principio.
El “doble gasto” es el problema central que todas las monedas digitales deben resolver. El llamado “doble gasto” significa que el mismo dinero se usa dos veces, lo que equivale a “ganar dinero de la nada”, lo cual es inaceptable para las monedas digitales. La capa inferior de Bitcoin utiliza el modelo UTXO (Salida de transacción no gastada), que puede evitar el “gasto doble” con una lógica extremadamente simple. El mismo UTXO no se puede utilizar dos veces. En el modelo de cuenta más familiar, la lógica para lidiar con tales problemas es mucho más complicada y no tiene nada que ver con este artículo, por lo que no se presentará.
La vulnerabilidad CVE-2018–17144 implica un ataque de “doble gasto” relativamente poco común: los mineros pueden usar esta vulnerabilidad para incluir transacciones ilegales de “doble gasto” en los bloques que extraen. Esta transacción se usa repetidamente con el mismo UTXO como entrada para “emitir” bitcoins adicionales.
Este ataque ciertamente no es fácil, y las versiones anteriores de Bitcoin han verificado rigurosamente esta situación. Sin embargo, como software, Bitcoin también se actualiza e itera constantemente. Los desarrolladores han reestructurado y optimizado estos controles con mucha lógica y eficiencia. Es durante los múltiples procesos de optimización que se introdujo un problema con la verificación de “doble gasto” mencionada anteriormente.
Proceso de introducción de vulnerabilidades
El proceso de introducción de la vulnerabilidad es aproximadamente el siguiente [4]:
En la versión de Bitcoin lanzada en 2012, el equipo de desarrollo introdujo una verificación de redundancia, que repetía la verificación de “doble gasto” mencionada anteriormente en dos piezas de código diferentes. Por supuesto, esto no es un problema en sí mismo, solo es una pérdida de tiempo.
Desde entonces, un desarrollador ha optimizado la lógica de la verificación redundante de segundo nivel y ha cambiado la lógica de rechazar transacciones cuando se encuentra con el “doble gasto” anterior para salir del nodo porque la verificación de primer nivel ya había verificado la verificación. Entonces, no sería posible volver a aparecer en la segunda inspección.
En 2017, en la versión Bitcoin 0.14, otro desarrollador realizó una optimización del rendimiento en la verificación redundante de la primera capa, porque esta verificación verificará la entrada de cada transacción una por una, y el desarrollador consideró que esta eficiencia era muy baja, por lo que el la verificación se omitió de forma predeterminada.
En la versión 0.15–0.16, la estructura de la base de datos del nodo Bitcoin había sufrido un ajuste relativamente grande. En el proceso, la verificación de redundancia de segundo nivel mencionada anteriormente se eliminó por completo. En este punto, la verificación de redundancia de dos niveles original se “eliminó” por completo.
Consecuencias
Como resultado, el ataque de “doble gasto” iniciado por el minero descrito anteriormente se vuelve posible:
Para los nodos 0.14.x, este ataque puede hacer que el nodo se bloquee directamente en un llamado ataque DoS;
Para las versiones posteriores de 0.15.x-0.16.2, este ataque de “doble gasto” se reconocerá directamente como una transacción legal para realizar la “emisión adicional” de Bitcoin.
Vale la pena señalar que solo los mineros pueden lanzar los ataques mencionados anteriormente porque las transacciones de “doble gasto” iniciadas por usuarios comunes pronto se considerarán ilegales una vez que se transmitan, mientras que los mineros pueden escribir transacciones directamente en bloques. Por lo tanto, el costo de este ataque también es muy alto y necesita suficiente potencia informática para soportarlo.
Pero incluso si no lanza un ataque directamente, solo necesita divulgar públicamente esta vulnerabilidad y método de ataque, puede “cortocircuitar” Bitcoin fácilmente y así obtener enormes beneficios en el mercado secundario.
En ese momento, la mayoría de los nodos de la red Bitcoin estaban afectados por las versiones 0.14–0.16. Si se explotara la vulnerabilidad, bastaría con destruir todo el consenso establecido por Bitcoin en los últimos diez años. El equipo de Qtum fue el primero en descubrir de forma independiente este problema adicional y, en teoría, tuvo tiempo suficiente para lanzar un ataque. Sin embargo, el equipo de Qtum no eligió lanzar un ataque o divulgarlo a través de canales públicos, sino que utilizó la divulgación responsable para informar de forma confidencial al equipo de seguridad de Bitcoin lo antes posible.
Qtum y Bitcoin
¿Por qué el equipo de Qtum puede descubrir los agujeros de seguridad de Bitcoin?
Qtum es el primer proyecto de cadena pública que admite con éxito contratos inteligentes sobre el modelo Bitcoin UTXO. La solución basada en UTXO propuesta por Qtum también se puede implementar en Bitcoin, pero es difícil para un equipo de desarrollo central conservador de Bitcoin promover una mejora tan grande. Al mismo tiempo, Qtum es también el único proyecto de código abierto que siempre sigue el último código de Bitcoin. Cada iteración de Bitcoin se introduce en Qtum. No solo eso, Qtum contiene tanto el código de modelo UTXO subyacente de Bitcoin como el EVM de Ethereum. También utiliza el mecanismo de consenso de PoS, por lo que los problemas de seguridad a considerar son más complicados que Bitcoin. Se puede decir que para convertirse en desarrollador de Qtum, primero debe convertirse en un experto en Bitcoin y Ethereum.
El 18 de septiembre de 2018, cuando el equipo de Bitcoin Core presentó la nueva versión a la comunidad para corregir la “vulnerabilidad DoS”, que ocultaba el hecho de que agregaba vulnerabilidades adicionales. El equipo de Qtum hizo un seguimiento de esta actualización, pero durante el proceso de prueba, el desarrollador de Qtum, David Jaenson, descubrió rápidamente que había un problema adicional. Con un enfoque cauteloso, David investigó en detalle el código UTXO, el código EVM y el código PoS de Qtum, y finalmente determinó que se trataba de un problema adicional del código Bitcoin en sí. Después de las discusiones con el equipo, Qtum informó la vulnerabilidad al equipo de desarrollo de Bitcoin y presentó un caso de prueba de ataque completo. Posteriormente, el equipo de Bitcoin hizo una revelación completa de la vulnerabilidad y agradeció específicamente al desarrollador de Qtum, David Jaenson, por su contribución [1].
Invitado a la mesa redonda de Satoshi Nakamoto
Hay muchos contribuyentes de código de Bitcoin entre los desarrolladores de Qtum, y es uno de los equipos técnicos más familiarizados con el código de Bitcoin y Ethereum. Es precisamente debido al apoyo a largo plazo del equipo técnico de Qtum para la comunidad tecnológica de Bitcoin que el cofundador de Qtum, Patrick Dai, fue invitado a participar en la reunión confidencial a puertas cerradas del círculo de Bitcoin en 2020: Satoshi Roundtable [5]. Esta reunión a puertas cerradas también se conoce como la “Reunión Bilderberg” del círculo de Bitcoin.
Conclusión
En el futuro, el equipo técnico de Qtum seguirá activo en proyectos de código abierto como Bitcoin y Ethereum, y trabajará con la comunidad de código abierto para garantizar el mecanismo de seguridad subyacente de la blockchain. Al mismo tiempo, Qtum continuará logrando avances en la informática de privacidad blockchain, mecanismos de consenso mejorados y máquinas virtuales más avanzadas. Creemos que otros proyectos de código abierto como Bitcoin adoptarán más soluciones de tecnología Qtum en el futuro para crear conjuntamente una infraestructura subyacente más completa de la blockchain.
Referencias
- https://bitcoincore.org/en/2018/09/20/notice/
- https://medium.com/hackernoon/bitcoin-core-bug-cve-2018-17144-an-analysis-f80d9d373362
- https://bitcoin.stackexchange.com/questions/79481/how-does-the-most-recently-found-critical-vulnerability-cve-2018-17144-work/79484#79484
- https://news.ycombinator.com/item?id=18032323
- https://mp.weixin.qq.com/s/8cxCyFvFnEV900duxNQ7fQ
Articulo Original: https://medium.com/@chain.info1/fcoin-cold-wallet-keeping-secrets-ed961cbb7e90
