Key points 

• A new class of vulnerabilities: “HTTP/2 CONTINUATION Flood” has been discovered in various implementations of the HTTP/2 protocol. 
• The vulnerability can lead to Denial of Service (DoS) attacks and is considered more severe than the previous HTTP/2 Rapid Reset vulnerability. 
• Several affected products have been identified and assigned CVEs, with more expected to be disclosed in the future. 
• The vulnerability arises when a single large HEADER frame is insufficient to store all the headers, and the data stream continues with CONTINUATION frames without the END_HEADERS flag set. 
• Disclosures and fixes were coordinated together with CERT/CC 

Understanding the HTTP/2 CONTINUATION Flood Vulnerability 

About HTTP/2 

HTTP/2 (RFC9204) is an updated version of the HTTP protocol that allows multiple streams of data to be sent simultaneously over a single TCP connection. The data is binary-encoded into frames, with different frame types designed for specific purposes. 

Two crucial frame types are HEADERS and CONTINUATION frames, which are used to send header fields in requests and responses. 

The headers are divided and serialized into “header lists” for transmission within HEADERS frames, while CONTINUATION frames are used to continue the sequence of headers in the data stream. 

HTTP/2 CONTINUATION Flood 

The vulnerability occurs when an attacker crafts a malicious request that never sets the END_HEADERS flag, creating an infinite stream of headers that the HTTP/2 server must parse and store in memory. As the server struggles to process the incoming headers, it becomes unavailable and may eventually crash due to an Out of Memory (OOM) error. 

Potential outcomes of this vulnerability include: 

• CPU exhaustion, causing slowness in responding to other requests. 
• Out of Memory crashes.  
• Server crashes.  

Comparison to Rapid Reset and Other CVEs 

The impact of the CONTINUATION Flood vulnerability is potentially more severe than the previous Rapid Reset vulnerability for two main reasons. 

1. Exploitation often requires only a single TCP connection and minimal data, making it easier to execute than Rapid Reset, which often requires a DDoS approach. 

2. The attack is harder to detect and protect against using standard mitigations, as not even a single request is made due to the absence of the END_HEADERS flag. 

Known Affected Products and CVEs 

Numerous Internet services already implement version 2 of HTTP which could present a risk to the Internet safety, and that’s why disclosures and fixes of the most critical services were coordinated with CERT/CC. 

Multiple CVEs have been assigned: 

Mitigation

In HTTP/1.1, servers are protected from infinite headers by enforcing header size limits and request/headers timeouts that drop the connection.

So, to mitigate the CONTINUATION Flood vulnerability, vendors must limit or sanitize the number of CONTINUATION frames sent within a single stream. Some vendors have already released fixes, while others are working on patches. 

CVE-2024-2653

Affects the amphp/http Composer package. Fixed in versions 1.7.3 and 2.1.1 with commit 881cc33d.

More information here. 

CVE-2024-27316

Affects Apache HTTP Server (httpd). Fixed in version 2.4.59 with commit b646741f.

More information here. 

CVE-2024-24549

Affects Apache Tomcat. Fixed in versions 8.5.99, 9.0.86, 10.1.19 and 11.0.0-M17 with commit 810f49d5.

Note that this CVE is not directly related to the CONTINUATION flaw but was discovered as a consequence of a POC for the vulnerability.

More information here. 

CVE-2024-31309

Affects Apache Traffic Server. Fixed in versions  8.1.10-rc0 and 9.2.4-rc0 with commit b8c6a23b.

More information here. 

CVE-2024-27919

Affects the Go package github.com/envoyproxy/envoy through the “oghttp” component. Fixed in versions 1.26.8, 1.27.4, 1.28.2 and 1.29.3 with commit d1936d03.

More information here. 

CVE-2024-30255

Affects the Go package github.com/envoyproxy/envoy through the “nghttp2” component. Fixed in versions 1.26.8, 1.27.4, 1.28.2 and 1.29.3.

More information here. 

CVE-2023-45288

Fixed in the Go packages golang.org/x/net/http2 version 0.23.0 and net/http 1.21.9 and 1.22.2 with commit ba872109.

More information here. 

CVE-2024-28182

Affects the Cpp library and Go wrapper nghttp2. Fixed in version 1.61.0 with commit 00201ecd.

More information here. 

CVE-2024-27983

Affect Node.js. Fixed in versions 18.20.1, 20.12.1 and 21.7.2.

