Denial of Service in proxy by redirecting to own host in jgraph/drawio

Valid

Reported on

Oct 14th 2022


Description

It is possible to partially interrupt the proxy in the backend by redirecting to the same URL again.

Proof of Concept

On a server or API mocking website implement a rule that will redirect all requests to the following URL:

https://diagrams.net/proxy?url=https://attacker.com (https://attacker.com being the site that will send the redirect)

Now open the URL a few times

After opening the URL the proxy will follow the redirect to the same url again, which will invoke another proxy request, and so on. By doing this the service will encounter a loop even with the restriction of redirects. Opening the URL a few times will spawn more of these loops. Doing it enough will partially interrupt the proxy service for other users.

https://e1.pcloud.link/publink/show?code=XZ2JI8ZyOSBJFwewA4LTpJJ3NDUbk6hih7y

Explanation of the terminal window:
Top right is a tunnel to my diagrams.net instance running on localhost, the URL shown is accessible from the web.
Top left shows my attacker server which redirects everything to my diagrams.net instance with the proxy URL of the attacker server itself.
Bottom left shows a simple script to invoke some request loops every few seconds.
Bottom right shows the diagrams.net docker container output.
First, I access the proxy with the URL of an API mocking tool to check the availability of the proxy. Then I invoke the PoC script and after a few seconds I invoke the proxy check again. At which this time, it only responds after a decent amount of loading, because the server is busy with resolving the requests loops.

Impact

This vulnerability is capable of interrupting the proxy service for other users.

Occurrences

The redirect check that checks the location header should also check for the same host

References

We are processing your report and will contact the jgraph/drawio team within 24 hours. a year ago
Marlon
a year ago

Researcher


I initially went for availability low but after finding the CVE I put in the references I chose high. I'm also okay with low if you think it does not apply here.

David Benson
a year ago

Maintainer


Please detail how you tested this and include screenshots of the resulting failure.

Marlon modified the report
a year ago
Marlon
a year ago

Researcher


I updated the report with a recording and an explanation of it.

David Benson
a year ago

Maintainer


How did you deploy draw.io? What version did you deploy? Did you make configuration changes from the default?

I need to be able to exactly recreate your environment.

Marlon
a year ago

Researcher


I deployed it with docker, using the command: docker run -it --rm --name="draw" -p 8080:8080 -p 8443:8443 jgraph/drawio I assume it pulls the latest version, in this case 20.4.0. And I did not make any configuration changes.

Marlon
a year ago

Researcher


Okay, I noticed an issue with my test setup. My setup did not pull the latest version in which the proxy is disabled by default.

Marlon
a year ago

Researcher


If it works against production (which I don't think I'm authorized to test), I would leave the availability as high, if not I would lower it to low.

Marlon
a year ago

Researcher


I have read that the production code is a bit different from the normal one? In such case and if production is affected, one could just add a check during the redirection if the host doesn't start with the own domain. And regarding the self-hosted version, I'm not sure if it's possible to dynamically know the own domain without specifying it in some config. And since the proxy is disabled there by default, I don't think it's a big issue for the self-hosted version.

David Benson validated this vulnerability a year ago

You have a valid test against the production version. We're fine with attacks on both the open source and production codebases.

Testing whether it's same domain is actually tough both in production (cloudflare) and in the java code. We'll think some more, it would be good to cover the java code in case someone enables the proxy.

myyxl has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
David Benson marked this as fixed in 20.4.2 with commit 601712 a year ago
The fix bounty has been dropped
ProxyServlet.java#L115-L135 has been validated
David Benson
a year ago

Maintainer


As a note to anyone deploying the draw.io war or docker, this is only an issue if you enable the proxy, or run an older build (which would have other security issues if the proxy is enabled by default).

Marlon
a year ago

Researcher


Neat fix, I totally forgot you could just check the user agent.

This vulnerability has now been published a year ago
to join this conversation