Adobe Commerce Unauthorized XXE Vulnerability

By Security News
July 8, 2024

Overview

The SonicWall Capture Labs threat research team became aware of an XML External Entity Reference vulnerability affecting Adobe Commerce and Magento Open Source. It is identified as CVE-2024-34102 and given a critical CVSSv3 score of 9.8. Labeled as an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability and categorized as CWE-611, this vulnerability allows an attacker unauthorized access to private files, such as those containing passwords. Successful exploitation could lead to arbitrary code execution, security feature bypass, and privilege escalation.

A proof of concept is publicly available on GitHub. Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier and Magento Open-Source versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier are vulnerable. Although Magento Open Source is popular mainly for dev environments, according to Shodan and FOFA, up to 50k exposed Adobe Commerce with Magento template are running.

Technical Overview

Magento (Adobe Commerce) is a built-in PHP platform that helps programmers create eCommerce websites and sell online. It is an HTTP PHP server application. Such applications usually have two global entry points: the User Interface and the API. Magento uses REST API, GraphQL, and SOAP.

Attackers can leverage this vulnerability to gain unauthorized admin access to REST API, GraphQL API, or SOAP API, leading to the disclosure of confidential data, denial of service, server-side request forgery (SSRF), port scanning from the perspective of the machine where the parser is located, and complete compromise of affected systems. This vulnerability poses a significant risk due to its ability to exfiltrate sensitive files, such as app/etc/env.php, containing cryptographic keys used for authentication, as shown in Figure 1. This key is generated during Magento 2 installation process. Unauthenticated actors can utilize this key to forge administrator tokens and manipulate Magento’s APIs as privileged users.

Figure 1: app/etc/env.php

The vulnerability is due to improper handling of nested deserialization in Adobe Commerce and Magento. This allows attackers to exploit XML External Entities (XXE) during deserialization, potentially allowing remote code execution. Unauthorized attackers can craft malicious JSON payloads that represent objects with unintended properties or behaviors when deserialized by the application.

Triggering the Vulnerability

XML External Entities (XXE) attack technique takes advantage of XML’s feature of dynamically building documents during processing. An XML message can provide data explicitly or point to a URI where the data exists. In the attack technique, external entities may replace the entity value with malicious data, alternate referrals, or compromise the security of the data the server/XML application has access to.

In the example below, the attacker takes advantage of an XML Parser’s local server access privileges to compromise local data:

The sample application expects XML input with a parameter called “username.” This parameter is later embedded in the application’s output.
The application typically invokes an XML parser to parse the XML input.
The XML parser expands the entity “test” into its full text from the entity definition provided in the URL. Here, the actual attack takes place.
The application embeds the input (parameter “username,” which contains the file) in the web service response.
The web service echoes back the data.

Attackers may also use External Entities to have the web services server download malicious code or content to the server for use in secondary or follow-on attacks. Other examples wherein sensitive files can be disclosed are shown in Figure 2.

Figure 2: Disclosing targeted files.

Exploiting the Vulnerability

A crafted POST request to a vulnerable Adobe instance with an enabled Magento template is the necessary and sufficient condition to exploit the issue. An attacker only needs to be able to access the instance remotely, which could be over the Internet or a local network. A working PoC with a crafted POST query aids in exploiting this vulnerability. Figure 4 shows a demonstration of exploitation leveraging the publicly available PoC.

Exploiting CVE-2024-34102, steps are enumerated below, which will exfiltrate the contents of the system’s password file from the target server.

Create a DTD file (dtd.xml) on the attacker’s machine. This file includes entities that will read and encode the system’s password file, then send it to your endpoint.
Host the dtd.xml file on the attacker’s machine, accessible via HTTP on a random port.
Send the malicious payload via a sample curl request to the vulnerable Magento instance, as shown in Figure 3. The payload includes a specially crafted XML payload referencing the DTD file hosted on the attacker’s machine.
The XML parser in Magento will process the DTD file, triggering the exfiltration of the system’s password file as shown in Figure 4.
Lastly, observe your endpoint to capture and decode the exfiltrated data.

Figure 3: CVE-2024-34102 attack request

00:00

00:15

Figure 4: CVE-2024-34102 Exploitation

Out of the 50k exposed Magento instances in the wild, multiple events were observed wherein attackers leveraged this vulnerability, as only 25% of instances have been updated since the vulnerability was exploited in the wild. According to Sansec analysis, CVE-2024-34102 can be chained with other vulnerabilities, such as the PHP filter chains exploit (CVE-2024-2961), leading to remote code execution (RCE).

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

IPS: 4462 – Adobe Commerce XXE Injection

Remediation Recommendations

