The attack targeted users of Atomic, Trust Wallet, Metamask, Ronin, TronLink, Exodus, and other prominent wallets in the crypto ecosystem. Presenting themselves as utilities for extracting mnemonic phrases and decrypting wallet data, these packages appeared to offer valuable functionality for cryptocurrency users engaged in wallet recovery or management. However, behind the scenes, these packages would fetch malicious code from dependencies to covertly steal sensitive cryptocurrency wallet data, including private keys and mnemonic phrases, potentially granting the attackers full access to victims’ funds.

This strategic use of dependencies allowed the main packages to appear harmless while harboring malicious intent in their underlying components.

Key Findings

• On September 22nd, multiple packages were published to the PyPI platform, targeting a wide range of crypto wallets including Atomic, Trust Wallet, Metamask, Ronin, TronLink, and Exodus.
• The malicious packages distributed their code across dependencies, making detection more challenging. This approach separated the seemingly benign main package from its harmful components.
• Unlike most malicious packages we’ve seen, these packages activate only when specific functions are called, not automatically upon installation.
• The malware’s capabilities include theft of private keys, mnemonic phrases, and other sensitive wallet data.
• The attack exploits the trust in open-source communities and the apparent utility of wallet management tools, potentially affecting a broad spectrum of cryptocurrency users.

A Web of Deception

The attacker behind this campaign implemented a multi-faceted strategy to disguise their intent and maximize the download count of their packages. This approach combined several deceptive techniques, each designed to exploit different aspects of user trust and package evaluation practices.

Deceptive Package Names and READMEs

Package names were carefully crafted to appeal to developers and users working with various wallet types. Names like “AtomicDecoderss,” “TrustDecoderss,” and “ExodusDecodes” mimicked legitimate tools.

Each package was accompanied by a professionally crafted README file, further enhancing its apparent legitimacy. These READMEs included detailed installation instructions, usage examples, and in one case, even “best practices” for virtual environments.

The attacker went a step further in their deception by including fake package statistics in the README files. At first glance, the packages displayed impressive stats, making them appear to be part of very popular and well-maintained projects. However, these were merely images creating an illusion of popularity and active development, further encouraging users to trust and download the package.

This level of detail and apparent popularity not only made the packages seem genuine but also significantly increased the likelihood of users implementing and running the malicious code.

Distributed Functionality Across Dependencies

Functionality was distributed across multiple dependencies within the packages themselves. Six of the malicious packages relied on a dependency called “cipherbcryptors,” which contained the core malicious code. Some packages further obfuscated their functionality by utilizing an additional dependency, “ccl_leveldbases.” This approach served dual purposes.

Firstly, it made the main packages appear more innocuous upon initial inspection, as they themselves contained little to no overtly malicious code.

Secondly, it significantly complicated the analysis process for security researchers and vigilant users. The full scope of each package’s capabilities wasn’t immediately apparent, requiring a deeper dive into the dependency chain to uncover the true nature of the code.

Obfuscation of Malicious Code

Within the “cipherbcryptors” package, where the heart of the malicious functionality resided, the code was heavily obfuscated. This obfuscation makes it challenging for automated security tools and human reviewers alike to quickly identify the package’s true intent.

Original obfuscated malicious function within the “cipherbcryptors” package

After deobfuscation – malicious function within the “cipherbcryptors” package

Furthermore, the attacker employed an additional layer of security by not hardcoding the address of their command and control server within any of the packages. Instead, they used external resources to retrieve this information dynamically.

This technique not only makes static analysis of the code more difficult but also provides the attackers with the flexibility to change their infrastructure without needing to update the packages themselves.

By combining these various deceptive techniques – from package naming and detailed documentation to false popularity metrics and code obfuscation – the attacker created a sophisticated web of deception. This multi-layered approach significantly increased the chances of the malicious packages being downloaded and used, all while making detection and analysis more challenging.

Attack Flow

The execution of this attack diverged from the typical pattern seen in malicious packages. Rather than triggering malicious actions immediately upon installation, these packages lay dormant until specific functions were called. This approach significantly reduced the chances of detection by security tools that scan packages at installation time.

When a user attempted to use one of the advertised functions, the malicious code would activate. The process typically began with the package attempting to access the user’s cryptocurrency wallet data. For different wallet types, this involved targeting specific file locations or data structures known to contain sensitive information.

Once the wallet data was accessed, the malware would attempt to extract critical information such as private keys, mnemonic phrases, and potentially other sensitive data like transaction histories or wallet balances. This stolen data would then be prepared for exfiltration.

The exfiltration process involved encoding the stolen data and sending it to a remote server controlled by the attacker.

Impact

The consequences for victims could be severe and far-reaching. The most immediate and obvious impact is the potential for financial losses. With access to private keys and mnemonic phrases, attackers can swiftly drain cryptocurrency wallets. The irreversible nature of blockchain transactions means that once funds are stolen, recovery is nearly impossible. Beyond immediate financial theft, compromised wallet data can lead to ongoing vulnerability, as attackers may monitor and exploit the wallet over time.

The packages’ ability to fetch external code adds another layer of risk. This feature allows attackers to dynamically update and expand their malicious capabilities without updating the package itself. As a result, the impact could extend far beyond the initial theft, potentially introducing new threats or targeting additional assets over time.

Conclusion

This sophisticated supply chain attack on the Python ecosystem serves as another stark reminder of the ever-evolving threats in the open-source world. The cryptocurrency space, in particular, continues to be a prime target, with attackers constantly devising new and innovative methods to compromise valuable digital assets. This incident underscores the critical need for ongoing vigilance of the entire open-source community to remain alert and proactive in identifying and mitigating such threats. The attack’s complexity – from its deceptive packaging to its dynamic malicious capabilities and use of malicious dependencies  – highlights the importance of comprehensive security measures and continuous monitoring.

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 One customers are protected from this attack.

Packages

• atomicdecoderss
• trondecoderss
• phantomdecoderss
• trustdecoderss
• exodusdecoderss
• walletdecoderss
• ccl-localstoragerss
• exodushcates
• cipherbcryptors
• ccl_leveldbases

IOCs

• hxxps[:]//pastebin[.]com/raw/FZUp6ESH
• hxxps://decry[.]in/check

This could be the perfect ending to a cybersecurity film, but it’s even better—it’s the exciting reality of ZAP’s core team joining Checkmarx to deliver the best in Dynamic Application Security Testing (DAST)! ZAP project leaders Simon Bennetts, Ricardo Pereira, and Rick Mitchell are joining Checkmarx to help develop the next generation of our enterprise-grade DAST solution. They will continue to support the open-source project and grow the ZAP community. This transition allows them to focus fully on advancing DAST.

What is DAST?

For those unfamiliar, DAST is a technique used to test web applications by detecting vulnerabilities while they are running. Unlike static analysis, DAST doesn’t require access to source code, making it essential in identifying security risks that emerge in live environments. This widely adopted tool helps uncover vulnerabilities that may remain hidden during static analysis.

What is ZAP?

ZAP (Zed Attack Proxy) is the world’s most widely used web application scanner, having been downloaded millions of times. This popularity is one of the reasons Checkmarx initially integrated it into its DAST solution.

Simon Bennets, Ricardo Pereira and Rick Mitchell are ZAP’s project leaders and have been contributing, guiding and reviewing any contribution to the open source project.

What does it mean for Checkmarx customers?

For users of Checkmarx DAST, our commercial offering, this collaboration means they will now benefit from the unmatched expertise of the ZAP core team. Checkmarx will continue to empower organizations to secure their applications from code to cloud. The ZAP team’s deep knowledge, gained from contributing to nearly every aspect of ZAP, adds tremendous value to Checkmarx’s already robust offering.

Checkmarx will gain unique insights and focus, enabling us to drive faster enhancements to Checkmarx DAST. The Checkmarx research team, working alongside ZAP’s leadership, will improve the accuracy of the engine, reducing false positives, and helping customers focus only on relevant findings. The team will also enhance key features like scan rules, automation, and authentication.