More information here. 

CVE-2024-2758

Affects Tempesta FW. Fixed in version 0.7.1.

Our team is actively tracking these vulnerabilities and ensuring that our SCA solution covers the affected products within its scope.

More information here. 

We maintain a comprehensive list of advisories on our DevHub page at https://devhub.checkmarx.com/advisories/. (A resource that provides timely information and insights about various SCA vulnerabilities).

Conclusion

The HTTP/2 CONTINUATION Flood vulnerabilities present a critical issue that can cause significant disruption to web servers.

This class of vulnerabilities is a reminder that while new protocols offer improvements, their implementations must be carefully designed and tested to ensure security.

Checkmarx is actively tracking these vulnerabilities and their impact on the open-source domain. 

Our SCA solution covers these vulnerabilities within its scope, helping organizations identify and mitigate potential risks.

Key Points

• GitHub search manipulation: Attackers create malicious repositories with popular names and topics, using techniques like automated updates and fake stars to boost search rankings and deceive users.
• Malicious code is often hidden within Visual Studio project files (.csproj or .vcxproj) to evade detection, automatically executing when the project is built.
• The attacker had set up the stage to modify the payload based on the victim’s origin, checking specifically if the victim is based in Russia. At this point, we don’t see this ability activated.
• The recent malware campaign involves a large, padded executable file that shares similarities with the “Keyzetsu clipper” malware, targeting cryptocurrency wallets.
• The malware establishes persistence on infected Windows machines by creating a scheduled task that runs the malicious executable daily at 4AM without user confirmation.
• Developers should be cautious when using code from public repositories and watch for suspicious repository properties, such as high commit frequencies and stargazers with recently created accounts.

Exploiting GitHub’s Search Functionality

Our recent findings reveal a threat actor creating GitHub repositories with names and topics that are likely to be searched by unsuspecting users. These repositories are cleverly disguised as legitimate projects, often related to popular games, cheats, or tools, making it difficult for users to distinguish them from benign code.

To ensure maximum visibility, the attackers employ a couple of clever techniques that consistently place their malicious repositories at the top of GitHub search results.

Automatic Updates

By leveraging GitHub Actions, the attackers automatically update the repositories at a very high frequency by modifying a file, usually called “log”, with the current date and time or just some random small change. This continuous activity artificially boosts the repositories’ visibility, especially for instances where users filter their results by “most recently updated,” increasing the likelihood of unsuspecting users finding and accessing them.

Faking Popularity

While automatic updates help, the attackers combine another technique to amplify the effectiveness of their repo making it to the top results.

The attackers employed multiple fake accounts to add bogus stars, creating an illusion of popularity and trustworthiness. This artificially boosts the repositories’ visibility further, especially for instances where users filter their results by “most stars.”

In contrast to past incidents where attackers were found to add hundreds or thousands of stars to their repos, it appears that in these cases, the attackers opted for a more modest number of stars, probably to avoid raising suspicion with an exaggerated number.

Many of the stargazers are created on the same date. A red flag for fake accounts.

This social engineering technique is designed to manipulate users into believing that the repository is widely used and reliable, preying on the inherent trust users place in highly-starred repositories.

Unsuspecting users, often drawn to the top search results and repositories with seemingly positive engagement, are more likely to click on these malicious repositories and use the code or tools they provide, unaware of the hidden dangers lurking within.

For a deeper dive into the tactic of fake stars, check out our recent blog that explores this manipulation technique in greater detail.

Hidden Malware in Project Files

The attackers conceal their malware primarily as obfuscated code deep within the .csproj or .vcxproj files of the repository (files commonly used in Visual Studio projects) to decrease the chances of the average user detecting it unless they proactively search for suspicious elements.

However, it’s worth noting that there have been a small number of other detected repos that contained different malware within other files.

Technical Analysis of the Common Malicious Payload

The malicious script is embedded within a pre-build event of a Visual Studio project file (.vcxproj) and is designed to be executed automatically during the build process. The script consists of two main parts:

1. A batch script that sets up the environment and executes a VBScript file.
2. A base64-encoded PowerShell script that is decoded and executed by the VBScript file.

The batch script creates a temporary directory, generates a VBScript file, and decodes the base64-encoded PowerShell script. It then executes the decoded PowerShell script and cleans up the temporary files.

The decoded PowerShell script performs the following malicious actions:

