BLOG |
Anuncios intermitentes
Cómo un atacante aprovechó una vulnerabilidad en nuestras herramientas de administración para sustraer 6,61 BTC de 24 cuentas, cómo se recuperaron todas ellas y qué medidas hemos tomado.
El sábado 19 de septiembre, a las 11:39 UTC, un cliente llamó por teléfono a uno de nuestros ingenieros para comunicarle que su saldo de Blink había desaparecido. Quince minutos después, habíamos desactivado por completo el servicio de custodia. Esa misma tarde se había subsanado el problema. El jueves siguiente, todos los clientes afectados habían recuperado su saldo exacto, sufragado por los accionistas de Blink. Ningún cliente ha sufrido pérdida alguna.
A los 22 clientes a los que se les sustrajeron bitcoins y a las 3.817 personas cuyos datos bancarios fueron consultados: lo sentimos.
¿Qué ocurrió? El 17 de septiembre, un atacante abrió una cuenta gratuita normal de Blink. Dos días después, aprovechó una vulnerabilidad en el modo en que nuestras herramientas administrativas comprobaban los permisos para otorgar a esa cuenta privilegios de administrador. Con esos poderes, modificó la dirección de correo electrónico o el número de teléfono de 35 cuentas, inició sesión en ellas como si fuera el titular, aumentó los límites de retirada en 14 de ellas y retiró bitcoins de 24 de ellas entre las 09:51 y las 11:54 UTC, en parte en la cadena y en parte a través de Lightning mediante el proceso que creamos para ayudar a los clientes a pasar a la autocustodia. El atacante se hizo con unos 6,61 BTC.
De quién era el dinero. Se centraron en 36 cuentas de custodia. Una se salvó por casualidad: sus intentos de cambiar su dirección de correo electrónico fracasaron, por lo que pasaron a otra. De las 35 que se apropiaron, retiraron fondos de 24. Nueve contaban con autenticación de dos factores y no perdieron nada (véase más abajo), y el atacante se hizo con las dos últimas cuentas solo unos minutos antes de que desactiváramos el servicio, por lo que no se movió nada de ellas. Veintidós de las veinticuatro cuentas vaciadas pertenecían a clientes; dos pertenecían a empresas del grupo Blink. Todas ellas se restablecieron el 24 de septiembre con el saldo exacto que tenían antes del incidente, se reembolsaron las comisiones por retirada de fondos y las cuentas bloqueadas se reabrieron a partir de ese mismo día. Blink asume la pérdida.
Lo que no se vio afectado. El dinero procedía de nuestra cartera «caliente» —el saldo operativo que mantenemos para los pagos diarios—. La mayor parte de los fondos de los clientes se encuentra en un almacenamiento «frío» con múltiples firmas, que requiere varias claves en poder de personas distintas, y ninguna de nuestras herramientas de administración puede acceder a él. Las cuentas sin custodia nunca se vieron afectadas: nosotros no tenemos esas claves, por lo que el atacante no tenía nada que llevarse.
Lo que vieron. Durante el ataque, también accedieron a los datos de otras 3.817 cuentas. En algunos casos, estos datos incluían un número de teléfono o una dirección de correo electrónico. No vieron nombres, documentos de identidad, direcciones, contraseñas ni frases de recuperación. Nos hemos puesto en contacto por escrito con todos los titulares de cuentas a los que hemos podido localizar para informarles de lo que se ha visto.
¿Qué les detuvo? La autenticación de dos factores. Ninguna de las 24 cuentas vaciadas la tenía activada. Nueve de las cuentas a las que se dirigieron sí la tenían. El atacante inició sesión en las nueve, pero se rechazaron los 18 intentos que realizó para utilizar esas cuentas. Cero pérdidas. Lo señalamos porque es una de las principales lecciones de este incidente: la autenticación de dos factores funcionó, y deberíamos haberla exigido para retiradas de grandes cantidades y para cuentas con saldos elevados.
Qué hemos cambiado. La vulnerabilidad se solucionó ese mismo día, y el 21 de septiembre se implementó en producción una tercera capa de protección. Las herramientas de administración ya no están accesibles desde la red pública de Internet. Las funciones de administración que permiten modificar el correo electrónico o el número de teléfono de un cliente se han desactivado para todos los usuarios mientras las rediseñamos. Se han revocado todas las claves API de los clientes. La cartera caliente ahora contiene solo una fracción de lo que contenía. Más abajo encontrarás la lista completa.
Dónde está el dinero. Parte de él sigue en las direcciones a las que lo retiraron. El resto pasó a sus otras carteras, desde las cuales unos 5 BTC se transfirieron a través de un servicio de intercambio entre cadenas y una pequeña cantidad llegó a Binance. En El Salvador, se presentó una denuncia ante la Fiscalía General de la República y se notificó al regulador financiero; en Próspera ZEDE, se presentó una denuncia ante la policía y se notificó al regulador financiero. No esperamos recuperar el dinero; la recompensa que se indica a continuación es para cualquiera que pueda cambiar esa situación.
Una recompensa del 50 %. Pagaremos el 25 % del valor de cualquier parte de los 6,61 BTC robados el 19 de septiembre que se recupere como consecuencia directa de la información que nos facilites, hasta un máximo de aproximadamente 1,65 BTC si se recuperara la totalidad. Otro 25 % de todo lo recuperado se destinará a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y su selección conjunta de economías circulares de Bitcoin en el Sur Global. Si la información conduce a la congelación de fondos, la recompensa se pagará una vez que dichos fondos se devuelvan a un monedero bajo nuestro control. La oferta no tiene fecha de vencimiento. Escribe a bounty@blinkbtc.com. Las condiciones completas, que son las que rigen, se encuentran en blink.sv/bounty-terms.
Qué debes hacer. Activa la autenticación de dos factores (Ajustes → Seguridad y privacidad → Autenticación de dos factores) y configúrala también en tu cuenta de correo electrónico. Añade un inicio de sesión por correo electrónico si solo tienes un teléfono, ya que el número de teléfono puede ser objeto de un «SIM swap». Si utilizas la API, genera una nueva clave. Ignora cualquier correo electrónico o SMS relacionado con este incidente que contenga un enlace: nos hemos puesto en contacto con los usuarios afectados a través de mensajes en la aplicación Blink. Nunca te pediremos tu PIN, contraseña, frase de semillas ni código de acceso, ni te pediremos que transfieras fondos. Si te hemos escrito sobre tu cuenta, sigue los pasos que se indican en ese mensaje. Si prefieres conservar tus propias claves, las cuentas sin custodia están disponibles en la aplicación desde junio (Ajustes → Cambiar a sin custodia).
Blink cuenta con una plantilla de unas veinte personas repartidas por una docena de husos horarios, por lo que no existe algo como una «mañana de sábado» para todos a la vez. A las 11:39 UTC era primera hora de la tarde en Hong Kong, hora de comer en Europa y antes del amanecer en El Salvador. El cliente que llamó se había dado cuenta de que su saldo era cero y de que le habían cambiado la dirección de correo electrónico. En seis minutos, el equipo ya estaba en una llamada, las primeras cuentas se habían bloqueado manualmente desde el panel de administración y se había tomado la decisión más importante: cerrarlo todo.
A las 11:54 desconectamos por completo el sistema de custodia. Esa decisión supuso para todos los usuarios de Blink una interrupción del servicio de casi ocho horas. Las retiradas se detuvieron en el mismo momento en que se interrumpió el servicio. A las 12:41 publicamos el primer comunicado: «Servicios suspendidos, se está investigando». A las 16:06 publicamos el segundo: «Se reembolsará íntegramente a todas las cuentas afectadas».
A las 16:17 se incorporó la primera corrección y a las 17:50, la tercera. Los fondos restantes del monedero activo se trasladaron a nuevas direcciones para que cualquier pago ya firmado para las retiradas del atacante fuera rechazado. A las 19:34 reactivamos el servicio para todos los usuarios, excepto para las 36 cuentas que el atacante había manipulado, que permanecieron bloqueadas hasta que pudimos restaurarlas correctamente. Las funciones de administración que modifican los datos de contacto se mantuvieron bloqueadas como medida de seguridad adicional; la corrección se verificó en el entorno de pruebas esa misma noche y, en los días siguientes, volvimos a simular todo el ataque nosotros mismos contra una copia del código anterior a la corrección, para asegurarnos de que lo habíamos entendido bien, y luego confirmamos que cada capa lo detiene ahora.
Todas las horas se indican en UTC; El Salvador va seis horas por detrás.
Desde octubre de 2023 hasta el 19 de septiembre de 2026, cualquier persona con una cuenta gratuita de Blink y un navegador web podía otorgarse a sí misma las facultades de nuestro personal de atención al cliente: cambiar la dirección de correo electrónico o el número de teléfono de la cuenta de cualquier cliente, iniciar sesión como ese cliente y aumentar sus límites de retirada. Publicamos exactamente cómo se hacía porque nuestro código es de código abierto, otros servicios utilizan implementaciones basadas en él y el error subyacente —confiar en la propia descripción de un token sobre lo que está autorizado a hacer— puede producirse en cualquier sistema construido de la misma manera.
Nuestro personal utiliza una interfaz de administración para ayudar a los clientes a: desbloquear una cuenta, corregir un número de teléfono o aumentar un límite. El acceso a dicha interfaz se realiza a través de OAuth2, el mismo estándar que te permite iniciar sesión en una página web utilizando las credenciales de otra. Se produjeron tres errores distintos, y cada uno de ellos, por sí solo, no tiene nada de especial.
La pantalla de consentimiento confiaba en el navegador. Cuando una aplicación solicitaba permisos, nuestra página de consentimiento tomaba la lista de permisos directamente del formulario enviado por el navegador y la transmitía tal cual a nuestro servidor OAuth. Nunca comparaba esa lista con lo que la aplicación había solicitado realmente. Así pues, cualquiera podía añadir un campo oculto al formulario que dijera «dame también permisos de administrador», y el servidor —confiando, como era lógico, en su propia página de consentimiento— generaría un token perfectamente válido que indicara «administrador».
La API de administración aceptaba cualquier token. El «gatekeeper» situado delante de ella aceptaba cualquier token válido procedente de nuestro servidor OAuth: no se exigía ningún permiso, no se comprobaba si el token estaba destinado a la API de administración ni se verificaba quién era el cliente. Simplemente copiaba los permisos autodeclarados del token en las credenciales que utiliza el servidor de administración.
El servidor de administración aceptaba la cadena de permisos sin más. Si la cadena indicaba «admin», eras administrador. No se comprobaba si la persona detrás del token era un administrador conocido.
Todo ello significaba que bastaba con una cuenta gratuita y un navegador. No se utilizó ninguna cuenta ni credencial del personal, y no hubo ningún tipo de malware. Nuestro propio sistema de identidad emitió esos tokens, y precisamente por eso no se activó ninguna alarma. El atacante probó primero la vía más obvia —añadir permisos en la solicitud de autorización principal— y nuestra configuración la rechazó correctamente. A continuación, lo intentó en la página de consentimiento, y esta le permitió el paso.
Para cualquiera que audite una pila similar, el historial es importante. La vulnerabilidad se abrió en octubre de 2023 mediante tres solicitudes de incorporación de cambios consecutivas: la primera permitía que la API de administrador aceptara tokens de OAuth mientras una comprobación independiente del editor aún la protegía; la segunda eliminó esa comprobación del editor; y la tercera otorgó a todos los usuarios acceso a la pantalla de consentimiento de OAuth. Un cambio de seguridad realizado en mayo de 2026 (PR n.º 158) añadió requisitos de permisos de administrador en el servidor de administración, pero estos permisos se leían directamente del propio token, y la página de consentimiento seguía permitiendo que cualquiera los introdujera allí. La vulnerabilidad estuvo expuesta durante aproximadamente tres años.
Las correcciones son públicas: la página de consentimiento ahora rechaza cualquier permiso que la aplicación no haya solicitado (PR n.º 853); los tokens de administrador deben incluir un público asignado exclusivamente para la API de administración, algo que los tokens de cliente no pueden obtener (misma PR; la PR n.º 855 nos permitió activar esta comprobación en el entorno de producción por separado, lo cual hicimos el 21 de septiembre); y las funciones de administración que modifican los datos de contacto pueden bloquearse por completo mediante la configuración, para todos los usuarios (PR n.º 861).
El código se escribió en 2023, dentro de la empresa donde se desarrolló la plataforma Blink a partir de 2019, y pasó a ser de nuestra propiedad en octubre de 2024, cuando Blink experimentó un cambio de titularidad y se convirtió en una empresa independiente. Dos de los ingenieros que habían creado la plataforma se unieron a nosotros, pero los ingenieros que habían escrito el flujo de autorización de administradores se quedaron atrás, por lo que nadie del equipo de Blink sabía por qué había existido una comprobación de permisos anterior. A lo largo de 2025, la mayor parte de nuestro trabajo de ingeniería se centró en separar nuestros sistemas de los de aquella empresa, que habían crecido juntos a lo largo de los años: nuestra propia infraestructura, nuestras propias cuentas, nuestro propio nodo.
En 2026, la normativa cambió en muchos de los países en los que operábamos. Google comenzó a exigir licencias locales para las aplicaciones de monedero en quince mercados, el periodo de transición de la normativa MiCA de la UE finalizó el 1 de julio y muchas otras jurisdicciones estaban aprobando nuevas leyes o poniendo en vigor leyes aprobadas en años anteriores. Respondimos reteniendo menos dinero de nuestros clientes en lugar de solicitar más licencias: desarrollamos y lanzamos un monedero sin custodia, retiramos el servicio de custodia de más de cuarenta jurisdicciones y trasladamos a decenas de miles de usuarios a cuentas en las que ellos mismos conservan sus propias claves. Nuestra publicación de junio sobre el lanzamiento del monedero sin custodia describe ese trabajo. Para un equipo de unas veinte personas, nos llevó la mayor parte del año.
La mejora de la seguridad del código que habíamos heredado quedó relegada a un segundo plano tras ambos proyectos. Se retrasó demasiado. Lo primero que cambiamos fue la forma en que se clasifican y se asignan las vulnerabilidades de seguridad.
La «hot wallet» elevada forma parte de la misma historia. La estábamos utilizando a aproximadamente el doble de su nivel habitual como colchón para la migración, cuya primera fase había concluido una o dos semanas antes del ataque. Aún no la habíamos reducido. Por eso la pérdida pudo ser tan grande. Desde entonces se ha reducido a una fracción de ese nivel, y el saldo operativo de Lightning se está reduciendo aún más.
El atacante se hizo con el control de 35 cuentas siguiendo el mismo procedimiento: cambiar la dirección de correo electrónico o el número de teléfono a través de las herramientas de administración, solicitar un código de acceso e iniciar sesión. En 24 de ellas, retiró fondos. En nueve de ellas se topó con un obstáculo. Esas nueve tenían activada la autenticación de dos factores —una aplicación de autenticación en el teléfono del titular— y, en una cuenta protegida con 2FA, una sesión que se abre solo con un código de acceso no permite realizar transferencias de dinero. Nuestros registros muestran que los 18 intentos del atacante en esas nueve cuentas fracasaron precisamente en ese punto. Cero pérdidas en ninguna de ellas.
La autenticación de dos factores (2FA) no impidió que se apropiaran de nuestras herramientas de administración. Sin embargo, sí impidió el robo de fondos de las cuentas individuales. Ninguna de las 24 cuentas que sufrieron pérdidas de dinero tenía activada esta medida. Deberíamos haberla exigido para las retiradas de grandes cantidades y para las cuentas con saldos elevados.
Si vas a hacer algo de lo que se explica en esta publicación, que sea esto: Ajustes → Seguridad y privacidad → Autenticación de dos factores. A continuación, actívala también para tu cuenta de correo electrónico, ya que los códigos de inicio de sesión de Blink se pueden enviar allí.
El domingo, al día siguiente del ataque, ya sabíamos qué se había sustraído y a quién, con una precisión de satoshi, tras cotejarlo con el libro mayor, la cadena de bloques y el nodo Lightning , y el Consejo de Administración había decidido cómo sufragarlo. Los accionistas de Blink comprometieron el importe total en un plazo de 24 horas en forma de préstamo sin intereses, lo adelantaron el miércoles, y se ha ofrecido a cada accionista la oportunidad de financiar su parte en las mismas condiciones. El jueves 24 de septiembre restablecimos todos los saldos afectados y reembolsamos las comisiones que habíamos cobrado por las retiradas fraudulentas. Nos pusimos en contacto directamente con los clientes afectados antes de hacer ninguna declaración pública, al igual que con las personas cuyos registros habían sido consultados.
El orden fue deliberado. Primero, los usuarios; todo lo demás, después. Informamos a nuestros accionistas el viernes con los mismos datos que estáis leyendo ahora, y retuvimos esta publicación hasta que las autoridades tuvieran en su poder nuestros informes: una denuncia penal presentada ante la Fiscalía General de la República de El Salvador, notificaciones al regulador financiero y a la agencia de ciberseguridad de El Salvador, una denuncia penal ante el Departamento de Policía de la ZEDE de Próspera y una notificación al regulador financiero de Próspera.
Esa semana ocurrieron dos cosas que queremos dejar constancia. El domingo, el atacante nos escribió exigiendo un pago, con la amenaza de publicar los datos de los usuarios. No pagamos y no lo haremos; el mensaje es ahora una prueba de su intento de extorsión. Y desde el domingo hasta el miércoles siguieron iniciando sesión en cuatro de las cuentas bloqueadas cuyos datos de contacto aún figuraban con la dirección de correo electrónico del atacante, ya que aún no las habíamos restablecido. Todos los pagos que intentaron fueron rechazados y no se produjo ningún cambio. Eso no debería haber sido posible. Nuestro procedimiento de reactivación ahora restaura primero los datos de contacto, cierra todas las sesiones y, solo entonces, desbloquea la cuenta.
No somos la primera empresa en asumir una pérdida como esta y compensar a los usuarios. Las plataformas de intercambio y los monederos ya lo han hecho antes que nosotros. La pérdida de un custodio es responsabilidad del propio custodio.
Blink no partía de cero el 19 de septiembre. La mayor parte de los fondos de los clientes ya se encontraban en almacenamiento en frío con múltiples firmas, repartidos por distintos continentes; el servicio opera con reserva total; la autenticación de dos factores estaba disponible y habíamos estado animando a los usuarios a utilizarla; y las retiradas estaban limitadas a nivel de cuenta. La mayor parte de eso se mantuvo: el atacante nunca llegó al almacenamiento en frío, nunca tocó ninguna cuenta sin custodia y fracasó en todas las cuentas que contaban con autenticación de dos factores. Lo que falló concretamente fueron los controles de autorización de nuestras herramientas de administración heredadas, así como la supervisión, que se centraba en detectar interrupciones del servicio en lugar de vigilar que un administrador no realizara acciones que ningún administrador debería llevar a cabo. Lo que falló de manera más general fueron nuestras prioridades: la transición de la propiedad y, posteriormente, el abandono de la custodia ocuparon a la mayor parte del equipo, y el trabajo de seguridad en el código que habíamos heredado quedó relegado a un segundo plano.
Esto es lo que hicimos al respecto durante los primeros días:
Se está llevando a cabo un mayor refuerzo en toda la plataforma.
Y dos compromisos que empiezan hoy mismo:
1.La recompensa por la recuperación. Pagaremos el 25 % del valor de cualquier parte de los 6,61 BTC robados el 19 de septiembre que se recupere como resultado directo de la información que nos facilites, hasta un máximo de aproximadamente 1,65 BTC si se recuperara la totalidad. De todo lo que se recupere, otro 25 % se destinará a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a una selección conjunta de economías circulares de Bitcoin del Sur Global que puedan necesitar un respaldo adicional. La oferta no tiene fecha de vencimiento; escribe a bounty@blinkbtc.com. La recompensa se pagará únicamente con fondos que hayan sido devueltos a un monedero bajo nuestro control. Los fondos robados pueden devolverse a través de la cadena de bloques a la dirección bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 o a través de Lightning a la dirección Lightning : bounty@blink.sv.
2.Un canal de notificación de incidencias de seguridad, con recompensas. Escribe a bounty@blinkbtc.com. Las notificaciones se confirman en un plazo de 72 horas y son gestionadas por nuestro equipo de seguridad hasta su resolución. Se agradece la investigación de buena fe sobre el software de Blink, y no tomaremos medidas contra nadie que notifique una vulnerabilidad de forma responsable. Pagamos recompensas discrecionales de hasta 0,1 BTC por hallazgos críticos. La política completa se encuentra en blink.sv/bounty-terms. Este canal existe a raíz de este incidente: cada informe debe llegar a algún sitio, ser confirmado y permanecer bajo la responsabilidad de alguien hasta que se resuelva.
El 50 % se divide en dos: el 25 % se destina a quien proporcione la información que permita recuperar los fondos, y otro 25 % de lo recuperado se destina a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y las economías circulares que estas organizaciones elijan. Creemos que lo más probable es que los fondos se hayan perdido para siempre. Los bitcoins robados son muy difíciles de recuperar, por lo que, para nosotros, cualquier cantidad recuperada supone un gran logro, y cuanta más gente podamos animar a que nos ayude a encontrar al atacante, mejor. Personas como esta no deberían salirse con la suya tan fácilmente, y queremos que gastar ese dinero les resulte lo más difícil e incómodo posible.
Hemos añadido ese segundo 25 % porque queremos recordar al atacante que ha robado dinero que nosotros y nuestros accionistas, alineados con nuestra misión, hubiéramos preferido destinar a apoyar la adopción de Bitcoin desde la base y a empoderar a los desarrolladores de Bitcoin en comunidades sin acceso a servicios bancarios de todo el mundo. ¡Qué vergüenza para el atacante!
Hemos realizado un seguimiento continuo de los fondos desde el 19 de septiembre. A fecha de 1 de octubre: alrededor de 0,87 BTC seguían sin moverse en las direcciones de recepción. El resto se transfirió a otras carteras de los mismos, que también contienen bitcoins que no proceden de Blink. De esas carteras, alrededor de 5,05 BTC han pasado por un servicio de intercambio entre cadenas (NEAR Intents), 1 BTC el 21 de septiembre y unos 4,05 BTC entre el 28 y el 29 de septiembre; y, tras no recibir respuesta a nuestra solicitud de retención del 22 de septiembre, hemos pedido a las autoridades que obtengan los registros de dicho servicio; unos 0,012 BTC se ingresaron en una cuenta de Binance, y el equipo de seguridad de Binance está trabajando en el asunto y añadiendo direcciones a la lista negra. Dado que los bitcoins del propio atacante se han mezclado con el resto, estas cifras no suman los 6,61 BTC. Las direcciones en cadena figuran en el apéndice.
Nuestro código fuente es de código abierto y los servicios que no hemos desarrollado nosotros ejecutan implementaciones derivadas de él. El patrón vulnerable —un flujo de consentimiento que confía en la lista de permisos del navegador y un controlador perimetral que acepta cualquier token activo sin comprobar su destinatario— es anterior a los repositorios actuales de Blink y se encuentra en el historial público archivado. Hemos informado de forma privada a los operadores de las implementaciones derivadas de las que tenemos constancia; uno de ellos aplicó el parche ese mismo día. Nuestro aviso de seguridad sobre el código fuente se publicará en GitHub en github.com/blinkbitcoin/blink/security/advisories, con un identificador CVE solicitado. Si ejecutas algo basado en el código fuente de Blink y no has recibido noticias nuestras, escribe a bounty@blinkbtc.com; una vez que hayamos confirmado que gestionas una implementación, te facilitaremos el procedimiento de comprobación completo y te ayudaremos a verificarlo. Las correcciones son las tres solicitudes de incorporación de cambios (PR) enlazadas anteriormente. Los atacantes ya analizan el código público a la velocidad de una máquina. Si ejecutas este código, compruébalo hoy mismo.
Blink comenzó como la cartera de Bitcoin para el día a día de un pequeño pueblo costero donde la gente necesitaba dinero que funcionara. El 19 de septiembre, para 22 de nuestros clientes, no fue así. Todos ellos nos habían confiado su dinero, que es precisamente para lo que sirve un custodio.
A nuestros clientes, por su paciencia; a los investigadores y a las bolsas que nos ayudaron en cuestión de horas; a los accionistas que respaldaron a la empresa sin dudarlo; y al equipo que lo dejó todo un sábado y no durmió ni un momento: gracias. Nos ganaremos de nuevo la confianza tal y como nos la ganamos en El Zonte: estando ahí y asegurándonos de que los pagos se procesen, cada día.
¿Estaba mi dinero en peligro? Si tu cuenta sigue abierta y no te hemos escrito, significa que no tenemos constancia de que el atacante haya accedido a los datos de tu cuenta y que no se haya sustraído nada de ella. Hasta que la cerramos el 19 de septiembre, la vulnerabilidad podría haberse aprovechado contra cualquier cuenta de custodia, aunque en una cuenta con autenticación de dos factores (2FA) no habría permitido a nadie mover dinero. La mayor parte de los fondos de los clientes se encuentran en almacenamiento en frío, al que las herramientas de administración no pueden acceder. Si tienes una cuenta sin custodia, tus claves nunca estuvieron en nuestros servidores y el atacante no tenía nada que sustraer.
¿El atacante ha accedido a mis datos? Se han consultado los datos de 3.817 cuentas. Nos hemos puesto en contacto por escrito con todos los titulares de cuentas a los que hemos podido localizar para informarles de lo que se ha consultado. Si tu cuenta está activa y no has recibido ese mensaje, significa que no se encontraba entre ellas. Siempre puedes preguntarnos a qué datos de tu cuenta se ha accedido, si es que se ha accedido a alguno: support@blink.sv.
¿Por qué vuestro sistema de supervisión no detectó el ataque? Nuestras alertas se diseñaron para detectar interrupciones del servicio. No contaban con ninguna regla para detectar que un administrador realizara acciones que ningún administrador debería hacer, y el atacante estaba utilizando nuestras propias herramientas con tokens que nuestro propio sistema había emitido.
¿Por qué había tanto dinero en el monedero caliente? Habíamos duplicado aproximadamente nuestro saldo operativo como colchón para la migración a cuentas sin custodia, y no lo habíamos reducido tras finalizar la primera oleada. Ahora es solo una fracción de ese nivel, y no vamos a publicar la cifra.
¿Me habría salvado la autenticación de dos factores (2FA)? En este caso, sí. Todas las cuentas que la tenían conservaron su dinero; todas las que perdieron dinero carecían de ella. No detendrá todos los ataques, pero detuvo este. Actívala.
¿Debería cambiarme a una cuenta sin custodia? Si prefieres conservar tus propias claves, sí: para eso sirven, y nadie en Blink, ni siquiera alguien que consiga acceder a Blink, puede mover los fondos que tú mismo gestionas. No es obligatorio, aún no están disponibles todas las funciones y la disponibilidad depende de tu región. Si sigues con la cuenta con custodia, activa la autenticación de dos factores (2FA).
¿Quién ha pagado esto? Los accionistas de Blink, en forma de un préstamo sin intereses concedido en un plazo de 24 horas y abonado el 23 de septiembre. No han sido los clientes, ni las reservas de los clientes. Blink sigue manteniendo un sistema de reserva completa: cada saldo está respaldado en una proporción de uno a uno.
He detectado un problema de seguridad en Blink. ¿Qué debo hacer? Escribe a bounty@blinkbtc.com. Recibirás una respuesta en un plazo de 72 horas, tu informe tendrá un responsable hasta que se resuelva y los hallazgos críticos se recompensan.
Aquí se irán añadiendo actualizaciones periódicas sobre la recuperación, la recompensa y cualquier corrección de esta publicación.
Las siguientes direcciones recibieron las retiradas en cadena. Se ruega a las plataformas de intercambio y a los investigadores que comprueben los depósitos procedentes de ellas y se pongan en contacto con bounty@blinkbtc.com. (Los fondos deLightning-rail se destinaron a carteras Lightning controladas por el atacante y se están rastreando por separado.)
Total en la cadena: 4,62685758 BTC recibidos en estas direcciones en 14 retiradas, siete de ellas a la primera dirección. Nuestro sistema de pagos agrupa las retiradas, por lo que las 14 se realizaron en 12 transacciones en la cadena. Los 1,98399667 BTC restantes del total de 6,61085425 BTC quedaron en Lightning.
Empieza a recibir y enviar bitcoins ahora
