CVE-2023-42439: SSRF Vulnerability

CVE ID: CVE-2023-42439

NVD publish date: 09/15/2023

Product: GeoNode

Version: > 3.2.0

Severity: High

CVE-2023-40017 [Part Two]

As some will know, I recently discovered CVE-2023-40017 however, following their patch, a further vulnerability was uncovered…

To briefly recap, CVE 2023-40017 was discovered within an open-source web application deployed across a range of sectors. This vulnerability used several methods to bypass whitelisting protections, ultimately achieving a full read Server-Side Request Forgery (SSRF).

The whitelisting protections were checking if a whitelisted host was requested, but failing to check the URL to identify how the passed request was presented. Presenting the TARGETIP and an encoded \ (%5c) as-well as an encoded # (%23) would instruct the backend request to only process the first host in the request and ignore the last host.

This latest CVE (CVE-2023-42439) is a new take on the recently implemented protections to bypass the security measures to achieve the same full read SSRF impact. Whilst studying how the latest security protections had been implemented, it became clear that the application was now ensuring the full address entered matched against a whitelist of domains. An incorrect domain even when attempting to trick the parser would display the following response:

Discovering the major SSRF vulnerability

I began to question exactly what protections may have been left out when implementing the fix. I quickly fuzzed characters and potential SSRF bypasses to see what the application would and would not accept. It became clear that the application was processing the URL encoded value of @ (%40). This is nothing new with web browsers, often web browsers will use the @ symbol to specify a credential login to a domain, e.g. Test:test@site.com. In this case, it was possible to add the whitelisted host as fake credentials and point this back to internal assets as it seemed the regex was purely looking for the @ symbol and not its encoded value, this leaves us with https://whitelisted.com%40internalasset:port. To prove impact, I needed to fuzz an internal asset on it’s corresponding port. This was quickly fixed by the team.

Why is this SSRF Vulnerability such a big deal?

When dealing with Server Side Request Forgery, an application is making a request from itself or passing the request to an internal asset to make the request. If the device is on a private network and not properly protected, a full read SSRF can allow a malicious user to view data hosted on private servers/devices.

This vulnerability can lead to several critical security risks, including but not limited to:

• Unauthorised Data Exposure: Attackers can abuse the SSRF vulnerability to access internal resources such as databases, configuration files, or cloud infrastructure metadata, potentially exposing sensitive data.

• Remote Code Execution (RCE): Depending on the application’s architecture, SSRF may allow attackers to execute arbitrary code on the server, leading to complete compromise.

• Denial of Service (DoS): Malicious actors can perform SSRF attacks to overwhelm internal resources, causing performance degradation or even system outages.

• Bypassing Security Controls: SSRF can be used to bypass network security controls and access restricted resources that should not be directly accessible from external interfaces.

Risk Mitigation

To effectively mitigate against these risks, I recommend that organisations take a proactive approach to their cyber security strategy. Adopting and implementing the following security measures will significantly reduce the risks associated with this vulnerability, improve your security posture and foster a safer digital environment for your systems and data.

• Patch or Update: Apply the latest security patches or updates provided by the application vendor or open-source community. Ensure that the SSRF vulnerability is addressed in the latest release.

• Input Validation: Implement strict input validation and sanitisation of user-provided input to prevent maliciously crafted URLs from being processed by the application.

• Whitelisting: Create a whitelist of allowed external domains or IP addresses to limit the destinations that the application can access. Deny all other requests by default.

• Network Segmentation: Implement proper network segmentation to restrict internal resource access from the application’s server. Isolate sensitive resources to prevent unauthorised access.

• Logging and Monitoring: Enable detailed logging and monitoring for SSRF attempts. Regularly review logs to detect and respond to suspicious activity.

• Security Awareness Training: Provide security training for developers and administrators to increase awareness of SSRF risks and secure coding practices.

• Firewall Rules: Configure firewall rules to block outgoing requests to known internal or sensitive resources, further restricting the attack surface.

• Web Application Firewall (WAF): Deploy a WAF with SSRF protection capabilities to filter and block malicious requests at the network perimeter.

• Penetration Testing: Conduct regular penetration testing to identify and remediate SSRF vulnerabilities and other security issues within the application.

stay up to date

This vulnerability, a bypass to a previous issue, emphasises the danger of persistent, determined attackers that aim to exploit SSRF vulnerabilities. SSRF vulnerabilities are high impact, with the potential for unauthorised data exposure, remote code execution, denial of service, and bypassing security controls.

Staying one step ahead of these threats is only possible if you take a proactive approach to your security. For those that want to know more about how we can help you do this – get in touch with our offensive security team.

Do you want to keep up with the evolving world of cyber security? For more exclusive expert intel, cyber security news and updates, sign up to our newsletter Access Granted.