A misconfigured Jupyter Notebook server running as root on a Linux system exposed a straightforward path for privilege escalation, allowing attackers with local access to obtain full root control through the server’s terminal API.
This technique highlights a common deployment error rather than a flaw in Jupyter itself, where disabled authentication combined with elevated privileges turns a useful data science tool into a security liability.
Security experts warn that such setups, often chosen for convenience in shared environments, create perfect conditions for abuse by threat actors.
Initial Discovery
During the test, the penetration tester encountered a restricted shell on a Linux machine, revealing a Jupyter server process executing as root via standard enumeration commands like ps aux.
Jupyter, widely used for interactive coding and data analysis, operates as a web service that can execute code and provide shell access if improperly secured.
A simple API check using curl on localhost:8888/api/status confirmed the server was active without requiring the default token authentication, indicating it was launched with options like –NotebookApp.token=” for ease of access.
This lack of safeguards, common in development setups, allowed immediate interaction with Jupyter’s endpoints.
The server’s exposure on localhost meant any local user or process could probe it, bypassing traditional barriers like firewalls or remote restrictions.
Analysts note that running Jupyter as root often stems from needs like GPU access, but it amplifies risks in multi-user scenarios where local compromise is feasible.
Abusing The Terminal API
Jupyter’s terminal API, accessible via /api/terminals, enables shell sessions over WebSockets, which can be created with a POST request and then hijacked using tools like websocat a command-line WebSocket client.
Connecting to the WebSocket endpoint requires sending JSON-formatted messages, such as [“stdin”, “id\n”], after a brief delay to initialize the protocol, revealing the root user ID (UID 0).
This grants a full root shell without sudo or exploits, as the terminal inherits the server’s privileges.
Further, attackers can read sensitive runtime files like kernel-*.json in /root/.local/share/jupyter/runtime, exposing connection details, HMAC keys, and session data for hijacking other kernels.
Establishing persistence involves piping commands through websocat to spawn a reverse shell with socat, directing traffic to an external command-and-control server while mimicking legitimate activity.
Such methods evade basic monitoring, as they leverage Jupyter’s core features rather than injecting malware.
Prevention and Lessons
To mitigate these risks, administrators should avoid running Jupyter as root, instead creating dedicated non-privileged users and using Docker with –user flags for isolation.
For multi-user environments, deploy JupyterHub with spawners like SystemUserSpawner to enforce per-user shells and disable terminals if unnecessary via c.ServerApp.terminals_enabled = False.
Capability-based access, such as –gpus all without root, addresses common justifications for elevation.
Detection involves logging API calls for /api/terminals, auditing kernel file access, and monitoring outbound connections from Jupyter processes.
Tools like auditctl can flag unauthorized reads, while netstat watches for anomalous ESTABLISHED sockets.
Ultimately, this case underscores the dangers of disabling defaults for convenience proper authentication and least-privilege principles prevent turning productivity tools into escalation vectors.
Security teams are urged to audit Jupyter deployments rigorously, especially in enterprise data science pipelines.
