ServiceNow Insecure Access Control leading to Administrator Account Takeover - CVE-2022-43684

In this article, we will discuss a series of vulnerabilities that when exploited in succession, could enable a low-privilege user in ServiceNow to gain unauthorized full administrative access to the ServiceNow instance.

ServiceNow is a cloud-based platform that provides service management software as a service (SaaS). It is used by a millions of companies worldwide, and specializes in IT Service Management (ITSM), IT Operations Management (ITOM), and IT Business Management (ITBM). It allows users to manage incidents, service requests, problems, and changes within the IT infrastructure of a business. It also provides a self-service portal where end users can request IT services and log issues.

While working internally as a security engineer on the offensive security team, we routinely scrutinize the security of third-party platforms that integrate with our systems and processes. This is a crucial step to verify the security of these platforms and prevent potential breaches that could expose our sensitive data. During a recent engagement in mid-2022 our security team was able to exploit a number of vulnerabilities in ServiceNow leading to an effective account takeover to obtain administrative access on the platform as a low privileged user.

Table of Contents

• Exploring the ServiceNow application
• Discovering the XHR request behind ‘Interactive Analysis’
• Enumerating tables using Glide Query Language (GQL)
• Constructing a valid session to escalate privileges to Administrator
• Ending Statement
• Credits
• Disclosure Timeline

Exploring the ServiceNow application

While exploring the ServiceNow application, we determined that the application uses .do pages. .do endpoints are often associated with Java servlets, which are used to process requests and return dynamic content. As these pages query server-side resources, it should be secured against unauthorized or unintended access to prevent users from gaining access to sensitive functionality.

ServiceNow also uses Xml Http Requests (XHR), which is a fundamental technology behind Asynchronous JavaScript and XML (AJAX). The use of these API calls are to allow the performance of various operations without needing a full refresh of the page, which can improve the usability and efficiency of the application. ServiceNow widely uses XHR requests to update records or interacting with certain server-side resources or ‘processors’.

The application also uses the Glide Query Language (GQL), which is an proprietary, object-oriented language that forms the basis for the ServiceNow API to perform CRUD operations on its database. In essence, GQL serves as an abstraction layer for SQL operations that allows developers to perform database operations without interacting with raw SQL.

As a low privilege user, we discovered that it was not possible to directly access many of the application’s functionalities. An example is shown below, where we attempted to view the $interactive_analysis.do page:

However, while navigating through the application, there are some locations that inadventently redirect us to sensitive pages by appending query strings needed to create a valid request. Due to insufficient access control being implemented, we discovered that a standard user could access the $interactive_analysis.do endpoint if the query string was correctly formatted. We can send the following request to successfully access the $interactive_analysis.do page:

https://somehost.service-now.com/$interactive_analysis.do?sysparm_field=password&sysparm_table=sys_user&sysparm_from_list=true&sysparm_query=active%3Dtrue%5Ecaller_id%3Djavascript:gs.getUserID()&sysparm_list_view=&sysparm_tiny_url=f040a8971ba38150d88b624c274bcbb3  

This is shown below:

This is a very interesting functionality, because at first glance it provides the low privilege user with a graphical representation of all the users that are within the application, which could potentially signal that potentially sensitive information is being retrieved through some database.

Discovering the XHR request behind ‘Interactive Analysis

Through further investigation, we determined that the $interactive_analysis.do page, as well as the corresponding report_viewer.do (by accessing the chart from a separate page), sends an XHR request to xmlhttp.do with the “ChartDataProcessor” processor in the POST request. The initial output is quite complex, however it is possible to decode/trim the request and simplify it to the following POST body:

1	sysparm_request_params={"page_num":"0","series":[{"table":"sys_user","groupby":"name","filter":"","plot_type":"horizontal_bar"}]}&sysparm_processor=ChartDataProcessor

Enumerating tables using Glide Query Language (GQL)

We identified that ServiceNow sent an XHR request to xmlhttp.do with the “ChartDataProcessor” processor in a GQL format. As previously mentioned, Glide Query Language is a language that is specifically used for ServiceNow, and the processors were scripts that run server-side that can be called through the XHR request. It is similar to SQL in the format structure sent in the POST request.

We identifed that the following parameters are of interest:

• table: The specific database table used by the application.
• groupby: Retrieves the rows from the specified column. This only retrieves the first 10 values used for rendering the chart/graph, however we can modify the “page_num” to enumerate all the values.
• filter: Filtering the results retrieved from the GQL query.

Leveraging this access control issue we enumerated a number of databases using Burp Suite Intruder and online documentation used by developers of ServiceNow third party plugins. This section of the test required a lot of trial and error to identify potentially useful tables, as there were hundreds of different tables containing varying degrees of sensitive data. We identified that the following tables were particularly interesting for a threat actor:

• sys_db_object: Retrieves the complete list of tables used by the application.
• sys_user: List of all users
• sys_emails: List of all emails

