Cybersecurity is a complicated circular pattern. Tools, strategies, and methodologies are constantly evolving to protect more expansive attack surfaces. At the same time, hackers develop new attack vectors at unprecedented rates. Round and round it goes with no end in sight.
Companies are often aware of massive cyberattacks that land in the headlines of major publications, such as the SolarWinds supply chain attack. Each time one of these crippling attacks happens, businesses panic (rightfully so) and rush to buy new security tools, many of which they don’t actually need.
Instead, they should routinely evaluate their security posture because most companies will fall victim to less splashy, more mundane attacks, the signs of which go overlooked until it’s too late. These types of attacks lean on social engineering and phishing incidents, unpatched misconfigurations, and unpatched systems – all open invitations to bad actors. The point is, it’s often the little things that make companies most vulnerable.
When manual, mundane work can be executed through automation, employees’ time is freed up, enabling them to work on tasks and projects that require their unique expertise and move businesses forward. However, sometimes automation leads to complacency, and in cybersecurity, that can be dangerous with severe consequences.
With such pervasive use and the staggering number of packages added every week, it’s no surprise that it has become a fruitful ground for bad actors. They release malicious NPM packages to steal credentials and personally identifiable information (PII), run botnets, and gain a foothold in targeted networks. An infected NPM gives a hacker the ability to deliver any malware they want.
How are NPM packages exploited to breach networks?
Bad actors are using NPN packages with increasing frequency. They provide an excellent entry point, as the research from Mend.io points out. With more than 20 billion NPM packages downloaded weekly and installed across that many environments, hackers gain access to a wide swath of companies with the ability to launch far-reaching supply chain attacks, engage in crypto-jacking, and more.
A recent incident explains just how easily NPM packages can be used to breach networks and wreak havoc. JFrog researchers identified a large-scale supply chain attack targeting Azure developers through over 200 malicious NPM packages. The attack used typosquatting – a method in which attackers create package names that mimic legitimate libraries, with only an easily overlooked naming discrepancy. The malicious packages, uploaded via an automatic script and designed to steal PII, used the existing Azure Scope package names but left out the @azure scope name. For example, an infected package was labeled as ‘core-tracing’ rather than the real package name of @azure/core-tracing. In an attempt to evade detection, each package was uploaded using a unique username and high version number, a sign of a dependency confusion attack.
When installing packages is habitual, as it is for many developers, it’s too easy to mistakenly omit the prefix and run the wrong command, which is exactly what happened. In this instance, each package was downloaded about 50 times before the malicious packages were identified and removed.
Last December, malware dubbed SysJoker was delivered via malicious NPM packages. It gave attackers access to a backdoor to target machines, allowing them to initiate follow-on attacks or move deeper into networks. Also, that month, JFrog found 17 malicious packages created to steal Discord tokens, enabling hackers to hijack account details and take over servers. Sonatype discovered klow, klonw, and oksa, three malicious crypto-mining packages, a few months earlier. The list goes on and on.
Can you use NPM packages securely?
With these software supply chain attacks on the rise – 2021 saw a 650% increase year over year - how can you ensure your developers, who rely on NPM packages to work quickly and efficiently, use them safely?
- Make sure your team is aware of the recent uptick in malicious packages, and they don’t automatically trust them. Although that should be a given, history shows us it’s not. Then create a framework for best practices which should start with continuously scanning all packages and their dependencies for security issues. Developers need to get into the habit of checking every open-source license and avoiding any packages that are unlicensed or have problematic licenses.
- Keep a running and complete list of all the NPM packages in use, noting the version used and the package’s purpose. Instruct teams to add new packages with care and only if they are needed to achieve the desired functionality. Make sure your team knows how to update NPM packages and pays special attention to the updates that include patch releases. Get developers into the habit of running NPM audits to identify any vulnerabilities within dependencies.
- Take security a step further by establishing a dependency firewall that will block packages if they contain restrictive licenses, are deemed insecure, or haven’t been scanned. You can also set up Escaping (or encoding) by instructing a browser to treat chunks of untrusted data as content only. Other best practices include requiring developers to check scripts before installing packages, using Two-Factor Authorization, and explicitly stating when a process should crash to stop DOS attacks.
Education and preparation are a must
As a business expands, so do attack surfaces. As researchers uncover malicious behaviors of any sort – delivered via NPM packages or other attack vectors – hackers are already concocting new attack vectors. The game of cat and mouse will continue. The only question is who will prevail.
Give your company a head start by recognizing that NPM packages, while critical to every developer’s working process, also come with risks. Those risks can be lessened by ensuring that teams are aware, educated, and follow best practices, even when that requires taking extra steps. Not doing so will be far more detrimental.
With attacks on the rise at alarming rates, ensure that your company has the tools. Don’t fall into the trap of choosing tools because they are popular or the newest ones to hit the market. Instead, take the time to select the right tools for your environment and the ones that will keep your company as safe as possible. Most importantly, recognize that attacks will happen and make sure you have disaster recovery and cyber recovery plans firmly in place to respond when the need arises.