Open-Xchange: SSRF in VCARD photo upload functionality

FYI - Tested on local installation of App Suite 7.8.4 REV 14, CentOS 7.4, x64

Hello,

I believe I may have found another SSRF re-direct vulnerability which again will allow port scanning of the App Suite server and the internal network, this is similar to my earlier report: #293847

The endpoint is the following which is used to import contacts via external VCARD files:

http://<domain>/appsuite/api/import?action=VCARD

Pre-requisites to exploit this vulnerability are the following:

-Attacker server
-Attacker controlled domain name
-vcard file
-Valid session from login or anonymous link

###Summary

The App Suite source code contains the following Java file which appears to be used to import a contact photograph via a URL, provided from a .vcard file:

backend/com.openexchange.contact.vcard.impl/src/com/openexchange/contact/vcard/impl/mapping/PhotoMapping.java

The section of code at line numbers 427-465 does a decent job of ensuring that any URL entered is not a local address to the App Suite server. I had to modify my PoC from my previous report to take this into account.

Further in this file, is the below section which handles redirect requests, line numbers 479-491:

// Follow & check redirects recursively
            if (urlConnnection instanceof HttpURLConnection) {
                HttpURLConnection httpURLConnection = (HttpURLConnection) urlConnnection;
                int responseCode = httpURLConnection.getResponseCode();
                if (responseCode == HttpURLConnection.HTTP_MOVED_PERM || responseCode == HttpURLConnection.HTTP_MOVED_TEMP) {
                    String redirectUrl = urlConnnection.getHeaderField("Location");
                    httpURLConnection.disconnect();
                    return new LoadedImage(redirectUrl);
                }
                if (responseCode >= 400) {
                    addConversionWarning(warnings, "PHOTO", "image URL \"" + origUrlString + "\" appears not to be valid, skipping import.");
                    return NULL_RESULT;
                }
            }

My interpretation was that if a redirect was sent that matched the following:

HTTP_MOVED_PERM****HTTP_MOVED_TEMP

Which translates to a HTTP 301 and302 response according to the following Java documentation:

https://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html

The returned URL would be re-checked to make sure it is not a local address. The suspected vulnerability is the check of response codes 301 and 302, as it doesn’t take into account other HTTP re-direct response codes such as 303 and 305. However, further testing proved that standard response codes were being accepted as well, e.g. 301/302.

Note. I am not a programmer so the above analysis might be incorrect

###PoC Setup

{F245109}

The below PoC will contain the following files:

attacker_server.py: (Attackers python web server running on TCP port 70, responses to all GET requests with a 301 re-direct to http://127.0.0.1 on a rotating TCP port

request.py: (Attackers python script that will submit login credentials to obtain a session cookie and then send 20 post requests to upload a VCARD)

test.vcard: (Attackers VCARD file based on the following example from Wikipedia https://en.wikipedia.org/wiki/VCard. The file contains the following URL entry which is used to upload a photo to the contact entry:

: PHOTO;VALUE=URI;TYPE=GIF:http://testserver65.com:70/test.jpeg.

script_results.txt: (Results of HTTP response times per-port)

###PoC

1. The attacker_server.py script will run on192.168.0.6(Attacker server), this will setup a Python webserver running onport 70 and will await a GET request.

2. Netcat listeners are running on TCP port 2, 6, 8, and 10 to simulate listening ports that will accept HTTP connections on the App Suite server.

3. request.py will also run from the attacker server and connect to the target host**(192.168.0.16), this will POSTtest.vcard** to the vulnerable endpoint multiples times, 20 by default. Make sure the test.vcard file is in the script working directory or it won’t be uploaded.

4. The App Suite server will then carry out a DNS lookup to the photo URL which can be found in the vcard file

http://testserver65.com:70/test.jpeg

In this case I added the following in /etc/hosts: <Wi-Fi gateway IP address> testserver65.com on the App Suite server.

The reason I’ve added a public IP address is that the Java file will block a private address during the initial POST. So I used the gateway address on my home router to port-forward port 70 to port 70 on the attacker system (192.168.0.6). I was using port 80 for something else in this case, hence the port change.

5. The attacker webserver will send a 301 response back after each request with the following URL:http://127.0.0.1:<port number>. The port number will rotate on every GET request.

6. The HTTP response time will then be logged to the script_output.txt file when a port connection attempt is made. Sorted in descending order of response time.

###Results

-Below are the results from the script_out.txt file. As you can see, the listening ports on the App-Suite server have the longest response times. (Port 2, 6, 8, 10)

2: [2.562081]
6: [2.557924]
10: [2.557095]
8: [2.556498]
1: [0.104492]
3: [0.044996]
9: [0.041817]
4: [0.037032]
7: [0.036648]
5: [0.036015]

-Below is an extract of the responses from the Netcat listeners on the App Suite server:

GET / HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_151
Host: 127.0.0.1:2
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

GET / HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_151
Host: 127.0.0.1:6
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

The following HTTP re-direct codes were attempted, results below:

300 - multiple choices, failed
301 - moved permanently, working
302 - found, working
303 - see other, working
305 - use proxy, working
307 - temporary redirect, failed
308 - permanent redirect, failed

Impact

Again, as with the previous report, this vulnerability can mainly be used for blind port scanning and IP discovery on the target host and any internal networks the target host has access to. There was no ability to extract files or access other data.

All the best.