BTCPay Server, el procesador de pagos autoalojado más usado del ecosistema Bitcoin, publicó el pasado 8 de septiembre la versión 2.4.4 de su software. Llega un mes después de que una vulnerabilidad crítica permitiera a atacantes vaciar fondos de operadores mediante el robo de credenciales de la red de segunda capa (L2) de Bitcoin Lightning Network (LN).

La nueva versión de BTCPay Server no se limita a cerrar ese agujero, sino que cambia de raíz cómo el servidor guarda y protege sus contraseñas y claves de acceso.

Publicidad

En agosto, un atacante remoto sin autenticar explotó una falla en Lightning Network y extrajo archivos de credenciales llamados «.macaroon», el equivalente a una llave maestra de LND (Lightning Network Daemon, el software de referencia para los nodos de la LN).

Con esas credenciales .macaroon, el atacante movió fondos de varios operadores afectados. BTCPay Server confirmó el robo de fondos y corrigió la falla original en la versión 2.4.2, además de restringir de forma temporal el acceso externo a esa interfaz, como lo informó CriptoNoticias.

El periodista conocido en X como hodlonaut, fundador de la revista cultural bitcoiner Citadel21, fue quien reportó uno de los primeros nodos de LN vaciados.

A través de una captura de pantalla de su propio nodo, sugirió que el drenaje habría sido de 174.245 satoshis (unos 132 dólares al precio actual), correspondiente a una transacción de salida no autorizada.

Publicidad

Captura de pantalla de un nodo de Lightning Network. — El periodista hodlonaut publicó una captura de su nodo con una transacción de salida. Fuente: hodlonaut / X.

El riesgo se limitó a los fondos de liquidez del propio nodo de Lightning, mientras que las wallets en la capa base de Bitcoin del comerciante, donde se acumulan los cobros ya liquidados, no resultaron comprometidas en ningún momento. El monto total sustraído a nivel global y el número de operadores afectados no se precisaron con exactitud.

Hackers mantuvieron activo el ataque a BTCPay Server

Los atacantes no se detuvieron tras el parche de agosto de BTCPay Server. Bots automatizados siguieron apuntando a servidores donde operadores habían vuelto a exponer manualmente el acceso a LND, pese a la recomendación explícita de no hacerlo.

La falla de agosto fue la manifestación de un patrón de diseño, no un error de código aislado que bastara con parchear: contraseñas compartidas entre nodos, secretos legibles y rutas sin autenticación, repartidos en varias capas del mismo software. Ese detalle cambia el sentido de todo el episodio.

La ventana que dejaba abierta un reinicio

BTCPay explicó en su aviso de seguridad que los bots insistían con una ruta específica de LND, /lnd-rest/btc/v1/changepassword.

Publicidad

Esa ruta no exige un .macaroon válido mientras la wallet del nodo permanezca bloqueada (es decir, mientras siga pidiendo la contraseña para operar, igual que un teléfono con el PIN puesto), una condición habitual justo después de reiniciar el software.

Las versiones más antiguas de BTCPay creaban esa wallet con una misma contraseña predeterminada en todas las instalaciones. Entre el reinicio de LND y el instante en que el desbloqueador interno actuaba, existía un margen breve. Quien llegara antes con esa contraseña conocida podía fijar una nueva y obtener el macaroon de administrador.

Ese .macaroon no es una credencial menor. Con privilegios de administrador sobre LND, un atacante puede abrir o cerrar canales de pago (las conexiones que mantienen a un nodo enlazado con el resto de la red Lightning), firmar transacciones y mover los fondos on-chain que forman parte del propio nodo.

El diseño no era exclusivo de BTCPay. Contraseñas idénticas de fábrica y paneles de administración sin autenticar son el mismo patrón que durante años explotaron botnets contra routers domésticos y cámaras de seguridad conectadas a Internet.

Publicidad

Los cambios que atacan la raíz, no el síntoma

Ninguno de los dos frentes que corrige 2.4.4 es menor: uno ataca las credenciales de LND, el otro las propias claves de la API de BTCPay.

Elemento	Antes	Ahora
Contraseña de la wallet LND	Compartida por defecto en todas las instalaciones	Única y aleatoria por instancia
Ruta de cambio de contraseña	Accesible sin autenticación con la wallet bloqueada	Bloqueada en el proxy inverso
Claves de API (Greenfield)	Secreto en texto plano guardado indefinidamente	Hash e identificador derivado
Autenticación heredada (BitPay Basic-auth)	Disponible y activa	Eliminada por completo

La ruta de cambio de contraseña ahora queda bloqueada en el proxy inverso, el filtro que recibe todo el tráfico externo antes de que llegue al servidor real. Ya no importa si alguien reactiva el acceso a LND por error: esa puerta específica queda cerrada de fábrica.

El cambio en las claves de API aplica un principio parecido a otro componente: si el servidor nunca guarda el secreto en claro, filtrarlo ya no sirve de nada. Un hash convierte esa clave en una huella irreversible, imposible de transformar de vuelta en la clave original. Revocar una clave ahora exige su identificador, no el secreto que antes había que exhibir para operar con ella.

BTCPay también anunció que restablecería el acceso externo a Lightning esa misma semana, pero con una condición: quedará desactivado por defecto y cada operador deberá habilitarlo de forma explícita. La decisión traslada el riesgo residual a quien decide activar la opción, no a la configuración inicial del software.

Publicidad

La soberanía no borra el riesgo, lo traslada

Operar un servidor propio como BTCPay saca al comerciante de la dependencia de un procesador de pagos centralizado que retiene fondos hasta liquidarlos. Esa autonomía, sin embargo, traslada la responsabilidad de la seguridad operativa a quien administra el servidor, sin un tercero que corrija el error en su lugar.

El propio patrón revela el límite de esa autonomía: en un servicio centralizado, una sola corrección protege a todos los usuarios al mismo tiempo. En un despliegue autoalojado, cada instancia se actualiza cuando su operador decide hacerlo, y hasta entonces la contraseña compartida sigue ahí, esperando a un atacante paciente.

No es el primer traspié de seguridad que sacude este año a un producto ampliamente usado del ecosistema Bitcoin: meses antes, una falla en hardware wallets Coldcard ya había dejado pérdidas confirmadas por más de USD 100 millones. Ambos casos comparten un mismo origen: un eslabón de software mal diseñado, no una falla del protocolo Bitcoin.

Eso no invalida el modelo autoalojado. Un fallo de esta magnitud en un custodio centralizado habría comprometido los fondos de todos sus clientes a la vez, sin que ninguno pudiera hacer nada al respecto. La soberanía sigue exigiendo mantenimiento activo, no solo la instalación inicial del software.

Publicidad

El protocolo Bitcoin no tuvo ninguna falla en este episodio: la cadena de bloques siguió validando bloques exactamente como debía. Lo que falló fue una decisión de diseño tan antigua como el software mismo, una contraseña igual para todos, pensada para simplificar la instalación y no para resistir un ataque dirigido. Cada vez que una aplicación decide qué tan simple debe ser su configuración inicial, también está decidiendo qué tan fácil será atacarla.

El fallo real de BTCPay no era el código: eran sus contraseñas por defecto