{"id":4546,"date":"2023-11-29T17:44:59","date_gmt":"2023-11-29T20:44:59","guid":{"rendered":"https:\/\/itconnect.lat\/portal\/?p=4546"},"modified":"2025-12-09T16:59:09","modified_gmt":"2025-12-09T19:59:09","slug":"vulnerabilidades-de-billeteras-cripto-001","status":"publish","type":"post","link":"https:\/\/itconnect.lat\/portal\/vulnerabilidades-de-billeteras-cripto-001\/","title":{"rendered":"Vulnerabilidades de billeteras cripto 2023: nadie parchea un castillo de cartas"},"content":{"rendered":"
\n
\n

Descubriendo vulnerabilidades de billeteras cripto, Unciphered ha dedicado 22 meses a analizar BitcoinJS y derivados, revelando riesgos en proyectos asociados.<\/h1>\n
\"Vulnerabilidades<\/a>
Vulnerabilidades de billeteras cripto<\/figcaption><\/figure>\n

En el trasfondo de a\u00f1os de investigaci\u00f3n meticulosa, emerge una vulnerabilidad de magnitud cr\u00edtica que ha dado lugar a la creaci\u00f3n masiva de billeteras de criptomonedas susceptibles a riesgos.<\/p>\n

La vulnerabilidad tiene su origen en la funci\u00f3n SecureRandom() incrustada en la biblioteca javascript JSBN. Su impacto se agrava por debilidades inherentes en las implementaciones clave de Math.random() en los navegadores.<\/p>\n

Es imperativo destacar que esta vulnerabilidad persisti\u00f3 en BitcoinJS hasta marzo de 2014, lo que subraya la importancia de la temporalidad en las actualizaciones.<\/p>\n

Este descubrimiento plantea cuestionamientos cruciales sobre la seguridad de las billeteras cripto en general.<\/p>\n

A medida que la comunidad se enfrenta a la magnitud de esta amenaza, IT CONNECT LATAM se compromete a seguir monitoreando y proporcionando detalladas actualizaciones sobre este asunto de ciberseguridad cr\u00edtico para los activos cripto.<\/p>\n

La conciencia y la acci\u00f3n inmediata son esenciales para mitigar los riesgos potenciales derivados de esta vulnerabilidad significativa.<\/p>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n
\n
\n

Ampliando la Perspectiva: Rastreando la Vulnerabilidad en BitcoinJS y sus Ramificaciones en Proyectos Afines<\/strong><\/h3>\n

El alcance temporal de la vulnerabilidad en BitcoinJS, utilizada por varios proyectos para la generaci\u00f3n de billeteras cripto, presenta un desaf\u00edo en la determinaci\u00f3n precisa de su duraci\u00f3n.<\/p>\n

No obstante, nuestras observaciones se\u00f1alan la generaci\u00f3n de billeteras vulnerables desde 2011 hasta 2015.<\/p>\n

La confirmaci\u00f3n de su explotabilidad resalta la urgencia de abordar este problema.<\/p>\n

Es esencial se\u00f1alar que la complejidad para explotar estas billeteras var\u00eda, increment\u00e1ndose con el tiempo.<\/p>\n

En t\u00e9rminos generales, las billeteras generadas en 2014 presentan una resistencia sustancialmente mayor a los intentos de ataque en comparaci\u00f3n con las generadas en 2012.<\/p>\n

Esta informaci\u00f3n crucial proporciona un marco temporal para la evaluaci\u00f3n de riesgos y destaca la necesidad de medidas proactivas en la comunidad de criptomonedas.<\/p>\n

La colaboraci\u00f3n con diversas entidades ha permitido una divulgaci\u00f3n coordinada, alertando a millones de usuarios sobre la cr\u00edtica vulnerabilidad detectada.<\/p>\n

En el caso de posibles activos en billeteras afectadas, se aconseja la migraci\u00f3n inmediata a una nueva billetera generada con software confiable.<\/p>\n

La prontitud en esta transici\u00f3n es esencial para salvaguardar los activos y mitigar cualquier riesgo asociado.<\/p>\n

La transparencia y la acci\u00f3n proactiva son pilares fundamentales en nuestra misi\u00f3n de mantener la integridad y seguridad en el espacio de las criptomonedas.<\/p>\n

Descubrimiento y Resoluci\u00f3n de Vulnerabilidad en Billeteras Cripto<\/strong><\/h3>\n

En enero de 2022, Unciphered abord\u00f3 un caso donde un cliente enfrentaba dificultades para acceder a su billetera Bitcoin de Blockchain.com.<\/p>\n

Durante la investigaci\u00f3n, identificamos un problema potencial en las billeteras generadas por BitcoinJS (y proyectos derivados) entre 2011 y 2015.<\/p>\n

Este hallazgo impacta a millones de billeteras, especialmente aquellas generadas en 2011. El valor de los activos en estas billeteras es significativo.<\/p>\n

Aunque otros pudieron haber observado el problema, Unciphered ha liderado esfuerzos durante m\u00e1s de un a\u00f1o para abordar y solucionar esta vulnerabilidad, demostrando nuestro compromiso con la seguridad y la protecci\u00f3n de los activos cripto.<\/p>\n

BitcoinJS: Evoluci\u00f3n desde la Incepci\u00f3n de Bitcoin<\/strong><\/h3>\n

BitcoinJS (o bitcoinjs-lib<\/a>) emerge como una implementaci\u00f3n crucial en el universo de Bitcoin.<\/p>\n

Con el inicio de la cadena de bloques en enero de 2009, BitcoinJS sigue la estela de la innovaci\u00f3n, marcando su primera confirmaci\u00f3n poco m\u00e1s de dos a\u00f1os despu\u00e9s, en mayo de 2011.<\/p>\n

Este periodo encapsula el desarrollo continuo de una herramienta vital en el ecosistema de criptomonedas, subrayando su relevancia en la evoluci\u00f3n tecnol\u00f3gica desde los primeros d\u00edas de Bitcoin.<\/p>\n

La intersecci\u00f3n entre la historia de Bitcoin y la implementaci\u00f3n de BitcoinJS refleja el progreso intr\u00ednseco en la creaci\u00f3n y gesti\u00f3n de activos digitales.<\/p>\n

Puede ver la versi\u00f3n 0.1.3 ac\u00e1: https:\/\/cdnjs.cloudflare.com\/ajax\/libs\/bitcoinjs-lib\/0.1.3\/bitcoinjs-min.js<\/a><\/p>\n

Desaf\u00edos en BitcoinJS: Revelaci\u00f3n de “Ketamina” sobre Vulnerabilidades Cr\u00edticas<\/strong><\/h3>\n

El 6 de abril de 2018, la comunidad de Bitcoin se vio sacudida por la revelaci\u00f3n de “Ketamina”.<\/p>\n

A trav\u00e9s de un correo electr\u00f3nico desde ketamina@national.shitposting.agency<\/a> a la lista de desarrolladores de bitcoin, titulado “M\u00faltiples vulnerabilidades en SecureRandom(), numerosos productos de criptomonedas afectados”, el autor alert\u00f3 sobre serias fallas en la biblioteca popular BitcoinJS.<\/p>\n

En la comunicaci\u00f3n, “Ketamina” afirm\u00f3 que una variedad significativa de productos cripto, tanto del pasado como del presente, albergaban una clase de JavaScript llamada SecureRandom().<\/p>\n

Esta clase, seg\u00fan el informe, exhib\u00eda deficiencias tanto en la recolecci\u00f3n de entrop\u00eda como en el Generador de N\u00fameros Aleatorios Pseudoaleatorios (PRNG).<\/p>\n

La gravedad de estas debilidades permit\u00eda a terceros con complejidad media recuperar material clave, arrojando luz sobre un desaf\u00edo cr\u00edtico que requer\u00eda atenci\u00f3n inmediata por parte de la comunidad de desarrollo y usuarios de criptomonedas.<\/p>\n

Profundizando en las Vulnerabilidades: Desaf\u00edos en la Recopilaci\u00f3n de Entrop\u00eda en BitcoinJS<\/strong><\/h3>\n
\"Vulnerabilidades<\/a>
Vulnerabilidades de billeteras cripto<\/figcaption><\/figure>\n

El informe de “Ketamina” se\u00f1al\u00f3 que las variantes comunes de la biblioteca intentaban recopilar entrop\u00eda del CSPRNG de window.crypto.<\/p>\n

Sin embargo, debido a un error de tipo en una comparaci\u00f3n, esta funci\u00f3n pasaba silenciosamente sin generar errores.<\/p>\n

La entrop\u00eda se recolectaba posteriormente de math.Random, un generador de n\u00fameros pseudoaleatorios lineal de 48 bits, sembrado por el tiempo en algunos navegadores, junto con la ejecuci\u00f3n de un temporizador de resoluci\u00f3n media.<\/p>\n

En ciertas configuraciones, este sistema pose\u00eda sustancialmente menos de 48 bits de entrop\u00eda.<\/p>\n

En el mismo hilo de la lista de correo, Mustafa Al-Bassam (“tflow” de LulzSec) coment\u00f3 que, en la pr\u00e1ctica, la versi\u00f3n del navegador era crucial, ya que navigator.appVersion < “5” siempre devolv\u00eda verdadero para navegadores antiguos.<\/p>\n

El problema real resid\u00eda en que los navegadores modernos no defin\u00edan window.crypto.random, lo que podr\u00eda afectar a las billeteras Bitcoin utilizando versiones anteriores a 2013 de jsbn al no emplear un CSPRNG al ejecutarse en navegadores contempor\u00e1neos.<\/p>\n

Este se\u00f1alamiento subray\u00f3 la relevancia de las versiones de bibliotecas y navegadores en la seguridad de las billeteras Bitcoin.<\/p>\n

Parece estar haciendo referencia al siguiente c\u00f3digo:<\/p>\n

function<\/span><\/span> SecureRandom<\/span><\/span>(<\/span>) <\/span><\/span>{} <\/span>var<\/span><\/span> rng_state, rng_pool, rng_pptr; <\/span>if<\/span><\/span> (rng_pool == <\/span>null<\/span><\/span>) { rng_pool = <\/span>new<\/span><\/span> Array<\/span><\/span>(); rng_pptr = <\/span>0<\/span><\/span>; <\/span><\/p>\n

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

8<\/span><\/span>; rng_pool[rng_pptr++] = t & <\/span>255<\/span><\/span>; } rng_pptr = <\/span>0<\/span><\/span>; } } rng_seed_time();<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n

