Researchers have discovered a Tunisian hacker using Jupyter Notebook and a motley slate of malware in a dual attempt at cryptomining and cloud compromise. The incident points out the continuing need to prioritize cloud security amid rapid adoption of advanced productivity tools.
Jupyter Notebook is an open source, Web-based, interactive, computational environment for creating notebook documents. Its flexible interface allows users to configure and arrange workflows in data science, scientific computing, computational journalism, and machine learning.
In terms of footprint, both Amazon Web Services and Google Cloud allow users to run it as a managed service, or users can run it over a standard virtual machine instance. Microsoft Azure Cosmos DB also has a Cosmos DB Jupyter Notebook feature.
In a blog post published Oct. 11, Cado Security demonstrated how attackers easily used Jupyter as a point of initial access into a honeypot cloud environment, after which they deployed a custom malware with a built-in cryptominer, rootkit, and the ability to harvest sensitive cloud credentials.
“If you’re deploying services like this,” advises Matt Muir, threat intelligence researcher at Cado Security, “make sure that you understand the security mechanisms around them, and make sure you enable authentication.”
Profile of a Cloud Compromise
The core issue in Jupyter is not a vulnerability, but the nature of the service itself — an open, collaborative platform where users tend to share and run code, within a highly customizable and modular environment.
“A lot of the appeal of using Jupyter Notebooks is to prototype small snippets of code, or to run lightweight versions of particular algorithms. People might expose them, for example, in an academic environment — if a lecturer wanted students to be able to run a particular algorithm, they might expose it publicly to allow students to connect from anywhere,” Muir explains. Or, he adds, “they may just be mistakenly exposed, which is what we see more often, to be honest with you.”
Demonstrating how easy it is to compromise one of these exposed instances, in September, the aforementioned hacker from an IP in Tunisia managed to compromise Cado’s cloud honeypot in 195 seconds, using half a dozen basic commands.
The hacker then used their access to download and execute a shell script, “mi.sh.”
Shell Script Shows the Damage a Cloud Attacker Could Do
mi.sh is a multifunctional weapon made up of taped-together open source tools. As Muir explains, it “bears a lot of similarities to other malware samples that we’ve seen in cloud native campaigns, but that’s something that is quite common. Quite a lot of cloud threat actors will steal code from each other or they’ll borrow code snippets that they find in online repositories.”
In all, mi.sh includes tools for establishing persistence, spreading to more hosts, and harvesting credentials, as well as the opensource Linux kernel rootkit “Diamorphine,” and the XMRig cryptominer. The hacker in this instance used it to steal bait AWS tokens, which they then attempted to use for unauthorized authentication.
Lock Down Those Jupyter Notebooks
Stopping a damaging attack like this, Muir says, begins with that initial access point.
“It’s something that we report quite commonly: the main initial access vector for these types of campaigns is almost always some sort of insecure deployment of a vulnerable service. In this case, it was Jupyter Notebook. In the past, we’ve seen things like Redis being deployed in an insecure fashion, and from there, they can pivot onto other resources,” he says.
Companies looking to buttress their walls can look to two places, primarily. “There’s authentication built into the service itself,” Muir says, “and there’s also network-level protection, like basic firewalling to ensure that only authorized IP addresses can actually communicate with the notebook and not just anybody on the public internet.”