Considering the severe consequences of this vulnerability and the trend of nefarious activists trying to leverage the exploit in the wild, users are strongly encouraged to upgrade their instances, according to Adobe advisory, to address the vulnerability.

Relevant Links

Source :
https://blog.sonicwall.com/en-us/2024/07/adobe-commerce-unauthorized-xxe-vulnerability/

The Top 10 AI Security Risks Every Business Should Know

By: Trend Micro
July 08, 2024
Read time: 4 min (1104 words)

With every week bringing news of another AI advance, it’s becoming increasingly important for organizations to understand the risks before adopting AI tools. This look at 10 key areas of concern identified by the Open Worldwide Application Security Project (OWASP) flags risks enterprises should keep in mind through the back half of the year.

For more than 20 years, Open Worldwide Application Security Project (OWASP) top 10 risk lists has have been go-to references in the fight to make software more secure. In 2023, OWASP brought forward a new addition: a rundown of risks specific to AI. Two draft versions of the AI risk list were published in spring/summer of that year, with a formal version 1 released in October.

Since then, LLMs have only become more entrenched as business productivity tools. Most companies are either using or exploring the use of AI, and while some liabilities are well known—such as the need to always check an LLM’s work—others remain under the radar.

We did some analysis and found the vulnerabilities identified by OWASP fall broadly into three categories:

Access risks associated with exploited privileges and unauthorized actions.
Data risks such as data manipulation or loss of services.
Reputational and business risks resulting from bad AI outputs or actions.

In this blog, we take a closer look at the specific risks in each case and offer some suggestions about how to handle them.

1. Access risks with AI

Of the 10 vulnerabilities listed by OWASP, three are specific to access and misuse of privileges: insecure plugin design, insecure output handling, and excessive agency.

According to OWASP, an LLM using that uses insecure could lose access control, opening them up to malicious requests or the execution of unauthorized remote code. On the flipside, plugins or applications that handle large language model outputs insecurely—without evaluating them—could expose backend systems be susceptible to XSS, CSRF, and SSRF attacks that execute unwanted actions, and to unauthorized privilege escalations, and remote code execution.

And because AI chatbots are ‘actors’ able to make and implement decisions, it matters how much free reign (i.e., agency) they’re given. As OWASP explains, “Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected/ambiguous outputs from an LLM (regardless of what is causing the LLM to malfunction; be it hallucination/confabulation, direct/indirect prompt injection, malicious plugin, poorly-engineered benign prompts, or just a poorly-performing model).”

For example, a personal mail reader assistant with message-sending capabilitiess could be exploited by a malicious email to propagate spam from a user’s account.

In all these cases, the large language model becomes a conduit for bad actors to infiltrate systems.

2. AI and data risks

Poisoned training data, supply chain vulnerabilities, sensitive information disclosures, prompt injection vulnerabilities , and denials of service are all data-specific AI risks.

Data can be poisoned deliberately by bad actors and inadvertently when an AI system learns from unreliable or unvetted sources. Both types of poisoning can occur within an active AI chatbot application or emerge from the LLM supply chain, where reliance on pre-trained models, crowdsourced data, and insecure plugin extensions may produce biased data outputs, security breaches, or system failures.

Poisoned data and the supply chain are input concerns. Allowing private, confidential, personally identifying information and the like into model training data can also result in unwanted disclosures of sensitive information.

With prompt injections, ill-meaning inputs may cause a large language model AI chatbot to expose data that should be kept private or perform other actions that lead to data compromises.

AI denial of service attacks are similar to classic DOS attacks. They may aim to overwhelm a large language model and deprive users of access to data and apps, or—because many AI chatbots rely on pay-as-you-go IT infrastructure—force the system to consume excessive resources and rack up massive costs.

3. Reputational and business risks associated with AI

The final two OWASP vulnerabilities relate to model theft and overreliance on AI. The first applies when an organization has its own proprietary LLM model. If that model is accessed, copied, or exfiltrated by unauthorized users, it could be exploited to harm the performance of a business, disadvantage it competitively, and potentially cause a leak of sensitive information.

Overreliance on AI is already having consequences around the world today. There’s no shortage of stories about large language models generating false or inappropriate outputs from fabricated citations and legal precedents to racist and sexist language.

OWASP points out that depending on AI chatbots without proper oversight can make organizations vulnerable to publishing misinformation or offensive content that results in reputational damage or even legal action.

Given all these various risks, the question becomes, “What can we do about it?” Fortunately, there are some protective steps organizations can take.

What enterprises can do about AI vulnerabilities