Ra\u00edces Vulnerabilidades de billeteras cripto : Explorando jsbn y SecureRandom en BitcoinJS<\/strong><\/h3>\n

Este c\u00f3digo proviene de la biblioteca jsbn, “Javascript Big Number” de Tom Wu, aclamada por su rapidez y portabilidad en matem\u00e1ticas de n\u00fameros grandes en JavaScript puro.<\/p>\n

Esta implementaci\u00f3n robusta habilita la criptograf\u00eda de clave p\u00fablica y diversas aplicaciones en navegadores de escritorio y m\u00f3viles, seg\u00fan la visi\u00f3n de Wu.<\/p>\n

La funci\u00f3n SecureRandom, ubicada en rng.js, se presenta como un recolector de entrop\u00eda rudimentario y una interfaz RNG. Su funcionamiento depende de un backend PRNG para definir prng_newstate().<\/p>\n

Este trasfondo t\u00e9cnico resalta la complejidad inherente en la generaci\u00f3n segura de n\u00fameros aleatorios, subrayando la necesidad de un an\u00e1lisis minucioso y una gesti\u00f3n diligente en el desarrollo de bibliotecas cripto esenciales como jsbn.<\/p>\n

Herencia de JSBN en BitcoinJS: Persistencia de Vulnerabilidades m\u00e1s All\u00e1 de 2014<\/strong><\/h3>\n

