Ampliando la Perspectiva: Rastreando la Vulnerabilidad en BitcoinJS y sus Ramificaciones en Proyectos Afines

El alcance temporal de la vulnerabilidad en BitcoinJS, utilizada por varios proyectos para la generación de billeteras cripto, presenta un desafío en la determinación precisa de su duración.

No obstante, nuestras observaciones señalan la generación de billeteras vulnerables desde 2011 hasta 2015.

La confirmación de su explotabilidad resalta la urgencia de abordar este problema.

Es esencial señalar que la complejidad para explotar estas billeteras varía, incrementándose con el tiempo.

En términos generales, las billeteras generadas en 2014 presentan una resistencia sustancialmente mayor a los intentos de ataque en comparación con las generadas en 2012.

Esta información crucial proporciona un marco temporal para la evaluación de riesgos y destaca la necesidad de medidas proactivas en la comunidad de criptomonedas.

La colaboración con diversas entidades ha permitido una divulgación coordinada, alertando a millones de usuarios sobre la crítica vulnerabilidad detectada.

En el caso de posibles activos en billeteras afectadas, se aconseja la migración inmediata a una nueva billetera generada con software confiable.

La prontitud en esta transición es esencial para salvaguardar los activos y mitigar cualquier riesgo asociado.

La transparencia y la acción proactiva son pilares fundamentales en nuestra misión de mantener la integridad y seguridad en el espacio de las criptomonedas.

Descubrimiento y Resolución de Vulnerabilidad en Billeteras Cripto

En enero de 2022, Unciphered abordó un caso donde un cliente enfrentaba dificultades para acceder a su billetera Bitcoin de Blockchain.com.

Durante la investigación, identificamos un problema potencial en las billeteras generadas por BitcoinJS (y proyectos derivados) entre 2011 y 2015.

Este hallazgo impacta a millones de billeteras, especialmente aquellas generadas en 2011. El valor de los activos en estas billeteras es significativo.

Aunque otros pudieron haber observado el problema, Unciphered ha liderado esfuerzos durante más de un año para abordar y solucionar esta vulnerabilidad, demostrando nuestro compromiso con la seguridad y la protección de los activos cripto.

BitcoinJS: Evolución desde la Incepción de Bitcoin

BitcoinJS (o bitcoinjs-lib) emerge como una implementación crucial en el universo de Bitcoin.

Con el inicio de la cadena de bloques en enero de 2009, BitcoinJS sigue la estela de la innovación, marcando su primera confirmación poco más de dos años después, en mayo de 2011.

Este periodo encapsula el desarrollo continuo de una herramienta vital en el ecosistema de criptomonedas, subrayando su relevancia en la evolución tecnológica desde los primeros días de Bitcoin.

La intersección entre la historia de Bitcoin y la implementación de BitcoinJS refleja el progreso intrínseco en la creación y gestión de activos digitales.

Puede ver la versión 0.1.3 acá: https://cdnjs.cloudflare.com/ajax/libs/bitcoinjs-lib/0.1.3/bitcoinjs-min.js

Desafíos en BitcoinJS: Revelación de “Ketamina” sobre Vulnerabilidades Críticas

El 6 de abril de 2018, la comunidad de Bitcoin se vio sacudida por la revelación de “Ketamina”.

A través de un correo electrónico desde ketamina@national.shitposting.agency a la lista de desarrolladores de bitcoin, titulado “Múltiples vulnerabilidades en SecureRandom(), numerosos productos de criptomonedas afectados”, el autor alertó sobre serias fallas en la biblioteca popular BitcoinJS.

En la comunicación, “Ketamina” afirmó que una variedad significativa de productos cripto, tanto del pasado como del presente, albergaban una clase de JavaScript llamada SecureRandom().

Esta clase, según el informe, exhibía deficiencias tanto en la recolección de entropía como en el Generador de Números Aleatorios Pseudoaleatorios (PRNG).

