In this two-part series, we began by examining the structure of ServiceNow, and the relationship between articles, pages, and widgets. Now, in Part 2, we discover how a widget misconfiguration can be exploited. To read the intro (Part 1), click here.

ServiceNow is one of the world’s most popular IT service management (ITSM) platforms, used by about 80% of Fortune 500 companies. Its knowledge base is one of the service’s most visible features, used to share sensitive company information, include one-time passwords, personal information, or internal links that aren’t intended for public consumption.

The Widget’s Misconfiguration That is Exposing Your Knowledge Base

In our previous post, we detailed the relationship between articles, pages, and widgets.

Configurations within ServiceNow were designed to prevent unauthorized users from accessing data using web browsers. However, we wanted to see if we could access an article through the widget rather than a web page.

The first thing to notice in this widget is that the checkbox next to Public is filled in. This is public by default, and means that anyone can access the widget without authenticating themselves first.

We took a look at the server-side code for this widget.

The code requires a “sys_id” or “sys_kb_id” GET parameter. This is used to query the “kb_knowledge” table, which stores all the knowledge articles. The parameter can either be the article’s unique sys_id (for example, d2bda21e93238e10aaf6fe818bba10a5) or its article number (KB0010001). Both the sys_id and the article number can be used interchangeably to query the database for the specific article.

The subsequent lines of code populate the “t” variable with comprehensive article information, including the article content, author details, and additional metadata. This “t” variable corresponds to the “data” object that will be returned to the client, encapsulating all the relevant information about the requested knowledge base article.

First, perform a GET request to the instance’s URL to communicate with the “KB Article page” widget to obtain all available information for the page.
https://INSTANCE_ID.service-now.com/

Request:

In the response, note the set-cookie “JSESSIONID” and the “g_ck” javascript values:

Both the set-cookie and javascript values are used in the next step.

Next, create a HTTP POST request to the following URL, which allows us to directly access the KB Article page and read article KB0010001.

https://INSTANCE_ID.service-now.com/api/now/sp/widget/c6545050ff223100ba13ffffffffffe8?sys_id=KB0010001
(Note the “c6545050ff223100ba13ffffffffffe8” in the URL is the widget sys_id)

Make sure to set the cookie JSESSIONID as the value received in the last response and use the g_ck value as the request X-UserToken HTTP header. The Content-Type header should be “application/json.”

Request

Response

As you can see, the response contains all the information exposed in the article, including article text, unique ID (sys_id), the article knowledge base name and sys_id (displayed in “kbId” in the response), and the author’s name.

Scaling this Technique to Capture All Articles

Once we realized that a widget could be used to download one article, we set our sights on retrieving entire databases of data, including all exposed public articles

We began by analyzing the widget structure of the KB_search page (older instances of ServiceNow call this the kb_find.do) to identify the widget responsible for article searches.

Two key widgets stood out: Knowledge Search and Knowledge Result. Contrary to what their names suggest, Knowledge Result was the widget that contains the core search logic. We examined the server-side code of the Knowledge Result widget to better understand how it handles article searches:

Note that some of the code was removed for better readability.

The call responsible for obtaining all public articles is the getResults function. It receives the input.payload parameter, which is derived from the POST request body. In order to generate this type of request, programmers left a hint in the code which is commented out and seems deprecated.

The crucial part of this code is the getResults function. It takes an input.payload parameter, which comes from the POST request body, and uses it to fetch the search results.

To understand what this payload should look like, we referred to some commented-out code that appears to be a template for constructing the search parameters:

This object structure gives us insight into the expected payload format for the search request. To retrieve all public articles, we can construct a POST request with a payload similar to this obj object, adjusting the parameters as needed for our specific search requirements.

By understanding this structure, we can effectively interact with the ServiceNow Knowledge Base search functionality, allowing us to programmatically search for and retrieve articles.

Request:

The response:

This approach allows us to access all publicly available articles within the ServiceNow instance.

Misconfigurations and the Shared Responsibility Model

ServiceNow security is jointly shared between the company and its customers. ServiceNow, like most SaaS applications, is responsible for ensuring the security of the application. That includes the platform design, physical security of its data centers, network security, and vulnerabilities, as well as other elements.

ServiceNow customers are responsible for securing access to the data within their ServiceNow tenants. That means using the security settings, such as MFA or privacy configurations, that limit access to authorized users.

