Over the past year, I’ve conducted extensive research into the ServiceNow platform to identify areas of the product that could be misused for the purpose of data exfiltration. The release of this research has led to some promising developments in the security of the ServiceNow product. These developments include:

• The introduction of new security properties that prevent select widgets from granting unauthenticated users access to data unless explicitly set to do so
• The inception of ‘Security Attributes’, a new addition to Access Control Lists (ACLs). This includes a specific check to verify if unauthenticated users are allowed access to the data in question. This new Security Attribute check was added to most ACLs by default.

This double-layered approach to data security was a welcome change. But unfortunately, these changes did not provide any added protections to one of the most prevalent sources of data exposure; the Knowledge Base (KB). While there are legitimate uses for externally facing information, KBs can be a treasure trove of sensitive internal data intended only for the eyes of an organization’s staff.

By leveraging my previous research and introducing new testing methodologies over the span of a year, I’ve uncovered that over 1,000 individual instances tested had unintentionally exposed data from KBs. This equates to nearly 45% of total enterprise instances I had tested during that time. In many of these cases, it was observed that organizations that have more than one instance of ServiceNow had consistently misconfigured KB access controls across each one. This could indicate a systematic misunderstanding of KB access controls or possibly the accidental replication of at least one instance’s poor controls to another through cloning. These instances were considered by the affected organizations to be sensitive in nature, such as PII, internal system details, and active credentials / tokens to live production systems.

Why are KBs still exposing data?

Prerequisite: For those unfamiliar with the concept of User Criteria, I highly recommend reading up on the topic within the official ServiceNow documentation before proceeding.

In the previous section, I mentioned the effective two-pronged approach that ServiceNow took to tackle unauthenticated data exposure. The root cause (misconfigured ACLs), was mitigated through the default addition of a security attribute to out-of-the-box (OOB) ACLs, while the avenues for data exposure (public widgets) were mitigated through the addition of system properties which restricted what data that the widgets could query.

There are two reasons why this proved ineffective to secure the KB:

1. Public widgets that can be used to access the content of KB articles did not receive the update, which prevented them accessing data without being added to an allow-list.
2. The vast majority of KBs are secured using User Criteria as opposed to ACLs, rendering the addition of the ‘UserIsAuthenticated’ Security Attribute redundant since it is an ACL exclusive feature.

Whilst this explains why the security of the KB has not improved as of late, it doesn’t necessarily explain why organizations are struggling to secure it in the first place. Historically, the feature has struggled from a security standpoint, with another researcher in 2020 reporting that he had found a large amount of sensitive data using a previously public UI page, which has long since been secured.

Through analysis of examined affected instances, I believe the current insecure state of most KBs comes down to several key points:

1. The main guardrail, a security property that denies access by default to KBs without User Criteria, is enabled by default for instances created since the Orlando release. Most enterprise instances have been around for far longer, causing them to still retain the previously insecure ‘allow public access by default’ value. This was the case for around 60% of enterprise instances analyzed. Additionally, when this property is securely configured, only defining a ‘Can Contribute’ on a KB will still allow unauthenticated users to read insecure articles within it. On top of this single guardrail, there is a complicated relationship between multiple other system properties and how they affect access depending on how controls are implemented for a KB.
2. The OOB User Criteria can be misleading to the untrained eye. Whilst there is an explicit ‘Guest User’ criteria for granting unauthenticated access, many administrators are unaware that other less-explicitly named criterias also grant access to unauthenticated users. Namely, the ‘Any User’ and ‘Any user for kb’ criterias which tend to be incorrectly used as an allow-list.
3. In cases where User Criteria is set on a KB, it is more often than not only set on the allow-lists (‘Can Read’) and the deny-list (‘Cannot’ Read’) is ignored as a result. Because of the complicated nature of User Criteria, this can allow external users to slip through the cracks and be granted access.

At the bottom of this article, I’ve taken the liberty of mentioning how many of these factors can be better mitigated. But prior to that, I’d like to demonstrate exactly how an unauthenticated malicious actor could access an insecure KB article.

Proof of Concept

Prerequisite: A HTTP proxy such as Burp Suite is required to conduct the proof of concept.

There are many widgets that can be used while unauthenticated to retrieve information from KB articles. However for the sake of this PoC, I will showcase the use of the ‘KB Article Page’ widget and will use it against a KB that has been purposefully made public through insufficient access controls. The primary reason for using this widget is that it allows for easy brute-forcing of article IDs, which are incremental in nature and of the format KBXXXXXXX where X represents a positive integer. This integer can be automatically incremented, starting from KB0000001, using Burp Suite’s Intruder feature to quickly iterate over and identify articles that may be exposed unintentionally. This is in contrast to other widgets that expect the UUID of the article which is extremely difficult to guess.

