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

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

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.

• Widespread Malware Distribution on GitHub: Recent discoveries, including Apiiro’s report on over 100,000 infected GitHub repositories, highlight a growing trend of using GitHub for malicious purposes.
• Diverse Attack Methods: GitHub-based cyber threats employ various sophisticated strategies, including attacks on legitimate repos, social engineering, and exploiting GitHub actions. This variety in attack vectors signifies the adaptability and ingenuity of cyber attackers in exploiting GitHub’s functionalities.
• Critical Role of Continuous Monitoring in Cybersecurity: The evolving nature of threats on platforms like GitHub underscores the imperative for robust, continuous monitoring solutions.
• Checkmarx’s Proactive Defense Against Supply Chain Cyber Threats: Checkmarx’s Supply Chain Security solution vigilantly monitors malicious activities, swiftly identifying and alerting on suspicious actions in the open source ecosystem to effectively counteract these cyber threats.

Malicious Repo Confusion Campaign

In light of a recent blog released by Apiiro, the cybersecurity landscape is yet again reminded of the innovative ways attackers exploit platforms like GitHub to host and spread malware. Apiiro’s findings reveal a large-scale malicious repo confusion campaign impacting over 100,000 GitHub repositories, shedding light on the evolving tactics of cybercriminals. Interestingly, part of the attackers’ strategy involved creating fake forks to make their repositories seem legitimate, a tactic we have discussed extensively in relation to repository spoofing.

The attacker took the following steps: they first cloned existing repos and infected them with malware loaders. Next, they uploaded them back to GitHub under identical names, automatically forking each one thousands of times. Finally, they covertly promoted them across the web via forums, discord, etc.

This is not an isolated case. The use of GitHub for malicious purposes has been a recurring theme, as evidenced by several incidents in the past.

Attacks on Legitimate Repos

A notable method of exploiting GitHub involves attacking legitimate repos. A prime example is an incident in mid-2023where attackers, leveraging stolen GitHub personal access tokens, impersonated Dependabot, a well-known dependency update helper tool. These tokens bypassed two-factor authentication, allowing malicious code to be committed under the guise of Dependabot. This code aimed to extract sensitive information and inject malware into JavaScript files.

Nation-State Social Engineering Using GitHub

Another tactic is the use of social engineering. In contrast to the scrutiny typically given to public open-source repositories, GitHub’s private repositories provide a more concealed avenue for attackers. A recent discoveryrevealed how North Korean state actors were using these malicious repos to then integrate into software through social engineering, targeting specific organizations or individuals.

Attacking GitHub Actions for Public Repos

In mid-2023, GitHub user account, pastramahodu, forked nearly 2,000 repositories, with 319,191 total stars combined, as part of a widespread bug bounty hunt attempt for finding misconfigurations in popular project’s CI pipelines. The procedure was most likely automated and created Pull Requests which in some projects triggered the project’s CI pipeline and executed the custom commands. This highlighted the increasing focus on pipeline security as an entry point for supply chain attacks.

Conclusion

The recurring theme across these examples is clear: GitHub, a platform integral to the development community, has become a focal point for cybercriminals looking to exploit the software supply chain. The sophistication and variety of these attacks demonstrate the evolving and persistent nature of these threats. As part of the Checkmarx Supply Chain Security solution, we continuously monitor and detect suspicious activities in the open-source software ecosystem, such as these. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. In the face of these sophisticated attacks, it is more important than ever for developers and organizations to stay alert, regularly review code sources, even from trusted platforms like GitHub, and implement robust security measures.

Let’s take a look back at the highlights from the past 365 day.

Application Risk Management powered by Fusion 2.0 

The biggest challenge in security, and specifically application security, today, is the noise. Also known as “alert fatigue” or simply, “I have too many vulnerabilities – where do I start??” Development teams can get overwhelmed with the number of alerts they get, and often don’t have the ability to quickly discern which ones are the most critical. Enterprises already ship vulnerable code to production, so the challenge isn’t about fixing everything, it’s fixing what matters most to the business. 

We launched Application Risk Management as an answer to exactly that. Powered by Fusion 2.0, it allows enterprises to get a prioritized list of vulnerabilities, so they know where to start remediating. It also provides a risk indicator per application, so management will be able to assess and manage the risk of each application.

Codebashing 2.0 with Security Champions

