Bitcoin Core 32.0 ya ha entrado en pruebas de versiones candidatas. Esta vez, la corrección aborda un problema de seguridad: no se trata de una filtración de claves privadas, sino de que se puede activar, a través de walletnotify, un nodo que ejecute comandos del sistema que podrían ser provocados por un nombre de billetera especialmente construido.
El escenario no es complejo: un usuario que ya pasó la autenticación RPC y que, además, tiene permisos para crear billeteras, configura un nombre de billetera manipulado. Cuando aparezcan transacciones relevantes, walletnotify ejecutará automáticamente un script predefinido. Si el programa no trata el nombre de la billetera de forma estricta como texto normal, los caracteres especiales podrían interpretarse como comandos adicionales.
Esto no significa que “Bitcoin haya sido comprometido”. El atacante necesita primero obtener permisos RPC del nodo, y el nodo también debe tener activado walletnotify. Pero revela una ruta de ataque que a menudo se pasa por alto: las transacciones en la cadena no son el problema, ni se pierden claves privadas; la vulnerabilidad puede, en cambio, entrar al host del nodo a través de RPC, el nombre de la billetera y los scripts del sistema.
La versión 32.0 también mejora el cálculo de comisiones y la lectura de datos del bloque. El nuevo método tomará más en cuenta las transacciones en tiempo real del mempool, para que la recomendación de comisiones baje más rápido después de que disminuya la congestión; además, el nodo puede leer en paralelo parte de los datos, acelerando la verificación y la sincronización de bloques.
Al ejecutar un nodo de Bitcoin Core, no expongas RPC directamente a Internet; desactiva walletnotify si no lo necesitas; y usa scripts automáticos con parámetros fijos y los permisos mínimos del sistema. La versión candidata debe probarse primero en un directorio aislado, sin reemplazar directamente la billetera de producción.
La seguridad del nodo no solo depende del consenso y de las claves privadas, sino también de qué interfaces, scripts y permisos del sistema están conectados a su lado.
#Bitcoin #SeguridadDeBilleteras #SeguridadDeNodos
El escenario no es complejo: un usuario que ya pasó la autenticación RPC y que, además, tiene permisos para crear billeteras, configura un nombre de billetera manipulado. Cuando aparezcan transacciones relevantes, walletnotify ejecutará automáticamente un script predefinido. Si el programa no trata el nombre de la billetera de forma estricta como texto normal, los caracteres especiales podrían interpretarse como comandos adicionales.
Esto no significa que “Bitcoin haya sido comprometido”. El atacante necesita primero obtener permisos RPC del nodo, y el nodo también debe tener activado walletnotify. Pero revela una ruta de ataque que a menudo se pasa por alto: las transacciones en la cadena no son el problema, ni se pierden claves privadas; la vulnerabilidad puede, en cambio, entrar al host del nodo a través de RPC, el nombre de la billetera y los scripts del sistema.
La versión 32.0 también mejora el cálculo de comisiones y la lectura de datos del bloque. El nuevo método tomará más en cuenta las transacciones en tiempo real del mempool, para que la recomendación de comisiones baje más rápido después de que disminuya la congestión; además, el nodo puede leer en paralelo parte de los datos, acelerando la verificación y la sincronización de bloques.
Al ejecutar un nodo de Bitcoin Core, no expongas RPC directamente a Internet; desactiva walletnotify si no lo necesitas; y usa scripts automáticos con parámetros fijos y los permisos mínimos del sistema. La versión candidata debe probarse primero en un directorio aislado, sin reemplazar directamente la billetera de producción.
La seguridad del nodo no solo depende del consenso y de las claves privadas, sino también de qué interfaces, scripts y permisos del sistema están conectados a su lado.
#Bitcoin #SeguridadDeBilleteras #SeguridadDeNodos