Randstorm: carteras de bitcoin creadas en la década de 2010 son vulnerables

Los investigadores descubrieron múltiples vulnerabilidades en la biblioteca de BitcoinJS que podrían hacer que las carteras de Bitcoin creadas online hace una década sean propensas a ataques de piratería. El problema básico es que las claves privadas para estas carteras criptográficas se generaron con una previsibilidad mucho mayor de la que esperaban los desarrolladores de la biblioteca.

Vulnerabilidades y consecuencias del Randstorm

Empecemos por el principio. Los investigadores de Unciphered, una empresa especializada en la recuperación del acceso a carteras criptográficas, descubrieron y describieron una serie de vulnerabilidades en la biblioteca de JavaScript de BitcoinJS que utilizan muchas plataformas de criptomonedas online. Entre estos servicios, se encuentran algunos muy populares, en particular, Blockchain.info, ahora conocido como Blockchain.com. Los investigadores llamaron “Randstorm” a este conjunto de vulnerabilidades.

Aunque las vulnerabilidades de la propia biblioteca de BitcoinJS se solucionaron en 2014, el problema se extiende a los resultados del uso de esta biblioteca: las carteras criptográficas creadas con BitcoinJS a principios de la década de 2010 pueden ser inseguras, en términos de que es mucho más fácil descubrir sus claves privadas de lo que asume la criptografía subyacente de Bitcoin.

Los investigadores estiman que varios millones de carteras, con un total de aproximadamente 1,4 millones de BTC, se encuentran en riesgo potencial debido a Randstorm. De las carteras potencialmente vulnerables, según los investigadores, del 3 al 5 % son realmente vulnerables a ataques reales. Según el tipo de cambio aproximado de Bitcoin de alrededor de 36500$ en el momento de la publicación, esto implica un botín total de 1500 a 2000 millones de dólares para los atacantes que logren explotar Randstorm con éxito.

Los investigadores afirman que las vulnerabilidades de Randstorm se pueden utilizar para ataques en el mundo real a carteras criptográficas. Además, aprovecharon estas vulnerabilidades para restaurar el acceso a varias carteras criptográficas creadas en Blockchain.info antes de marzo de 2012. Por razones éticas, no publicaron una prueba de concepto del ataque, ya que esto habría expuesto directamente a decenas de miles de carteras criptográficas al riesgo de robo.

Los investigadores ya se pusieron en contacto con los servicios de criptomonedas que se sabe que utilizaron versiones vulnerables de la biblioteca de BitcoinJS. A su vez, estos servicios notificaron a los clientes que podrían verse afectados por Randstorm.

La naturaleza de las vulnerabilidades de Randstorm

Analicemos de forma más detallada cómo funcionan estas vulnerabilidades. En el núcleo de la seguridad de la cartera de Bitcoin, se encuentra la clave privada. Como cualquier sistema criptográfico moderno, Bitcoin se basa en que esta clave es secreta e imposible de descifrar. Y, como en cualquier sistema criptográfico moderno, esto implica el uso de números aleatorios muy largos.

Además, para la seguridad de todos los datos que protege la clave privada, debe ser lo más aleatoria posible. El hecho de que el número usado como clave sea altamente predecible hace que forzar la clave sea más fácil y rápido para un atacante que cuenta con información sobre el procedimiento de generación de claves.

Ten en cuenta que generar un número verdaderamente aleatorio no es nada sencillo. Además, los ordenadores, por su naturaleza, son extremadamente inadecuados para la tarea ya que son demasiado predecibles. Por lo tanto, solemos tener números pseudoaleatorios y, para aumentar la entropía (en lenguaje de criptógrafos, la medida de imprevisibilidad) de la generación, usamos funciones especiales.

Ahora volvamos a la biblioteca de BitcoinJS. Para obtener números pseudoaleatorios de “alta calidad”, esta biblioteca utiliza otra biblioteca de JavaScript llamada JSBN (JavaScript Big Number), específicamente su función SecureRandom. Como su nombre lo indica, esta función se diseñó para generar números pseudoaleatorios que reúnan los requisitos para su uso en criptografía. Para aumentar su entropía, SecureRandom utiliza la función del navegador window.crypto.random.

Allí radica el problema: si bien la función window.crypto.random existía en la familia de navegadores de Netscape Navigator 4.x, estos navegadores ya eran obsoletos cuando los servicios web comenzaron a usar activamente la biblioteca de BitcoinJS. Además, en los navegadores populares de aquellos días (Internet Explorer, Google Chrome, Mozilla Firefox y Apple Safari), la función window.crypto.random simplemente no estaba implementada.

Por desgracia, los desarrolladores de la biblioteca de JSBN no tomaron en cuenta ningún tipo de verificación o mensaje de error correspondiente. Como resultado, la función SecureRandom pasó por alto el paso de incremento de la entropía en silencio, lo que entregó efectivamente la tarea de crear claves privadas al generador de números pseudoaleatorios estándar, Math.random.

Esto es malo en sí mismo porque Math.random no está diseñado para fines criptográficos. Sin embargo, lo que empeora aún más la situación es el hecho de que la implementación de Math.random en los navegadores populares del 2011 al 2015, en particular Google Chrome, contenía errores que dieron como resultado números incluso menos aleatorios de lo que deberían haber sido.

A su vez, la biblioteca de BitcoinJS heredó todos los problemas ya mencionados de JSBN. En consecuencia, las plataformas que lo usaron para generar claves privadas para carteras criptográficas obtuvieron números mucho menos aleatorios con la función SecureRandom de lo que esperaban los desarrolladores de la biblioteca. Dado que estas claves se generan con gran previsibilidad, son mucho más fáciles de forzar, lo que permite piratear carteras criptográficas vulnerables.