Aunque BitcoinJS ces\u00f3 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\u00f3digo y continuaron utilizando funciones vulnerables hasta 2015.<\/p>\n

La amplia adopci\u00f3n del c\u00f3digo temprano de BitcoinJS ha dejado una huella significativa, resultando en la presencia de billeteras vulnerables generadas en 2015.<\/p>\n

La divulgaci\u00f3n original resalta una lamentable realidad: el c\u00f3digo JSBN importado a BitcoinJS intenta recopilar entrop\u00eda de window.crypto.random, una propiedad que no forma parte est\u00e1ndar de la API de criptograf\u00eda web moderna o JavaScript.<\/p>\n

Este desafortunado detalle ampl\u00eda la ventana de vulnerabilidad y destaca la importancia de la revisi\u00f3n constante en el desarrollo de proyectos cripto para garantizar la seguridad continua de las billeteras generadas en ese periodo.<\/p>\n

Lecciones del Pasado: Desaf\u00edos con Math.random en Criptograf\u00eda JavaScript (2009)<\/strong><\/h3>\n

En el art\u00edculo de 2009, “Criptograf\u00eda sim\u00e9trica en Javascript” de Emily Stark, Michael Hamburg y Dan Boneh, se plantea la cr\u00edtica limitaci\u00f3n de Math.random como fuente \u00fanica de entrop\u00eda. La falta de confiabilidad en Math.random lleva a la b\u00fasqueda de alternativas, destacando la posibilidad de utilizar el PRNG criptogr\u00e1fico dedicado window.crypto.random, que hizo su primera aparici\u00f3n en Netscape 4.<\/p>\n