Over the last couple of years we have truly seen how valuable developers are to effective application security. One way to help drive adoption across enterprises, is a security champion program that includes a robust education on security specifically for developers. Codebashing 2.0 was built with developers in mind. It brings a fresh look and feel, packaged with gamifications to help drive the competitive nature of developers, and the ability to train and certify anyone in the organization as a certified security champion.

CheckAI

With the introduction of ChatGPT in early 2023, everyone has been talking about GenAI. Developers use it to generate code, designers use it to create new graphics and my mother use it to get travel recommendations. It’s truly life-changing technology. As with many ground-breaking technologies, the risks are yet to be fully realized. As GenAI solutions started to rapidly spread through the industry, we started to see new types of attacks that utilize GenAI: everything from prompt injections to hallucinations to malicious LLMs. This is why we introduced, CheckAI, the industry first and only GPT plugin to scan GenAI generated code and protect against an AI hallucination attack. And we are just getting started here! Expect much more in 2024. 

A new supply-chain module in Checkmarx One

Checkmarx was the first vendor to include malicious detection as part of our SCA solution in 2022. Checkmarx now has the largest malicious packages database in the market, with over 8 million analyzed packages and over 250K malicious packages identified. However, the software supply-chain has much more to pay attention to than just malicious packages. Protecting the entire software supply-chain includes everything in your development process. From your CI/CD plugins and configurations, your compilers and, yes, your open source packages. As part of Checkmarx One 3.0, we introduced a new dedicated module to the wider software supply-chain. Our goal is to help enterprises protect their entire software supply-chain. We introduced 2 new engines: enterprise secrets detection (which utilizes 2MS) and repo health (which utilizes the OSSF Scorecard) and we will continue to add more coverage throughout 2024.

Checkmarx One 3.0

 Probably the biggest launch of the year for us – Checkmarx One 3.0, marks 2 years of investment into our Checkmarx One platform. With close to 500 enterprise customers already using it, and over a 100B LOC which are being scanned every month, it’s the enterprise application security platform every enterprise needs. With over 660 new capabilities introduces in 2023, 8 solutions already on the platform, it was really a remarkable release. In the launch we had over 1500 registrants, which broadcasted around the globe to our customers, prospects, partners and analysts. 

Stay tuned to what is yet to come in 2024 and in version 4.0!

Today, Checkmarx SAST provides tremendous flexibility  to scan applications based on how they are built. This is done using two constructs:

• Queries: essentially a rule that identifies a potential vulnerability. 
• Presets: a collection of queries optimized for a specific type of application (for example, a mobile app) that defines the scope of the SAST scan. We’ve written elsewhere about working with presets. 

Queries are building blocks for identifying potential vulnerabilities and critical for filtering through the noise to avoid sending false positives and false negatives to your developers. Understanding queries enables AppSec teams and developers to prioritize your efforts, and promptly address the most critical issues.  

Checkmarx SAST includes pre-built queries (and presets) written in the Checkmarx Query Language (CxQL). These identify common security issues such as SQL injection, cross-site scripting, and insecure access controls and provide an easy way to start securing applications out of the box.  

Customizing queries for your unique applications 

Checkmarx is the only solution in the market that allows for queries to be customized – either by creating new custom queries or customizing existing queries.  

Custom queries provide a uniquely flexible and powerful mechanism to tailor your SAST tool solution to specific application requirements. They provide the freedom to explore unique or specific code structures that pre-built rules may not cover adequately.  

For example, as we wrote in an earlier post: 

A common use case that neatly highlights the benefits of customizing queries can be found in cross-site scripting (XSS) vulnerability findings where a false positive may be occurring due to the use of an in-house sanitizer method that is not included in the Checkmarx One default out-of-the-box query. We can simply add this method to the appropriate CxQL query and rescan the project to remove the FP. 

AI enters the room 

Unless you’ve been living under a rock, you’ve probably heard about AI and the impact that it’s having across every industry. In tech, many developers have embraced AI and are already using AI to generate their code. But even more so, according to a recent IDC survey(1) , developers believe that software quality and testing (22.5%) and security testing and vulnerability management (21.5%) have the most potential to benefit from Generative AI. 

Making custom queries more accessible with AI 

