Jupyter Notebook 伺服器是程式碼執行服務：15,000 個暴露實例實際提供甚麼

A Notebook Server Is an Execution Service: What 15,000 Exposed Jupyter Instances Actually Offer

Most web applications mishandled badly give up data. A notebook server mishandled badly gives up a shell, because executing code is the feature rather than the flaw. Aqua Nautilus research on exposed Jupyter installations found roughly 15,000 reachable servers with around one per cent permitting execution, and the activity observed on them was not data theft. Attackers ran ffmpeg to relay sports streams, which tells you how little skill the entry required and how much capacity the host provided.

Why the surface is unusual

A Jupyter server exposes an API that creates kernels, runs cells and reads files. There is no meaningful separation between using the interface and running commands on the host once a token is obtained or the authentication layer is misconfigured. Deployments that skip the token, bind to all interfaces without a proxy, or leave a container's server running after an experiment belongs to the reason this population exists.

What the servers hold is not incidental either. Datasets used for training, model weights, cloud credentials in environment variables, mounted volumes from the host and connections to the feature store. A notebook is frequently the most privileged workload its team runs, because it was provisioned for convenience on a machine that had to reach everything.

The hash-leak issue

CVE-2024-35178 covers Jupyter Server on Windows. A request referencing a UNC path causes the server to authenticate to a remote SMB share, which discloses the NTLMv2 hash of the account the server runs as. Fixed in 2.14.1 and scored 7.5, with no public proof of concept at disclosure. On its own it discloses a credential hash that can be cracked offline or relayed. Combined with an environment where the server runs as a service account with broader rights, the hash is the beginning of lateral movement rather than the end.

Reading the population honestly

The 15,000 figure comes from a scanning study rather than from a census, and the one per cent execution rate is a measurement of what automated probes confirmed, not a bound on what a motivated attacker could do. A hardened deployment with a token and a reverse proxy looks identical from outside to an unhardened one until the token is tried, so a fingerprint counts candidates. The direction is still informative: the number of reachable notebook servers has grown with the number of teams doing data work, and the habit of putting a token in front of them has not grown at the same rate.

What the intrusion looked like

The observed activity is instructive because it was low effort and long lived. Miners and stream relays are chosen when an attacker wants a machine's CPU or bandwidth and does not care about detection. A notebook host offers both, plus a plausible excuse in the process list, since data workloads legitimately run ffmpeg and saturate cores.

A targeted intruder would take a different path with the same access: read environment variables, query the metadata endpoint, enumerate mounted volumes, copy model artefacts, and use the notebook's own credentials to reach the object store holding the training data. The distinction between opportunistic and targeted use is one of intent, not of capability.

Controls that survive the next mistake

• Require a token or, better, terminate authentication at a proxy and keep the server on a private interface.
• Run each notebook in its own namespace with no host mounts, a read-only root filesystem and a network policy that names its permitted destinations.
• Inject cloud credentials as short-lived role assumptions rather than long-lived environment variables, and keep the metadata endpoint off the pod network.
• On Windows, disable outbound SMB where it is not required, since the hash-leak path depends on the server being willing to authenticate outward.
• Monitor for interactive kernels started outside scheduled hours, for outbound connections to hosting and streaming domains, and for sustained CPU use on hosts that should be idle.

References

• Aqua Nautilus research on exposed Jupyter Notebook servers, execution rates and observed cryptomining and streaming activity.
• NVD record for CVE-2024-35178, Jupyter Server on Windows UNC path NTLM hash disclosure, fixed in 2.14.1.
• Jupyter Server security documentation covering token authentication and server extension exposure.