Documentum is an enterprise content management platform in which it is possible to upload and share documents. I found an open redirect in it that also exposes credentials.
If you visit some non-existing URL under Documentum Administrator 7.1, it redirects you to the virtuallinkconnect page. For example, if you visit http://localhost:8080/da/helloworld, you are redirected to the following URL:
This is supposedly part of the virtual link functionality. A virtual link is a link to document with authentication included. This way you can send a link to your coworker and he can access that document because the link contains an access token. The documentation says this about the parameters to virtuallinkconnect:
- redirectUrl - (Required) URL to be displayed when the object cannot be located in the repository.
- virtualLinkPath - (Required) URL to the feature that provides anonymous access, which allows the use of predefined login credentials (per repository) instead of requiring a user to log in using their credentials.
So the virtuallinkconnect page tries to look up the given virtualLinkPath, and redirects to redirectUrl if that fails. This is a good point to test for an open redirect. An open redirect is a page that redirects the user to another site. This can be used in a phishing attack so that a seemingly trustworthy link to legit.com actually redirects to attacker.com.
To test this, we fill in a full URL in redirectUrl, any anything that does not exist in virtualLinkPath:
This indeed redirects to https://www.sjoerdlangkemper.nl/, confirming that this is an open redirect without any validation on the redirectUrl parameter.
With authentication credentials
Besides simply redirecting, it passes a couple of parameters along with the redirect. The full URL that it redirects to is this:
The virtuallinkconnect adds several query parameters:
docbase, the name of our Documentum repository,
domain, always empty,
username, our Documentum username,
ticket, a base64-encoded authentication token,
rootpaths, some configured paths.
These parameters are only added if an option called “secure vlinks” is disabled. If it is enabled, all these values are passed to the next page through the session and not through GET parameters. The documentation says
If secure vlink deployment is enabled, vlink and webtop will communicate using HTTPSession. Hence, they cannot be deployed as different web applications. If secure vlink deployment is disabled, vlink and webtop will communicate using HTTP(S) GET. In this case, they can be deployed as different web applications in the application server.
Assuming secure vlinks is disabled, your username, docbase name and ticket are sent to a third-party web site if you can be tricked in visiting a link. This ticket is particularly interesting, because it contains some authentication token. It turns out it is quite easy to use to authenticate as another user. Just paste the ticket value in the password field at the login page.
As soon as the victim visits a link, he will sent his username and ticket to a third-party site. The attacker can then log in as the victim, using the username and ticket that were sent using the open redirect. That makes this an open redirect with serious impact.