NoticiasCriptoEl hackeo de Coldcard demuestra que la reputación no es un modelo de seguridad

El hackeo de Coldcard demuestra que la reputación no es un modelo de seguridad

Autor: Coindesk·

Puntos clave

  • Los atacantes han robado casi 114 millones de dólares en bitcoin en más de 709 direcciones al aprovechar una falla en el firmware de Coldcard que producía semillas de billetera con una aleatoriedad insuficiente; un barrido inicial vació aproximadamente 500 billeteras en 25 minutos.
  • El código defectuoso de generación de semillas se introdujo en un commit de marzo de 2021 —el mismo commit que eliminó el último código con licencia GPL— y permaneció visible públicamente durante más de cinco años sin que nadie lo detectara.
  • Coldcard pasó de una licencia GPL a una licencia con Commons Clause a fines de 2020, después de que un competidor construyera sobre su código, y la propia FAQ de la Commons Clause establece que el software resultante ya no es de código abierto.
  • Investigadores de Shift Crypto, Nunchuk y el proyecto WalletScrutiny que previamente reportaron fallas en Coldcard enfrentaron burlas públicas, cuestionamientos a su competencia y amenazas de litigio por parte del CEO de Coinkite, Rodolfo Novak, lo que, según el autor, desalentó la revisión independiente.
  • El autor advierte que actualizar el firmware no puede reparar las semillas generadas en versiones vulnerables, y que el exploit ha desatado una crisis de confianza más amplia en la autocustodia de bitcoin.
El hackeo de Coldcard demuestra que la reputación no es un modelo de seguridad

El hackeo de Coldcard demuestra que la reputación no es un modelo de seguridad

Una comunidad construida sobre la verificación pasó cinco años externalizando su juicio a un solo hombre, escribe Zach Herbert, CEO de Foundation.

Los atacantes ya han drenado casi 114 millones de dólares en bitcoin de más de 709 direcciones, aprovechando una falla en el firmware de Coldcard que generaba semillas de billetera con solo una fracción de la aleatoriedad prometida. El primer barrido vació aproximadamente 500 billeteras en 25 minutos. El error entró en el código base en marzo de 2021 y permaneció a la vista pública, en código abierto, durante más de cinco años, un recordatorio de que el código visible no es lo mismo que el código revisado.

Muchas personas están explicando lo que ocurrió. La pregunta más difícil es por qué nadie lo detectó, y la respuesta implica mucho más que una línea de código.

El error permaneció público durante cinco años

El código fuente de Coldcard siempre estuvo disponible para inspección. “No confíes, verifica” solo funciona cuando personas calificadas realmente revisan, y durante cinco años, en la práctica, nadie lo hizo.

La cronología en torno a la introducción del error merece atención. En 2020, el firmware de Coldcard tenía una licencia de código abierto GPL. Dos días después de que un competidor anunciara un dispositivo basado en ese código GPL, el CEO de Coinkite, Rodolfo Novak, conocido como NVK, dijo públicamente (en un tuit que luego fue eliminado) que se arrepentía de haber elegido GPL. Ese noviembre, Coldcard adoptó una nueva licencia con la Commons Clause, cuya propia FAQ establece con claridad que el software resultante ya no es de código abierto.

Le siguió una reescritura integral, y el commit de marzo de 2021 que eliminó el último código GPL es el mismo commit que rompió la generación de semillas. Nadie puede medir cuánta presión de licenciamiento moldeó el alcance o la velocidad de esa reescritura, y la renovación también perseguía objetivos técnicos legítimos. Los hechos documentados son más acotados y, aun así, contundentes: un cambio de licencia destinado a restringir a los competidores precedió a un reemplazo apresurado de código criptográfico probado en batalla, y ese reemplazo contenía la falla que ahora drena billeteras. En el software sensible a la seguridad, los cambios que alteran el licenciamiento, la propiedad del código o el proceso de publicación pueden importar tanto como la propia ruta del código, porque determinan cuántos ojos permanecen sobre el resultado final.

Los principios del software libre y de código abierto existen precisamente para evitar que la seguridad dependa de las decisiones de una sola empresa. Esos principios no pueden incluir una excepción de personalidad.

Zach Herbert es cofundador y CEO de Foundation.

