There’s Something Phishy in the Package

Building and maintaining a chain of trust for the code that your company is using is obviously critical and not a new concept. I covered some of these issues in a recent blog on dynamic dependencies. But a frequently used trick in email phishing, typosquatting or misspelling names, may be on its way to a code repository near you.

Typosquatting involves using a name that is very similar to the legitimate one but which has a typo or mistake that will trick the eye. Common techniques include substituting similar looking Ietters, reversing the odrer of two letters in a word, changing the number of repeating lettters, and using adjacent keys on the keybosrd.

Information systems student Nikolai Tschacher demonstrated this risk in his thesis. After adding packages with misspelled names into several code registries, more than 17,000 computers executed his code instead of the legitimate package they intended to use, and more than 7,500 of them ran the scripts with administrator privilege.

The majority of package or code registries today include techniques, such as a hash, to verify that the code has not been altered. Additional protections include digital signatures or restrictions on which destinations you can load from. But these don’t help much if you are loading the wrong package because of a typo.

There does not yet appear to be any third-party trusted repositories of code. That’s probably because it is a significant amount of work: registering developers; verifying people, companies, and addresses; monitoring and evaluating submissions; and generally making sure that work is valid and traceable. Somebody would have to pay for the extra work, and it would significantly slow down the process.

This highlights the ongoing challenges with open repositories from essentially anonymous sources. We have all benefited from open source code and package repositories, getting quick access to everything from basic utilities to unusual functions. Being fast and agile is hugely desirable, but so is being trustworthy and secure. To address these challenges in other work areas, we sometimes ask for some type of verification or certification from an intermediary or trusted party.

Using an internal registry is a great way to protect software from the time it comes off the development machines to when it is deployed in production. But you are still vulnerable to being infected if a developer gets caught by a typosquatting package when retrieving code from an external repository.

Until we can require attackers to get Phishing Licenses, as illustrated by XKCD, we are going to have to increase our vigilance and control over third-party source code. Know what sources you use and what controls they have. Know what is going into production and at what stage packages you use are moved to a controlled repository. Carefully scrutinize new items before they go on the approved list.