Bothered by Brandjacking
Hey Sloan,
You may remember when I wrote to you about typosquatting a few months ago? Your article helped me a lot, and I read up on the most recent State of the Software Supply Chain Report and saw that brandjacking is something I need to worry about now. Can you tell me exactly how brandjacking works and what I should be looking out for?
Thanks,
Bothered by Brandjacking
Dear Bothered by Brandjacking,
Welcome back! I’d be happy to explain brandjacking and talk a little bit about how to look out for it. First let’s review social engineering a bit to think about why brandjacking is effective.
Brief Review of Social Engineering
Brandjacking and its cousin typosquatting are both social engineering attacks. You may remember from the typosquatting article that social engineering attacks leverage human behavior to gain access to data or systems. Typosquatting generally relies on people making common typos in components or domain names. Brandjacking is very similar in nature, but involves naming malicious packages in a way that fools people into thinking that they are associated with a well-known “brand.”
Familiarity is a successful component of social engineering attacks. If you get an email from someone claiming to be one of your coworkers, they’re invoking a sense of familiarity because you know that name. Similarly, if a component’s name contains the name of a popular language library, that component is taking advantage of a brand’s familiarity to entice people to download it.
How to Look out for Brandjacking
So what does brandjacking look like from a developer’s perspective? Let’s look at an example from February 2022. A malicious npm package called “jquery-lh” racked up over 100 million downloads. It’s easy to assume that “lh” refers to line height here, and because “jquery” is in the package name, it looks pretty legitimate at first glance.
On inspection, the file did contain functional jQuery code. It also contained code that used a mechanism that could access system variables like PATH. In some cases this package would upload your environment variables to a server set up by the package author.
There were some suspicious points on the package’s page though.
This package had four versions, all released in a single day, and a low number of weekly downloads.
At risk of sounding like a broken record, vigilance is key. Even if something carries a familiar name, a little bit of verification will go a long way! Is a package you’re looking at a commonly used component with lots of downloads? Is there a history of updates? Is there a quality Readme file associated with the component?
Maintaining a healthy sense of vigilance will keep you and your applications safer! For the latest of security vulnerabilities, check out our blog. If you want to read more advice columns, peruse all of Sloan’s advice. As always, if you have a question or a comment please let us know in the comments below!
Until next time,
Sloan
Verification is certainly key. How do you recommend developers distinguish between a potentially malicious new component and a legitimate new component?
Hi Jeff,
From the 2022 State of the Software Supply Chain report:
“Mitigating these types of attacks unfortunately is not possible without some level of automated verification that looks at the newly acquired dependencies against known malware signatures or other suspicious signs. Due diligence at the keyboard will certainly help alleviate errors, but we all have a tendency to make typos so organizations should be cognizant of this reality in their approach.”
Unfortunately, risk is inherent in using open-source software, and is especially present with new releases. There are tools that can help to mitigate the risk of bringing in a potentially malicious package without having to spend time on manual assessment or analysis. Additionally, not every developer has the background needed to assess components with security in mind. So bringing solutions designed for developers that help to mitigate OSS risk is a good solution here.
Nexus Firewall, with its Release Integrity features, is an example that can help to protect against suspicious and malicious new releases and reduce the time spent performing manual assessments of new components.