Los investigadores aprendieron a no revisar

El fracaso más profundo tiene que ver con lo que les ocurrió a quienes sí revisaron. En agosto de 2020, investigadores de Shift Crypto y Nunchuk revelaron una falla de verificación multisig en Coldcard. Coinkite reconoció el error y publicó una corrección, y NVK, en el podcast Citadel Dispatch, a la vez calificó la divulgación de “terrorismo de relaciones públicas” y cuestionó si un investigador sin un CVE contaba como profesional. En 2023, cuando el proyecto WalletScrutiny reportó problemas para reproducir versiones antiguas de Coldcard, la respuesta tachó al proyecto de incompetente o malicioso y planteó entablar litigio (publicación de seguimiento). Un seguimiento independiente encontró más tarde problemas genuinos de reproducción en versiones antiguas y concluyó que nadie había actuado de mala fe.

Cada ataque público contra un investigador cambia el cálculo para el siguiente. La revisión independiente es lenta, difícil y, por lo general, no remunerada. Un investigador que sopesa meses de ese trabajo frente a la perspectiva del ridículo, las listas de bloqueo y las amenazas legales a menudo destinará su tiempo a otra parte. Nadie puede demostrar que esta cultura haya causado que el error de entropía pasara desapercibido. Lo que sí puede afirmarse con seguridad es que la seguridad depende de que las personas estén dispuestas a revisar, y el entorno alrededor de Coldcard castigaba revisar.

La reputación se convirtió en la evidencia

¿Cómo terminó aquí una comunidad cuyo lema fundacional es “no confíes, verifica”? La psicología tiene nombres para ello. El efecto de verdad ilusoria hace que las afirmaciones repetidas parezcan confirmadas de forma independiente, incluso cuando provienen de una sola fuente. El efecto halo convierte el estatus, la seguridad en sí mismo y los productos populares en una autoridad técnica presumida. Año tras año, las mismas afirmaciones circularon por los mismos podcasts y feeds: los críticos eran publicistas encubiertos, los investigadores eran terroristas, los competidores eran clones. La repetición hizo el trabajo que la evidencia debería haber hecho, y la confianza se convirtió en un sustituto de la prueba.

El resultado se describe mejor como captura epistémica: una comunidad que externaliza gradualmente su juicio a una autoridad de confianza hasta que la propia autoridad se convierte en la evidencia. Ben Perrin, presentador de BTC Sessions, describió el mecanismo con una franqueza inusual en una transmisión en vivo reciente, admitiendo que dejó pasar ese comportamiento porque asumía que la arrogancia venía acompañada de una capacidad superior para crear y asegurar. Gran parte de la industria hizo el mismo cálculo. La crisis de confianza que hoy se propaga por la autocustodia es la factura que llega a su vencimiento, porque usuarios y desarrolladores por igual ahora tienen que distinguir entre la lealtad de marca de larga data y la verificación real.

Verificar a todos

La primera prioridad de la industria tras el exploit son los usuarios: difundir la guía de migración y dejar claro que actualizar el firmware no puede reparar una semilla generada en versiones vulnerables. Luego viene el trabajo detrás de cámaras. Las antiguas páginas de recomendaciones, las notas de episodios y las guías de productos acumulan años de afirmaciones que se repitieron en lugar de verificarse, y merecen correcciones con fuentes primarias adjuntas. Los desarrolladores e investigadores que fueron atacados merecen el espacio para explicar su trabajo. Los medios de bitcoin deben volver a ser adversariales, aplicando a los amigos, patrocinadores y anunciantes el mismo escrutinio que aplican a los desconocidos.

Bitcoin fue diseñado bajo el supuesto de que los expertos y las instituciones eventualmente fallarán, y su respuesta fue hacer innecesaria la confianza mediante la verificación. La comunidad que construyó herramientas que encarnan ese principio eximió de él a sus propias voces más estridentes. La solución es la instrucción fundacional, aplicada esta vez sin favoritismos. No confíes en el proveedor. No confíes en los críticos del proveedor. Verifica.

Nota: Las opiniones expresadas en esta columna pertenecen al autor y no necesariamente reflejan las de CoinDesk, Inc. ni las de sus propietarios y afiliados.