Users of ServiceNow, a cloud-based platform used to manage IT services and processes, could be unknowingly exposing confidential information, including names, phone numbers, internal system details, and active credentials.

Misconfiguration of Knowledge Bases — self-service platforms within ServiceNow where users can create, store, and share information such as articles and guides — could lead to unauthorised individuals gaining access to the system. Many organisations use Knowledge Bases as repositories of sensitive internal information, such as how to reset company passwords, how to respond to a cyberattack, data related to HR processes, and more.

According to a new blog from SaaS security platform provider AppOmni, around 60% of exposures involve older versions of Knowledge Bases that are set up to allow public access by default. Others have “User Criteria” — rules that define specific conditions for users to access or contribute to Knowledge Bases — that are unintentionally granting access to unauthenticated users.

SEE: ServiceNow vs Jira Service Management

ServiceNow is used by 85% of Fortune 500, and over a thousand instances are currently set up incorrectly. Many organisations with multiple ServiceNow instances were found to have consistently misconfigured Knowledge Base access controls, indicating that the settings were either cloned across instances or a fundamental misunderstanding of how they work exists.

Aaron Costello, chief of SaaS security research at AppOmni, said, “This highlights the urgent need for enterprises to routinely check and update their security configurations to prevent unauthorised access and protect their data assets.

“Understanding these issues and how to mitigate them is essential for maintaining robust security in enterprise SaaS environments.”

This is not the first time ServiceNow has been found to have been exposing sensitive data due to user misconfigurations. In 2020, another researcher reported a similar finding where Knowledge Base articles were publicly accessible through a now-secure UI page.

Ben De Bont, chief information security officer at ServiceNow, said, “ServiceNow is committed to fostering collaboration with the security community. We are committed to protecting our customers’ data, and security researchers are important partners in our ongoing efforts to improve the security of our products.”

What are the Knowledge Base misconfigurations?

AppOmni discovered three circumstances whereby businesses were putting their ServiceNow Knowledge Bases at risk of compromise:

1. If using an older version of ServiceNow where the default settings for Knowledge Base allow public access when User Criteria aren’t set up.
2. If the “Any User” and “Any user for kb” User Criteria are used as allowlists. Both of these grant access to unauthenticated users, which administrators may not realise.
3. If administrators do not configure denylists, allowing external users to bypass access controls.

SEE: 6 Best Governance, Risk & Compliance (GRC) Tools for 2024

How attackers can gain access to the Knowledge Bases

According to Costello’s proof of concept, attackers can gain access to misconfigured Knowledge Bases through Public Widgets, such as the “KB Article Page” widget, which displays content from a specific Knowledge Base article.

An attacker can automate requests to find and access articles through the widget using a tool called Burp Suite. This is easier with the KB Article Page widget, which uses a predictable format for article IDs of “KBXXXXXXX,” where X represents a positive integer.

Burp Suite’s Intruder feature can quickly iterate over these integers and identify articles that may be exposed unintentionally. It can then return the body text, which may contain the sensitive data of multiple unsecured articles at once.

How to secure Knowledge Bases against unauthorised access

Run regular diagnostics on Knowledge Base access controls

ServiceNow’s User Criteria diagnostics tool allows administrators to determine which users, both authenticated and unauthenticated, have the ability to access Knowledge Bases and individual articles.

Navigate to /get_public_knowledge_bases.do to identify public Knowledge Bases, and the full diagnostics tool at /km_diagnostics.do to identify the access level of public and non-public users to individual articles.

Use Business Rules to deny unauthenticated access to Knowledge Bases by default

Ensure the “sys_id 6c8ec5147711111016f35c207b5a9969” Business Rule — which adds the Guest User to the “Cannot Read and Cannot Contribute” User Criteria — is activated for Knowledge Bases.