1. Retrieves the country code of the machine’s IP address, determining whether the machine is based in Russia.
2. Downloads content from specific URLs based on the country code (content is continuously updated by the attacker)
3. Downloads encrypted files from each URL, extracts them with a predefined password, and executes the extracted files.

The script also employs error handling to silently catch exceptions and continue execution.

Active Campaign

On April 3rd, the attacker updated the malicious code within one of their repositories, pointing to a new URL that downloads a different encrypted .7z file containing an executable named feedbackAPI.exe.

The attacker had padded the executable with many zeros, a technique used to artificially boost the file size. Due to this padding, the file size exceeded the threshold of many security solutions, VirusTotal being a notable one, preventing the possibility of it from being scanned. According to VirusTotal’s documentation,

“If the file to be uploaded is bigger than 32MB, please use the /private/files/upload_url endpoint instead which admits files up to 650MB.”

The padded feedbackAPI.exe file was 750MB in size, exceeding even the increased limit for the alternative endpoint.

The results of our analysis of this malware suggest that the malware contains similarities to the “Keyzetsu clipper” malware, a relatively new addition to the growing list of crypto wallet clippers commonly distributed through pirated software.

This executable file also attempts to create persistence on Windows machines. It achieves this by creating a shortcut to the exe file and then establishing a daily scheduled task named “Feedback_API_VS_Services_Client” that executes the shortcut at 4AM. Notably, this task is created without any confirmation prompts, making it stealthier and more likely to go unnoticed by unsuspecting users.

Indicators of Successful Exploitation

Evidence indicates that the attackers’ campaign has successfully deceived unsuspecting users. Numerous malicious repositories have received complaints through Issues and pull requests from users who experienced problems after downloading and using the code.

Conclusion

The use of malicious GitHub repositories to distribute malware is an ongoing trend that poses a significant threat to the open-source ecosystem. By exploiting GitHub’s search functionality and manipulating repository properties, attackers can lure unsuspecting users into downloading and executing malicious code.

To prevent falling victim to similar attacks, it is recommended to keep an eye on the following suspicious properties of a repo:

1. Commit frequency: Does the repo have an extraordinary number of commits relative to its age? Are these commits changing the same file with very minor changes?
2. Stargazers: Who is starring this repo? Do most of the stargazers appear to have had accounts created around the same time?

By being aware of these red flags, users can better protect themselves from inadvertently downloading and executing malware.

In the aftermath of the XZ attack and many other recent incidents, it would be irresponsible for developers to rely solely on reputation as a metric when using open source code. A developer who blindly takes code also blindly takes responsibility for that code. These incidents highlight the necessity for manual code reviews or the use of specialized tools that perform thorough code inspections for malware. Merely checking for known vulnerabilities is insufficient.

As part of Checkmarx’s commitment to supply chain security, our research team continuously monitors and detects suspicious activities in the open-source software ecosystem. We track and flag potential indicators of malicious behavior and promptly alert our customers and the community to help protect them from these evolving threats.

Working together to keep the open source ecosystem safe.

IOC

• hxxps[:]//cdn.discordapp[.]com/attachments/1192526919577649306/1211404800575537304/VisualStudioEN.7z?ex=6612fda3&is=660088a3&hm=5ae3b1b5d2c7dc91a9c07a65dbf8c61d3822b1f16a2d7c70eb37a039979e8290&
• hxxps[:]//cdn.discordapp[.]com/attachments/1192526919577649306/1211403074799804476/VisualStudioRU.7z?ex=6612fc07&is=66008707&hm=0a7fc9432f5ef58960b1f9a215c3feceb4e7704afd7179753faa93438d7e8f54&
• 08b799d56265e93f6aae4f089808d1cb
• cc9d54b78688ef6f41e4f4d0c8bced3e04bfcedc
• ooocyber[.]keenetic[.]pro
• 188[.]113[.]132[.]109
• https://rentry.co/MuckCompanyMMC/raw
• hxxps[:]//rentry[.]co/hwqfx/raw
• hxxps[:]//rentry[.]co/q3i7zp/raw
• hxxps[:]//rentry[.]co/tvfwh/raw
• hxxps[:]//cdn[.]discordapp.com/attachments/1193658583947149322/1218876343232630844/main.exe?ex=6609420d&is=65f6cd0d&hm=f5a0af7499e892637935c3e4071f2dc59d48214f56a1c1d7aedc3392f58176db&
• hxxps[:]//paste[.]fo/raw/dd6cd76eb5a0
• hxxps[:]//paste[.]fo/raw/efda79f59c55
• hxxps[:]//rentry[.]co/4543t/raw
• hxxps[:]//rentry[.]co/a2edp
• hxxps[:]//textbin[.]net/raw/gr2vzmwcvt

