Discovering CVE-2023-40017

CVE ID: CVE-2023-40017

NVD publish date: 08/24/2023

Product: GeoNode

Version: From (including) 3.2.0   Up to (including) 4.1.2

Severity: High (7.5) Patch: A patch is available at commit a9eebae80cb362009660a1fd49e105e7cdb499b9.

As some of you may have heard, I recently discovered a critical vulnerability in an open-source web application that’s widely deployed across a large range of sectors, from government entities to educational institutions.

This vulnerability was particularly brutal, as it allowed Server Side Request Forgery (SSRF) attacks, despite existing security measures designed to prevent them. The flaw specifically involves a weak whitelist check that mistakenly enables unauthorised requests to pass through the application’s front-end to its back-end.

In this expert intel, I will walk you through how I discovered this vulnerability, some of the slightly more technical details, the impact, and ultimately what mitigations need to be made moving forward.

But first, for those that don’t know what a CVE is, let’s start with the basics…

So, what is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a standardised identifier for a specific security vulnerability in a software application, hardware device, or system. It’s a unique alphanumeric code, such as “CVE-YYYY-NNNNN,” where YYYY represents the year of assignment and NNNNN is a sequential number. The importance of finding CVEs lies in their role as a foundational element of cyber security risk management. They provide the critical information needed to understand, prioritise, and mitigate security vulnerabilities, ultimately enhancing the overall security of systems and data.

A vulnerability is defined by CVE as “a flaw in a software, firmware, hardware, or service component resulting from a weakness that can be exploited, causing a negative impact to the confidentiality, integrity, or availability of an impacted component or components”.

Therefore, a vulnerability grants attackers unauthorised entry into a system or network, often with full privileges for executing commands or accessing restricted information. An exposure arises from code or configuration errors, allowing attackers to gain indirect and challenging-to-detect access to application data like customer information.

Uncovering the Critical Vulnerability

During my investigation, it became clear that the application I was testing was designed with SSRF protections that involve a whitelist-based filtering mechanism. However, a bypass vulnerability exists that allowed me (and potentially, an attacker) to manipulate the request to confuse the front-end, thus evading the whitelist check.

As a result of this vulnerability, illegitimate requests get passed on to the back-end server, tricking the whitelist with characters a browser interprets in special ways.

SSRF Definition: SSRF is a type of vulnerability where an attacker tricks a server into making unintended requests to internal or external resources, often leading to unauthorised data exposure or service disruption.  Often SSRF vulnerabilities have devastating consequences, if we take a look into the data leak that Capital One suffered, we can see this evolved from an initial SSRF entry point, leaking details to 100 million credit applications. Malicious users bypass protections to make an application request information/data from another device on the internal network.

From my experience, the severity of this vulnerability would be especially high if the targeted organisation is operating in an AWS (Amazon Web Services) environment. An attacker exploiting this SSRF flaw could not only request internal hosts but also navigate through the application to access sensitive AWS resources. In the worst-case scenario, it would become possible to retrieve an organisation’s AWS Secret Access Key and Access Key ID, thereby gaining unauthorised access to AWS S3 buckets or other cloud resources containing confidential information. In brief terms, an organisation that utilises AWS buckets, stores data in these buckets, this data will relate to the business. Should a malicious user retrieve and steal the keys, they can authenticate to the bucket and pull out all the data.

This scenario would be detrimental to the operations, reputation and financial stability of any organisation unaware of this threat. Not catching this vulnerability early enough could result in far-reaching, long lasting consequences, impacting data integrity, intellectual property, and requiring expensive remediation efforts.

Risk Mitigation

Given the widespread deployment and critical nature of this vulnerability, I would advise organisations to take immediate action to avoid the potential of a cyber-attack. The best course of action is to patch your systems with the latest security updates, alternatively you can implement strict firewall rules to mitigate the risks associated with unauthorised internal requests. I would recommend:

• To stay on top of relevant developments for this vulnerability and future vulnerabilities, I recommend regularly monitoring GeoNode security announcements.

• Given the severity of this vulnerability, it is critical to perform security assessments and penetration testing of your GeoNode installation, this will identify and address any vulnerabilities proactively.

• Regardless of whether your organisation could be affected by this vulnerability, I strongly recommend Educating system administrators and users about the importance of strong access controls and network security practices.

Conclusion

And there you have it – my latest CVE discovery. If you would like to view the official publication of CVE-2023-40017, you can read it here on the NIST website.

To stay up to date with the latest intel, discoveries and developments at Stripe OLT, sign up to our cyber security newsletter, Access Granted. Made for cyber specialists, by cyber specialists.