Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
8/5/2016
10:00 AM
Jonathan King
Jonathan King
Partner Perspectives
50%
50%

There’s Something Phishy in the Package

The typosquatting risk is real. It's time to increase our vigilance and control over third-party source code.

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.

 

Jon King is a security technologist and Intel Principal Engineer in the Intel Security Office of the CTO, where he is researching and working on future security challenges. Jon is a seasoned developer and architect with over 20 years of industry experience, and a 10-year ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.
CVE-2021-32554
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the xorg package apport hooks, it could expose private data to other local users.
CVE-2021-32555
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the xorg-hwe-18.04 package apport hooks, it could expose private data to other local users.
CVE-2021-32556
PUBLISHED: 2021-06-12
It was discovered that the get_modified_conffiles() function in backends/packaging-apt-dpkg.py allowed injecting modified package names in a manner that would confuse the dpkg(1) call.