La gravedad de estas debilidades permitía a terceros con complejidad media recuperar material clave, arrojando luz sobre un desafío crítico que requería atención inmediata por parte de la comunidad de desarrollo y usuarios de criptomonedas.

Profundizando en las Vulnerabilidades: Desafíos en la Recopilación de Entropía en BitcoinJS

El informe de “Ketamina” señaló que las variantes comunes de la biblioteca intentaban recopilar entropía del CSPRNG de window.crypto.

Sin embargo, debido a un error de tipo en una comparación, esta función pasaba silenciosamente sin generar errores.

La entropía se recolectaba posteriormente de math.Random, un generador de números pseudoaleatorios lineal de 48 bits, sembrado por el tiempo en algunos navegadores, junto con la ejecución de un temporizador de resolución media.

En ciertas configuraciones, este sistema poseía sustancialmente menos de 48 bits de entropía.

En el mismo hilo de la lista de correo, Mustafa Al-Bassam (“tflow” de LulzSec) comentó que, en la práctica, la versión del navegador era crucial, ya que navigator.appVersion < “5” siempre devolvía verdadero para navegadores antiguos.

El problema real residía en que los navegadores modernos no definían window.crypto.random, lo que podría afectar a las billeteras Bitcoin utilizando versiones anteriores a 2013 de jsbn al no emplear un CSPRNG al ejecutarse en navegadores contemporáneos.

Este señalamiento subrayó la relevancia de las versiones de bibliotecas y navegadores en la seguridad de las billeteras Bitcoin.

Parece estar haciendo referencia al siguiente código:

function SecureRandom() {} var rng_state, rng_pool, rng_pptr; if (rng_pool == null) { rng_pool = new Array(); rng_pptr = 0;

var t; if (navigator.appName == “Netscape” && navigator.appVersion < “5”) { for (t = 0; t < “MOZILLA”.length; ++t) { rng_pool[rng_pptr++] = “MOZILLA”.charCodeAt(t) & 255; } window.crypto.random(32); } else { while (rng_pptr < rng_psize) { t = Math.floor(65536 * Math.random()); rng_pool[rng_pptr++] = t >>>

8; rng_pool[rng_pptr++] = t & 255; } rng_pptr = 0; } } rng_seed_time();

Raíces Vulnerabilidades de billeteras cripto : Explorando jsbn y SecureRandom en BitcoinJS

Este código proviene de la biblioteca jsbn, “Javascript Big Number” de Tom Wu, aclamada por su rapidez y portabilidad en matemáticas de números grandes en JavaScript puro.

Esta implementación robusta habilita la criptografía de clave pública y diversas aplicaciones en navegadores de escritorio y móviles, según la visión de Wu.

La función SecureRandom, ubicada en rng.js, se presenta como un recolector de entropía rudimentario y una interfaz RNG. Su funcionamiento depende de un backend PRNG para definir prng_newstate().

Este trasfondo técnico resalta la complejidad inherente en la generación segura de números aleatorios, subrayando la necesidad de un análisis minucioso y una gestión diligente en el desarrollo de bibliotecas cripto esenciales como jsbn.

Herencia de JSBN en BitcoinJS: Persistencia de Vulnerabilidades más Allá de 2014

Aunque BitcoinJS cesó su uso de JSBN en marzo de 2014, el legado persiste. El JSBN de Tom Wu, contenido en el directorio src de bitcoinjs-lib-0.1.3.tar.gz, ha encontrado vida en otros proyectos que incorporaron su código y continuaron utilizando funciones vulnerables hasta 2015.

La amplia adopción del código temprano de BitcoinJS ha dejado una huella significativa, resultando en la presencia de billeteras vulnerables generadas en 2015.

La divulgación original resalta una lamentable realidad: el código JSBN importado a BitcoinJS intenta recopilar entropía de window.crypto.random, una propiedad que no forma parte estándar de la API de criptografía web moderna o JavaScript.

Este desafortunado detalle amplía la ventana de vulnerabilidad y destaca la importancia de la revisión constante en el desarrollo de proyectos cripto para garantizar la seguridad continua de las billeteras generadas en ese periodo.

