Una vulnerabilidad en el monedero hardware Coldcard provoca el robo de más de 88 millones de dólares en bitcoin

Las pérdidas derivadas de la explotación de una vulnerabilidad en los monederos hardware Coldcard ya superan los 88 millones de dólares y el ataque sigue activo. El 31 de julio se comprometieron aproximadamente 500 dispositivos Coldcard, con el robo de 594 BTC valorados en torno a 38 millones de dólares. Posteriormente, Coinkite —fabricante de Coldcard— confirmó un fallo de seguridad en el proceso de generación de claves que afecta a varias generaciones del producto, incluidas Coldcard Mk2, Mk3, Mk4, Q y Mk5. Se recomienda a los usuarios trasladar sus fondos a otra dirección lo antes posible. Beosin publicó el siguiente análisis técnico y el seguimiento de los fondos sustraídos: I. Análisis de la vulnerabilidad El historial de commits del firmware de Coldcard muestra que en el commit anterior 37e4af5451c260c1e7d429fe8972c4cb5e68ee59 el equipo actualizó varios fragmentos vinculados a la configuración de MK4. Entre ellos, en mpconfigboard.h figura: // We have our own version of this code. #define MICROPY_HW_ENABLE_RNG (0) En MicroPython para STM32, esta macro determina la ruta de compilación del binding del generador de números aleatorios por hardware (RNG) y la implementación genérica de aleatoriedad. Al fijarse en 0, se impide que la ruta RNG por hardware por defecto se utilice como backend de la función genérica rng_get(). El comentario sugiere que el desarrollador implementará su propio RNG. Al revisar el archivo personalizado rng.h solo se declaran dos objetos de MicroPython: MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj); MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj); Su implementación asociada es: /// \function pyb_rng_get() ///// Returns a 30bit hardwaregenerated random number, or fails! //STATIC mp_obj_t pyb_rng_get(void){ // Retrieve and return the new random number return mp_obj_new_int(rng_get_or_fault() >> 2); } /// \function rng_get_bytes() /// Fills a buffer with random bits; the caller must provide a buffer of appropriate size. STATIC mp_obj_t pyb_rng_get_bytes(mp_obj_t buffer_io) { mp_buffer_info_t bufinfo; mp_get_buffer_raise(buffer_io, &bufinfo, MP_BUFFER_WRITE); mp_uint_t count = bufinfo.len; if(count SR & RNG_SR_DRDY)) { if (HAL_GetTick() start >= RNG_TIMEOUT_MS) { // Hardware failure... do not return anything! mp_raise_OSError(MP_EFAULT); } } // Retrieve and return the new random number last_value = RNG>DR; return last_value; } Esto indica que el código personalizado de Coldcard pretendía usar el RNG por hardware, pero solo lo garantiza cuando se llama a pyb_rng_get* o a random_buffer() internamente. En la creación del monedero, el flujo real invoca la función en shared/seed.py: async def make_new_wallet(nwords): # Select a new random seed. await ux_dramatic_pause(\u0022Generating...\u0022, 3) seed = generate_seed() words = await approve_word_list(seed, nwords) if words: await commit_new_words(words) Esa llamada entra primero en el módulo shared/random.py de Coldcard. En versiones anteriores, random.py dependía explícitamente de ngu.random e incluía: # random.py subset of the random module, with no compatibility, using cryptographically secure RNG # for bytes, use ngu.random.bytes(len) # bytes = ngu.random.bytes La inicialización del monedero utiliza random.bytes, no pyb.rng(); el objeto personalizado pyb_rng_get_obj no sustituye automáticamente a random.bytes. Con MICROPY_HW_ENABLE_RNG configurado en 0, la generación del monedero no usó un RNG por hardware y terminó llamando a pyb_rng_yasmarang desde micropython/ports/stm32/rng.c: #if MICROPY_HW_ENABLE_RNG uint32_t rng_get(void) { // Use STM32 hardware RNG ... } #else // For MCUs without an RNG, we still need to provide an rng_get() function. // A pseudoRNG is not ideal, but we use it for now. // Yasmarang random number generator static uint32_t pyb_rng_yasmarang(void) { static bool seeded = false; static uint32_t pad = 0, n = 0; ... } uint32_t rng_get(void) { return pyb_rng_yasmarang(); } #endif pyb_rng_yasmarang es un generador seudoaleatorio y resulta altamente inseguro para crear semillas de un monedero hardware, ya que un atacante puede forzar la clave mediante fuerza bruta. Coinkite ha indicado que ahora excluye explícitamente stm32/rng.c en el Makefile: Do not compile MicroPython\u0027s fallback PRNG. The boardspecific rng.c provides rng_get(), and this empty object satisfies the upstream object list. $(BUILD)/rng.o: CFLAGS += Dpyb_rng_yasmarang=errordonotwantthis $(BUILD)/rng.o: $(ECHO) \u0022SKIP stm32/rng.c\u0022 $(Q)$(CC) $(CFLAGS) x c c /dev/null o $@ II. Seguimiento de los fondos robados Los fondos de múltiples víctimas ya se han movido y concentrado en varias direcciones, sin que por ahora se observe un proceso de blanqueo adicional. A partir de inteligencia de amenazas y análisis de comportamiento on-chain, Beosin Trace identificó las siguientes direcciones de agregación: bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r (562 BTC) bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 (398.47 BTC) Además, estas direcciones muestran un patrón de flujo de fondos similar y aún no registran nuevas transferencias: bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q (89.62 BTC) bc1q0rvn88w08j75k4h48lf9fvhan7unjp7vjf5q6m (64.9 BTC) bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75 (45.9 BTC) bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6 (30.18 BTC) Beosin señala que los ataques contra Coldcard continúan y que su equipo sigue monitorizando nuevas direcciones de concentración y analizando los movimientos relacionados. III. Conclusión Este incidente de seguridad en Coldcard se originó por un error de implementación: durante el proceso crítico de generación de la semilla del monedero se utilizó un generador seudoaleatorio. El equipo de desarrollo debería reforzar las pruebas, auditorías y revisiones continuas del código. Los usuarios de Coldcard, por su parte, deberían mover sus activos de inmediato y seguir de cerca los próximos avisos de seguridad de Coinkite. Beosin es una empresa especializada en seguridad blockchain y tecnología de cumplimiento regulatorio. Sus servicios incluyen auditorías de seguridad de contratos inteligentes antes del lanzamiento, monitorización y bloqueo de riesgos en tiempo real, recuperación de activos, soluciones AML para activos virtuales y trazabilidad investigativa. Beosin afirma haber prestado productos y servicios integrales de cumplimiento y seguridad blockchain a reguladores y cuerpos de seguridad en más de 20 países y regiones, a más de 200 proveedores de servicios de activos virtuales y a más de 4.500 proyectos Web3.