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
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
Modern Day Insider Threat: Network Bugs That Are Stealing Your Data
David Pearson, Principal Threat Researcher,  10/21/2020
Are You One COVID-19 Test Away From a Cybersecurity Disaster?
Alan Brill, Senior Managing Director, Cyber Risk Practice, Kroll,  10/21/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-21269
PUBLISHED: 2020-10-27
checkpath in OpenRC through 0.42.1 might allow local users to take ownership of arbitrary files because a non-terminal path component can be a symlink.
CVE-2020-27743
PUBLISHED: 2020-10-26
libtac in pam_tacplus through 1.5.1 lacks a check for a failure of RAND_bytes()/RAND_pseudo_bytes(). This could lead to use of a non-random/predictable session_id.
CVE-2020-1915
PUBLISHED: 2020-10-26
An out-of-bounds read in the JavaScript Interpreter in Facebook Hermes prior to commit 8cb935cd3b2321c46aa6b7ed8454d95c75a7fca0 allows attackers to cause a denial of service attack or possible further memory corruption via crafted JavaScript. Note that this is only exploitable if the application usi...
CVE-2020-26878
PUBLISHED: 2020-10-26
Ruckus through 1.5.1.0.21 is affected by remote command injection. An authenticated user can submit a query to the API (/service/v1/createUser endpoint), injecting arbitrary commands that will be executed as root user via web.py.
CVE-2020-26879
PUBLISHED: 2020-10-26
Ruckus vRioT through 1.5.1.0.21 has an API backdoor that is hardcoded into validate_token.py. An unauthenticated attacker can interact with the service API by using a backdoor value as the Authorization header.