Lecciones del Pasado: Desafíos con Math.random en Criptografía JavaScript (2009)

En el artículo de 2009, “Criptografía simétrica en Javascript” de Emily Stark, Michael Hamburg y Dan Boneh, se plantea la crítica limitación de Math.random como fuente única de entropía. La falta de confiabilidad en Math.random lleva a la búsqueda de alternativas, destacando la posibilidad de utilizar el PRNG criptográfico dedicado window.crypto.random, que hizo su primera aparición en Netscape 4.

Sin embargo, los autores lamentan que, en ese momento, window.crypto.random no estaba implementado en ningún navegador importante. Esta limitación subraya los desafíos inherentes a la obtención de entropía segura en el entorno JavaScript de la época y resalta la evolución necesaria en las capacidades de criptografía web para mejorar la seguridad de las aplicaciones basadas en navegador.

Desafiando las Limitaciones: Evolución de Entropía en BitcoinJS y JSBN

A pesar de la existencia de window.crypto.random en Netscape Navigator 4.x, su utilidad se ve comprometida en el contexto de la generación de billeteras de criptomonedas mediante BitcoinJS.

En las versiones tempranas de BitcoinJS, la función window.crypto.random no estaba presente en los navegadores utilizados para crear billeteras cripto.

Esta ausencia lleva a que la llamada a window.crypto.random en JSBN falle silenciosamente, lo que resulta en la posterior recopilación de entropía de Math.random().

Aunque Math.random() nunca debería ser empleado para generar materiales de claves criptográficas, durante el periodo crítico de 2011-2015, esta función presentaba deficiencias en todos los principales navegadores.

Este escenario subraya la complejidad de mantener la seguridad en el espacio de criptomonedas durante una fase en la que las fuentes de entropía eran limitadas y desafiantes, resaltando la necesidad de avances continuos en las prácticas de seguridad cripto.

Lecciones de la Realidad: Desafíos con Math.random() en el Motor V8 de JavaScript (2015)

El 19 de noviembre de 2015, Mike Malone compartió su experiencia en la entrada de blog “TIFU usando Math.random()“. Detalló problemas específicos en la implementación de Math.random() en el motor JavaScript V8, ampliamente utilizado por Chrome. En su empresa, Math.random() se utilizaba para generar identificadores de API, empleando identificadores de 22 caracteres.

Aunque se esperaría una colisión de 1 entre 6 mil millones de solicitudes con esta longitud de identificador, Malone descubrió que existiría un alarmante 50% de posibilidades de colisión después de generar solo 30,000 identificadores.

Este incidente resalta las limitaciones y deficiencias en la generación de números aleatorios en el entorno JavaScript, evidenciando las repercusiones directas en la seguridad de las implementaciones criptográficas y la necesidad de prácticas más seguras en el manejo de entropía.

Dificultades Generalizadas: Debilidades en Math.random() Reveladas por Comunidad y Mozilla (2015)

La publicación de Mike Malone no solo destacó los problemas específicos en el motor V8 de Chrome, sino que también señaló las preocupaciones sobre el uso de LCG (generador congruencial lineal) por parte de Mozilla en Firefox. Malone abogó por un cambio en el algoritmo de Mozilla debido a sus propias observaciones.

En respuesta, Jan de Mooij de Mozilla llevó a cabo una investigación detallada que culminó en las publicaciones del blog “Math.random() y precisión de 32 bits” y “Pruebas de Math.random(): rompiendo el navegador“.

Describió el algoritmo utilizado por Firefox como “importado de Java hace décadas” y especuló sobre su similitud con el algoritmo de Microsoft.

Los resultados de las pruebas confirmaron la falta de robustez en los RNG utilizados por la mayoría de los navegadores para Math.random().

De Mooij destacó que el GameRand RNG de Safari, aunque extremadamente rápido, era significativamente débil, generando solo alrededor de 4.2 mil millones de números diferentes, en comparación con los 9007199 millones (2^53) que podría generar un RNG ideal.