For customers already using our DAST solution, the usage will remain seamless. The new features developed with the ZAP core team will be integrated into our existing solution and available “out of the box” in Checkmarx DAST.

A unified view of vulnerabilities

By combining Static Application Security Testing (SAST), DAST, and API security testing into a single platform, Checkmarx provides a unified view of vulnerabilities, allowing for comprehensive analysis. This holistic approach to vulnerability management, which includes both static and dynamic analysis, along with API security, ensures better prioritization and more efficient remediation.

Integrating DAST in the Checkmarx One platform helps secure applications by detecting vulnerabilities in live environments and throughout the SDLC. Correlation between the different results adds a layer of  prioritization, making remediation more efficient. It’s a key part of our vision for managing application risk, spanning from development to runtime insights (code-to-cloud).

What does it mean for ZAP and the open source community?

Moving forward, ZAP will be known as “ZAP by Checkmarx” and will continue as a separate, community-driven project under the Apache v2 license. As Simon noted in his blog, “This is by far the biggest investment any one company has made in ZAP and ensures that ZAP will continue to thrive.”

For the open-source community, this collaboration is great news. Checkmarx  has a proven track record with open-source projects such as KICS, 2MS, CxFlow, Vorpal, ImageX and many others, contributing significantly to the community.

Personally, as the previous Product Manager for our open-source secret detection solution (2MS) and through my work with our research team identifying malicious packages, I’ve always felt a close connection to the open source community. I’m happy to have another opportunity to contribute.

The ZAP community will benefit from our company’s expertise and resources, enabling the development of key features requested by the community. ZAP by Checkmarx will continue to be a community-driven, open-source DAST solution, while our enhanced Checkmarx DAST will build upon and improve on our existing solution.

This marks a significant step in expanding our dynamic application security testing capabilities and strengths our commitment to Checkmarx DAST, with the knowledge and support of the ZAP project leaders.

If you’d like to learn more, feel free to contact us.

Intro

In an era where misinformation and identity theft pose significant threats, the security of survey platforms is crucial, particularly during pivotal global election cycles. The Checkmarx research team recently identified two Cross-site scripting (XSS) vulnerabilities on Gallup’s website. XSS is a vulnerability that might enable attackers to bypass the same origin policy, impersonate users (and perform actions on their behalf), and access their data. This vulnerability can potentially allow attackers to gain full control over an application’s functionality and data, especially if the affected user has privileged access.

The types of XSS vulnerabilities found are:

• Reflected XSS – type of cross-site scripting that occurs when an application unsafely includes data from an HTTP request directly in its response.

• DOM-based XSS – this type of cross-site scripting occurs when client-side JavaScript unsafely processes data from an untrusted source, often writing it back to the DOM, as was the case in Gallup’s systems.

This blog examines these vulnerabilities, their potential impact, and the broader implications for digital security in the field of public opinion research.

Reflected Cross Scripting – gx.gallup.com

CVSS Score: 6.5 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /kiosk.gx endpoint did not properly sanitize or encode the query string ALIAS parameter value before including it on the page.

Figure 1: Exploiting the issue to display the document’s domain

Figure 1 shows the execution of JavaScript code included in the vulnerable parameter. This endpoint doesn’t require the victim to be authenticated.

If left unaddressed and exploited by malicious actors, these vulnerabilities could lead to the execution of arbitrary code in the victims’ navigation session context. This could result in unauthorized actions being performed on their behalf. It’s important to note that this endpoint is commonly used to access Gallup surveys, which may make users more susceptible to exploitation. This could lead to unauthorized access to personally identifiable information (PII), manipulation of user preferences, and other detrimental actions.

In this proof of concept (PoC) video, we show how this vulnerability could be exploited to manipulate the victim’s shopping cart. The victim innocently visits a specially crafted URL to participate in a “work-life balance” survey. Unbeknownst to them, the malicious URL triggers the browser to load a JavaScript file from a remote location controlled by the attacker. This script leverages a JSONP endpoint (https://buy.gallup.com/store/gallup/SessionToken) to retrieve and exfiltrate Digital River API access tokens to a server controlled by the attacker. With these tokens, the attacker gains access to the victim’s PII and can add a new product to the shopping cart, illustrating the potential risks of this vulnerability.

The JSONP endpoint plays an important role in this attack scenario. The gallup-session-token cookie is required to get the access tokens. Nevertheless, it is not accessible to JavaScript (httpOnly), and the browser refuses to include it in cross-site requests. SameSite attribute is set to None, and the server has Access-Control-Allow-Origin set to *.Exploit methodology

The following URL would pop a dialog box like the one shown in Figure 1:

https://gx.gallup[.]com/kiosk.gx?ALIAS=%22);alert(document.domain)//&TYPE=q12

DOM-Based Cross-Site Scripting – my.gallup.com

CVSS Score: 5.4 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /_Portal/ApplicationAsync endpoint did not properly sanitize nor encode query string searchTerm parameter value before including it into the page.

Figure 2: Exploiting the issue to display the document’s domain

Figure 2 shows the execution of JavaScript code included in the vulnerable parameter. The vulnerable endpoint requires authentication.

Malicious actors might exploit this issue to execute arbitrary code in the victims’ navigation session context and perform actions on their behalf.

In the above PoC video, this issue is exploited to take over a victim’s account (account takeover). The victim visits a specially crafted URL that includes a payload to pull a JavaScript file from a remote location controlled by the attacker. That script is responsible for 1) rendering my.gallup.com inside an iframe, 2) automating the required workflow to change the victim’s email, and 3) pinging the attacker’s remote server with the new email address associated with the victim’s account. From here, all the attacker needs to do is recover the account password, and set a new one.

Exploit methodology

The following URL, after logging in, will pop dialog box like the one shown in Figure 2:

https://my.gallup[.]com/_Portal/ApplicationAsync?gssClientId=dduOMXW7d71AS3U _2BFMiMY8EiRX0WxJVn_2FHNUkaHb4okdayR4Pz6_2BetryXCC5aLQ2&dashbo ardWidgetId=AQICAHgcAgLcqG_2BjL48JMeAx11Kd4K4khEMoYzbmIpOoa9wRw QHwBn_2B2jOYRmEThy2bBjhebAAAAeDB2BgkqhkiG9w0BBwagaTBnAgEAMGI GCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMwOTTYIEr2OY_2B8xLiAgEQ gDW9L_2B9lkGghNQqrG7K_2BQ36lyXdiSZZEDX3JBsqfhN3ST3LlZ_2FgMDzhuz_2BrcRxStCcFpuhu5Zw_3D_3D&eCode=LEARN#/search?searchTerm=%3Cimg%20src=x%20onerror=alert(document.domain)%3E

After validation to avoid these vulnerabilities, we recommended:

• Properly encode data according to the output context it will be included before appending it to the response markup (HTML) or page DOM – Document Object Model.
• Consider adding/adjusting the Content Security Policy (CSP) to restrict locations where the browser can fetch and execute scripts.

References

• CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site
• A03:2021 – Injection, OWASP Top 10 2021
• Cross Site Scripting Prevention Cheat Sheet, OWASP Cheat Sheet Series
• Testing for Reflected Cross Site Scripting, OWASP Web Security Testing Guide
• Content Security Policy (CSP), Mozilla Developer Network Scripting’)

Timeline

• 23-June-2024 Full findings reported to Gallup’s incident response team
• 25-June-2024 Gallup confirmed receiving the report
• 11-July-2024 vulnerabilities were reviewed and found to be fixed.
  
  

You are a security professional who has been given the task of managing  and mitigating the wide array of vulnerabilities within the open source software your organization uses. In an ideal world, you would have the time, energy, and resources necessary to immediately begin addressing and fixing each and every one of these vulnerabilities immediately – including all the new ones coming in.

However, reality is quite different. No one has all the necessary resources readily at their disposal. The number of vulnerabilities in open source software is insurmountable. The reality is that it would take an unprecedented amount of time, manpower, and financial resources to tackle each and every vulnerability.
 