From our perspective at Trend Micro, defending against AI access risks requires a zero-trust security stance with disciplined separation of systems (sandboxing). Even though generative AI can challenge zero-trust defenses in ways that other IT systems don’t—because it can mimic trusted entities—a zero-trust posture still adds checks and balances that make it easier to identify and contain unwanted activity. OWASP also advises that large language models “should not self-police” and calls for controls to be embedded in application programming interfaces (APIs).

Sandboxing is also key to protecting data privacy and integrity: keeping confidential information fully separated from shareable data and making it inaccessible to AI chatbots and other public-facing systems.

Good separation of data prevents large language models from including private or personally identifiable information in public outputs, and from being publicly prompted to interact with secure applications such as payment systems in inappropriate ways.

On the reputational front, the simplest remedies are to not rely solely on AI-generated content or code, and to never publish or use AI outputs without first verifying they are true, accurate, and reliable.

Many of these defensive measures can—and should—be embedded in corporate policies. Once an appropriate policy foundation is in place, security technologies such as endpoint detection and response (EDR), extended detection and response (XDR), and security information and event management (SIEM) can be used for enforcement and to monitor for potentially harmful activity.

Large language model AI chatbots are here to stay

OWASP’s catalogue of AI risks proves that concerns about the rush to embrace AI are well justified. At the same time, AI clearly isn’t going anywhere, so understanding the risks and taking responsible steps to mitigate them is critically important.

Setting up the right policies to manage AI use and implementing those policies with the help of cybersecurity solutions is a good first step. So is staying informed. The way we see it at Trend Micro, OWASP’s top 10 AI risk list is bound to become as much of an annual must-read as its original application security list has been since 2003.

Source :
https://www.trendmicro.com/en_us/research/24/g/top-ai-security-risks.html

The Potential Impact of the OpenSSH Vulnerabilities CVE-2024–6387 and CVE-2024-6409

By: Jagir Shastri
July 17, 2024
Read time: 5 min (1331 words)

We check the OpenSSH vulnerabilities CVE-2024–6387 and CVE-2024-6409, examining their potential real-world impact and the possibility of exploitation for CVE-2024–6387 in x64 systems.

Introduction

CVE-2024–6387, also known as “regreSSHion,” is a vulnerability that exists in OpenSSH, a widely-used suite of secure networking utilities based on the SSH protocol. This vulnerability, which was discovered in July 2024, allows for remote unauthenticated code execution, potentially providing attackers root privileges on affected systems. The Common Vulnerability Scoring System (CVSS) has rated this vulnerability with a score of 9.8

The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible but this has not been demonstrated at the time of publishing.

On July 8, another similar vulnerability, the signal handler race condition CVE-2024-6409 was discovered. This flaw occurs when a client fails to authenticate within the LoginGraceTime period, which is 120 seconds by default, and 600 seconds in older OpenSSH versions. Consequently, this can lead to a signal handler race condition in the cleanup_exit() function within the child process of the SSHD server.

The “regreSSHion” vulnerability arises from the unsafe handling of the SIGALRM signal during SSH authentication. When the LoginGraceTime expires, the SIGALRM signal is raised, and the corresponding handler performs certain actions, including calling non-async-signal-safe functions like syslog(). This can create a race condition, where the timing of operations could lead to memory corruption or other unexpected behaviors.

SIGALRM
SIGALRM is a signal in Unix-like operating systems that indicates an alarm or timer expiration. When a process sets and a function triggers, it schedules a SIGALRM signal to be sent to the process after a specified number of seconds. This signal is commonly used for timing operations, such as implementing timeouts for network requests or scheduling periodic tasks. Processes can define custom signal handlers to respond to SIGALRM, allowing them to perform actions such as terminating processes, resetting timers, or managing execution time limits. Overall, SIGALRM facilitates time-sensitive operations within Unix processes by providing a mechanism to handle scheduled alarms and timing events.

Exploiting CVE-2024–6387 requires an attacker to initiate thousands of connection attempts to trigger the race condition accurately. The process involves repeatedly setting and resetting LoginGraceTime, causing the server to invoke the SIGALRM signal handler. This requires precise timing and proper inputs to manipulate the server’s memory layout, leading to heap corruption and code execution.

Signal handlers
Signal handlers are special functions that get called in response to specific signals sent to a program. These signals can be generated, either by the operating system or by the program itself. However, not all functions are safe to call from within a signal handler since they may not be reentrant, therefore cannot safely be interrupted and called again (“async-signal-safe”). For instance, syslog() is a function used to log messages to the system logger and is not considered async-signal-safe.

Researchers have found that approximately 10,000 attempts are needed to successfully exploit this vulnerability. While the exploit could take days to complete, it is still not guaranteed that the attempt would be successful . The presence of modern security mechanisms such as Address Space Layout Randomization (ASLR) and No-eXecute (NX) bits further complicate the exploitation process but do not entirely mitigate the risk.