Estos hallazgos subrayan la necesidad crítica de mejorar la calidad de los RNG en los navegadores para garantizar la seguridad en operaciones criptográficas y generación de números aleatorios.

Presenta un error contra WebKit en el que sugiere que pasen a un “mejor RNG”.

Evolución hacia la Seguridad: Cambios en Algoritmos Math.random() (2016)

En un esfuerzo por abordar las vulnerabilidades inherentes, los principales navegadores realizaron cambios significativos en sus algoritmos Math.random() en 2016, optando por XorShift128+.

Esta actualización marcó un hito crucial en la mejora de la calidad y seguridad de los números aleatorios generados en el entorno del navegador.

Para un análisis más detallado de estos problemas y las soluciones adoptadas, se puede consultar la publicación del blog “Aleatoriedad en el navegador web”, que ofrece un resumen comprensivo de la evolución y los desafíos enfrentados en la generación de números aleatorios en el contexto de los navegadores web.

Debido al fallo silencioso al intentar recopilar entropía de window.crypto.random, el código BitcoinJS, importado de JSBN, se ve obligado a depender de una generación más débil de números pseudoaleatorios.

En rng.js de JSBN, se sugiere la recopilación adicional de entropía mediante la presión de teclas y clics de ratón como medida recomendada para mejorar la seguridad en el proceso de generación de números aleatorios.

En respuesta a las limitaciones de entropía de Math.random(), algunos proyectos dependientes de BitcoinJS han optado por seguir el consejo de recopilar entropía adicional mediante la interacción del usuario (presionar teclas y clics de ratón).

Esta medida, aunque mejora la situación al diversificar las fuentes de entropía, no garantiza una generación de claves completamente segura.

La cantidad de entropía recopilada sigue siendo un factor crucial, ya que determina la fortaleza de las claves generadas.

Dependiendo de la implementación y la cantidad de entropía disponible, la generación de claves aún podría ser susceptible a ciertos tipos de ataques.

Este escenario destaca la importancia de la educación y la implementación cuidadosa de prácticas de seguridad en proyectos que dependen de bibliotecas cripto, especialmente cuando se trata de la generación de claves criptográficas.

Notificación de Vulnerabilidad: Acciones Cruciales Requeridas

Aunque la notificación original de la vulnerabilidad en la lista de correo de Bitcoin-Dev no hace referencia explícita a la biblioteca JSBN, BitcoinJS, ni a proyectos posteriores como Blockchain.info (posteriormente blockchain.com), proporciona pautas claras de acción.

La recomendación principal es:

• Identificar y Mover Fondos:
  • Identificar y transferir todos los fondos almacenados utilizando SecureRandom().
• Rotar Claves:
  • Rotar todas las claves generadas o que hayan interactuado con cualquier software que utilice SecureRandom().
• Prudencia en Herramientas Criptográficas:
  • Evitar desarrollar herramientas criptográficas en lenguajes no seguros para tipos.
• Precaución con Salida de CSPRNG y RC4:
  • No utilizar la salida de un CSPRNG y pasarla por RC4.

Esta notificación enfatiza la gravedad de la situación y la necesidad de tomar medidas inmediatas.

La identificación del código débil lleva a la urgente recomendación de mover fondos y realizar rotaciones de claves para mitigar el riesgo.

La prudencia en el desarrollo de herramientas criptográficas y el manejo cuidadoso de las salidas de CSPRNG subrayan la importancia de prácticas seguras en el ámbito de la criptografía.

Impacto

BitcoinJS en Yarnpkg: Imprescindible para Billeteras de Bitcoin Web

La descripción de BitcoinJS en Yarnpkg subraya su posición vital en el ecosistema de criptomonedas:

“La biblioteca Bitcoin de JavaScript puro para node.js y navegadores.

Una implementación continua de la versión 0.1.3 original utilizada por más de un millón de usuarios de billeteras; la columna vertebral de casi todas las billeteras web de Bitcoin que se producen hoy en día.”