The attack, discovered accidently on March 29, 2024, by a developer named Andres Freund, during performance testing, was carried out over several years by the GitHub account Jia Tan (JiaT75), who gained the trust of the long-time maintainer of the xz project and eventually replaced them as the main point of contact.

The backdoor was added in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. This backdoor allows attackers unauthorized access on systems that have the compromised versions installed.

The impact of this backdoor is significant because of xz’s use in many systems around the world, including popular Linux distributions like Red Hat and Debian.

In this blog post, we will provide a timeline of the events, look at the key people involved, and discuss what this incident means for the open-source community and the importance of maintaining the security and integrity of widely-used software libraries.

Key Findings

• xz, a widely-used compression library, was compromised with a backdoor (CVE-2024-3094) that allows forunauthorized access on systems with compromised versions (5.6.0 and 5.6.1) installed.
• The attack was carried out over several years by a user named Jia Tan (JiaT75), who gradually gained maintainer status after continuous pressure from unknown accounts on the long-time maintainer, Lasse Collin, to add a new maintainer and approve Jia Tan’s patch.
• The widespread use of xz in Linux distributions makes the impact of the backdoor significant.
• The backdoor was accidentally discovered on March 29, 2024, by the developer Andres Freund.

Gaining Reputation Over Time

The xz compression library, a widely-used tool for compressing files, found across Linux distributions, community projects, and commercial products, was compromised by a malicious actor named Jia Tan (JiaT75) who gradually and patiently gained maintainer status in order to pull off the attack, ultimately introducing a backdoor identified as CVE-2024-3094.

The attack began in 2021 when Jia Tan created their GitHub account and began using it for various activities.

In April 2022, Jia Tan submitted a patch to the xz project via a mailing list. Soon after, unknown accounts, including one named Jigar Kumar and another named Dennis Ens , began pressuring the long-time maintainer of xz, Lasse Collin, to merge the patch and add a new maintainer to the project. Lasse Collin, who had limited availability to take care for the project, eventually agreed to add Jia Tan as a maintainer. A decision that is in fact not unusual in the open-source community, where maintainers often hand off projects to others due to various reasons.

Over the next two years, Jia Tan became a regular contributor to the xz project, gaining trust within the community.

By March 2023, Jia Tan had become the primary contact for xz in Google’s oss-fuzz, a platform for finding vulnerabilities in open-source software.

Most Sophisticated Supply Chain Attack We Know

The backdoor itself was introduced in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. The malicious code allows attackers unauthorized access by infecting the SSH on systems with the compromised versions installed, making it a significant threat to users of the library.

A Discovery

The backdoor was accidentally discovered on March 29, 2024, by Andres Freund during routine performance testing. Freund noticed unusual CPU usage in the sshd process, which led him to investigate further and uncover the malicious code. This accidental discovery, the backdoor could have gone unnoticed for a longer period, effecting a large part of the open source ecosystem.

Impact

The impact of the backdoor could have had particularly severe consequences due to the widespread use of xz in compressing critical software components, including popular Linux distributions like Red Hat and Debian. Many systems worldwide rely on xz for compressing and decompressing files, making the potential reach of the backdoor extensive.

Advanced Persistent Threat

The involvement of multiple identities. The complexity of the payload, and the high level of technical expertise required, along with the patience and persistence shown in gradually gaining trust within the xz community over several years before introducing the backdoor. All these are consistent with the capabilities of nation-state actors and are qualities of advanced persistent threats (APTs). 

This incident is part of a growing and alarming trend of advanced persistent threats (APTs) targeting critical open-source projects.

Conclusion

The xz compromise highlights the urgent need for the open-source community to improve its security practices and tools to prevent similar attacks in the future. Collaboration, transparency, and shared responsibility are essential to detecting and mitigating advanced persistent threats (APTs) targeting critical open-source projects. 

We, the community must develop more effective strategies, to strengthen the security of open-source software. By learning from this incident and taking proactive measures, the open-source community can build a more resilient and trustworthy ecosystem, ensuring the long-term success and integrity of open-source projects in the face of ever-evolving cybersecurity threats.

Working together to keep the opensource ecosystem safe.

