Vulnerability Report: Open Redirect in Jive Social Networking Platform
Authors:- Eric Goldman
21 Oct 2016 :: Security :: #Jive #Vulnerability Report #open redirect
Release Date: 10/21/2016
Updated: 10/25/2016
CVE
This vulnerability report has been assigned CVE-2016-4334
Status
The following vulnerability has been reported to Jive. In response to the initial report the Jive Security team had noted this issue was already identified and a solution was being tracked. The Jive team has addressed this issue by implementing an optional warning exit page for external links. The patch was included in the 2016.2 release which was deployed to customers between the dates of 15 July 2016 and 26 August 2016.
Note: Individual end-users are still responsible for performing an independent analysis of the trustworthiness of the link. No whitelisting/blacklisting was reported as part of this fix.
Update 10/25/2016: The below recommendation provided by Jive does not properly address the issue after additional testing. Instead of using an actual exit page and implementing the check on external-link.jspa, this solution only pops up a modal on the page. The result is if you make a GET request directly to an exit link, such as https://[customer-sub-domain].jiveon.com/external-link.jspa?url=http%3A%2F%2Fexample.com%2F, you will be redirected without any warning. As a result, an attacker who utilizes an exit link via external-link.jspa directly in a phishing email will not be stopped by this protection which is added.
Current Recommendation to Jive Administrators
Jive administrators should configure their Jive instance to use the exit warning page. There is currently no known public documentation which covers this new setting when it was deployed in the 2016.2 release. However, the administrator only need to enable the setting by clicking a checkbox at the sites /admin/settings-links.jspa page or by following these steps for navigation:
- Login as a Jive Admin
- Go to the
Admin console - Click the
System Tab - Click the
Settings Tab - Click “External Links” on the left
- Check “Warn users that they are leaving Jive when they click on external link in content”
- Click “Save Settings”
Update 10/25/2016: I have done some additional research, and it looks like in 2016.3.1 version they introduced another setting Delay the redirect to external links so users are made aware that they are leaving the instance. What it appears this setting does is show the URL and then redirect with a countdown. I would not recommend utilizing this new, third option as it warns people but provides no time for the user to take action. The following screenshots shows the configuration screen with this new option:
Update 10/25/2016: I have performed some testing to show the user experience when you enable the exit page:
Please note longer URLs will be truncated and only the first part of the URL will be shown, followed by three dots.
Original Report Submitted to Jive
This is an open redirect and is therefore generally considered a low risk vulnerability; however, the risk is slightly elevated because an attacker could target a specific community and abuse the existing trust of a community user who is familiar with the subdomain.jiveon.com address and may stop checking after seeing it is a familiar host part of the URI
The enterprise social networking platform from Jive (jiveon.com) is vulnerable to an open redirect. This can allow an attacker to effectively target enterprise users and abuse trust in the platform.
If an enterprise is filtering emails for spam/phishing, it may whitelist the domain for its Jive instance (*.jiveon.com). Then a malicious email using this open redirect may not be filtered if the preventative engine does not also follow redirects and blindly trusts the link in the email. This open redirect in more dangerous than an open redirect on a random compromised website or a URL shortening service (e.g., bit.ly) because an enterprise’s Jive website will be highly trusted by the community’s users.
User awareness efforts often mistakenly tell users to hover their mouse over links to validate; in such a case, the user will see that it starts with a domain name they recognize and will trust it. The tooltip may not show the full address or the user may stop after seeing a host portion of a URI he/she trusts.
For example, to redirect to http://bing.com would be:
https://[customer-sub-domain].jiveon.com/external-link.jspa?url=http%3A%2F%2Fbing.com%2F
A list of Jive customer sub domains can be found by a web search using a search query such as:
site:jiveon.com –www
as in:
The company/community associated with a subdomain is usually very clearly identified or could be researched .
Jive is a SaaS platform. Though some customers may self-host, many are using the Jive hosting so there is unlikely customization that would impact this vulnerability on a given target victim organization.
An attacker could also likely find this the proper domain as part of normal footprinting. A determined attacker could likely use other reconnaissance via web searches and news searches to find other victims, even those who are self-hosted.
There are some open communities used for B2C customer support as well. Using the usernames of community members, attackers may be able to determine email addresses or other details and perform spear phishing. For example, using the above Google search, the following was one of the results in the top 100 hits:
For such an open community, you can create the link:
https://republicwireless.jiveon.com/external-link.jspa?url=http%3A%2F%2Fbing.com%2F
and it will redirect you without issue.
From testing, it does not appear there is any check to whether the URL was legitimately ever created internally on the site (i.e., there is no whitelist database of “good URLs”).
e.g., blindly creating a redirect for:
as
It appears that for the non-public closed communities, the user must first be logged in. For enterprise customers, many will be automatically logged in via an SSO mechanism or will be presented with their corporate login screen, which they will trust. This further empowers the attacker because the user will recognize and trust their real login screen. In earlier testing, it did not seem the user had to be logged in; this may either have been a recent enhancement, per instance setting, or an error in the initial documentation I made for this issue when it was first discovered. However, for a targeted attack, the victim users will likely already be logged in.
The redirect is also very familiar to users, because Jive uses the redirect for all external links. When a user creates a legitimate online Document, Discussion, etc. on the platform any links to an external resource will be rewritten to use the external-links.jspa redirector.
I have not done extensive testing to see if there is any filtering during the redirect for security purposes. However, it is clear that the redirects are not checked against a database of legitimately created links in an existing piece of content, as any arbitrary URL-encoded URL will be redirected.
Remediation Proposed
It is recommended that Jive should only allow redirects by adding a legitimately created redirect to a database and only allowing outbound links to those URLs which were created by a user in the instance. As a secondary measure, Jive may wish to implement an “exit page” which informs the user he is leaving the Jive platform and going to a third party website. Individual instance administrators could be given the option to whitelist their corporate domains or other domains to avoid the exist page for domains which are trusted. Jive could also implement a check against blacklists for malicious domains (built in house or purchased) to warn users of potentially dangerous links.
Other Notes
There are many large customers of Jive, as it is a large competitor of Yammer, etc. Jive makes a public list of many customers: https://www.jivesoftware.com/customers/ . Given a company or organization, one could easily do a web search for “[Company Name] Jive logon” etc. and find the domain.
On a Jive platform, when creating an online “Document” and in Discussions, etc. any time an external hyperlink is created, the published version will use this redirect. Jive likely does some statistics and tracking with this external exit link gateway. It has not been tested if they blacklist certain domains, URLS, etc. It is not clear from research if the customer administrator for a Jive instance can see these statistics or only Jive.
Further enhancements recommended
Jive should continue to enhance protections against malicious external linking by implementing filtering rules or implementing other checks such as those now common on URL redirection services.