The only viable solution is to prioritize. So, how do you effectively prioritize your efforts?
Having the right tools in your vulnerability management toolbox is critical. This is where the Exploit Prediction Scoring System (EPSS) comes in.

Understanding EPSS: Enhancing Vulnerability Management

Developed by the Forum of Incident Response and Security Teams (FIRST) [1], EPSS [2] provides a data-driven approach to predicting the likelihood of a vulnerability being exploited in the wild within the next 30 days. By leveraging this industry-recognized standard, organizations can make informed decisions and allocate their limited resources much more efficiently.

At its core, EPSS is a probability score ranging from 0 to 1 (0 to 100%). A higher score indicates a greater likelihood of a vulnerability being exploited. But how is this score calculated, and what factors does it consider?

EPSS considers a wide range of information, including:

• Vendor
• Vulnerability age
• References
• Vulnerability description
• Common Weakness Enumeration (CWE)
• CVSS metrics
• Various exploit lists (e.g., CISA KEV, Google Project Zero, Trend Micro’s Zero Day Initiative)

By analyzing this data[LZ1] [RG2]  and monitoring exploitation activity through various methods, such as honeypots, IDS/IPS sensors, and host-based detection, EPSS provides a nuanced understanding of the urgency and impact of vulnerabilities. It uses machine learning to detect patterns and connections between vulnerability data and exploitation activities gathered over time.

Interpreting EPSS Scores

EPSS data is refreshed daily and offers two key metrics: probability and percentiles.
Probability represents the likelihood of a vulnerability being exploited in the wild within the next 30 days, while the percentile indicates the percentage of vulnerabilities that have a score equal to, or lower than, a particular vulnerability’s score.

For example, an EPSS probability of just 0.10 (10%) rests at about the 88th percentile – meaning that 88% of all CVEs are scored lower. These percentiles are derived from probabilities and offer insights into how a particular EPSS probability compares to all other scores – all the other CVEs.

The figure below shows the probability distribution of EPSS scores for over 170,000 vulnerabilities as of March 2022. It illustrates that most vulnerabilities score below 10%, indicating a global measure of vulnerability exploitation in the wild.

Limitations and Considerations

While EPSS is a powerful tool, it’s essential to understand its limitations and use it in conjunction with other exploitability metrics and threat intelligence. Some key points to keep in mind:

• EPSS scores are founded in gathered data, which means they can change over time which could introduce mistakes.
• If there is evidence that a vulnerability is being actively exploited, that information should supersede EPSS, as EPSS is pre-threat intel, and therefore may lag behind live incidents.
• The model only produces scores based on available data, which is based only on disclosed and known incidents – public availability for information the model itself are acknowledged limitations.
• EPSS is a risk management model – just because a vulnerability has been exploited in the past does not guarantee future exploitation and, conversely, just because a vulnerability has been known for a while and not actively exploited does not guarantee it will not surge soon.

EPSS Score vs. CVSS: Understanding the Difference

EPSS and CVSS (Common Vulnerability Scoring System) are both measures to help organizations manage vulnerabilities, but they serve different purposes.

EPSS aims to predict the likelihood of a vulnerability being exploited, using a forward-looking and probabilistic approach. In contrast, CVSS evaluates the severity of a vulnerability by assessing its characteristics and potential impact, with a descriptive and deterministic approach.

The graph below shows the comparison between CVSS and EPSS scores for a sample of CVEs.

EPSS Value in Prioritizing Remediation and Risk Management

EPSS should be treated as one aspect of the overall vulnerability management picture, complementing other factors like CVSS.

FIRST compares two strategies, one prioritizing CVEs with CVSS 7 and higher, and another prioritizing CVEs with EPSS of 0.1 and higher.

They compared:
Effort – The proportion of vulnerabilities being prioritized for remediation
Efficiency – How efficiently resources were spent by measuring the percent of prioritized vulnerabilities that were exploited.
Coverage – The percent of exploited vulnerabilities that were prioritized, calculated as the number of exploited vulnerabilities prioritized (TP – correctly prioritized) divided by the total number of exploited vulnerabilities (TP + FN – correctly prioritized + incorrectly delayed).

By prioritizing vulnerabilities with an EPSS of 0.1 and higher, organizations can significantly reduce their remediation effort while improving efficiency.

They also analyzed EPSS and CVSS scores to understand their correlation [3]. The analysis showed that attackers do not exclusively target the most impactful or easiest-to-exploit vulnerabilities, challenging the assumption that they only focus on the most severe ones. Therefore, it’s recommended to use a combination of factors to effectively prioritize which vulnerabilities to patch first.

EPSS at Checkmarx

At Checkmarx, we understand the importance of effective vulnerability management. That’s why Checkmarx Customers using the Checkmarx One Platform can leverage the integrated EPSS scores for quicker and more effective risk triaging and remediation.

EPSS complements our existing array of exploitability metrics which include but are not limited to:

• KEV (Known Exploited Vulnerability): A vulnerability cataloged by CISA as a Known Exploited Vulnerability, indicating that it poses a severe and imminent threat.
• POC (Proof of Concept): A Proof of Concept for exploiting the vulnerability is available in the wild, making it easy for threat actors to implement an exploitation of this vulnerability.
• Exploitable Path: This feature analyzes whether your source code provides a path that can be exploited by a specific vulnerability. Checkmarx SCA leverages SAST’s ability to scan the actual project code itself in parallel with scanning the manifest file, validating whether the vulnerable open-source packages are called from your proprietary code and whether the vulnerable methods are used by your code. This enables you to focus on the remediation of actively exploitable vulnerabilities. Exploitable Path also identifies which lines in your project code reach the vulnerable method in the vulnerable package and shows you the full path to the vulnerability.

By combining these tools, our customers can achieve a comprehensive view of their vulnerability landscape and take proactive measures to mitigate risks with high potential to be exploited by malicious actors.

The following displays how EPSS, and other exploitability metrics, are integrated into Checkmarx’ product.
 

 
Conclusion

Staying ahead of current threats requires a proactive and data-driven approach. EPSS offers organizations a valuable tool to prioritize their vulnerability management efforts effectively. By leveraging EPSS alongside other exploitability metrics, security professionals can make informed decisions, allocate resources efficiently, and strengthen their overall security posture.

At Checkmarx, we are committed to providing our customers with the most comprehensive and cutting-edge vulnerability management solutions and empowering organizations to navigate the complex landscape of open-source vulnerabilities with confidence and precision.

References

[1] FIRST: https://www.first.org/
[2] EPSS: https://www.first.org/epss/
[3] EPSS: User Guide, Using EPSS and CVSS Together https://www.first.org/epss/user-guide

Key Points

• Dozens of malicious npm packages mimicking the popular “noblox.js” library have been identified in a campaign dating back to August 2023, with the most recent ones appearing in late August 2024.
• The attackers of this campaign have employed techniques including brandjacking, combosquatting, and starjacking to create a convincing illusion of legitimacy for their malicious packages.
• The malware’s capabilities include Discord token theft, system information harvesting, system persistence, and deployment of additional payloads such as Quasar RAT.
• The malware employs a sophisticated persistence technique by manipulating the Windows registry, causing it to execute every time a user opens the Windows Settings app.
• While the identified malicious packages have been removed from npm, the attacker’s GitHub repository containing malicious executables remains active, posing a potential threat for future attacks.

Malware in Disguise: The Social Engineering Aspect

The attackers have employed a multi-faceted approach to craft an illusion of authenticity around their malicious packages.

One deceptive tactic combines brandjacking and combosquatting—two methods that fall under the broader category of typosquatting. This strategy creates the illusion that their packages are either extensions of or closely related to the legitimate “noblox.js” library.

For example: noblox.js-async, noblox.js-thread, and noblox.js-api.

