Typosquatting in package repositories

"Typosquatting" is normally associated with registering domain names that are variants of popular domains, such that a user trying to reach the site might mistype and land on the variant page, which might be serving up malware, ads, or some kind of phishing scam. But in early June, Nikolai Tschacher reported on some research he had done that used typos in package names for languages like Python and Ruby to show that their package repositories were vulnerable; an attacker could use that flaw to execute code on remote systems. It was a fairly eye-opening report (as is the thesis [PDF] it was based on) that bears some further scrutiny.

Package managers often require privileges, which makes packages both a security danger and a target for attackers. Distribution packages are normally signed by a distribution key, which makes it much harder—though certainly not impossible—for an attacker to subvert those packages. But language package repositories, or those for frameworks like Node.js, are not so centralized. In fact, they are meant to be places where anyone can upload their code, with little or no vetting of that code.

So it is relatively easy for an attacker to upload a package with malware to sites like the Python Package Index (PyPI), RubyGems.org, or npmjs.org, but that is only part of the puzzle. In order to get users to actually install the packages, they must be enticed to do that somehow—that's where typosquatting comes into play.

So, if there is a popular PyPI package called "requests", which, of course, there is, then a typo version of the name, "reqeusts", say, might find its way to some systems. A user who typed:

    $ sudo pip install reqeusts

The danger of installing language packages as root is well known, but it is still regularly done. The pip command for Python runs setup.py from the package as part of the installation process. That makes it easy for a malicious actor to run their code to get malware onto the system—or for a researcher to add some non-malicious test code to the system. The JavaScript npm package manager and the Ruby gem package manager also provide ways to execute code at installation time.

So Tschacher created some 200 packages that each contained a notification program and used some form of typo for its name. He uploaded them to the repositories over a few months and waited to see what notifications he would get. The notification program gathered some basic information about the system and whether the user was doing the installation with administrative rights; that information was sent back to his server. The notification program also printed a warning to the user that explained that they had probably grabbed the wrong package with a link to a page about his research.

In two phases that totaled roughly two months, Tschacher gathered information from more than 17,000 unique IP addresses. Most of those were for PyPI packages (15,221), with far lesser amounts for RubyGems.org (1631) and npmjs.com (525) files. Those differences may reflect the relative popularity of the package repositories and/or cultural differences in those language communities. In any case, a whopping 43% of the installers did so with administrative rights.

There are other statistics that he gathered and reported in the blog post and thesis. For example, the installation requests came from a broad swath of the internet, including a few from .gov and .mil domains. Interestingly, roughly 10% of the IP addresses he could resolve to a hostname were requests from Amazon's AWS cloud service.

One other piece of his research was for the notification program to check the .bash_history files on Linux and other Unix systems to report on what other incorrect package names had been tried on the system. These might be standard library package names (e.g. urllib2) that can be registered in a repository, popular names of other tools (e.g. git, docker), or just shortened names of real packages (e.g. scikit rather than scikit-learn). He used some of the names he harvested that way in the second phase of running the experiment with good success.

His post lists several ways for package repositories to avoid these kinds of problems, starting with the obvious: "Prevent Direct Code Execution on Installations". His other suggestions in the post are to generate (and blacklist) potential typo candidate names and to analyze the repository server log files to find potential typos as well. The thesis itself goes into much more detail on ideas for reducing the vulnerability's footprint.

At some level, it is not terribly surprising that installing code uploaded by random folks on the internet is dangerous. Doing so as root is even more so, but there is generally plenty an attacker can do even if their code is only granted access to an unprivileged user account. Even if the typosquatting problem were reduced (by limiting the registration of typo package names, say) and the installation of the package did not directly run code provided by the attacker, there would still be concerns. Eventually, users may get the typo into their code and "import reqeusts" will obviously have to execute the code supplied by the reqeusts module—limiting typo registrations will reduce the problem, but can hardly eliminate it. Not to mention that users may simply be able to be tricked into installing any package name that an attacker chooses.

Curated package repositories, like those run by Linux distributions and others, go a long way toward eliminating these problems. But they also have to put a fair amount of bureaucracy between a code purveyor and the user in order to avoid distributing malicious code—which is just what PyPI and repositories like that are trying to avoid.

Something interesting to ponder is what might have happened to Tschacher had he done that research in the US. From his thesis it seems that he did correspond with PyPI operators and others while the research was ongoing, who asked him to make some changes (such as removing the pip typos in .bash_history piece), but were fairly tolerant overall. On the other hand, there are various US computer laws that have sometimes been (ab)used by (over)zealous prosecutors to go after security and other researchers. One hopes that legitimate research such as this would not be so affected.