According to the documentation, to be able to view ServiceNow tables we need to have read access to at least the ServiceNow tables sys_db_object, sys_dictionary, and sys_glide_object, and in addition to that to the tables you want to view, including referenced tables. However we were not allowed to access certain fields such as the user_password column in the sys_user table, as this would be an easy method to obtain privilege escalation against the system. Through further enumeration however, we were able to find two additional interesting tables, which will prove to be extremely useful later on:

• sys_user_session: Retrieves the “glide_session_store” and “X-Usertoken” used by any account.
• sys_user_token: Partially retrieves the “glide_user_activity” value.

Constructing a valid session to escalate privileges to Administrator

When testing the application and enumerating the database using the GQL language, we also noted that a valid authenticated session requires the following cookies/headers:

• First method: The glide_user_activity and glide_session_store cookies, and the X-Usertoken header to be correctly set, OR
• Second method: The JSESSIONID cookie and the X-Usertoken header to be correctly set.

As it was possible to leak the tables we assumed that sys_user_session and sys_user_token would be all we needed to steal other accounts. While this was true there proved to be more nuance that made it more difficult to exploit.

The second method initially stood out since the knowledge of a JSESSIONID cookie and the X-Usertoken header would lead to an effective account takeover of any logged in administator user. Ultimately, we were unable to obtain the JSESSIONID from any table, however it may be possible to leverage XSS/CSRF for a successful account takeover, but this was never attempted because we were able to retrieve a valid pathway to exploitation using the first method. The steps are outlined as follows:

Firstly, we can use the following query to retrieve the glide_session_store, which is used to store session information for users. Each record represents a unique session for each user, as well as other related information:

1	sysparm_request_params={"page_num":"0","series":[{"table":"sys_user_session","groupby":"id","filter":"nameCONTAINS[Insert_Admin_Email_Here]^invalidatedISNULL","plot_type":"horizontal_bar"}]}&sysparm_processor=ChartDataProcessor

Note that the results are filtered by the name of the target user, which we can enumerate using the sys_user table - this can also help us determine who the administrators of the instance are. The ^invalidatedISNULL removes all the invalidated or expired tokens.

Secondly, we need to retrieve the X-Usertoken value from the sys_user_session table, which is the CSRF token that the application provides users to ensure that requests made are genuine and not malicious. We require this token to make subsequent requests to the server.

1	sysparm_request_params={"page_num":"0","series":[{"table":"sys_user_session","groupby":"csrf_token","filter":"nameCONTAINS[Insert_Admin_Email_Here]^invalidatedISNULL","plot_type":"horizontal_bar"}]}&sysparm_processor=ChartDataProcessor

The most difficult aspect was to determine a valid glide_user_activity token. A standard glide_user_activity token looks like this:

1	U0N2M18xOmV4VFozT2Eyb2p0OVVWcXY5WktIeUl2L2h5MjFBMlY1d3RnRWkrUVpkZnM9Ok9NNzFIRDV1S0ZBMy90L1plMW5oQXk0OWliYVdBMXFlZUc5cmE3aGdPQ1E9

We can make the following request to retrieve the partial token from the database:

1	sysparm_request_params={"page_num":"0","series":[{"table":"sys_user_token","groupby":"token","filter":"nameCONTAINS[Insert_Admin_Email_Here]","plot_type":"horizontal_bar"}]}&sysparm_processor=ChartDataProcessor

However the values that were retrieved from sys_user_token appeared as follows:

Each glide_user_activity token could be base64 decoded however, revealing that the value from sys_user_token was the first half of the token:

Through trial and error, we determined that the signature section of the token was not sufficiently validated when sent to the server, and it was possible to simply replace or remove the second half of the token to create a valid token.

With all three requirements satisfied, it was then possible to takeover any account including administrative accounts with an active session on the ServiceNow instance. ServiceNow also implements impersonation to allow admin to login into any user account for debugging purposes, we were able to use the admin account to impersonate a spefical user admin account and grant our account admin privileges on the ServiceNow instance.

Ending Statement

Overall, we were able to leverage several vulnerabilities to escalate privileges from a standard user account to administrator of the ServiceNow instance. The following vulnerabilities allowed us to gain effective account takeover:

• Insecure access control in the “ChartDataProcessor” processor
• Overly permissive read access to sensitive tables in ServiceNow database
• Insufficient signature validation of the glide_user_activity token

While the root cause of the issue was due to a insecure access control, the other vulnerabilties discovered and chained together took a medium impact bug to a critical impact bug with a CVSS score of 9.9 - https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H&version=3.1

Credits

The multiple vulnerabilities leading to full compromise of the ServiceNow instance were discovered by Luke Symons, Tony Wu, Eldar Marcussen, Gareth Phillips, Jeff Thomas, Nadeem Salim, and Stephen Bradshaw.