Since libraries commonly have multiple versions or extensions for specific use cases, mimicking this naming pattern increases the likelihood that developers will install the attackers’ packages, assuming they’re official extensions of “noblox.js.”

Another tactic used is starjacking, a popular method attackers employ to fake their package stats. In this instance, the malicious packages were linked to the GitHub repository URL of the genuine “noblox.js” package. This tactic falsely inflates the perceived popularity and trustworthiness of the malicious packages.

The attackers also used tactics to disguise the malware within the package itself. They meticulously mimicked the structure of the legitimate “noblox.js” but introduced their malicious code in the “postinstall.js” file. They heavily obfuscated this code, even including nonsensical Chinese characters to deter easy analysis.

These combined techniques create a convincing façade of legitimacy, significantly increasing the chances of the malicious packages being installed and executed on developers’ systems. As reported in previous analyses by Socket,  Stacklok and Reversinglabs, these tactics have been consistently employed and refined throughout the year-long campaign.

Attack Flow

The malicious code exploits NPM’s postinstall hook, ensuring automatic execution when the package is installed. This hook, designed for legitimate setup processes, becomes a gateway for running the obfuscated malware without the user’s knowledge or consent.

At first glance, the obfuscated code appears daunting and impenetrable. However, by simply using an online automated JavaScript deobfuscation tool, we were able to gain significant insight into the malicious code’s operation. This initial deobfuscation revealed the general steps the malware takes to achieve its objectives. Yet, the resulting code still contained confusing elements and required additional cleaning to fully comprehend its functionality. This process of incremental deobfuscation and analysis allowed us to piece together the complete attack flow, with its most notable details listed below.

Discord Token Theft

The malware searches for Discord authentication tokens in multiple locations.

The stolen tokens are then validated to ensure only active ones are exfiltrated.

Antivirus Evasion

The malware aggressively undermines the system’s security measures. It first targets Malwarebytes, attempting to stop its service if running. This is followed by a more comprehensive attack on Windows Defender: the script identifies all disk drives and adds them to Windows Defender’s exclusion list. This action effectively blinds Windows Defender to any file on the system. By disabling third-party antivirus and manipulating built-in Windows security, the malware creates an environment where it can operate freely, significantly increasing its potential for damage and persistence.

Additional Payload Deployment

The malware expands its capabilities by downloading two additional executables from the attacker’s GitHub repository. These files, “cmd.exe” and “Client-built.exe”, are fetched using base64-encoded URLs and saved to the “C:\WindowsApi” directory with randomized names. The malware uses a combination of “nodeapi_” prefix and a unique hexadecimal string, likely to help the malicious files blend in with legitimate system files.

Persistence Mechanism

To ensure long-term access, the malware manipulates a Windows registry key to ensure it runs consistently on the infected system.

Specifically, it adds the path of the downloaded “Client-built.exe” to the strategic registry location:

“HKCU\Software\Classes\ms-settings\Shell\Open\command”

By modifying this key, the malware hijacks legitimate Windows functionality. As a result, whenever a user attempts to open the Windows Settings app, the system inadvertently executes the malware instead.

Data Exfiltration

Throughout its execution, the malware collects various types of sensitive information from the infected system. This data is packaged and sent to the attacker’s command and control server using a Discord webhook.

QuasarRAT Deployment

The final stage involves deploying QuasarRAT, a remote access tool that gives the attacker extensive control over the infected system.

The Attacker

The second-stage malware originates from an active GitHub repository: https://github.com/aspdasdksa2/callback. As of this writing, the repository remains accessible and potentially in use for distributing malware through other packages. The repository, owned by user “aspdasdksa2”, contains multiple malicious executables. The repository’s continued existence and its content suggest ongoing malware development and distribution.

Previous malicious npm packages were found to be linked to a different repository of that user for their second stage, but that repository is no longer accessible.

Notably, the attacker maintains a second repository named “noblox-spoof”, which appears to house the latest malicious npm package content, directly referencing the target of this campaign.

The most recent malicious packages impersonating the popular noblox.js library (four packages published by user “bicholassancheck14” – noblox.js-async, noblox.js-threads, noblox.js-thread, and noblox.js-api) have been taken down after we promptly reported them to npm’s security team. While this is a positive development, it’s important to note that the threat is not entirely neutralized.

We strongly advise the developer community to remain vigilant. The attacker’s continued infrastructure presence and persistence pose an ongoing threat. Developers should exercise caution, particularly when working with packages that resemble popular libraries like noblox.js.

Conclusion

This malware campaign, targeting Roblox developers through npm packages, has persisted for over a year. By mimicking the popular “noblox.js” library, attackers published dozens of malicious packages designed to steal sensitive data and compromise systems.

Central to the malware’s effectiveness is its approach to persistence, leveraging the Windows Settings app to ensure sustained access.

The discovery of these malicious NPM packages serves as a stark reminder of the persistent threats facing the developer community. By masquerading as legitimate, helpful libraries, attackers continue to find new ways to exploit trust within the open-source ecosystem.

This campaign underscores the critical importance of thoroughly vetting packages before incorporation into projects. Developers must remain vigilant, verifying the authenticity of packages, especially those resembling popular libraries, to protect themselves and their users from such sophisticated supply chain attacks.

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.

Packages

• noblox.js-async
• noblox.js-thread
• noblox.js-api
• noblox.js-threads

IOC

•  hxxps[:]//github[.]com/aspdasdksa2/callback/raw/main/Client-built.exe
• hxxps[:]//github[.]com/aspdasdksa2/callback/raw/main/cmd.exe
• hxxps[:]//discord[.]com/api/webhooks/1273489016658071624/HWeSPo3qKIbUbqkwiWNoTneHoqo70s5aAYf9NBkAxoICy1SBMezf9ka22Ry59WK1kwYk

By 2029, more than 95% of global organizations will be running containerized applications in production, according to Gartner.  This is a significant increase from less than 50% in 2023. To address these challenges, Checkmarx has developed an innovative container security solution designed to secure your applications from development to deployment.

Let’s explore the real-world impact of our solution and highlight how it helped a leading cloud-based service provider enhance their own container security.

But first…What are containers

Containers are a type of virtualization technology that packages an application and its dependencies together. This allows the application to run consistently across different computing environments, regardless of the underlying operating system.  In simpler terms, imagine a container as a shipping container – it carries everything an application needs to run (code, libraries, settings), but remains isolated from the system it runs on (like the operating system on a server). This isolation ensures portability and security for the application.

While containers provide many benefits, they also introduce unique security challenges. For example, pulling container images from public registries can expose systems to malware and vulnerabilities. Using large base images is like carrying unnecessary baggage—they slow down operations and introduce extra vulnerabilities and limited visibility in managing containerized environments can hide security threats.

Containerization is popular when developing, deploying, and running microservices-based applications.  Microservices are small, independent applications that work together to form a larger application.    Containers are ideal for this because they isolate each service and make them easy to deploy and scale. Because containers offer efficient resource utilization and faster deployment times, it is easier for developers to build, test, and deploy applications rapidly.

Why securing containers is crucial

We know that it’s convenient to pull container images from public registries. Although it saves time, this practice can expose your systems to malware and vulnerabilities, since hackers often upload malicious images to exploit unsuspecting developers. Similarly, sensitive information like passwords or API keys can inadvertently find their way into container registries, leading to data breaches. Managing these secrets is crucial.

Another pitfall is relying solely on static image scanning tools. These tools are great for detecting known vulnerabilities, but often miss emerging threats or misconfigurations. This oversight can leave your containers exposed. The inherent nature of containers increases the attack surface compared to traditional applications. Developers must secure multiple layers, including container runtimes, orchestrators, and plugins, to mitigate these risks effectively.

Adopting minimal base images, updated regularly, can significantly reduce these risks. Limited visibility makes it challenging to detect and respond to issues in real time. Robust visibility and observability tools are essential in gaining deep insights into container workloads and implementing effective threat detection and response strategies.

