BLOG |
Anuncios intermitentes
Cómo un atacante aprovechó una vulnerabilidad en nuestras herramientas administrativas para sustraer 6,61 BTC de 24 cuentas, cómo hemos reembolsado cada una de ellas y qué medidas hemos tomado.
El sábado 19 de septiembre, a las 11:39 UTC, un cliente llamó al teléfono de uno de nuestros ingenieros para comunicarle que su saldo en Blink había desaparecido. Quince minutos después habíamos desactivado todo el servicio de custodia. Esa misma noche se había solucionado el fallo. El jueves siguiente, cada cliente afectado había recuperado su saldo exacto, abonado por los accionistas de Blink. Ningún cliente sufre pérdida alguna.
A los 22 clientes a los que les robaron bitcoins y a las 3.817 personas cuyos datos de cuenta fueron consultados: lo sentimos.
Esto es lo que ocurrió. Un atacante abrió una cuenta básica y gratuita de Blink el 17 de septiembre. Dos días después, aprovechó un fallo en el modo en que nuestras herramientas administrativas verificaban 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 su titular, aumentó los límites de retirada en 14 de ellas y retiró bitcoins de 24 entre las 09:51 y las 11:54 UTC, en parte en la cadena de bloques y en parte a través de Lightning, utilizando el proceso que creamos para ayudar a los clientes a pasar a la autocustodia. El atacante obtuvo unos 6,61 BTC.
De quién era el dinero. El atacante se centró en 36 cuentas de custodia. Una se salvó por casualidad: sus intentos de cambiar la dirección de correo electrónico fracasaron y pasó a otra. De las 35 que se apropió, retiró fondos de 24. Nueve contaban con autenticación de dos factores y no perdieron nada (véase más abajo), y de las dos últimas tomó el control apenas unos minutos antes de que desactiváramos el servicio, por lo que de ellas no se movió nada. Veintidós de las 24 cuentas vaciadas pertenecían a clientes; dos eran de empresas del grupo Blink. Cada una recuperó su saldo exacto anterior al incidente el 24 de septiembre, con la devolución de las comisiones de retirada, y las cuentas bloqueadas se reabrieron a partir de ese día. Blink asume la pérdida.
Lo que no se vio afectado. El dinero salió de nuestra cartera operativa, el saldo que mantenemos para los pagos del día a día. La mayor parte de los fondos de los clientes se encuentra en almacenamiento en frío con firma múltiple, lo que requiere varias claves en manos de personas distintas, y ninguna de nuestras herramientas administrativas puede acceder a ellos. Las cuentas no custodiales nunca estuvieron en peligro: no disponemos de esas claves, por lo que el atacante no tenía nada que llevarse.
Lo que vio. Durante el ataque también consultó 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 vio nombres, documentos de identidad, direcciones, contraseñas ni frases semilla. Nos pusimos en contacto con cada titular al que pudimos localizar para informarle detalladamente de lo que se había visto.
Lo que frenó el ataque fue la autenticación de dos factores. Ninguna de las 24 cuentas vaciadas la tenía activada. Nueve de las cuentas atacadas sí. El atacante inició sesión en las nueve, pero cada uno de sus 18 intentos de utilizarlas fue rechazado. Cero pérdidas. Lo destacamos 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.
Lo que hemos cambiado. La vulnerabilidad se solucionó ese mismo día, y el 21 de septiembre entró en funcionamiento una tercera capa de protección. Las herramientas administrativas ya no están expuestas a Internet. Las funciones administrativas que modifican el correo electrónico o el número de teléfono de un cliente están desactivadas para todos mientras las rediseñamos. Se han revocado todas las claves de API de los clientes. El monedero operativo almacena ahora una fracción de lo que almacenaba. La lista completa se encuentra más abajo.
¿Dónde está el dinero? Una parte sigue en las direcciones a las que el atacante retiró los fondos. El resto pasó a otras carteras de su propiedad, desde donde unos 5 BTC salieron 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 penal ante la Fiscalía General de la República y se notificó al regulador financiero; en Próspera ZEDE se presentó una denuncia penal 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 quien 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 resultado directo de la información que nos facilites: hasta unos 1,65 BTC si se recuperara todo. Otro 25 % de todo lo que se recupere se destinará a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares de Bitcoin del Sur Global que elijan de forma conjunta. Si la información da lugar a la congelación de fondos, la recompensa se pagará cuando dichos fondos vuelvan a un monedero que controlemos. La oferta no tiene fecha de caducidad. Escribe a bounty@blinkbtc.com. Las condiciones completas, que son las que prevalecen, se encuentran en blink.sv/bounty-terms.
Qué debes hacer. Activa la autenticación de dos factores (Configuración → Seguridad y privacidad → Autenticación de dos factores) y actívala también en tu correo electrónico. Si solo inicias sesión con tu número de teléfono, añade una dirección de correo electrónico para iniciar sesión: un número de teléfono puede ser robado mediante una duplicación de la tarjeta SIM (SIM swap). Si utilizas la API, crea una clave nueva. Ignora cualquier correo electrónico o SMS sobre este incidente que incluya un enlace: nos ponemos en contacto con los usuarios afectados mediante mensajes dentro de la aplicación de Blink. Nunca te pediremos tu PIN, tu contraseña, tu frase semilla ni un código de acceso, ni que transfieras tus fondos. Si te escribimos sobre tu cuenta, sigue los pasos que se indican en ese mensaje. Si prefieres guardar tus propias claves, las cuentas sin custodia están disponibles en la aplicación desde junio (Configuración → Migrar a sin custodia).
Blink cuenta con unas veinte personas que trabajan en una docena de husos horarios, por lo que no existe un sábado por la mañana para todos a la vez. A las 11:39 UTC estaba anocheciendo en Hong Kong, era la hora de comer en Europa y aún no había amanecido en El Salvador. El cliente que llamó se había dado cuenta de que su saldo estaba a cero y de que le habían cambiado el correo electrónico. En menos de seis minutos, el equipo 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 que importaba: apagarlo todo.
A las 11:54 desconectamos todo el sistema de custodia. Esa decisión supuso para cada usuario de Blink casi ocho horas sin servicio. Las retiradas se interrumpieron en el momento en que se interrumpió el servicio. A las 12:41 publicamos el primer comunicado: «Servicios en pausa, investigando». A las 16:06 publicamos el segundo: «Se restituirá íntegramente el saldo de cada cuenta afectada».
A las 16:17 se había implementado la primera corrección y a las 17:50, la tercera. Los fondos restantes de la cartera operativa se transfirieron a nuevas direcciones para que cualquier pago ya firmado destinado a las retiradas del atacante fuera rechazado. A las 19:34 reactivamos el servicio para todos, excepto para las 36 cuentas que el atacante había afectado, que permanecieron bloqueadas hasta que pudimos restablecerlas correctamente. Las funciones administrativas que modifican los datos de contacto permanecieron bloqueadas como segunda medida de seguridad; la corrección se verificó en el entorno de pruebas esa misma noche y, en los días siguientes, repetimos nosotros mismos todo el ataque contra una copia del código anterior a la corrección, para asegurarnos de que lo entendíamos, y confirmamos que cada capa lo detiene ahora.
Todas las horas están 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 podía otorgarse a sí misma los poderes de nuestro equipo de asistencia: cambiar el 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 abierto, otros servicios utilizan implementaciones basadas en él y el error subyacente —confiar en lo que un token afirma sobre sí mismo en cuanto a lo que está autorizado a hacer— puede cometerse en cualquier sistema construido de la misma manera.
Nuestro equipo utiliza una interfaz administrativa para ayudar a los clientes: desbloquear una cuenta, corregir un número de teléfono o aumentar un límite. El acceso se realiza a través de OAuth2, el mismo estándar que te permite iniciar sesión en una página web con tu cuenta de otra. Había tres errores, y ninguno de ellos, por sí solo, llama la atención.
La pantalla de consentimiento se basaba en el navegador. Cuando una aplicación solicitaba permisos, nuestra página de consentimiento tomaba la lista de permisos directamente del formulario que enviaba el navegador y se la pasaba tal cual a nuestro servidor OAuth. Nunca comparaba esa lista con lo que la aplicación había solicitado realmente. Así que cualquiera podía añadir al formulario un campo oculto que dijera «dame también permisos de administrador», y el servidor —que confiaba, con razón, en su propia página de consentimiento— emitía un token perfectamente válido que indicaba «administrador».
La API administrativa aceptaba cualquier token. El control de acceso que tenía delante aceptaba cualquier token válido de nuestro servidor OAuth: sin exigir ningún permiso, sin comprobar que el token estuviera destinado a la API administrativa y sin verificar quién era el cliente. Copiaba los permisos que el token declaraba tener en la credencial que utiliza el servidor administrativo.
El servidor administrativo se basaba en el texto de los permisos. Si el texto decía «administrador», eras administrador. No se comprobaba en absoluto que la persona asociada al token fuera un administrador conocido.
En conjunto, estas tres vulnerabilidades hacían que bastara con una cuenta gratuita y un navegador. No se utilizó ninguna cuenta ni credencial del personal, y no hubo malware. Nuestro propio sistema de identidad emitió esos tokens, y por eso mismo no saltó ninguna alarma. El atacante probó primero la vía obvia —añadir permisos en la solicitud de autorización principal— y nuestra configuración la rechazó correctamente. Luego probó la página de consentimiento, y por ahí sí pudo pasar.
Para quien audite una pila similar, el historial es importante. La vulnerabilidad se abrió en octubre de 2023 con tres solicitudes de incorporación de cambios consecutivas: la primera hizo que la API administrativa aceptara tokens OAuth, mientras que una verificación de editor independiente seguía protegiéndola; la segunda eliminó dicha verificación de editor; la tercera otorgó a todos los usuarios acceso a la pantalla de consentimiento de OAuth. Una actualización de seguridad en mayo de 2026 (PR n.º 158) añadió requisitos de permisos administrativos en el servidor administrativo, pero leía esos permisos del propio token, y la página de consentimiento seguía permitiendo que cualquiera los introdujera allí. La vulnerabilidad pudo explotarse durante unos 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 administrativos deben incluir un identificador de audiencia emitido exclusivamente para la API administrativa, que los tokens de los clientes no pueden obtener (la misma PR; la PR n.º 855 nos permitió activar esta verificación en producción de forma independiente, y lo hicimos el 21 de septiembre); y las funciones administrativas que modifican los datos de contacto pueden desactivarse por completo mediante la configuración, para todos (PR n.º 861).
El código se escribió en 2023, en la empresa donde se desarrolló la plataforma Blink desde 2019, y pasó a ser de nuestra propiedad en octubre de 2024, cuando Blink cambió de manos y se convirtió en una empresa independiente. Dos de los ingenieros que habían desarrollado la plataforma se unieron a nosotros, pero no así los que habían escrito el flujo de autorización administrativa, por lo que nadie en el equipo de Blink sabía por qué existía una verificación de permisos previa. Durante 2025, la mayor parte de nuestro trabajo de ingeniería se centró en separar nuestros sistemas de los de esa empresa, que con el paso de los años se habían entrelazado: 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 empezó a exigir licencias locales para las aplicaciones de monedero en quince mercados, el periodo de transición de la normativa MiCA de la Unión Europea finalizó el 1 de julio y muchas otras jurisdicciones aprobaron nuevas leyes o pusieron 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 guardan sus propias claves. Nuestra publicación de junio sobre el lanzamiento de las cuentas sin custodia describe ese trabajo. Para un equipo de unas veinte personas, eso nos llevó la mayor parte del año.
La mejora del código que habíamos heredado quedó relegada a un segundo plano tras esos dos proyectos. Se tardó demasiado en abordarla. Lo primero que cambiamos fue la forma en que se clasifican y se asignan los hallazgos de seguridad.
La elevada cartera operativa forma parte de la misma historia. La manteníamos aproximadamente al doble de su nivel habitual como colchón para la migración, cuya primera oleada había concluido una o dos semanas antes del ataque. Todavía no la habíamos reducido. Por eso la pérdida pudo ser tan grande. Desde entonces la hemos 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 35 cuentas siguiendo el mismo procedimiento: cambiar la dirección de correo electrónico o el número de teléfono mediante las herramientas administrativas, solicitar un código de acceso e iniciar sesión. De 24 de ellas retiró fondos. En nueve 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 abierta solo con un código de acceso no permite mover dinero. Nuestros registros muestran que los 18 intentos del atacante en esas nueve cuentas fracasaron precisamente en ese control. Cero pérdidas en cada una de ellas.
La autenticación de dos factores (2FA) no impidió que nos robaran nuestras herramientas administrativas. Pero sí impidió el robo de fondos de las cuentas individuales. Ninguna de las 24 cuentas que sufrieron pérdidas de dinero tenía esta función activada. Tuvimos que exigirla para las retiradas de grandes cantidades y para las cuentas con saldos elevados.
Si vas a hacer solo una cosa después de leer esto, que sea esta: Configuración → Seguridad y privacidad → Autenticación de dos factores. A continuación, actívala también en tu correo electrónico, ya que es ahí donde pueden llegar tus códigos de acceso a Blink.
El domingo, un día después del ataque, sabíamos qué se había sustraído y a quién, hasta el último satoshi, tras cotejarlo con el libro mayor, la cadena de bloques y el nodo de Lightning, y el Consejo de Administración había decidido cómo pagarlo. Los accionistas de Blink comprometieron el importe total en menos de 24 horas en forma de préstamo sin intereses, lo adelantaron el miércoles, y a cada accionista se le ha ofrecido financiar su parte en las mismas condiciones. El jueves 24 de septiembre restituimos cada saldo afectado y devolvimos las comisiones que habíamos cobrado por las retiradas fraudulentas. Los clientes afectados recibieron un mensaje directo nuestro antes de que hiciéramos ninguna otra declaración pública, al igual que las personas cuyos datos fueron consultados.
El orden fue deliberado. Primero, resarcir a los usuarios; todo lo demás, después. El viernes informamos a nuestros accionistas de los mismos hechos que estás leyendo ahora, y retrasamos esta publicación hasta que las autoridades tuvieran nuestros informes: una denuncia penal 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 Próspera ZEDE y una notificación al regulador financiero de Próspera.
Hay dos cosas de esa semana que queremos dejar constancia. El domingo, el atacante nos escribió exigiendo un pago, amenazando con publicar datos de los usuarios. No pagamos y no lo haremos; ese mensaje es ahora prueba de su intento de extorsión. Y desde el domingo hasta el miércoles siguió iniciando sesión en cuatro de las cuentas bloqueadas cuyos datos de contacto aún incluían el correo del atacante, ya que todavía no las habíamos restablecido. Cada pago que intentó fue rechazado y no se movió nada. No debería haber sido posible. Nuestro procedimiento de reactivación ahora restablece primero los datos de contacto, cierra todas las sesiones y solo entonces desbloquea la cuenta.
No somos la primera empresa que asume una pérdida de este tipo y indemniza a sus 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 encontraba en almacenamiento en frío con firma múltiple, repartidos por varios continentes; el servicio opera con reserva completa; la autenticación de dos factores ya estaba disponible y llevábamos tiempo animando a los usuarios a activarla; y los retiros estaban limitados según el nivel de la cuenta. Casi todo eso resistió: el atacante nunca llegó al almacenamiento en frío, nunca tocó una cuenta no custodial y fracasó en todas las cuentas que tenían 2FA. Lo que falló, concretamente, fueron las verificaciones de autorización de las herramientas administrativas que heredamos, y un sistema de monitorización que vigilaba las caídas del servicio y no a un administrador haciendo algo que ningún administrador debería hacer. Lo que falló, en general, fueron nuestras prioridades: el cambio de propiedad y, posteriormente, la migración fuera de la custodia ocuparon a la mayor parte del equipo, y el trabajo de seguridad sobre el código heredado quedó relegado a un segundo plano.
Lo que hicimos durante los primeros días:
Se sigue reforzando toda la plataforma.
Y dos compromisos que empiezan hoy:
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 unos 1,65 BTC si se recuperara todo. De todo lo que se recupere, otro 25 % se destinará a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares de Bitcoin del Sur Global que elijan de forma conjunta y que puedan necesitar un apoyo adicional. La oferta no tiene fecha de caducidad; escribe a bounty@blinkbtc.com. La recompensa solo se pagará con fondos que hayan sido devueltos a un monedero bajo nuestro control. Los fondos robados pueden devolverse en la cadena de bloques a bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 o mediante Lightning a la dirección Lightning bounty@blink.sv.
2.Un canal para informar de problemas de seguridad, con recompensas. Escribe a bounty@blinkbtc.com. Acusamos recibo de cada informe en un plazo máximo de 72 horas, y nuestro equipo de seguridad se encarga de él hasta resolverlo. Se agradece la investigación de buena fe sobre el software de Blink, y no tomaremos medidas contra nadie que informe de 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 se ha creado a raíz de este incidente: cada informe debe llegar a algún sitio, recibir respuesta y tener un responsable hasta que se resuelva.
El 50 % se divide en dos: el 25 % es para quien aporte la información que permita recuperar los fondos, y otro 25 % de todo lo que se recupere se destinará a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares que ellos elijan. Creemos que lo más probable es que los fondos se hayan perdido para siempre. Recuperar bitcoins robados es muy difícil, por lo que para nosotros cualquier cantidad recuperada supone una gran victoria, y cuantas más personas animemos a que nos ayuden a encontrar al atacante, mejor. Alguien así no debería salirse con la suya tan fácilmente, y queremos que gastarse ese dinero le resulte lo más difícil e incómodo posible.
Añadimos el segundo 25 % porque queremos recordarle al atacante que robó dinero que nosotros y nuestros accionistas, comprometidos con nuestra misión, hubiéramos preferido mil veces destinar a apoyar la adopción de Bitcoin desde la base y a impulsar a quienes construyen con Bitcoin en comunidades sin acceso a servicios bancarios en todo el mundo. Debería darle vergüenza.
Hemos rastreado los fondos de forma ininterrumpida desde el 19 de septiembre. A fecha de 1 de octubre, unos 0,87 BTC seguían sin moverse en las direcciones receptoras. El resto se transfirió a otras carteras del atacante, que también contienen bitcoins que no salieron de Blink. Desde esas carteras, unos 5,05 BTC salieron a través de un servicio de intercambio entre cadenas (NEAR Intents): 1 BTC el 21 de septiembre y unos 4,05 BTC los días 28 y 29 de septiembre. Nuestra propia solicitud de conservación de datos del 22 de septiembre quedó sin respuesta, y hemos pedido a las autoridades que obtengan los registros de dicho servicio. Unos 0,012 BTC llegaron a una cuenta en Binance, y el equipo de seguridad de Binance está colaborando y bloqueándolos. Dado que hay bitcoins propios del atacante mezclados, estas cifras no suman los 6,61 BTC. Las direcciones en cadena se encuentran en el anexo.
Nuestro código es abierto, y hay servicios que no hemos desarrollado nosotros y que utilizan implementaciones derivadas de él. El patrón vulnerable —un flujo de consentimiento que se basa en la lista de permisos del navegador y un control de acceso que acepta cualquier token válido sin verificar el destinatario— es anterior a los repositorios actuales de Blink y se encuentra en el historial público archivado. Hemos avisado en privado a los operadores de implementaciones derivadas de las que tenemos constancia; uno de ellos aplicó la corrección ese mismo día. Nuestro aviso de seguridad sobre el código se encuentra en GitHub, en github.com/blinkbitcoin/blink/security/advisories, con un identificador CVE solicitado. Si gestionas algún sistema basado en el código de Blink y no has recibido noticias nuestras, escribe a bounty@blinkbtc.com; una vez que confirmemos que gestionas una implementación, te facilitaremos el procedimiento de verificación completo y te ayudaremos a comprobarlo. Las correcciones son las tres solicitudes de incorporación de cambios (PR) enlazadas más arriba. Los atacantes ya están escaneando el código público a velocidad de máquina. Si gestionas este código, revísalo hoy mismo.
Blink nació como el monedero 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 funcionó. Cada uno de ellos nos había confiado su dinero, que es la única razón de ser de un custodio.
A nuestros clientes, por su paciencia; a los investigadores y a las plataformas de intercambio que nos ayudaron en cuestión de horas; a los accionistas que respaldaron a la empresa sin dudarlo; y al equipo que lo dio todo un sábado y no durmió: gracias. Recuperaremos la confianza tal y como nos la ganamos en El Zonte: estando presentes y garantizando que los pagos se realicen, todos los días.
¿Estuvo mi dinero en peligro? Si tu cuenta sigue abierta y no te hemos escrito, no tenemos constancia de que el atacante haya consultado los datos de tu cuenta, y no se ha sustraído nada de ella. Hasta que la cerramos el 19 de septiembre, la vulnerabilidad podía utilizarse contra cualquier cuenta de custodia, aunque en una cuenta con autenticación de dos factores (2FA) no habría permitido mover dinero. La mayor parte de los fondos de los clientes se encuentra en almacenamiento en frío, al que las herramientas administrativas no pueden acceder. Si tienes una cuenta no custodial, tus claves nunca estuvieron en nuestros servidores y el atacante no tenía nada que llevarse.
¿El atacante ha conseguido mis datos? Se han consultado datos de 3.817 cuentas. Hemos escrito a todos los titulares con los que hemos podido contactar para informarles de lo que se ha detectado. Si tu cuenta está activa y no has recibido ese mensaje, significa que no se encontraba entre ellas. Siempre puedes preguntarnos qué se ha consultado de tu cuenta, si es que se ha consultado algo: support@blink.sv.
¿Por qué el sistema de monitorización de Blink no detectó el ataque? Nuestras alertas estaban diseñadas para detectar interrupciones del servicio. No contaban con ninguna regla para un administrador que realizara acciones que ningún administrador debería llevar a cabo, y el atacante utilizó nuestras propias herramientas con tokens que nuestro propio sistema había emitido.
¿Por qué había tanto dinero en la cartera operativa? 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 el fin de la primera ola. Ahora se encuentra en una fracción de ese nivel, y no vamos a publicar la cifra.
¿Me habría protegido la autenticación de dos factores (2FA)? En este caso, sí. Todas las cuentas que la tenían conservaron su dinero; ninguna de las cuentas que perdieron dinero la tenía. No detendrá todos los ataques, pero detuvo este. Actívala.
¿Debería cambiarme a una cuenta no custodial? Si prefieres guardar tus propias claves, sí: para eso están, y nadie en Blink, ni nadie que consiga acceder a Blink, puede mover los fondos que guardas tú. No es obligatorio, todavía no cuenta con todas las funciones y su disponibilidad depende de tu región. Si sigues con una cuenta custodial, activa la autenticación de dos factores (2FA).
¿Quién ha pagado esto? Los accionistas de Blink, mediante un préstamo sin intereses que se concedió en menos de 24 horas y se abonó el 23 de septiembre. Ni los clientes ni las reservas de los clientes. Blink sigue operando con reservas completas: 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. Te responderemos en un plazo máximo de 72 horas, tu informe tendrá un responsable hasta que se resuelva y los hallazgos críticos cuentan con una recompensa.
Aquí iremos añadiendo, con la fecha correspondiente, las novedades sobre la recuperación, la recompensa y cualquier corrección de esta publicación.
Las siguientes direcciones recibieron las retiradas en cadena. Pedimos a las plataformas de intercambio y a los investigadores que filtren los depósitos procedentes de ellas y que escriban a bounty@blinkbtc.com. (Lo que salió a través de Lightning se destinó a las carteras Lightning controladas por el atacante y se rastrea por separado.)
Total en cadena: 4,62685758 BTC recibidos en estas direcciones en 14 retiradas, siete de ellas a la primera dirección. Nuestro sistema de pagos agrupa los retiros, por lo que los 14 se realizaron en 12 transacciones en cadena. Los 1,98399667 BTC restantes del total de 6,61085425 BTC se enviaron a Lightning.
Empieza a recibir y enviar bitcoins ahora