Sin embargo, los autores lamentan que, en ese momento, window.crypto.random no estaba implementado en ning\u00fan navegador importante. Esta limitaci\u00f3n subraya los desaf\u00edos inherentes a la obtenci\u00f3n de entrop\u00eda segura en el entorno JavaScript de la \u00e9poca y resalta la evoluci\u00f3n necesaria en las capacidades de criptograf\u00eda web para mejorar la seguridad de las aplicaciones basadas en navegador.<\/p>\n

Desafiando las Limitaciones: Evoluci\u00f3n de Entrop\u00eda en BitcoinJS y JSBN<\/strong><\/h3>\n

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\u00f3n de billeteras de criptomonedas mediante BitcoinJS.<\/p>\n

En las versiones tempranas de BitcoinJS, la funci\u00f3n window.crypto.random no estaba presente en los navegadores utilizados para crear billeteras cripto.<\/p>\n

Esta ausencia lleva a que la llamada a window.crypto.random en JSBN falle silenciosamente, lo que resulta en la posterior recopilaci\u00f3n de entrop\u00eda de Math.random().<\/p>\n

Aunque Math.random() nunca deber\u00eda ser empleado para generar materiales de claves criptogr\u00e1ficas, durante el periodo cr\u00edtico de 2011-2015, esta funci\u00f3n presentaba deficiencias en todos los principales navegadores.<\/p>\n

Este escenario subraya la complejidad de mantener la seguridad en el espacio de criptomonedas durante una fase en la que las fuentes de entrop\u00eda eran limitadas y desafiantes, resaltando la necesidad de avances continuos en las pr\u00e1cticas de seguridad cripto.<\/p>\n

Lecciones de la Realidad: Desaf\u00edos con Math.random() en el Motor V8 de JavaScript (2015)<\/strong><\/h3>\n

El 19 de noviembre de 2015, Mike Malone comparti\u00f3 su experiencia en la entrada de blog “TIFU usando Math.random()<\/a>“. Detall\u00f3 problemas espec\u00edficos en la implementaci\u00f3n 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.<\/p>\n

Aunque se esperar\u00eda una colisi\u00f3n de 1 entre 6 mil millones de solicitudes con esta longitud de identificador, Malone descubri\u00f3 que existir\u00eda un alarmante 50% de posibilidades de colisi\u00f3n despu\u00e9s de generar solo 30,000 identificadores.<\/p>\n

Este incidente resalta las limitaciones y deficiencias en la generaci\u00f3n de n\u00fameros aleatorios en el entorno JavaScript, evidenciando las repercusiones directas en la seguridad de las implementaciones criptogr\u00e1ficas y la necesidad de pr\u00e1cticas m\u00e1s seguras en el manejo de entrop\u00eda.<\/p>\n

Dificultades Generalizadas: Debilidades en Math.random() Reveladas por Comunidad y Mozilla (2015)<\/strong><\/h3>\n

La publicaci\u00f3n de Mike Malone no solo destac\u00f3 los problemas espec\u00edficos en el motor V8 de Chrome, sino que tambi\u00e9n se\u00f1al\u00f3 las preocupaciones sobre el uso de LCG (generador congruencial lineal) por parte de Mozilla en Firefox. Malone abog\u00f3 por un cambio en el algoritmo de Mozilla debido a sus propias observaciones.<\/p>\n

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

