Over 1,000 ServiceNow instances found leaking corporate KB data


Over 1,000 misconfigured ServiceNow enterprise instances were found exposing Knowledge Base (KB) articles that contained sensitive corporate information to external users and potential threat actors.

The exposed information includes personally identifiable information (PII), internal system details, user credentials, access tokens for live production systems, and other essential information depending on the Knowledge Base topic.

Aaron Costello, chief of SaaS security research at AppOmni, found over a thousand ServiceNow online instances that are unintentionally exposing company information due to configuration issues.

This is still a significant problem despite ServiceNow’s updates in 2023 explicitly aimed at improving Access Control Lists (ACLs), but which didn’t apply to KBs.

Exposed KB articles

ServiceNow is a cloud-based software platform organizations use to manage digital workflows across various departments and processes.

It is a complete solution that incorporates IT service and IT operations management, HR tasks, customer service management, security tools integration, and a knowledge base.

The knowledge base feature acts as a repository of articles where organizations can share how-to guides, FAQs, and other internal procedures for users authorized to view them. However, as many of these articles are not meant to be seen publicly, they can contain sensitive information about an organization.

After a 2023 report by Costello on ServiceNow data exposure, the company rolled out a security update that introduced new ACLs to prevent unauthenticated access to customer data. However, AppOmni says that most ServiceNow KBs utilize the User Criteria permission system rather than ACLs, making the update less useful.

Furthermore, some public-facing widgets that expose customer information did not receive the 2023 ACL update and continue to allow unauthenticated access.

Due to this, Costello says that misconfigured access controls on public-facing ServiceNow widgets can still be used to query data in KBs without requiring any authentication.

“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,” AppOmni says in a new report published today.

Using tools like Burp Suite, a malicious actor can send a large number of HTTP requests to a vulnerable endpoint to brute-force the KB article number.

The researchers explain that Knowledge Base article IDs are incremental in the format KBXXXXXXX, so a threat actor can brute force a ServiceNow instance by incrementing the KB number starting at KB0000001 until they find one that is unintentionally exposed.

AppOmni developed a proof-of-concept attack to illustrate how an external actor can access a ServiceNow instance without authentication, capture a token for use in HTTP requests, query the public widget to retrieve KB articles, and brute-force the IDs of all hosted articles.

Sample request (left) and token interception (right)
Sample request (left) and token interception (right)
Source: AppOmni

Blocking unauthorized access

AppOmni suggests that SecureNow admins protect KB articles by setting the appropriate ‘User Criteria’ (Can Read/Cannot Read), blocking all unauthorized users.

Criteria like “Any User” or “Guest User” lead to configurations that don’t protect the articles from arbitrary external access.

If public access to Knowledge Bases isn’t explicitly needed, administrators should turn it off to prevent articles from being accessible on the internet.

The researchers also highlight specific security properties that can guard data from unauthorized access, even in the case of misconfigurations. These are:

  • glide.knowman.block_access_with_no_user_criteria (True): Ensures that access is automatically denied to authenticated and unauthenticated users if no User Criteria are set for a KB article.
  • glide.knowman.apply_article_read_criteria (True): Requires users to have explicit “Can Read” access to individual articles, even if they have “Can Contribute” access to the entire KB.
  • glide.knowman.show_unpublished (False): Prevents users from seeing draft or unpublished articles, which may contain sensitive, unreviewed information.
  • glide.knowman.section.view_roles.draft (Admin): Defines a list of roles that can view KB articles in a draft state.
  • glide.knowman.section.view_roles.review (Admin): Defines a list of roles that can view KB articles in a review state.
  • glide.knowman.section.view_roles.stagesAndRoles (Admin):  Defines a list of roles that can view KB articles that are in a custom state.

Finally, it is recommended to activate ServiceNow’s pre-built out-of-the-box (OOB) rules that automatically add Guest Users to the “Cannot Read” list for newly created KBs, requiring admins to specifically give them access when needed.



Source link