Today, Checkmarx introduced AI Query Builder for SAST. This feature lets Checkmarx One users harness the power of AI to automatically generate new custom queries or modify existing ones. AI Query Builder builds on the custom query capability, allowing AI to help any AppSec team write new or edit existing custom queries. This allows every organization to tune SAST more easily for your applications, increasing accuracy and minimizing false positives and false negatives. 

AI Query Builder is an expert in the ins and outs of CxQL. You no longer need to be an expert in building a query when an AI can do the work for you! With this feature, a simple prompt such as, “Help me generate a Checkmarx query that will detect an authentication issue,” will immediately generate a new custom query.  

Benefits of AI-Generated Custom Queries 

 Some benefits of using artificial intelligence to generate custom queries include: 

• Comprehensive coverage: AI Query Builder can use existing public SAST documentation and security best practices to generate custom queries that cover a broader range of potential vulnerabilities. This reduces the risk of making mistakes or missing critical issues. 
• Enhanced efficiency: Save time and effort – instead of manually crafting queries, AppSec managers and developers can engage with AI Query Builder to generate tailored queries, reducing time spent on query development. 
• Fewer false positives: False positives are always a challenge for any AppSec solution, but AI-generated custom queries can improve accuracy and reduce false positives.  

• Everyone can use it : No longer are custom queries reserved for power users, but now every Checkmarx One user can now better tune their SAST solution using AI.  

Try it yourself.  

Interested in seeing for yourself?  

Join the Checkmarx Early Access program.  

We’re just beginning. Check in next week when we’ll have a new blog post taking us through AI Query Builder for IaC Security. 

(1) Source: IDC, Generative AI Adoption and Attitudes: A Survey of U.S. Developers, Doc #US50655123, May 2023 

Checkmarx Security Research team reached out to Ericsson’s Responsible Disclosure Program, notifying them of the the finding on 14th March 2023. Ericsson acknowledged the finding and replied  that the issue was fixed on 11th April 2023. 

ASP.NET web applications that run with tracing enabled, may publicly expose sensitive information. This feature allows any user to view diagnostic information about a single request for an ASP.NET page. When this feature is enabled,  Trace Viewer (Trace.axd) may be publicly accessible, without server’s root authentication. The Checkmarx Security Research team discovered this vulnerability and will explore what that means for users in this post.   

This research was conducted following Ericsson Vulnerability Disclosure Program. 

One of Ericsson’s subdomains is forecast.ericsson.net. However, when accessing it via a web browser it redirects to https:// forecast.ericsson.net /Login /Login. aspx. No complex reconnaissance process was required to understand that we were dealing with an ASP.NET web application. 

There are several, well-known endpoints/resources of interest to check for when dealing ASP.NET web applications, and  – /Trace.axd is one of them.  Trace.axd is a web-page that is intended to provide extensive logging information in regard to  web requests to the application. – If this is exposed, it may provide attackers unauthenticated access to the last 80 web requests made to the server. This has the potential to result in a  sensitive information, such as PII data, and session details being disclosed. This information may  then be used to potentially take over user accounts, and further compromise Ericsson’s applications. 