The research team of Checkmarx simultaneously investigated a campaign of multiple malicious packages appear to be related to the same threat actors.

The threat actors target victims with Typosquatting attack technique using their CLI to install Python packages. 

This is a multi-stage attack and the malicious payload aimed to steal crypto wallets, sensitive data from browsers (cookies, extensions data, etc..) and various credentials.

In addition, the malicious payload employed a persistence mechanism to survive reboots.

PyPi Suspended User and Project Creation

A few hours ago, on Mar 28, 2024 – 02:16 UTC, The Python Package Index (PyPi) added a new website banner and released an official update: “We have temporarily suspended new project creation and new user registration to mitigate an ongoing malware upload campaign”

Evidence of Multiple Malicious Typosquatting Packages

Between March 27 and March 28, 2024, multiple malicious Python packages were uploaded on the Python Package Index (PyPI). These packages most likely created using automation 

The Malicious Payload

The malicious code is located within each package’s setup.py file, enabling automatic execution upon installation.

employed a technique where the setup.py file contained obfuscated code that was encrypted using the Fernet encryption module. When the package was installed, the obfuscated code was automatically executed, triggering the malicious payload.

Upon execution, the malicious code within the setup.py file attempted to retrieve an additional payload from a remote server. The URL for the payload was dynamically constructed by appending the package name as a query parameter. 

The retrieved payload was also encrypted using the Fernet module, Once decrypted, the payload revealed an extensive info-stealer designed to harvest sensitive information from the victim’s machine.

The malicious payload also employed a persistence mechanism to ensure it remained active on the compromised system even after the initial execution.

A small piece of the larger script

Summary

The discovery of these malicious Python packages on PyPI highlights the ongoing nature of cybersecurity threats within the software development ecosystem.

This incident is not an isolated case, and similar attacks targeting package repositories and software supply chains are likely to continue.

As this situation unfolds, we will provide updates on any new developments.

Working together to keep the open source ecosystem safe.

Package List

IOCs

• hxxps://funcaptcha[.]ru/paste2
• hxxps://funcaptcha].[ru/delivery
• hxxps://funcaptcha.ru/atomic/app.asar
• ABE19B0964DAF24CD82C6DB59212FD7A61C4C8335DD4A32B8E55C7C05C17220D      

0C1DDD33E630F4AC684880F0E673DFA84919272494C11DA0F1EC05FB4F919CE8

The threat actors behind these packages deviated from conventional tactics, introducing a nuanced twist in their approach. The first notable tactic was the exploitation of GitHub, a platform synonymous with trust and reliability within the developer community, to disseminate their malicious code. The packages themselves were mere vessels; the actual malicious content was not embedded within them but distributed through them.

This tactic capitalizes on the confidence developers inherently place in GitHub as a staple source for software tools, adding a layer of deceit to the attackers’ scheme and complicating the task for developers in distinguishing between legitimate and suspicious packages.

But that is not the only thing that stands out in this attack attempt. In this blog, we will explain the various combined tactics the attacker used to make these packages stand out.

Key Takeaways

• A number of Python packages surfaced in December on PyPI, utilizing GitHub as a distribution channel for their malicious code.
• One of the packages combined obfuscation with encryption/decryption techniques to mask the harmful intent within the code.
• One of the packages deployed fileless malware, ensuring stealthy execution without leaving traces on disk and better circumventing modern EDR solutions.
• One of the packages exploited the reputation of the widely-used PySocks project to gain trust and increase the likelihood of their malicious packages being downloaded.
• All packages specifically targeted Windows machines.

The “httprequesthub” Package: A Multiple-Stage Malicious Process

The httprequesthub Python package stands out for its sophisticated multi-stage process, executing malicious code hidden within layers of encryption and obfuscation.

httprequesthub attack flow

Stage One

The package starts by decoding a Base64 encoded string within its setup.py file, unveiling a URL that points to a GitHub gist created by the threat actor. This gist acts as the first external payload source.

First stage payload in setup.py file

At the time of publication, the user and gist are still active.

Stage Two

Upon accessing the URL, the package retrieves a second-stage payload characterized by complex obfuscated code combined with arbitrary and non-descriptive variables and function names.

The attacker adds a unique twist by mixing the use of obfuscation and encryption to enhance the complexity of the code, making it even more challenging to understand its intent.

After manually simplifying this code, we get this:

Second stage payload after simplifying it.