Esta afirmación destaca la relevancia crítica de BitcoinJS, siendo una implementación clave que ha servido como base para una gran cantidad de billeteras web de Bitcoin utilizadas por una amplia base de usuarios.

Su papel central en la infraestructura cripto subraya la importancia de abordar cualquier vulnerabilidad en esta biblioteca para garantizar la seguridad y confiabilidad de las operaciones en el espacio de las criptomonedas.

BitcoinJS fue utilizado por muchos proyectos a principios de la década de 2010. A continuación se muestra una lista no exhaustiva de proyectos que utilizaron BitcoinJS y su estado actual:

Impacto y Desafíos en Proyectos Dependientes de BitcoinJS

El impacto de la vulnerabilidad en proyectos dependientes de BitcoinJS es diverso y depende de varios factores, como la duración del uso del código vulnerable, las mitigaciones implementadas y el tamaño de la base de usuarios en ese período.

La situación varía para cada proyecto, y la magnitud del riesgo se determina según cómo se hayan generado las claves privadas.

Es crucial destacar que las claves privadas de Bitcoin deben generarse con 256 bits de entropía.

Sin embargo, debido a la vulnerabilidad en BitcoinJS y proyectos dependientes, las claves generadas podrían haber utilizado menos entropía de la requerida. Evaluar el impacto con precisión es desafiante, ya que no todas las carteras se vieron afectadas de la misma manera.

Para que un ataque sea factible, un atacante generalmente necesitaría elementos generados a partir de Math.random() en el momento de la creación de la billetera, como el GUID o IV.

Esto reduce la cantidad de trabajo necesario, pero aún implica explotar debilidades en los RNG utilizados en los navegadores durante ese período.

La capacidad de derivar el estado del RNG a partir del GUID o IV permitiría la generación de todos los valores anteriores y futuros generados por el RNG, incluida la entropía inicial crucial para la generación de claves privadas.

La complejidad y la magnitud del riesgo subrayan la importancia de la notificación temprana de vulnerabilidades, la implementación de mejores prácticas de seguridad y la evaluación continua del impacto en proyectos criptográficos y de carteras.

Evolución de la Seguridad: Mejoras Graduales en la Generación de Claves

La experiencia de Unciphered en la recuperación de carteras generadas con software derivado de BitcoinJS proporciona una visión valiosa de la evolución de la seguridad en el tiempo. En casos donde se ha tenido éxito, se ha requerido realizar 48 bits de trabajo, principalmente en billeteras generadas antes de marzo de 2012.

La dificultad de estos ataques disminuye a medida que los proyectos incorporan fuentes adicionales de entropía en la generación de billeteras.

Un ejemplo notable es el cambio realizado por Blockchain.info (ahora Blockchain.com) en marzo de 2012. Antes de esta fecha, se recopilaban hasta 48 bits de entropía adicional durante la generación de la billetera a partir de la entrada del usuario.

Después de marzo de 2012, la tarea de realizar el ataque se vuelve más desafiante, ya que se recopilan, en promedio, entre 6 y 12 bits de entropía adicional por pulsación de tecla y clic del mouse.

La entropía se extrae de la marca de tiempo (en milisegundos) de la entrada del usuario, con la marca de tiempo inicial agregando alrededor de 32 bits.

La variabilidad en el tiempo entre pulsaciones de teclas determina cuántas posibilidades de marca de tiempo deben adivinarse para reconstruir adecuadamente el conjunto de entropía utilizado para generar la clave privada del usuario.

La introducción de la entropía adicional a partir de movimientos del mouse, implementada por Blockchain.info en 2014, ha fortalecido aún más la seguridad, haciendo que el ataque sea exponencialmente más difícil.

Bitaddress.org, otro ejemplo que utiliza BitcoinJS, ha estado recopilando entropía a partir de pulsaciones de teclas, clics y movimientos del mouse desde noviembre de 2011, demostrando la evolución constante hacia prácticas más seguras en la generación de billeteras Bitcoin.