Como ya se mencionó, este no es un peligro teórico, sino bastante práctico: el equipo de Unciphered pudo explotar estas vulnerabilidades para restaurar el acceso (en otras palabras, ejecutar piratería ética) a varias carteras criptográficas antiguas creadas en Blockchain.info.

Quiénes están en riesgo de Randstorm

BitcoinJS utilizó la biblioteca de JSBN vulnerable desde su introducción en 2011 hasta 2014. Sin embargo, ten en cuenta que es posible que en algunos proyectos de criptomonedas se haya estado usando la versión anterior a la más reciente de la biblioteca durante algún tiempo. En cuanto a los errores que afectaban a la función Math.random en los navegadores populares, ya se habían solucionado en 2016 al cambiar los algoritmos para generar números pseudoaleatorios. En conjunto, esto da un marco de tiempo aproximado del 2011 al 2015 para la creación de las carteras criptográficas potencialmente vulnerables.

Los investigadores enfatizan que BitcoinJS era muy popular a principios de la década de 2010, por lo que es difícil compilar una lista completa de servicios que podrían haber utilizado una versión vulnerable de este. Su informe incluye una lista de plataformas que pudieron identificarse como en riesgo:

• BitAddress, aún en funcionamiento.
• BitCore (BitPay), aún en funcionamiento.
• Bitgo, aún en funcionamiento.
• info, aún en funcionamiento como Blockchain.com.
• Blocktrail, redirige a https://btc.com  o  https://blockchair.com
• BrainWallet, fuera de servicio.
• CoinKite, ahora comercializa carteras de hardware.
• CoinPunk, fuera de servicio.
• Dark Wallet, redirige a  https://crypto-engine.org
• DecentralBank, fuera de servicio.
• info (Block.io), aún en funcionamiento.
• EI8HT, fuera de servicio.
• GreenAddress, redirige a  https://blockstream.com/green/
• QuickCon, fuera de servicio.
• Robocoin, fuera de servicio.
• Cajero automático Skyhook, redirige a https://yuan-pay-group.net

Además de las carteras de Bitcoin, las carteras de Litecoin, Zcash y Dogecoin también podrían estar en riesgo, ya que también existen bibliotecas basadas en BitcoinJS para estas criptomonedas. Parece natural suponer que estas bibliotecas podrían usarse para generar claves privadas para las carteras criptográficas correspondientes.

En el informe de Unciphered, se describen una serie de otras complejidades asociadas con el Randstorm. Sin embargo, todo se reduce en esencia a que las carteras creadas entre 2011 y 2015 con la biblioteca vulnerable pueden presentar diversos grados de vulnerabilidad, según las circunstancias particulares.

Cómo protegerse contra el Randstorm

Como los propios investigadores afirman con razón, este no es el caso cuando basta con reparar la vulnerabilidad en el software: no es posible “revisar” las claves privadas de los propietarios de la cartera y reemplazarlas por otras seguras. Por lo tanto, a pesar de que los errores se solucionaron hace mucho tiempo, continúan afectando a las carteras criptográficas que se crearon cuando la biblioteca de BitcoinJS estaba repleta de los errores mencionados. Esto significa que los mismos propietarios de carteras vulnerables deben implementar medidas de protección.

Debido a que es difícil elaborar una lista completa de plataformas de criptomonedas que usaron la biblioteca vulnerable, es mejor ir a lo seguro y considerar que cualquier cartera criptográfica creada online entre 2011 y 2015 es potencialmente insegura (a menos que sepas con certeza que no lo es). Además, desde luego, cuanto más fondos contenga la cartera, más tentadora resultará para los delincuentes.

La solución obvia (y única) al problema es crear carteras criptográficas nuevas y mover allí todos los fondos de las carteras potencialmente vulnerables.

Como no tienes otra opción más que hacerlo, lo más lógico es que lo hagas con la mayor precaución esta vez. La protección criptográfica es un proceso de varios pasos, por lo que preparamos una lista de verificación completa para ti con mucha información adicional a la que se puede acceder a través de los siguientes enlaces:

1. Explora en detalle las amenazas criptográficas y los métodos de protección principales.
2. Comprende las diferencias entre los monederos fríos y calientes, y las formas más comunes de ataques que reciben.
3. Usa una cartera de hardware (fría) para el almacenamiento a largo plazo de los activos criptográficos principales y una cartera caliente con fondos mínimos para las transacciones diarias.
4. Antes de transferir todos los fondos de la cartera anterior a la nueva, instala en todos tus dispositivos una protección fiable. Protegerá tu teléfono inteligente u ordenador de los virus troyanos que buscan robar contraseñas y claves privadas o los clippers que sustituyen las direcciones de la cartera criptográfica en el portapapeles, además de proteger tu ordenador de los mineros criptográficos maliciosos y el acceso remoto no autorizado.
5. Nunca guardes una fotografía o una captura de pantalla de tu frase de seguridad en el teléfono inteligente; nunca publiques tu frase de seguridad en nubes públicas; nunca la envíes por mensaje o correo electrónico y no la introduzcas en ningún lugar, excepto para recuperar una clave privada perdida.
6. Guarda de forma segura tu clave privada y la frase de seguridad para su recuperación. Esto es posible con la Cartera de protección de identidad en Kaspersky Premium, que cifra todos los datos almacenados mediante AES-256. La contraseña correspondiente no se almacena en ninguna parte, excepto en tu mente (a menos que, por supuesto, esté en una nota adhesiva pegada en el monitor) y es irrecuperable, por lo que el único con acceso a tus documentos personales eres tú.
7. Otra opción es usar una cartera criptográfica fría, que no requiere una frase de seguridad para hacer una copia de seguridad de la clave privada. Así es como funciona, por ejemplo, la cartera de hardware de Tangem.