Another base64 encoded URL within the executed code leads to yet another GitHub gist, deepening the layers of the attack. This GitHub gist and user profile are no longer active.

This phase also includes a specific condition to fetch and execute the code from the second URL only on Windows systems, tailoring the attack based on the victim’s OS.

Stage Three

The third stage involves executing Python code from the second URL, which is also obfuscated. Simplifying this code reveals a blend of encryption and obfuscation, with a base64 encoded string undergoing a custom XOR decryption process. This produces a complex, encrypted code block, showcasing the attacker’s dedication to concealing their payload’s nature.

After again, manually simplifying this code we get this:

Third stage payload after simplifying it.

The sophistication of the attack escalates further with its reliance on fileless execution Instead of the traditional file-based execution, allowing it to bypass modern EDR solutions.

It dynamically allocates memory within the current process and transfers the decoded payload into this space. Utilizing the Windows API via the ctypes module, it manipulates system memory to create an executable thread directly within the memory, circumventing traditional disk-based detection mechanisms. This fileless execution approach is particularly concerning as it leaves no trace on the hard drive, posing a significant challenge for conventional security tools to detect and mitigate.

Given the multi-staged nature of this attack, it is extremely challenging to identify the malicious intent of the package through static analysis alone, even with the aid of machine learning. For such cases, advanced dynamic solutions are necessary alongside static methods to effectively detect such sophisticated threats.

We have yet to fully determine the end goal of this package.

The “easyhttprequest” Mysterious Package, Exploiting the Shadow of a Popular Project

easyhttprequest attack flow

The easyhttprequest Python package employs a deceptive technique by overriding the standard installation process with a custom PostInstall class embedded within its setup.py script. This class is meticulously mapped to the “install” command in the cmdclass dictionary and is designed to execute additional code when the package is installed using the setup.py install command.

Upon installation, the package’s first move is to clone a GitHub repository (isaaknikolaev/PySocks) into a temporary directory on the user’s system, creating a folder named “PySocks.”

This repository is in fact a fork of the vastly popular “Anorov/PySocks” repository, whose corresponding Python package “pysocks” boasts millions of weekly downloads. This tactic of riding off the reputation of a renowned project is a calculated move to cloak the package’s true intent under the guise of a trustworthy source, enhancing its chances of evading detection.

This cloning occurs regardless of the operating system. However, the script includes a condition specifically for Windows systems, where it installs an additional Python package, dulwich (a package used for interacting with Git repositories)

Upon cloning the repository, the package checks the latest commit message for a particular trigger string (uJq93k8bmm7KqjL). If this string is present, the script removes the trigger string, decodes the remaining message, and proceeds to execute the remaining part of the commit message, which is encoded in Base64. This execution step is where the potential for running malicious code lies.

At the time of discovery, no malicious content was found in the commit message of the cloned repository. This could indicate that either the package was intercepted and sanitized before the attacker could deploy their intended malicious code, or the harmful content was never committed. Nevertheless, the structure of the package indicates a clear intent for malicious use, showcasing a sophisticated method of hiding and executing potentially harmful code through a seemingly innocent package installation.

Key Findings

• NPM Account Takeover: Ledger Connect-Kit was compromised due to npmjs account takeover of a former Ledger employee.
• Affected Versions: Malicious code was injected into versions 1.1.5, 1.1.6, and 1.1.7, resulting in wallet-draining attacks.
• Impact: At this time, over $700,000 has been stolen as a result of this security breach.
• Rapid Mitigation: Ledger swiftly released version 1.1.8 to patch the vulnerability.

Attack Details

The Ledger Connect Kit, instrumental in linking users’ wallets to decentralized applications (dApps), like SushiSwap and Revoke.cash, was compromised when a threat actor took over the NPM account of one of the projects maintainers. The actor then continued to publish multiple new versions of the package, injected with malicious code, that drains the wallets of users. Unsuspecting users that performed transactions unknowingly sent their crypto funds to an attacker-controlled wallet.

The breach targeted versions 1.1.5, 1.1.6, and 1.1.7 of the Ledger Connect Kit NPM Package. These versions were infected with a malicious drainer, that diverted user funds to an attacker-controlled wallet. The compromised package used a rogue WalletConnect project to reroute funds.

Notifying users of the attack

Notifying users of the attack

Apps affected, warning their users

Tactic Used: Account Takeover

