Jupyter Notebook unwittingly opens huge server security hole
Jupyter Notebook has become a reliable tool for individuals to learn new programming languages, build proof-of-concept tools and analyze data.
However, there are severe consequences when security is sacrificed for simplicity. Unfortunately, users in a hurry overlook easily preventable security configurations when setting up their notebooks and create vulnerabilities that are easy for attackers to exploit.
DataGravity research found more than 350 internet-facing Jupyter Notebook servers have been giving unauthenticated access to Jupyter’s web user interface and command line shell interface. Default installations of Jupyter Notebook servers prior to version 4.3 do not offer any default security mechanisms that could prevent attackers from accessing the notebook web interface.
This makes it possible for attackers to exploit three trivial vectors that will give them full access to the target system with the permissions of the user that started the notebook server.
Vector 1: Run arbitrary code from within a notebook
Jupyter Notebooks can run code in many different languages, however each has its own kernel (e.g., Python, Ruby, etc.) that runs the code in a single language. Using carefully crafted code, an attacker could execute commands on the system from within the notebook.
For example, a notebook using the Python3 kernel could be leveraged to install the popular Netcat tool via the subprocess module as shown below.
Vector 2: Execute local systems commands from within a notebook
Similar to Vector 1, but without the dependency of knowing the specific programming or scripting language on the notebook server, an attacker can interact directly with the operating system by using a leading exclamation mark (!) before a system command. Simple whoami or ls commands could be issued on the system, as well as destructive file deletion commands (e.g., rm) as shown below.
Vector 3: Launch a shell directly from within the web interface
Perhaps the easiest vector to exploit is the provided interface for direct system interaction. The notebook web interface provides a terminal that can be used to open a shell on the system in another window. This shell, shown below, allows for direct system commands as if you were logged in via a standard terminal application.
These vectors were reported on December 13, 2016 via the VE system and were granted CVE-2016-9970 as the associated identifier.
Finding vulnerable servers
Using the Internet-connected device search engine Shodan, DataGravity crafted a search query that can identify Jupyter Notebook servers that did not have a password set for access to the web interface. Executing the same search on Tuesday, January 24th, 2017 at 9 a.m. PT, the number of connected vulnerable servers has increased to 632 (up from 481 in December).
The latest data shows that the top three geographic locations of discovered instances reside in the U.S. (467), China (33) and Japan (17), but we can also see hits in South America, Russia, India and Iran, among others.
As seen below, Amazon leads the pack with the majority of discovered instances, but other cloud providers (Google, SoftLayer, Microsoft), hosting providers (Digital Ocean) and educational institutions (Merit Network, Universite de Strasbourg) round off the top 10 list.