CVE-2024-6409 technical details

Like CVE-2024-6387, this vulnerability occurs when the SSHD’s SIGALRM handler is called asynchronously, which in turn calls various functions that are not async-signal-safe.

The race condition in grace_alarm_handler() calls cleanup_exit() from the privsep child process. However, cleanup_exit() is not designed to be called from a signal handler, potentially invoking unsafe functions. Cleanup function calls can be interrupted by signals, causing unsafe state changes and potential remote code execution (RCE).

As a privsep child process run’s with reduced privileges, there is less reason to worry about the vulnerability. In addition, working exploits for the CVE-2024-6409 have not been yet discovered, therefore proof of its actual exploitation has not been established at the time of publishing.

Exploitability of CVE-2024-6387 in x64 Systems

The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library (glibc) systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible. However, certain characteristics of X64 systems make this exploitation much more difficult, which we’ll expound on in this section.

In x64 systems, ASLR plays a crucial role by randomizing memory addresses, including those of the GNU C Library (glibc), with each program execution. This randomness makes it very difficult for attackers to predict the location of the glibc base address, thus mitigating exploits that depend on precise memory targeting. The x64 architecture’s expansive address space further complicates exploitation, as attackers have to guess an exponentially greater amount of addresses. Combined with security measures such as stack canaries and NX bits, exploiting vulnerabilities such as CVE-2024-6387 becomes highly impractical on x64 systems.

While theoretically possible under specific conditions, the effective implementation of ASLR and the inherent complexities of the x64 environment significantly reduce real-world exploitability, highlighting the robust security benefits of these architectural safeguards.

Potential impact

Our As per our internal telemetry we did not notice any trend change for CVE-2024–6387, which could be considered a known exploited vulnerability (KEV)that is being exploited in wild. .

While CVE-2024–6387 presents a critical security risk, its real-world impact is mitigated by several factors. The technical complexity of the exploit and the extensive time required to execute it make large-scale attacks impractical. Each attack attempt resets the login timer, requiring precise timing and substantial effort from the attacker.

Moreover, the vulnerability affects specific versions of OpenSSH (up to 4.4p1 and 8.5p1 to 9.7p1) running on Linux systems using the GNU C Library. Systems with additional protections against brute force attacks and distributed denial-of-service (DDoS) are less likely to be successfully exploited. Therefore, while targeted attacks are possible, mass exploitation is unlikely due to the unavailability of working exploits and the time required to exploit these vulnerabilities.

Mitigation

To mitigate the risks associated with CVE-2024–6387, administrators should immediately update OpenSSH to version 9.8 or later. If immediate updating is not feasible, reducing the LoginGraceTime can provide temporary mitigation against this vulnerability.

Additionally, organizations can consider implementing the following best practices for general vulnerability exploit protection:

Patch management
Regularly updating and patching software, operating systems, and applications is the most straightforward method for organizations to avoid the exploitation of vulnerabilities within their systems.

Network segmentation
Separating critical network segments from the larger network can minimize the impact of a potential vulnerability exploitation.

Regular security audits
Performing security audits and vulnerability assessments can identify and remediate potential weaknesses within the infrastructure before they can be exploited.

Security awareness training
Educating employees about the common tactics used by attackers can help them avoid falling victim to social engineering attacks that might precede vulnerability exploitation.

Incident response plan
Developing, testing, and maintaining an incident response plan can help organizations quickly and effectively respond to security breaches and vulnerability exploitations.

Additionally, employing network-based access controls, intrusion prevention systems such as Trend Vision One™, and regular vulnerability scanning can further enhance security.
For Trend customers, the following IPS smart rules can detect the attack on a surface level:

1003593 Detected SSH Server Traffic (ATT&CK T1021.004)
1005748 Multiple SSH Connection Detected (ATT&CK T1499.002, T1110)

Conclusion

According to other researchers, there could be non-functional exploits in circulation that claim to be working proofs-of-concept (POCs) for CVE-2024-6387. These fake exploits contain payloads that download files from remote servers and establish persistence on the systems of security researchers. Assuming they are testing a legitimate POC for the vulnerability, the security features of their systems might be disabled, making them vulnerable to malicious activities.

Overall, while CVE-2024–6387 and CVE-2024-6409 is a critical vulnerability, it does not pose a widespread threat to the internet due to its exploitation complexity and existing mitigations. However, administrators should remain vigilant, apply patches promptly, and implement recommended security practices to protect their systems.

Source :
https://www.trendmicro.com/en_us/research/24/g/cve-2024-6387-and-cve-2024-6409.html