While containers offer immense benefits, they also require security frameworks. Addressing issues like insecure image sources, exposed secrets, incomplete static scanning, an increased attack surface, bloated base images, and limited visibility can help secure your containerized environments. Staying ahead of threats ensures that you can harness the full potential of containerization without compromising on security.

Introducing our new Container Security solution

Checkmarx provides a new powerful container security solution that enhances team efficiency across the software development lifecycle. It empowers developers and security teams with the following benefits:

Comprehensiveness:  Checkmarx goes beyond static scanning, offering a rich set of features including image scanning, package inspection, vulnerability assessment, triage, remediation, results view, scan risk report, image breakdown, and Sysdig integration for runtime coverage.

Proactive Security: Early vulnerability identification and mitigation within the development process minimizes security risks in production.

Actionable Insights: Checkmarx provides detailed information about vulnerabilities, enabling developers to prioritize remediation efforts and act.

Ease of Use: The solution integrates seamlessly with existing workflows, minimizing disruption to development processes.

Diving into key container security capabilities

Let’s dive into some of our key container security capabilities:

Checkmarx’ container security approach starts with comprehensive image scanning. It examines every layer of an image—base image, software dependencies, and application code—to uncover vulnerabilities and threats. Constant updates to vulnerability databases ensure it identifies the latest threats.

Next, the solution inspects packages within container images. It performs checks like version control to confirm the use of latest secure versions and verifies licenses to avoid potential legal issues.

Finally, it offers detailed image breakdowns. Users can drill down into each layer of a container image to view vulnerabilities and package details. This granular view enables developers to pinpoint andaddress specific security issueseffectively. 

Vulnerability Assessment:  Checkmarx prioritizes vulnerabilities based on severity and provides detailed information about each one. This includes the CVE details, potential impact, and remediation guidance.

Triage:  This allows users to manage the severity, and status, of vulnerabilities for each project or application. They can update severity levels, change status (e.g., Verify, Not Exploitable), and maintain detailed audit trails for all actions taken.

Remediation: Checkmarx identifies vulnerabilities within container images and recommends alternative base images with a lower security risk profile. This approach helps developers choose more secure foundations for their applications.

Results View: This intuitive interface provides a detailed view of container image scan results. Users can see the distribution of vulnerabilities across different severities and analyze them based on runtime status.

Scan Risk Report:  Checkmarx generates comprehensive reports summarizing scan results, including the number of vulnerabilities and their severity. These reports can be downloaded in various formats (JSON, CSV, PDF) for further analysis and compliance purposes.

Final Thoughts

Checkmarx offers a comprehensive container security solution that empowers developers and security teams throughout the development lifecycle. By identifying and mitigating vulnerabilities early, Checkmarx helps organizations build secure and compliant containerized applications. The case study demonstrated how a cloud service provider achieved a significant reduction in vulnerabilities and improved security posture with Checkmarx.

As containerization continues to reshape software development, prioritizing container security is no longer optional. By leveraging solutions like the Checkmarx One Platform, organizations can unlock the full potential of this technology while ensuring the long-term security of their applications and data.

Ready to take the next step?

Visit our website to learn more about Checkmarx’s container security solution and download our free container security Enhancement guide. You can also request a demo to experience the solution firsthand and see how it integrates seamlessly into your development workflow.

Wondering what you should consider when picking a container security solution? These are six things important things you should keep in mind. 

Glossary of terms – Container Security

Attack Surface: The sum of all potential entry points that an attacker can use to gain access to a system. A larger attack surface means more vulnerabilities attackers can exploit.

Base Image: The foundation image upon which a container is built. It typically contains the operating system and essential libraries needed for your application to run. Choosing a minimal base image reduces the attack surface.

Container: A lightweight, self-contained unit of software that packages code and all its dependencies (libraries, configuration files) for deployment and execution. Imagine a shipping container for code, allowing it to run consistently across different environments.

Container Image: A template that defines the contents and configuration of a container. It’s like a blueprint for building a container with specific functionalities.

Container Registry: A repository that stores and manages container images. Developers can pull (download) images to create containers and push (upload) new images they’ve built. Think of it as a library for container images.

Container Security: The practice of protecting containerized applications and the infrastructure they run on from vulnerabilities, malware, and unauthorized access. It’s crucial to ensure the integrity and security of your containerized environment.

DevSecOps: An approach to software development that integrates security considerations throughout the entire development lifecycle (Dev), security operations (Sec), and IT operations (Ops). Container security is a key aspect of DevSecOps.

Exploit: A piece of code or script that takes advantage of a vulnerability to gain unauthorized access or cause harm. Exploiting vulnerabilities in containers can compromise your applications and data.

Runtime: The environment where containers are executed. Container security needs to consider both the security of the image and the runtime environment.

Static Image Scanning: A security analysis technique that examines container images for known vulnerabilities without running the container. It’s like checking the ingredients list of a meal for potential allergens before cooking.

Vulnerability: A weakness or flaw in software that can be exploited by attackers to gain unauthorized access or cause harm. Vulnerabilities in container images or underlying infrastructure pose a risk to container security.

Docker, an open-source platform that automates the deployment of applications in lightweight, portable containers, has impacted application development and deployment since its launch in 2013. Containers bundle an application with its dependencies, ensuring consistent operation across different environments. This addresses the common “it works on my machine” problem, making Docker an essential tool for developers and operations teams. Docker’s rise in popularity is due to its ability to simplify the deployment process, enhance scalability, and improve resource efficiency.

According to Gartner, by 2029, more than 95% of global organizations will be running containerized applications in production, which is a significant increase from less than 50% in 2023 (source: Sysdig 2023 Cloud-Native Security and Usage Report)

The Importance of Security in Containerization

Containers, by their very nature, package not just the application but also its dependencies, which can often include outdated or vulnerable software. Why does that matter? Vulnerable software can lead to a security breach, which could result in customer attrition, as clients might lose confidence in the company’s capacity to secure their information. Ensuring that these containers are free from vulnerabilities is critical to maintaining the integrity and security of the deployed applications. According to Red Hat, State of Kubernetes Security 2023 cloud-native technologies offer agility, faster time to market, and reliability. However, 67% of enterprises face deployment delays due to security concerns. Security incidents can lead to severe impacts, including employee terminations, fines, revenue loss, and eroded customer trust.

According to the same source, in the last 12 months, 66% of enterprises have experienced software supply chain security issues due to the usage of insecure container images
and ”more than 50% of respondents are worried about misconfigurations and vulnerabilities”
Recognizing these challenges, Checkmarx aims to meet developers where they are with our extension – Docker Desktop – which  empowers them to strengthen Docker image security posture early in the development lifecycle and adopt a proactive security approach.

What is Docker Desktop

With over 3.3 million installs, Docker Desktop is one of the most popular software platforms for developers. It allows them  to work locally on their workstations, and provides out-of-the-box containerization technology for building, running, and sharing applications.

This means that developers can build an application on one computer and then run it on another, without having to worry about installing all the dependencies that the application needs. This saves developers time and effort.

Checkmarx Docker Desktop Extension Overview

The Checkmarx Docker Desktop Extension is designed to enhance the security of your Docker images by proactively identifying and mitigating vulnerabilities. This extension integrates seamlessly with Docker Desktop, providing robust features such as comprehensive image scanning, package inspection, and vulnerability assessment.

Let’s dive deeper and understand how the Checkmarx Docker Desktop Extension works

Let’s begin with a common use case.

You want to ensure your container image’s security. In that case, you should utilize a container security engine to scan it for risks.

One you scan, you discover 632 vulnerabilities. Next, you must investigate them, assess their severities, and prioritize fixes accordingly.

You can then investigate the image scan results to upgrade to safer versions, if there are nay available, or look at specific CVEs.

Alternatively, opting for a more secure base image earlier in your development cycle can reduce vulnerabilities and risks. This is where Checkmarx Docker Desktop Extension comes in.

By seamlessly integrating this capability into Docker Desktop, developers can proactively identify and mitigate security issues much earlier, significantly reducing the risk of exposure in production environments.