1. Ensure Burp Suite is proxying HTTP requests. Navigate to your ServiceNow instance, but do not authenticate.
2. Within the History tab of Burp Suite, locate any HTTP request to the instance and send it to the Repeater tab.
3. Look for another request in Burp Suite History to the root path of the site (/) and locate the g_ck javascript variable in the response as seen below. Copy its value.

4. Navigate to the Repeater request from step (2) and make the following changes:

• Modify the HTTP path to the following /api/now/sp/widget/c6545050ff223100ba13ffffffffffe8?sys_id=KB_NUMBER_HERE’. Replace KB_NUMBER_HERE with the number of the known public KB article.
• Change the HTTP verb/method to POST. 
• Add the following header: X-Usertoken and provide it the value of g_ck copied from step (3).

Once these changes are made, the request should look similar to the following:

5. Send the request.

In the above response, the following information is shown with the most useful highlighted in orange:

• kbName: The name of the owning KB
• author: The name of the author who wrote the article
• short_description: The short description field of the article
• text: The full content of the article
• rating: The current rating of the article
• publishedUtc: The date in UTC TZ when the article was first published
• sys_id: The record UUID of the article
• categoryDisplay: The plaintext category name to which the article belongs

As demonstrated, all sensitive data is returned within the response, particularly the short_description and text fields. Evidently, this widget’s ability to quickly iterate over KB numbers to rapidly retrieve information is extremely useful for an attacker who can send requests in quick succession and even facilitates them to attack multiple ServiceNow instances simultaneously without much bandwidth.

How to Mitigate ServiceNow KB Data Risks

Be Aware of Relevant Security Properties 

As mentioned earlier, the KB security properties can act as important security guardrails that greatly affect how access control is dictated when both internal and external users attempt to access data. Below is a curated table of these properties, in descending order of risk and importance in my opinion.

*Note: If ‘Can Contribute’ is set, but no ‘Can Read’ / ‘Cannot Read’ is defined on the owning KB, unauthenticated users will have access to insecure articles within it.

Activate OOB Business Rule(s) to Prevent Unauthenticated Access By Default

When it comes to security, I always advise organizations to take advantage of the powerful customization capabilities that ServiceNow is known for. In mid 2022, ServiceNow introduced a Business Rule (sys_id 6c8ec5147711111016f35c207b5a9969) which adds the Guest User to the Cannot Read and Cannot Contribute User Criteria of a KB when it is first created. It is imperative that Administrators ensure this Business Rule is still activated on their platform since User Criteria prioritizes ‘Deny’ over ‘Allow’. This has the added benefit of still preventing access in the event that the ‘Can Read’ criteria accidentally includes the Guest User.

Routinely Run Diagnostics on KB Access Controls

ServiceNow’s built-in User Criteria diagnostics tool allows administrators to quickly determine which users, both authenticated and unauthenticated, have the ability to access both KBs and also individual articles. To identify which KBs are public, administrators may navigate to /get_public_knowledge_bases.do of their instance. To pinpoint individual articles that can be accessed by the public or to investigate the level of access possessed by non-public users, I recommend leveraging the full diagnostics tool located at /km_diagnostics.do of the ServiceNow instance.

Maintain Communication with ServiceNow

Lastly, it’s imperative that organizations maintain current contact information with ServiceNow to receive communications on the latest security updates and outreach from the ServiceNow security team. In January 2024, ServiceNow sent communications, with follow-ups, to customers who may accidentally have their KBs exposed to public access.

Bolster Your SaaS Security with AppOmni

Since April 2023, I’ve found over 1,000 enterprise instances were exposing sensitive information unintentionally, including PII, internal system details, networking or infrastructure diagrams, and even credentials. With these findings, there’s no doubt that KB articles could be a valuable resource for attackers. In the previous sections, I’ve highlighted the ways in which organizations can help protect themselves from unintended data exposure to the anonymous world. However, without comprehensive customization, it’s difficult to automate on-platform diagnostic processes, and for large instances it can quickly become cumbersome.

At AppOmni, we’ve implemented a combination of best practice policies and automated scanning to ensure that organization’s keep their KB access locked down from unintended access for the foreseeable future. These security capabilities are incorporated into the AppOmni SSPM solution through pioneering research such as this, conducted by AppOmni Labs, in an ongoing effort to identify the known and unknown risks to SaaS.

The State of SaaS Security 2024 Report

Learn how cybersecurity leaders are overcoming obstacles, boosting cyber resilience, and key steps to secure your SaaS environments. 

Additional Resources

The post Enterprise ServiceNow Knowledge Bases at Risk: Extensive Data Exposures Uncovered appeared first on AppOmni.

*** This is a Security Bloggers Network syndicated blog from AppOmni authored by Aaron Costello, Chief of SaaS Security Research, AppOmni. Read the original post at: https://appomni.com/ao-labs/servicenow-knowledge-bases-data-exposures-uncovered/