After finding Trace Viewer (Trace.axd) on our target subdomain (https://forecast.ericsson.net/Trace.axd), we checked what information was available. 

The picture above shows the Trace Viewer main page (Trace.axd), which is where the physical directory of the web application (E:webrootsSupplyExtranet) and the last requested web application files are printed (Supply/ChangePassword.aspx). 

As you can see, it is  possible to view additional details for each request. This potentially can allow malicious actors  access to sensitive information. The body of POST requests, especially those to the Login/Login.aspx endpoint, are good candidates to monitor for disclosure sensitive information,  including usernames and passwords. We can see    this scenario, where user account credentials, username and password, are both shown in plaintext in the figure below. 

Information disclosure via Trace Viewer (Trace.axd) for ASP.NET web applications is a high severity security issue that can lead to the compromise of sensitive information and online systems. This feature should not be enabled in production environments. 

Intro 

In the evolving world of cybersecurity, attackers are always looking for new ways to exploit weaknesses and compromise systems. Attackers have been using lowercase letters in package names on the Node Package Manager (NPM) registry for potential malicious package impersonation. This deceptive tactic presents a dangerous twist on a well-known attack method — “Typosquatting.” In this blog post, we will explore the origins of this issue, the risks it poses, and the steps that were taken to address it while also examining its relationship to Typosquatting. 

A Brief History of Package Naming in NPM 

Prior to 2017 NPM package creators were allowed to use both upper and lowercase letters in their package names. However, in 2017, NPM changed its policy, and new packages could only be created with lowercase letters. Despite this change, existing packages with mixed-case names were allowed to remain on the registry and are still in use to this day. In fact, there are thousands of mixed-case packages still available, collectively accounting for tens of millions of downloads. 

The Impersonation Threat 

Bad actors can easily exploit this situation by uploading packages with names that closely resemble legitimate packages, simply by using lowercase letters to mimic uppercase letters in the original package names. This tactic is intended to trick users into downloading, and installing, the malicious package instead of the intended legitimate one. 

For instance, consider these two packages: 

Legitimate package 

Removed for security reasons 

The only difference between the two package names is the capitalization of the “S” and “D” in “memoryStorageDriver.” Malicious users hope that unsuspecting users will unintentionally install the wrong package, due to the close resemblance in their names. 

A stealthier approach to Typosquatting: 

This malicious package impersonation takes the traditional “Typosquatting,” attack method to a new level, where attackers register package names that consist of the exact same letters as the legitimate ones, with the only difference being capitalization. This makes it even harder for users to detect the deception since it can be easy to overlook the subtle differences in capitalization. 

The Scope of the Problem: 

3,815 packages were found on NPM containing uppercase letters. Out of these, 1,900 packages were at risk of impersonation, meaning that someone could upload a package with the same name but with all lowercase letters. Some of the at-risk packages were quite popular, such as “objectFitPolyfill,” which has hundreds of thousands of weekly downloads. In total, the download count of the packages at risk is in the tens of millions. 

Popular vulnerable package on NPM (capital letters used in the package name) 

Package name “objectFitPolyfill” in all lowercase letters available for anyone to use in a new package 

How do other Package Managers compare with NPM? 

To better understand the malicious package impersonation issue in NPM, let’s compare how other popular package managers, such as PyPI and NuGet, handle this issue.  

Both PyPI and NuGet adopt more robust strategies for dealing with package names containing uppercase and lowercase letters. For example, let’s take a package named “ExamplePackage” published on PyPI or NuGet. Unlike NPM, these package managers allow package creators to upload packages with names containing both upper and lowercase letters. Once “ExamplePackage” is published, PyPI and NuGet will restrict anyone else from uploading a package with the same name, regardless of the capitalization of letters. This means that a package named “examplepackage” or “Examplepackage” cannot be uploaded by someone else, preventing bad actors from exploiting package name variations. 

In addition, PyPi and NuGet have implemented an automatic typo-correction mechanism to assist users who accidentally type package names with incorrect capitalization. By employing these measures, PyPI and NuGet significantly reduce the chances of users falling victim to deceptive tactics. This approach provides a more secure environment for package distribution and installation. 

Addressing the Issue 

The issue was brought to the attention of the NPM security team, who promptly acknowledged and effectively addressed the concern. Now, if anyone attempts to upload packages that use all lowercase letters to imitate existing uppercase letters, they will be met with an error message that reads, “Package name too similar to existing package.” 

Package health checks: Users can check package health prior to installation. For example, Overlay Browser Extension can alert you if a package has known security issues or vulnerabilities, based on the latest advisories from trusted sources. By using tools like this, you can ensure that the package you are installing is secure and reliable. 

Raising awareness: We are dedicated to spreading awareness about attacks such as these and their potential impacts. By sharing our findings with the community, we aim to educate users and developers about the risks involved and the precautions they can take. 

Conclusion 

It is important to emphasize how easy it is to fall for this type of attack. It’s as simple and subtle as a change in capitalization. This vulnerability highlights the importance of staying vigilant and being aware of evolving tactics employed by bad actors. By understanding the risks, users can take appropriate precautions. The matter was reported to the NPM security team, who quickly recognized and efficiently resolved the issue. 

Even if you lived under a rock in the last few months, I’m sure you still have heard about OpenAI – especially their ChatGPT project. If you still don’t know what it is, let ChatGPT introduce itself: 

When OpenAI first allowed users to sign up for an account, it was offering a free credit as a trial to try their AI projects (around $7). 

Although it was enough for any user willing to start using ChatGPT, it was clearly insufficient for those looking forward to being the first to come up with some sort of integrated product. 

What we’ve found during the OpenAI signup process, was that there is a mechanism in place which validates user phone-numbers, which is used as a layer of validation to ensure users are unique individuals in order to prevent abuse of the free credit trial. By intercepting and modyfing the OpenAI API request, we’ve identified a vulnerability which allows us to bypass these restrictions. This allowed us to sign up for an arbitrary number of user accounts using the same phone number, getting as many free credits as we wanted. 

Vulnerability Details 

Account Validation Behavior 

Before going into the details of how this vulnerability might be exploited, allow me to explain how the registration process worked: 

1. Register an e-mail 

2. Click on the e-mail activation link 

3. Enter a phone number 

4. Enter the validation code received by SMS 

Both e-mail and phone number must be unique, otherwise, the user would be informed that the account already exists, and no free credits would be granted. 

Bypass Validation 

After understanding this process, we dove into the API underneath the web application. 

Providing a valid e-mail could be achieved by using a catch-all e-mail account on a private mail domain, or any of the many temporary e-mail services. You could even automate that with a script to monitor an inbox and follow the activation link for you. Bypassing the phone number restriction, however, was a bit more challenging. 

As a result, this is what we did: 

1. Register Account A (https://auth0.openai.com/u/signup/) with our unique phone number 

2. Register Account B (https://auth0.openai.com/u/signup/) with the same phone number. 

Account B was created but without being assigned the free credits. Account B was informed that the entered phone number had already got the free credits. 

How to bypass it? 

After intercepting the traffic with Burp proxy, we noticed the following request: 

Our first thought was to do subtle changes to the “phone_number”, prepending the country code (00351): 

This resulted in the following response: 

At this point, we noticed that we could use different variations of essentially the same phone number, and get the same number associated to different accounts. This would allow a malicious user to have multiple accounts with as many credits as they need, while effortlessly using the same phone number. 

Just using this technique, the attacker could keep adding leading zeros in order to create an arbitrary number of phone number variations. 

However, the amount of zeros would likely be finite, and we wanted to increase our credit value to a more respectable and significant sum, and deliver a better proof-of-concept to OpenAI. 

This is where the open-source tool REcollapse was put to use (https://github.com/0xacb/recollapse). This tool allows a user to fuzz inputs and bypass validations and discover normalization, canonicalization, and sanitization in web applications and APIs. 

After some initial testing, some patterns were observed to be sanitized by OpenAI API. Using Unicode encoding on certain non-ASCII bytes allowed us to bypass it and register more accounts. 

Root Cause? 

The likely root cause for this issue is that one upstream component, probably around user management, observes the phone number as a unique value, under the assumption that if it is invalid, it simply will not function for the purpose of account validation.  

Given the arbitrary prepended zeros and inline non-ASCII bytes, these permutations of the original value are not identical at an early point where comparison is made. However, once the system attempts to validate the phone number associated with the account, this tainted phone number is passed on to another component (or components), which sanitizes the value for prefixed zeros and unwanted bytes before using it as a proper phone number.  

This late-stage normalization can cause a massive, if not infinite, set of different values (e.g., 0123, 00123, 12u000a3, 001u000au000b2u000b3 etc.) that are treated as unique identifiers to collapse into a single value (123) upon use, which allows bypassing the initial validation mechanism altogether. 

The likely solution to this is to run the same normalization before ever processing the value, so that it is identical, both when used as a unique value upstream, and as a phone number downstream. 

Disclosure 

We can say that OpenAI was on top of this issue after we sent the report, even in the middle of a big Microsoft investment and lots of project changes. 

OpenAI feedback: 

Thank you again for your detailed report. We have validated the finding and have fixed the issue. 

We appreciate your reporting this to us and adhering to the OpenAI coordinated vulnerability disclosure policy (https://openai.com/policies/coordinated-vulnerability-disclosure-policy). 

Timeline: 

2 December 2022 – Report sent to OpenAI 

6 December 2022 – OpenAI replied back that they were investigating the issue 

28 February 2023 – We requested an update on the issue 

1 March 2023 – OpenAI replied that the issue was fixed 

4 May 2023 – Full Disclosure 

It was a pleasure to collaborate so effectively with the OpenAI , who took ownership and were professional through the disclosure and remediation process. For this reason, and a great researcher experience, we’re granting OpenAI the Checkmarx Seal of Approval. 

And, as always, our security research team will continue to focus on ways to improve application security practices everywhere