Once you have assessed the security posture of the image you intend to use, based on the tool recommendation, you can continue to use it or select a different base image with a stronger security posture. In our example, you can see a decrease from 591 vulnerabilities to just two.

The extension uses Checkmarx’ proprietary database and  provides insights and recommendations to protect images from security risks, preserving the integrity of your containerized environments.

The key capabilities of the Checkmarx Docker Desktop Extension include:

1. Free Tool: No cost to use, with additional premium features coming soon.
2. No Checkmarx Account Required: Accessible without needing to sign up.
3. Image Scanning: Scan local images to obtain a detailed breakdown of image layers and identify security risks associated with dependencies
4. Package Inspection: Inspect packages within Docker images to ensure compliance with security best practices (package version, license,…)
5. Vulnerability Assessment: Identify vulnerabilities associated with packages within Docker images. You will find a detailed description of the CVE and its severity.
6. Recommendations and Remediation (Premium Feature): Receive suggestions for fixing vulnerabilities (coming soon).

The Checkmarx Docker Desktop Extension is a significant advancement in container security, empowering developers to strengthen their Docker images and align with industry best practices. With the integration of security into the development workflow, our extension enables developers to build and deploy secure containerized applications with confidence.

The Checkmarx Docker Desktop Extension is an important tool for developers and DevOps  professionals. By providing detailed insights into vulnerabilities along with offering robust scanning and inspection features, this extension helps maintain the integrity and security of containerized environments.

Install Checkmarx Docker Desktop Extension: Link to download.
You can find the detailed documentation here.

A malicious campaign involving several python packages, most notably the “spl-types” Python package began on June 25th with the upload of an innocuous package to PyPI. This initial version, devoid of malicious content, was intended to establish credibility and avoid immediate detection. It was a wolf in sheep’s clothing, waiting for the right moment to reveal its true nature. The attacker’s patience paid off on July 3rd when they unleashed multiple malicious versions of the package. The heart of the malware was in the init.py file, obfuscated to evade casual inspection. Upon installation, this code would execute automatically, setting in motion a chain of events designed to compromise and control the victim’s systems, while also exfiltrating their data and draining their crypto wallets.

Key Findings

• Multiple malicious Python packages were uploaded to PyPI, targeting cryptocurrency users involved with Raydium and Solana.
• The attacker exploited StackExchange as their primary vector to direct people to their malicious package. They posted a seemingly helpful answer on a popular thread that referenced their malicious package, leveraging trust in community-driven platforms.
• The multi-stage malware exfiltrated extensive sensitive data and facilitated the draining of victims’ crypto wallets
• Windows Virus and Threat Protection failed to detect the active malware on a victim’s system, providing a real-world validation of our previous research demonstrating that modern EDR systems are ineffective against threats from malicious packages.
• A backdoor component in the malware granted the attacker persistent remote access to victims’ systems, enabling potential future exploits and long-term compromises.

A Multi-Stage Assault

The initial payload acted as a springboard, reaching out to external resources to download and execute additional malicious scripts. These scripts formed the core of the operation, and meticulously scanned the victim’s system for valuable data. The malware cast a wide net, targeting an array of sensitive information – browser data was readily available, as the malware harvested saved passwords, cookies, browsing history, and even stored credit card information. Cryptocurrency wallets, including popular options like Exodus, Electrum, and Monero, were also prime targets. The attack didn’t stop there; it also sought out data from messaging applications such as Telegram, Signal, and Session. In a particularly invasive move, the malware captured screenshots of the victim’s system, providing the attacker with a visual snapshot of the user’s activities. It also scoured the system for files containing specific keywords related to cryptocurrencies and other sensitive information, including GitHub recovery codes and BitLocker keys. The final part of this digital heist involved compressing the stolen data and exfiltrating it to the attacker’s command and control server via several Telegram bots.

Also included in the malicious scripts was a backdoor that granted the attacker remote control over the victim’s system, allowing for ongoing access and potential future exploits.

One of the attacker’s telegram bots receiving screenshots and data from victims machines.

Profiling the Victims & Motives behind the attack

As we continued to follow this attack, a clear pattern emerged around the victims. What united them was not their profession or location, but their involvement with Raydium and Solana, two prominent players in the cryptocurrency space. This commonality suggests that the attacker had a specific target in mind.

The focus on users of these platforms indicates a level of strategic thinking on the part of the attacker. By targeting this specific group, they positioned themselves to potentially intercept or manipulate high-value transactions, pointing to clear financial motives behind the attack.

Delivery Strategy of the Malware

The attacker was strategic when thinking about how to deliver the malicious package to unsuspecting victims. Their approach was twofold: create a seemingly legitimate package and then lending it credibility through manipulative online engagement.

Step 1: Crafting a Deceptive Package

The first step involved creating a package that would raise minimal suspicion.

In screenshots from compromised systems, we observed victims using, or installing, a package named “Raydium”.

It’s crucial to note that while Raydium is a legitimate blockchain-related platform (an Automated Market Maker (AMM) and liquidity provider built on the Solana blockchain for the Serum Decentralized Exchange (DEX)), it does not have an official Python library.

Exploiting this gap, the attacker, used a separate username to publish a Python package named “Raydium” on PyPI.

The malicious packages of this campaign were dependencies within other seemingly legitimate packages.

This package included the malicious “spl-types” as a dependency, effectively disguising the threat within a seemingly relevant and legitimate package.

Step 2: Building Credibility and Ensuring Adoption

To lend credibility to this package and ensure its widespread adoption, the attacker scoured StackExchange, a popular Q&A platform similar to Stack Overflow, for highly viewed threads related to Raydium and Solana development. Upon identifying a suitable and popular thread, the attacker contributed what seemed to be a high-quality, detailed answer. This response, while ostensibly helpful, included references to their malicious “Raydium” package. By choosing a thread with high visibility—garnering thousands of views—the attacker maximized their potential reach.

Developers seeking solutions to Raydium-related questions would likely view the answer as credible and follow the suggestions with minimal suspicion.

This tactic underscores the importance of verifying the authenticity of packages, especially those recommended in forums by unknown individuals.

Case Studies and the personal impact

The impact of this attack goes beyond theory. Behind each compromised system is a real person, and their stories reveal the true cost of such breaches. There were many cases, but in this blog, let’s look at a couple notable ones that highlight different aspects of this attack:

Case Study 1

In one of the malware-captured screenshots, we observed clear personal details of a victim. Cross-referencing this information with LinkedIn allowed us to identify the individual, who happened to also be employed at a respected IT company. This discovery prompted us to take the step of reaching out to warn them about the breach. During our subsequent communication, we learned the victim’s entire Solana crypto wallet had been drained shortly after unknowingly downloading the malicious package. This case vividly illustrates how such attacks can have immediate and severe financial consequences for individuals.

Case Study 2

Bottom left: Screenshot of the victim’s screen. Top right: Windows Defender scan declaring in Dutch that the system is clear of threats after the scan. Top left: victim’s private key.

Another victim’s experience highlighted a critical weakness in current cybersecurity practices. A screenshot from their system showed a private key clearly visible – a goldmine for any attacker since these keys bypass any password or multi factor authentication active on the account that the private key is for.

In addition to that, and what made this image particularly alarming, was the Windows Virus and Threat Protection screen displayed alongside it, declaring that a scan had just been completed and that the system was clear of threats.

The revelation that Windows Virus and Threat Protection failed to detect the threat during active data exfiltration is particularly concerning. It emphasizes a critical blind spot in traditional security measures when it comes to malicious activities initiated through package managers. This failure of detection occurred not just before or after the attack, but during the very moment the malware was active and stealing data.

This incident provides a real-world example of how Endpoint Detection and Response (EDR) systems can fall short in stopping malicious package activity or sending relevant alerts.

Moreover, even if the malicious package is later taken down from the repository and not publicly declared as malicious, EDR systems typically won’t flag the package as vulnerable if it remains installed on a user’s system. This leaves users potentially exposed to ongoing threats from previously downloaded malicious packages.