Central to this attack was a well-crafted social engineering strategy that led to the compromise of a former Ledger employee’s npmjs account credentials. This breach then led to unauthorized releases of the Ledger Connect Kit. Account takeovers are particularly dangerous since they allow attackers to bypass many traditional security checks, directly inserting malicious code into trusted software. Phishing attacks against contributors have been a rising trend for more than a year.

A critical, and often overlooked, indicator of such an attack is the discrepancy in package versions between the package manager (npm) and the version control system (Git). We can clearly see in this attack that there were no changes and no tags or releases on the Ledger git corresponding to the malicious versions on the NPM package manager.

When a project works efficiently it maintains consistency between these platforms, with each npm release corresponding to a Git tag. This is either done automatically or manually. However, in this case, the versions released on npm lacked matching tags on Git. This mismatch serves as an indicator of suspicious activity, particularly for projects known for their orderly release processes as seen in previous attack cases.

Monitoring for such inconsistencies can be a crucial part of early detection strategies for account takeovers and unauthorized package releases. Tools and practices that keep track of this alignment can quickly flag discrepancies, prompting an immediate investigation and potentially preventing widespread impact.

Rapid Response and Remediation

Upon discovering the breach, Ledger’s team acted swiftly, releasing version 1.1.8 of the Ledger Connect Kit to patch the vulnerability within 40 minutes of detection. Despite their quick response, the malicious versions were active for approximately five hours, with a critical window of less than two hours where funds were actively drained.

Impact

The financial repercussions are becoming increasingly apparent. As of the latest reports, over $700,000 has been stolen due to this security breach.

But I use SBOMs, so I’m good – right?

While a Software Bill of Materials (SBOM) is a critical tool for enhancing transparency and security in software supply chains, its effectiveness is limited in certain types of attacks. An SBOM effectively lists all components used in a software product, but it primarily addresses issues related to known vulnerabilities in these components, not necessarily the security of the distribution mechanism itself.

In the case of the Ledger Connect Kit attack, the primary issue was not with the components themselves but with the compromised distribution process due to an account takeover. The attacker published malicious versions of the package through a legitimate channel, which would not necessarily be flagged by an SBOM. Since the SBOM would list components as usual, it wouldn’t identify the malicious code introduced by the attacker in the compromised versions.

So, while SBOMs are vital for component transparency, they must be complemented with fast, proactive scanning mechanisms that can detect unauthorized changes or malicious activities in real-time, beyond just component listing.

Conclusion

This breach highlights the potential domino effect of a single compromised element in interconnected digital platforms. The reliance on third-party components, adds layers of vulnerability, making every participant in the chain a potential target and contributor to a larger-scale compromise. Therefore, it is crucial to ensure that effective security strategies are in place which involves things like rigorous vetting of third-party components, implementing robust internal security measures, and fostering a culture of cybersecurity awareness.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. 

Checkmarx customers are protected against this attack.

Learn how Checkmarx and AWS have partnered to help your financial services firm adapt to the evolving landscape

The way we bank has changed beyond recognition. Where transactions once took place in person within the walls of impressive buildings, we now see mobile and online banking on the rise. Anywhere, anytime, palm-of-your-hand banking is the norm, and our expectations are shaped by the seamless, personalized app experiences that have become the default in the digital universe. At the same time, the global acceleration of digital banking licenses has created a new competitive landscape populated by fast-moving market entrants and born-in-the-cloud providers.

One thing that hasn’t changed, though, is the position of trust at the cornerstone of the banking system. Indeed, in today’s volatile economic and cybersecurity environment, building brand trust is more important than ever. Whether you are a legacy brand or a new market entrant, any lack of trust compromises your ability to succeed.

So financial services firms face a continuing challenge: how to innovate at the speed required without compromising customer safety and system security? Most are turning to the cloud for answers. Its flexibility and scalability are making it central to financial service organizations’ efforts to embrace new trends and deliver innovative services at pace.

AWS has some intriguing solutions to meet the challenge. The cloud leader provides a full suite of services to help banks achieve the agility to thrive in the digital age, while certified partners such as Checkmarx ensure the security of the applications and services banks develop.

Recently, the team at AWS identified seven key trends that are impacting the financial services industry. Here we take a deep dive into three areas where AppSec is highly relevant and explore what they mean for the sector.

Trend 1: Customer experience — speed and security must be dual priorities

