Vacían nodos Lightning del procesador de pagos que usan las tiendas en bitcoin, y el fallo lo destapó un programador al que le robaron, no la auditoría con IA
El aviso público llegó tarde. A las 15:51 UTC de este viernes, la cuenta oficial de BTCPay Server pidió a sus usuarios actualizar a la versión 2.4.2 porque una vulnerabilidad crítica estaba…
El aviso público llegó tarde. A las 15:51 UTC de este viernes, la cuenta oficial de BTCPay Server pidió a sus usuarios actualizar a la versión 2.4.2 porque una vulnerabilidad crítica estaba «siendo explotada activamente» y podía provocar pérdida de fondos. Para entonces ya había nodos Lightning vaciados. Zach Herbert, consejero delegado de Foundation, la empresa del monedero hardware Passport, escribió dos horas después que el nodo de su compañía había sido barrido «durante la noche», con todos los canales cerrados y los saldos retirados.
La versión con el arreglo llevaba veinte minutos publicada en GitHub cuando salió el aviso. Lo comprobé en la API del repositorio: la etiqueta v2.4.2 se creó a las 15:22:11 UTC y se publicó a las 15:31:16, con una nota de una sola línea firmada por el fundador Nicolas Dorier que dice que el fallo se está explotando y que hay que actualizar «lo más rápido posible». Esa cronología importa porque BTCPay es autoalojado: no hay un operador central que pueda aplicar el parche por nadie.
Veinte minutos entre el parche y el aviso
La secuencia se reconstruye entera con datos públicos del repositorio. Hubo tres movimientos de código en tres días distintos, y el último llegó cuatro minutos antes de que se cortara la versión.
| Momento (UTC) | Qué ocurre | Tamaño |
|---|---|---|
| 4-ago 19:11 → 19:32 | Se abre y se fusiona el arreglo del salto de doble factor en la API Greenfield | 1 fichero, 1 línea |
| 5-ago 13:42 → 16:48 | Se desactiva por defecto la autenticación básica de Greenfield cinco minutos después de crear la cuenta | 12 ficheros, +74 |
| 7-ago 15:18:52 | Comit «Disabled unwanted routes» | 5 ficheros, +9 |
| 7-ago 15:31:16 | Se publica la versión 2.4.2 con el aviso de explotación activa | Sin binarios |
| 7-ago 15:51 | Aviso público en la cuenta del proyecto: actualizar o apagar el servidor | +19 min 44 s |
| 7-ago 18:01 | Foundation confirma que su nodo Lightning fue vaciado «durante la noche» | Antes del aviso |
El proyecto no ha dicho cuál es el agujero que están usando, y ha descartado expresamente el único que sí aparece documentado en el registro de cambios, según recogió The Block. Lo que sí se puede leer es el código que entró el mismo día del lanzamiento. El comit 6689cad, de las 15:18:52 UTC, toca cinco ficheros y añade nueve líneas sin borrar ninguna: nueve veces el atributo [NonAction] sobre métodos públicos de los controladores.
Eso apunta a un patrón conocido de la plataforma sobre la que está escrito BTCPay. En ASP.NET Core, cualquier método público de un controlador es accesible por HTTP por defecto, así que un método auxiliar escrito por comodidad se convierte en un punto de entrada sin que nadie lo decida. Los nueve marcados incluyen dos en los controladores de LNURL, el protocolo con el que se piden y se pagan facturas Lightning, y cuatro en el de suscripciones. Que ese comit preceda a la versión de emergencia no prueba que sea el fallo explotado, porque el proyecto no lo ha confirmado, pero es el único cambio funcional de ese día.
La auditoría con IA no lo vio
El miércoles contamos aquí que dieciséis voluntarios del Bitcoin Red Team declaraban 4.962 hallazgos en 390 proyectos en 27,5 horas, con 85 críticos y 635 de gravedad alta, y que solo el 21,4% se había podido reproducir. BTCPay agradeció al grupo la comunicación de fallos, y la nota de la versión 2.4.2 cita a dos de sus miembros, brunoerg y benthecarman. Ese segundo nombre ya estaba en nuestra nota del miércoles, en la lista de colaboradores del sprint.
Lo que encontraron está en el expediente: el aviso de benthecarman describe que el gestor de autenticación básica de la API comprobaba únicamente si el usuario tenía llaves FIDO2, de modo que una cuenta protegida solo con aplicación de autenticación podía llamar a toda la API con correo y contraseña y recibir un permiso sin restricciones. La pantalla de inicio de sesión del navegador sí exigía el segundo factor. Se arregló cambiando una condición, un fichero, una línea, veintiún minutos después de abrirse el aviso.
No es el fallo que está vaciando nodos. Según The Defiant, Dorier respondió a quien atribuía el ataque a ese salto de doble factor que ese no era el fallo en cuestión, y explicó de dónde salió el bueno: apareció porque a un programador le robaron y pudo mirar sus propios registros. El desarrollador es Craig Raw, autor del monedero Sparrow.
Tuvimos una suerte enorme de que el afectado fuera un programador que podía analizar los registros para entender qué estaba pasando. Esto no lo encontraron los escaneos con IA, sino él perdiendo dinero. El informe de IA que nos dio el red team no incluía este. Pero era un fallo muy escurridizo, no me sorprende que un escaneo simple no lo encontrara, o que lo considerara de riesgo bajo.
Autoalojado quiere decir que nadie parchea por ti
La gracia de BTCPay es que no hay intermediario. Es un servidor gratuito y de código abierto, con 7.695 estrellas y 2.001 bifurcaciones en GitHub, que cada comercio levanta en su propia máquina para cobrar en bitcoin y en Lightning sin comisiones y sin que nadie custodie el dinero por él. Esa misma virtud convierte un fallo en un problema de miles de administradores distintos, cada uno con su ritmo y su nivel de atención a X un viernes por la mañana.
El tamaño del parque no es anecdótico. Namecheap, uno de los mayores registradores de dominios del mundo, publicó en su caso de estudio con el proyecto que entre el 18 de mayo de 2020 y octubre de 2024 pasó 1,1 millones de transacciones y más de 73 millones de dólares de ingresos por esta vía, con más de 500.000 usuarios y pagos de más de 200 países. Sale a 66,36 dólares por transacción de media. Detrás hay cientos de comercios pequeños y varios monederos que lo usan como trastienda. A todos ellos el aviso les dice lo mismo: si no puedes actualizar ahora, apaga el servidor, o sea apaga el cobro.
Actualizar no cierra el incidente
Aquí está la parte que la mayoría de coberturas deja en el último párrafo. El proyecto pidió, además de subir a 2.4.2, regenerar por completo los ficheros macaroon y macaroons.db, que son las credenciales con las que se autoriza el acceso a un nodo Lightning de LND, y renovar las cadenas de autenticación de otros programas de nodo. Quien haya generado un monedero caliente dentro de BTCPay debería mover esos fondos y crearlo de nuevo.
El motivo explica lo que describen las víctimas. Una credencial robada sobrevive a la actualización. Si el atacante copió los macaroons antes del parche, sigue teniendo llave del nodo hasta que esos ficheros se destruyan y se emitan otros, y eso encaja con canales cerrados a la fuerza y saldos barridos en lugar de un servidor vuelto a comprometer. Evan Kaloudis, del monedero ZEUS, que corre sobre LND, lo resumió pidiendo que nadie dé por hecho que está a salvo después de actualizar.
Nueve días, tres roturas y un mismo financiador
Esto llega al noveno día de la peor racha de seguridad en infraestructura de Bitcoin en años. El 30 de julio empezó el drenaje de los Coldcard por un generador de semillas débil introducido en una compilación de 2021, con un recuento que ya va por unos 114 millones de dólares y más de 5.200 direcciones. El 3 de agosto Boltz apagó sus swaps indefinidamente diciendo que los atacantes iteran más rápido de lo que un equipo de su tamaño puede encontrar y parchear. Hoy le toca al procesador de pagos.
Un detalle que nadie ha señalado: OpenSats financia las dos orillas. Aparece como patrocinador de la BTCPay Server Foundation en el pie de su propio blog y puso los más de 40.000 dólares en tokens de modelos con los que corrió el sprint del Red Team, según contamos el miércoles. El mismo donante paga a quien audita y a quien es auditado, y el fallo que vació nodos lo destapó una víctima.
La otra cara
Contra la lectura catastrofista hay tres datos. El primero es la velocidad: el aviso de un fallo se cerró en veintiún minutos con un cambio de una línea, y la versión de emergencia salió el mismo día en que se entendió el ataque, algo que en software cerrado no se puede ni verificar desde fuera. El segundo es que el registro de cambios, los avisos, los comits y las horas están públicos, y por eso esta cronología se puede contar al minuto en lugar de repetir un comunicado. El tercero es que no hay cifra de pérdidas. Ni Foundation ni Citadel21, la otra víctima conocida, han dado importe, y hodlonaut dijo que en su nodo no había mucho. Nadie ha publicado un recuento de nodos afectados.
Dorier también dejó ver la duda incómoda de cualquier divulgación: preguntado por retener los detalles técnicos, respondió que se pregunta si tiene sentido esperar ahora que ya se está explotando en la práctica. El equipo dice que publicará un análisis técnico junto al Red Team. Mientras, el mercado no se ha enterado: bitcoin cotiza a 64.917 dólares con una subida del 0,76% en 24 horas, ether a 1.914 con un 0,41%, y ninguno de los grandes se mueve un 5%.
- El análisis técnico prometido: si confirma que el agujero explotado son las rutas HTTP accidentales del comit del viernes o si es otro.
- Un recuento de nodos vaciados y de bitcoin movido. A esta hora no existe ninguno, ni oficial ni de firmas de análisis en cadena.
- Cuántos servidores siguen en versiones antiguas la semana que viene, que es la única medida real de si un aviso en X mueve un parque autoalojado.
- Si aparecen víctimas que actualizaron pero no regeneraron los macaroons, el escenario que avisó Kaloudis.
- Qué dice el Red Team sobre haber pasado por encima de este fallo, después de anunciar 85 críticos en 27 horas.
- Si la cuarta rotura de la racha llega a un monedero o a un nodo de uso masivo, porque las tres primeras han sido en piezas que el usuario final no ve.
- Si algún comercio grande de los que cobran con BTCPay suspende el pago en bitcoin en lugar de solo actualizar.
Documentación: cuenta oficial de BTCPay Server, notas de la versión v2.4.2 y API de GitHub del repositorio btcpayserver, avisos 7491 y 7492 y comit 6689cad, caso de estudio de Namecheap en el blog del proyecto, The Defiant, The Block, Decrypt, CoinGecko.