Describi\u00f3 el algoritmo utilizado por Firefox como “importado de Java hace d\u00e9cadas” y especul\u00f3 sobre su similitud con el algoritmo de Microsoft.<\/p>\n

Los resultados de las pruebas confirmaron la falta de robustez en los RNG utilizados por la mayor\u00eda de los navegadores para Math.random().<\/p>\n

De Mooij destac\u00f3 que el GameRand RNG de Safari, aunque extremadamente r\u00e1pido, era significativamente d\u00e9bil, generando solo alrededor de 4.2 mil millones de n\u00fameros diferentes, en comparaci\u00f3n con los 9007199 millones (2^53) que podr\u00eda generar un RNG ideal.<\/p>\n

Estos hallazgos subrayan la necesidad cr\u00edtica de mejorar la calidad de los RNG en los navegadores para garantizar la seguridad en operaciones criptogr\u00e1ficas y generaci\u00f3n de n\u00fameros aleatorios.<\/p>\n

Presenta un error contra WebKit<\/a> en el que sugiere que pasen a un “mejor RNG”.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\"\"<\/div>\n<\/div>
\n
\n

del <\/em>error 151641<\/em><\/a> : use un RNG mejor para Math.random()<\/em><\/p>\n<\/div>\n<\/figcaption><\/figure>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n

Evoluci\u00f3n hacia la Seguridad: Cambios en Algoritmos Math.random() (2016)<\/strong><\/h3>\n

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

Esta actualizaci\u00f3n marc\u00f3 un hito crucial en la mejora de la calidad y seguridad de los n\u00fameros aleatorios generados en el entorno del navegador.<\/p>\n

Para un an\u00e1lisis m\u00e1s detallado de estos problemas y las soluciones adoptadas, se puede consultar la publicaci\u00f3n del blog “Aleatoriedad en el navegador web”, que ofrece un resumen comprensivo de la evoluci\u00f3n y los desaf\u00edos enfrentados en la generaci\u00f3n de n\u00fameros aleatorios en el contexto de los navegadores web.<\/p>\n

Debido al fallo silencioso al intentar recopilar entrop\u00eda de window.crypto.random, el c\u00f3digo BitcoinJS, importado de JSBN, se ve obligado a depender de una generaci\u00f3n m\u00e1s d\u00e9bil de n\u00fameros pseudoaleatorios.<\/p>\n

En rng.js de JSBN, se sugiere la recopilaci\u00f3n adicional de entrop\u00eda mediante la presi\u00f3n de teclas y clics de rat\u00f3n como medida recomendada para mejorar la seguridad en el proceso de generaci\u00f3n de n\u00fameros aleatorios.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\"\"<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n

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

Esta medida, aunque mejora la situaci\u00f3n al diversificar las fuentes de entrop\u00eda, no garantiza una generaci\u00f3n de claves completamente segura.<\/p>\n

La cantidad de entrop\u00eda recopilada sigue siendo un factor crucial, ya que determina la fortaleza de las claves generadas.<\/p>\n

Dependiendo de la implementaci\u00f3n y la cantidad de entrop\u00eda disponible, la generaci\u00f3n de claves a\u00fan podr\u00eda ser susceptible a ciertos tipos de ataques.<\/p>\n

Este escenario destaca la importancia de la educaci\u00f3n y la implementaci\u00f3n cuidadosa de pr\u00e1cticas de seguridad en proyectos que dependen de bibliotecas cripto, especialmente cuando se trata de la generaci\u00f3n de claves criptogr\u00e1ficas.<\/p>\n

Notificaci\u00f3n de Vulnerabilidad: Acciones Cruciales Requeridas<\/strong><\/h3>\n
\"Vulnerabilidades<\/a>
Vulnerabilidades de billeteras cripto<\/figcaption><\/figure>\n

Aunque la notificaci\u00f3n original de la vulnerabilidad en la lista de correo de Bitcoin-Dev no hace referencia expl\u00edcita a la biblioteca JSBN, BitcoinJS, ni a proyectos posteriores como Blockchain.info (posteriormente blockchain.com), proporciona pautas claras de acci\u00f3n.<\/p>\n

La recomendaci\u00f3n principal es:<\/p>\n