PyPi for example, to this day, completely eliminates all traces of a package, leaving no placeholders behind. Although malicious usernames often remain, they appear without any associated malicious packages. Consequently, anyone who encounters these malicious usernames may be unaware of the user’s history of uploading malicious packages.

 Just recently, we published a POC on the blind spots of current EDR solutions.

Attack Timeline

Conclusion

The “spl-types” malware incident is more than just another data breach. It serves as a stark reminder of the cost of cybersecurity failures and the ongoing challenges we face in securing the software supply chain.

This incident’s impact extends beyond individual users to enterprises. A single compromised developer can inadvertently introduce vulnerabilities into an entire company’s software ecosystem, potentially affecting the whole corporate network.

This attack serves as a wake-up call for both individuals and organizations to reassess their security strategies. Relying solely on traditional security measures is not sufficient. A more comprehensive approach is needed, one that includes rigorous vetting of third-party packages, continuous monitoring of development environments, and fostering a culture of security awareness among developers.

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.

The fight against such sophisticated threats is ongoing, and as we gather more insights into the attacker’s methods and infrastructure, we will continue to share our findings with the community. Together, we can work towards a safer digital future for all.

Packages

• spl-types
• raydium
• sol-structs
• raydium-sdk
• sol-instruct

IOC

• Hxxps[:]//ipfs.io/ipfs/QmQcn1grVAFSazs31pJAcQUjdwVQUY9TtZFHgggFBN6wYQ
• hxxps[:]//rentry[.]co/7hnvbc6n/raw
• hxxps[:]//api.telegram[.]org/bot6875598996:AAGATybCyN73i3als0VRGlP8cILsFjKf4ao/sendDocument?chat_id=7069869729
• 147[.]45[.]44[.]114
• hxxps[:]//api[.]telegram[.]org/bot7265790107:AAE9XT3b23WyBHq-0fw5BwW5U7wzYNZT3cc/sendDocument?chat_id=7069869729
• hxxps[:]//rentry[.]co/foyntbdk/raw
• hxxps[:]//api.telegram[.]org/bot7265790107:AAE9XT3b23WyBHq-0fw5BwW5U7wzYNZT3cc/sendPhoto?chat_id=7069869729
• hxxps[:]//rentry[.]co/xcsshmno/raw
• hxxps[:]//rentry[.]co/2p7kv9d8/raw

In March 2023, the White House published the National Cybersecurity Strategy. In July, the White House followed that up with the National Cybersecurity Strategy Implementation Plan.

As we wrote in a blog post earlier this year:

“With the introduction of the National Cybersecurity Strategy earlier this year, the US Government has started to use its influence and buying power to alter the behavior of all software producers. The US Government is the world’s largest consumer of IT products and services in dollars. It appears they will be using that buying power to add additional cybersecurity requirements for all software purchased. Companies will be faced with the options of changing their behavior or walking away from selling to the federal government.

The National Cybersecurity Strategy makes the case that there must be a shift of the burden for cybersecurity from the consumers of software to the producers of software. One of the requirements they are implementing is that all software vendors attest that they developed their software in accordance with NIST 800-218, the Secure Software Development Framework, or SSDF.”

Companies providing software to government customers need to certify that their development process meets certain standards known as the Secure Software Development Framework (SSDF).

The Secure Software Development Framework (SSDF) is composed of “fundamental, sound, and secure recommended practices based on established secure software development practice documents” and organized into four groups:

• Prepare the Organization (PO): Ensure that people, processes, and technology are prepared to perform secure software development at the organization level.
• Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
• Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
• Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar ones in the future.

What CEOs Need to Do Right Now

1. Understand the Requirements: Familiarize yourself with NIST 800-218 and the SSDF.
2. Designate a Responsible Leader: Assign a high-level leader, such as the CISO, to oversee SSDF compliance.
3. Conduct an Internal Audit: Ensure your software development lifecycle (SDLC) aligns with SSDF practices.
4. Leverage Tools: Use tools like Checkmarx One and Codebashing to meet SSDF standards.
5. Sign the Attestation Form: Verify the security practices and sign the Secure Software Development Attestation Form.

Taking these steps will help secure your software development processes and maintain your business relationship with the federal government.

What NIST 800-218 Requires

NIST 800-218 is not strictly a compliance requirement but rather a set of best practices. The Secure Software Development Framework (SSDF) Is a core set of high-level secure software development practices that can be integrated into each SDLC implementation.

So, it isn’t a compliance framework—it’s a set of principles that should be followed. This is an important distinction since Checkmarx supports the implementation of many of those practices.

Why Now?

On March 11th, the Cybersecurity and Infrastructure Security Agency (CISA) released a critical form—the Secure Software Development Attestation Form. This stems from government mandates (OMB memorandums M-22-18 and M-23-16) aiming to improve software security for government use.

The form requires a signature from a high-level leader within your software company, potentially the CEO. The deadline is coming up fast!

Submitting false information is a crime. Simply checking “yes” to all questions without truly adhering to secure development is a risky strategy.

This is the opportunity for CEOs to verify with their teams if they are managing their SDLC securely and maturing their security practices.

The Attestation Form has a short list of basic software security requirements which are a small subset of the NIST Secure Software Development Framework (SSDF). It has examples for each task to simplify the requirements, which are sometimes less straightforward for CEOs.

CEOs and CISOs should audit their requirements, replacing the examples in the Attestation Form with their own material.

This form signifies a growing focus on secure software development within the government sector. Understanding these requirements and taking them seriously is crucial for companies doing business with the American federal government.

According to the press release from CISA, this is “a critical step towards ensuring software producers who work with Government provide securely developed products” and “furthers the President’s National Cybersecurity Strategy, which made clear that the “most capable and best-positioned actors in cyberspace must be better stewards of the digital ecosystem.””

How Checkmarx One Can Help Achieve Compliance

Checkmarx products and services help organizations meet the requirements of the SSDF.

Checkmarx’s Assessment and Advisory services, in particular the APMA framework, can help identify gaps and create an actionable workplan to improve your AppSec program.

We have mapped where specific requirements of NIST 800-218 align with the APMA framework, so you can be confident that your AppSec program meets the SSDF standards. The practices are implemented through a combination of tools such as Checkmarx One, in conjunction with the relevant processes and procedures being put into place.

We previously laid out which of these requirements are supported by Checkmarx.

Checkmarx One supports many of these regulations with a comprehensive AppSec platform that provides differentiated users and roles, full records and audits of activities, and comprehensive security controls across the entire SDLC—from SAST and SCA to API Security, Container Security, Infrastructure as Code, and more.

Here are just a few examples of how Checkmarx helps organizations meet SSDF’s requirements:

• PO.2.2: Role-based training for personnel with responsibilities that contribute to secure development. Checkmarx Codebashing directly supports PO.2.2 by offering developers constantly updated secure code training.
• PS.3.2: Collecting, safeguarding, maintenance, and sharing of data for all components in each software release, such as in a software bill of materials (SBOM). Checkmarx supports this with Checkmarx SBOM, designed to meet these compliance challenges head-on and provide an automated and efficient solution for generating and maintaining SBOMs.
• PW.5: Source code adherence to secure coding practices. Checkmarx SAST can automatically scan your application’s source code, identify vulnerabilities, and even automatically remediate it at a click of a button. Developers can get real-time feedback on their code to ensure it meets secure coding practices.

If you have any questions or would like to have a deeper discussion on implementation in support of SSDF, please contact us.

In this blog, I’ll discuss the concept of Infrastructure as Code (IaC) and its security implications. We’ll explore the common security challenges faced by organizations implementing IaC and discuss strategies for securing their infrastructure through IaC security measures.

What is Infrastructure as Code (IaC) Security

IaC manages the configuration of cloud infrastructure through automated code, ensuring consistency when deploying applications. Tools like Terraform and CloudFormation automate tasks, simplifying configuration and deployment. IaC security focuses on addressing vulnerabilities and misconfigurations in code-based provisioning (with IaC templates) to prevent security breaches from compromising data integrity.