Riesgos Persistentes: Posibles Debilidades en la Generación de Carteras Criptográficas

A pesar de las mejoras y medidas implementadas en la generación de billeteras para abordar la vulnerabilidad en BitcoinJS, persisten situaciones en las que podrían generarse carteras criptográficamente débiles.

En escenarios donde las contraseñas se copian y pegan, como el uso de generadores de contraseñas, la entropía no se obtendría de las pulsaciones de teclas, lo que podría resultar en la creación de una billetera criptográficamente débil.

Este riesgo se extiende más allá de Bitcoin, ya que es probable que carteras de otras criptomonedas, como Dogecoin, también se vean afectadas por esta vulnerabilidad.

Dogechain.info, un explorador popular de Dogecoin que ofrece servicios de generación de billeteras derivados de BitcoinJS desde diciembre de 2013, podría estar en riesgo.

Además, bifurcaciones de BitcoinJS en GitHub existen tanto para Dogecoin como para Zcash. Aunque es importante señalar que Zcash se lanzó por primera vez a finales de 2016.

Bitpay, un proveedor de servicios de pago de criptomonedas fundado en 2011, incorporó código de BitcoinJS, incluido rng.js de jsbn, en su paquete bitcore desde la versión 0.1.6 en febrero de 2014 hasta la versión 0.9.5 en febrero de 2015.

La versión 0.9.4 lanzada el 12 de febrero de 2015 también podría verse afectada, lo que destaca la necesidad de una evaluación exhaustiva y actualizada de la seguridad en proyectos que han incorporado código de BitcoinJS.

Conclusión: Desafíos Persistentes en la Seguridad de Criptomonedas

La conclusión resalta la realidad de los desafíos persistentes en la seguridad de criptomonedas, especialmente en el contexto de dependencia de bibliotecas de terceros.

El caso de BitcoinJS ilustra cómo proyectos populares pueden depender de bibliotecas que carecen de suficiente personal o están abandonadas, lo que puede dar lugar a vulnerabilidades significativas.

BitcoinJS reconoce estos problemas y aconseja a los usuarios realizar auditorías exhaustivas de su código y las dependencias del proyecto.

La integridad del código se vuelve esencial, especialmente cuando se protegen activos financieros, información personal identificable (PII) u otra información confidencial.

La cadena de suministro del software, como se evidencia en el historial de problemas con SecureRandom(), Math.random() y proyectos relacionados, ha sido históricamente vulnerable a riesgos.

La analogía con el fiasco de Debian/OpenSSL en 2008 destaca la importancia de aprender de la historia para fortalecer la seguridad en el presente.

La publicación insta a los usuarios de criptomonedas a ser proactivos en la seguridad de sus billeteras.

La naturaleza única de las criptomonedas, donde no se puede parchear una clave privada y mover activos sin permiso es un delito, crea desafíos adicionales.

La única solución, en caso de descubrir que el software generó billeteras vulnerables, es que los usuarios muevan sus activos a nuevas billeteras.

La conclusión refleja el compromiso de Unciphered en la divulgación responsable y la colaboración con proveedores afectados. Además, se destaca que la vulnerabilidad es explotable, y se insta a los usuarios a considerar la transferencia de fondos a billeteras más recientes y generadas por software confiable.

La reticencia a proporcionar detalles adicionales sobre la explotación de la vulnerabilidad resalta la importancia de equilibrar la divulgación de información para la conciencia pública con la necesidad de evitar dar información adicional a posibles malos actores.

¡Importante Aviso de BitcoinJS!

¡NO uses Math.random, de ninguna manera, no lo hagas!

Este enfático mensaje desde la página actual de GitHub de BitcoinJS resalta la crítica importancia de evitar el uso de Math.random en el contexto de la generación de claves criptográficas.

Es un recordatorio directo de la vulnerabilidad asociada con esta función y la necesidad de adoptar prácticas más seguras para garantizar la integridad de las billeteras criptográficas.