Today, the economic power is passing to a digital-native generation with little loyalty to legacy banking brands and great expectations of how personal and business financial services should perform. This means customer experience is the modern commercial battleground. Banking must be hyper-personalized and service-led. Increasingly, banking is integrated into consumers’ day-to-day journeys through embedded financial services within trusted brands such as Starbucks and Uber.

Banks are leaning heavily on AI and machine learning to predict customer needs through analysis of internal and external datasets, while the omnichannel drive continues through solutions such as authentication based on voice recognition, real-time sentiment analysis of customer service calls, chatbot support, and automated self-service options.

AWS supports these initiatives and many more through cloud-powered big data analysis that allows banks to leverage AI and machine learning on a massive scale. It also, in its own words, “helps compress time to innovation and, ultimately, time to value, by facilitating rapid development, testing, and deployment to produce new ideas and customer propositions.”  

AWS allows banks to accelerate innovation through its cloud-native application development services, but they also need to ensure the code they create is secure and resilient. Achieving application security assurance without putting a brake on delivery speed is crucial. However, a recent Checkmarx survey of banking and insurance CISOs found that 84% of respondents undergoing digital transformation and implementing a cloud-native strategy were concerned about secure application development and deployment.

As an AWS accredited partner, Checkmarx understands that security must work at the speed of DevOps. The Checkmarx One Application Security Platform is designed for the cloud development generation and delivered from the cloud, bringing integrated one-click AppSec testing that allows financial services companies to deploy more secure code — fast.

Trend 2: Ecosystem-based banking and banking-as-a-service — APIs take center stage

The open banking era is unlocking the doors to greater innovation and collaboration. Providers can now seize new opportunities to develop products that blur the boundaries between different types of financial services. They are establishing solutions that offer their banking services, including fully managed banking propositions, to third parties securely via microservices and a common platform.

AWS identifies two key approaches to this trend. The “marketplace” approach sees banks providing “value-added and contextualized services to their customers such as ERP integrations or personal finance management.” The aim is to deepen the relationship with individual and business customers beyond basic service provision.

The “banking-as-a-service” approach sees banks offering a range of services — from standalone specific regulatory-driven services like Know Your Customer’s Customer (KYCC) to fully managed offerings that let any organization set up a branded banking service.

Center-stage in both approaches are the bank’s APIs, designed to allow banking products and services to be distributed to customers and third parties. Modernizing API architecture in the cloud accelerates the development and testing of APIs, making them easier to integrate as well as providing scalability.

Checkmarx API security offers banks and their customers and partners a crucial service that helps discover, control, and mitigate API security risk. It offers complete visibility into your API inventory and identifies vulnerabilities and misconfigurations. Controlling API risk is an essential component of developing financial marketplace ecosystems and banking-as-a-service solutions.

Trend 3: Cyber event recovery — reducing the attack surface and responding to regulatory requirements

Given its nature, it is not surprising that the financial services sector faces more cyberattacks than any other. On top of these external incursions comes the disruption of digital transformation, which can also create vulnerabilities including third-party and supply chain risk.

Banks are investing in a range of measures designed to manage and mitigate risk and accelerate recovery from any attack. Reducing the attack surface and minimizing vulnerabilities is an essential activity if the sector is to safeguard its reputation and maintain customer trust. Additionally, the growing library of regulations designed to ensure banks are meeting their security obligations means they need to adopt solutions that support compliance.

AWS offers a wealth of solutions to ensure client data is protected and banks can recover quickly from attacks. These include Amazon Simple Storage Service (Amazon S3), key management services, software-defined firewalls that facilitate network isolation, and geographic sovereignty solutions that meet compliance requirements.

These and many other offerings take care of Amazon’s part of the shared security bargain, however, banks are also responsible for securing the workloads they deploy in AWS. This is where Checkmarx steps in, providing comprehensive AppSec solutions that integrate seamlessly with AWS SDLC tools to secure the entire process. Checkmarx addresses all types of application risk, from custom code errors to open source component vulnerabilities, API risks, and infrastructure as code misconfigurations.

These are dynamic times for financial services firms, and AWS with Checkmarx are helping them capitalize on opportunities while defending against threats — both malicious and competitive.

Interested in learning more?

We’re exploring these trends in detail in our webinar on May 4, 2023, where AWS and Checkmarx will explain how you can turn AppSec into a competitive advantage as you continue your cloud transformation journey.

REGISTER FOR THE WEBINAR

Stay Ahead of Supply Chain Attacks: Secure Your Banking Sector Software