Types of IaC: Declarative vs. Imperative Approaches

Two main approaches govern IaC implementation: declarative and imperative. Declarative IaC defines the desired system state, without detailing the steps to achieve it, while the system handles the process of achieving and maintaining the desired state. An example of a declarative tool is Terraform. Imperative IaC specifies the commands required to achieve the desired configuration. For example, AWS SDK. Each approach presents its unique security challenges, underscoring the need for security measures throughout the development and deployment process.

Example of Declarative IaC using terraform

terraform {version = “0.11.13”}

provider “aws” {

  region = “eu-central-1”

}

resource “aws_s3_bucket” “your_new_bucket” {

  bucket = “my-first-website-cloud-native-website”

  acl    = “public-read”

  website {

    index_document = “index.html”

  }

}

Example of imperative IaC

Simple line of code to create an S3 bucket with the AWS CLI tool
aws s3api create-bucket –bucket my-first-website-cloud-native-website –region eu-central-1

IaC: Challenges

1. The declarative approach: The declarative approach must know whether the infrastructure already exists, to know whether to create it or not. One of the biggest challenges is the loss of control over individual provisioning steps, this approach is less suitable for small fixes, potentially complicating and slowing down processes.

2. The imperative approach: The imperative approach has no idea if the infrastructure exists. The imperative example also cannot be easily re-run and doesn’t include the ability to update or delete.The most significant challenge introduced by this approach is the need for advanced programming skills, specifically for teams new to DevOps. Due to the explicitness of the imperative approach, scripts are less editable and that results in less flexibility due to a varied outcome across environments. Errors in one step can disrupt the entire process.

3. Credential/Secret Disclosure: Sensitive information, like access keys, may be mistakenly hardcoded and wind up in version control systems, risking exposure. This occurs when sensitive information such as passwords, API keys, or other types of credentials are inadvertently exposed in plain text within code repositories or configuration files. Such exposure could result in data loss, financial liabilities, or even reputational damage to the organization.

4. Misconfiguration: Misconfigurations in IaC templates pose a serious security threat. Misconfigurations that can lead to exploitable vulnerabilities include improper access controls, overly permissive networks, and insecure storage settings. These challenges are compounded by the imperative approach, which demands advanced programming skills and lacks flexibility which can lead to unauthorized data access, service interruptions, or data breaches.

5. Elevated Privileges: IaC automation often relies on high-privilege identities, making them lucrative targets for attackers for example granting overly permissive permissions to a service account or user role, allowing it to access sensitive resources or perform actions beyond its intended scope, which can lead to security breaches or data leaks.

6. CI/CD Infrastructure: CI/CD systems, vital for deploying IaC changes, face security risks such as weak authentication and authorization. Without proper access controls, unauthorized users may access sensitive resources or execute malicious actions, causing security breaches or deployment disruptions.

Securing IaC: Best Practices

1. Declarative programming is the favored method in IaC, it defines the desired end-state, ensuring repeatable execution and adaptability to configuration drift, unlike the imperative programming method that requires scripting expertise, as it needs commands for each provisioning step, offering precise control for fine-tuning, optimization, and addressing software specific needs.
2. IaC template Analysis: IaC template analysis tooling involves leveraging application security testing tools specifically designed to scan IaC source code for potential security vulnerabilities – including sensitive values such as passwords, API keys, or other credentials. These tools utilize static analysis techniques to parse through the codebase, identifying patterns or syntax that indicate the presence of sensitive information. For example, they may look for strings that match known patterns of API keys or AWS access keys within Terraform or CloudFormation templates. By flagging these instances during the scanning process, developers and security teams can promptly address and remediate such exposures before they lead to security incidents.
3. Policy Engine: A policy engine within the context of IaCin volves implementing a robust set of granular policies that dictate the configuration and behavior of cloud resources provisioned through code. These policies are typically defined based on security best practices, compliance requirements, and organizational standards. The policy engine acts as a centralized control mechanism, allowing administrators to enforce rules and constraints on various aspects of cloud infrastructure provisioning, such as network configurations, access controls, encryption settings, and resource tagging. For example, policies may specify that all storage buckets must be encrypted at rest. By implementing policy-based controls, organizations can reduce the risk of misconfigurations and unauthorized access.
4. Securing CI/CD Pipeline: Securing the Continuous Integration/Continuous Deployment (CI/CD) pipeline involves implementing a multi-faceted approach to protect the entire workflow from potential security threats. Role-based access controls (RBAC) are essential for ensuring that only authorized individuals have permission to view, modify, or execute pipeline tasks. Additionally, isolating the CI/CD infrastructure from other systems and environments helps mitigate the risk of unauthorized access or tampering. Securing the CI/CD pipeline requires a combination of proactive measures, including RBAC, infrastructure isolation, and continuous monitoring, to safeguard the integrity and reliability of the software delivery process.
5. Credential and Secret Management: Securing credentials and secrets is critical when implementing Infrastructure as Code (IaC). Organizations must implement processes and tools to prevent exposure of sensitive information in version control systems and other repositories. This means using secure storage methods like encrypted key vaults or reliable credential management systems to protect this information from unauthorized access. Using environment-specific config files can also help reduce the chance of accidental exposure by keeping sensitive data separate from the IaC templates. Regular audits and automated scans are essential for promptly spotting and fixing any instances of exposed credentials.
6. Misconfigurations: To address this challenge, organizations must implement rigorous validation processes and automated checks to ensure that IaC templates adhere to security best practices. Additionally, leveraging infrastructure security scanning tools can help identify and remediate misconfigurations before they are deployed into production environments. Embracing the declarative programming approach has its advantages as well, by defining the desired end-state and automated provisioning, it inherently reduces the likelihood of misconfigurations by minimizing manual intervention and human errors, providing a proactive solution to the misconfiguration challenge.

Our Approach to IaC Security

Checkmarx provides a comprehensive IaC security solution that is integrated into the Checkmarx One platform correlating data from the entire software development life cycle (SDLC). This enables the platform to prioritize risks based on context from the different security engines, providing developers with actionable insights and allowing them to focus on addressing critical vulnerabilities efficiently.

1. IaC template code Analysis: Checkmarx’s IaC Template analysis tool integrates with the developers’ environment to automatically scan IaC templates for vulnerabilities and misconfigurations, providing actionable insights to developers and security teams. By identifying security issues early in the coding stage of the development lifecycle, organizations can proactively mitigate risks and ensure the integrity of their infrastructure.
2. Policy Enforcement: Checkmarx enables organizations to enforce preventive security policies and stop the build process at the coding stage preventing vulnerable or misconfigured code from making it into production ensuring compliance with industry regulations and internal security standards. Customizable policies allow organizations to tailor their security controls to meet their specific requirements and mitigate potential threats effectively.
3. Seamless Integration: Checkmarx seamlessly integrates into existing workflows, ensuring minimal disruption to development processes. Its compatibility with popular IDEs enables developers to manually scan templates during development, while CI/CD integrations automate scans later in the process. This streamlined approach ensures security checks occur at every stage of the development lifecycle, enhancing overall security posture.
4. Education and Training: Education and Training: Checkmarx provides educational resources and training programs to help organizations build and maintain a strong security culture. By educating developers and security professionals on best practices for IaC security, Checkmarx empowers organizations to proactively address security challenges and protect their cloud environments effectively.

Final Thoughts

As organizations embrace Infrastructure as Code, prioritizing security becomes imperative to prevent potential vulnerabilities and misconfigurations. With Checkmarx, organizations can embark on their IaC journey with confidence, knowing that their infrastructure remains protected against potential threats. Infrastructure as Code security is not a choice; it’s a strategic imperative. By embracing a proactive approach to security and leveraging cutting-edge solutions like Checkmarx, organizations can unlock the full potential of IaC while protecting their assets against threats.