In effect, that means that ServiceNow must build an app that is secure, while its customers must take care to lock the door. In the misconfiguration described here, customers did not use the privacy tools included to prevent outsiders from accessing their knowledge base articles. SaaS Security Posture Management (SSPM) is designed to detect misconfigurations and enable security teams to secure their applications.

Remediation

SaaS applications are secured through a shared responsibility model. In this case, ServiceNow is responsible to ensure there are no vulnerabilities in the application, while organizations are responsible for ensuring that their instances are configured securely to meet their needs.

This issue is clearly one of configurations.

To prevent data leaks of this type, organizations should configure their knowledge base articles and public pages as private. For Adaptive Shield customers, these configurations are part of our platform’s security checks. All other users should follow these guidelines to secure their knowledge base content.

Make Knowledge Base Articles Private

Set “Can Read” user criteria on the knowledge base as non-public. To do so:

1. Open ServiceNow → All → Search for “Knowledge Base״ under Administration
2. Select the knowledge base
3. Scroll down and click “Can Read” → Edit
4. Verify that the user criteria do not have a public role
5. Click Save and Update

To check if a user criteria has a public role, review the user criteria and verify that no role or containing role is set to public and that no user contains guest user.

As part of its security checks, Adaptive Shield verifies that no roles or containing roles have public roles assigned to them.

Add guest user to “Cannot Read” by following these steps

1. Open ServiceNow → All → Search for “Knowledge Base” under Administrations
2. Select the knowledge base
3. Scroll down and click “Cannot Read”
4. Verify that the user set is “Guest User”
5. If the user is not set as “Guest User,” click Edit
6. Search Guest User → Double Click on “Guest User” to add it
7. Click Save and Update

As part of its security checks, Adaptive Shield verifies that Guest User exists across all knowledge bases.

Make Public Pages Private

To change public pages to private, follow these steps:

1. Open ServiceNow → All → search for “sys_public.list”
2. Click on the funnel icon next to the search
3. Set the following filters: ID Contains “kb”, OR ID Contains “articles”, OR ID contains “find”, OR ID Contains “search”
4. You will receive a list of pages. Verify that they are not publicly accessible by finding the Public checkbox on each page and removing the checkmark if it is filled in.

In newer ServiceNow releases, the steps required are slightly different:

1. Open ServiceNow → All → search for “sp_page.list”
2. Click on the funnel icon next to the search
3. Set the following filters: ID Contains “kb” OR ID Contains “find” OR ID Contains “article” OR ID Contains “search”.
4. You will receive a list of pages. Verify that they are not publicly accessible by finding the Public checkbox on each page and removing the checkmark if it is filled in.

If you are unable to see the Public field on the page, click on the gear icon at the top of the page, and double-click on the “Public” field to add it.

Adaptive Shield’s security checks automatically verify that these pages are not publicly accessible.

Responsible Disclosure

The scale and nature of this exposure raised significant security concerns, and it appeared in about 30% of the accounts we reviewed. In response, we initiated a responsible disclosure process, prioritizing communication with companies where we identified critical misconfigurations. We reached out to these organizations to alert them of the potential risks and offer guidance on securing their ServiceNow instances to prevent unauthorized access to sensitive data.

This discovery underscores the critical need for organizations to implement robust access controls, regularly audit their public-facing assets, and carefully review shared content to safeguard confidential information in SaaS environments.

About Adaptive Shield

Adaptive Shield is a SaaS Security Posture Management (SSPM) & Identity Threat Detection and Response (ITDR) company, dedicated to enabling organizations to be on top of their SaaS security. Our research team reviews all application configurations to better understand the implications of each setting and the potential risk exposed by misconfigurations. We work with SaaS developers to make SaaS safer.

Our SSPM & ITDR platform integrates with over 160 applications out of the box including ServiceNow security, covering misconfiguration management, human and non-human identity security, and any suspicious behavior in the ecosystem. For more information visit adaptive-shield.com

The post Part 2: Can Just Anyone Access Your ServiceNow Articles? appeared first on Adaptive Shield.

*** This is a Security Bloggers Network syndicated blog from Adaptive Shield authored by Dan Meged. Read the original post at: https://www.adaptive-shield.com/blog/part-2-can-just-anyone-access-your-servicenow-articles/