Misconfigured ServiceNow knowledge bases expose sensitive information


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

Incorrectly configured knowledge bases—self-service platforms within ServiceNow where users can create, store, and share information such as articles and guides—could result in unauthorized individuals gaining access to the system. Many organizations use knowledge bases as repositories for sensitive internal information, such as how to reset company passwords, how to respond to a cyberattack, data related to HR processes, and so on.

According to a new blog from SaaS security platform provider AppOmni, around 60% of exposures involve older versions of knowledge bases that are set 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 unintentionally grant access to unauthenticated users.

SEE: ServiceNow vs Jira Service Management

85% of Fortune 500 companies use ServiceNow, and today over a thousand instances are incorrectly configured. Many organizations with multiple instances of ServiceNow were found to be incorrectly configuring knowledge base access controls, indicating that configurations were cloned across instances or there is a fundamental misunderstanding of how they work.

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

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

This is not the first time ServiceNow has been found to expose sensitive data due to user misconfigurations. In 2020, another researcher reported a similar finding where knowledge base articles were publicly accessible via a now-secured 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 incorrect Knowledge Base configurations?

AppOmni discovered three circumstances in which companies were putting their ServiceNow knowledge bases at risk:

  1. If you are using an older version of ServiceNow where the default configuration for the Knowledge Base allows public access when user criteria is not configured.
  2. If the user criteria “Any User” and “Any User for Knowledge Base” are used as allowlists, both grant access to unauthenticated users, something that administrators may not notice.
  3. If administrators do not configure block lists, they allow external users to bypass access controls.

SEE: Top 6 Governance, Risk, and Compliance (GRC) Tools for 2024

How attackers can gain access to 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 the content of a specific knowledge base article.

An attacker can automate requests to search for and access articles through the widget using a tool called Burp Suite. This is made 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 unintentionally exposed. It can then return the body text, which may contain sensitive data from multiple unprotected articles at once.

How to protect knowledge bases from unauthorized access

Run periodic diagnostics on Knowledge Base access controls

ServiceNow's User Criteria Diagnostics tool enables 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 to the full diagnostic tool at /km_diagnostics.do to identify the level of access that public and non-public users have to individual articles.

Use business rules to deny unauthenticated access to knowledge bases by default

Ensure that the business rule “sys_id 6c8ec5147711111016f35c207b5a9969”, which adds the guest user to the “Cannot Read and Cannot Contribute” user criteria, is enabled for knowledge bases.

scroll to top