90.626 servidores Jupyter sin autenticación exponen ejecución remota de código

Un barrido con el fingerprint app="Jupyter Notebook" de ZoomEye devolvió 90.626 hosts con la interfaz de Jupyter expuesta a internet, según la medición del 21 de septiembre. El dato, por sí solo, no distingue entre instancias con autenticación configurada y las que no la tienen. Es decir: es el tamaño del conjunto que conviene revisar, no el número de máquinas comprometidas ni de fallos confirmados. Pero dentro de ese conjunto, cada instancia sin token es una shell abierta.

El motivo es cómo funciona la interfaz. Jupyter no sirve solo cuadernos: incluye un terminal ligado al kernel. Quien alcanza la UI sin que le pidan credenciales abre ese terminal y ejecuta lo que quiera con los permisos del usuario del servicio y desde su posición de red. Si esa máquina corre en una nube, el usuario del notebook suele poder consultar el endpoint de metadatos de la instancia, que es justo lo que convierte un descuido en una escalada. El proyecto lo sabe: la documentación describe la autenticación por token como comportamiento por defecto desde la versión 5.0, así que una instancia sin él está mal configurada, a propósito o por descuido.

Jupyter ha aparecido varias veces en cadenas de ataque de criptominería y ransomware. No es un objetivo exótico: es una forma cómoda de entrar y quedarse.

El número agregado no responde la pregunta útil

Noventa mil casos repartidos por todo internet no dicen nada sobre una organización concreta. Lo que importa es local: si alguno de los hosts de análisis aparece en una IP pública. Los cuadernos tienen un problema estructural para el inventario, y es que los levanta cada analista por su cuenta, muchas veces atados a 0.0.0.0, fuera del registro de activos y olvidados a las dos semanas. El recuento global sirve sobre todo para recordar que ese conjunto sin gobernar no es pequeño.

Qué hacer con lo que ya está ahí

La receta no tiene misterio y está en la documentación de seguridad de Jupyter Server:

• Atar el servidor a localhost o a una interfaz interna y acceder por túnel SSH o proxy con autenticación, siguiendo la guía de servidor público.
• Exigir token o contraseña; nunca desactivarlos en hosts multiusuario.
• Limitar los permisos del usuario del notebook y no ejecutarlo como root.
• Tratar cualquier Jupyter público dentro del propio espacio de IP como incidente inmediato, asumiendo que la ejecución de código ya ocurrió.

Ese último punto es el que más cuesta aceptar y el que más se salta. Una instancia expuesta sin credenciales no es un riesgo latente que se parchea cuando haya hueco: es un servicio de ejecución remota que lleva abierto un tiempo indeterminado. La remediación pasa por rotar credenciales y revisar qué tocó ese usuario durante la ventana de exposición, no solo por cerrar el puerto.