Security Advisories
4 minutes

Are Your ServiceNow ACLs Publicly Exposing Data?

On October 18, 2023, ServiceNow acknowledged a potential security issue stemming from misconfigurations of Simple List, a widget used simply to retrieve and display data within the Service Portal. This particular vulnerability had been discovered and documented a few days prior by security engineer Aaron Costello through an in-depth blog post.

The objective of this blog is to review the configuration issues that can lead to ServiceNow public data exposure, then provide practical steps for remediation that can be implemented either directly through ServiceNow or via the Obsidian platform.

What is the misconfiguration exposing ServiceNow data?

The ServiceNow platform uses Access Control Lists (ACLs) to limit access to specific resources based on certain requirements. In the absence of a defined ACL, ServiceNow typically defaults to denying all access to a given resource.

This specific security issue occurs when there is an ACL created without proper conditions defined, leaving fields such as Required Role and Condition empty. In such a case, the ACL will default to allow any user to access the resource—including any guest users.

While unauthenticated users are usually highly limited in their access to ServiceNow, they have access to designated public portals and the resources contained therein. Widgets within these portals rely on the underlying ACL system to restrict data access since users are not authenticated. If ACLs are not properly configured, the Simple List widget is one example of how one can inadvertently expose sensitive information to anyone.

What steps can be taken to address this vulnerability?

Remediation of this security issue necessitates the review and proper configuration of ACLs within the tenant to ensure that data access is delegated to the appropriate desired groups. This can be managed directly via ServiceNow, or through a SaaS Security Posture Management (SSPM) platform like Obsidian.

Remediation via ServiceNow for ServiceNow ACLs

Earlier this month, ServiceNow notified customers that they would be performing proactive maintenance to amend ACLs with missing fields and take other steps to secure Service Portal widgets. Still, they recommend customers review their own policies and follow some steps outlined in the knowledge base.

Teams should first review their ServiceNow ACLs to identify any presence of this misconfiguration. If the issue is identified and your team would like to prevent access by unauthenticated users while maintaining access for authenticated users with the public or no role, you can add this line of script to the ACL:

gs.isLoggedIn()

While this specific vulnerability focuses on the Simple List widget, ServiceNow provides broader guidance to combat the inadvertent exposure of data to public users. Review any ACLs with empty conditions, scripts and that have either an empty role or public roles to validate whether or not this access is appropriately delegated.

Remediation via Obsidian for ServiceNow ACLs

Obsidian enables teams to centrally monitor and manage the posture of SaaS applications like ServiceNow. Of the various ServiceNow controls highlighted in Obsidian, these four will surface issues related to this specific vulnerability:

  • Shadow Public Tables: Identify when conditions exist in a table’s ACLs that would still allow unauthenticated users to access the table.
  • Widget table Allow List: Identify which tables are explicitly allowed to grant unauthenticated users access via public widgets. The tables here should be reviewed to ensure this public access is safe and intentional.
  • Widget Allow List: Identify widgets that can be used by unauthenticated users to access tables and columns if the ACLs allow access. Any widget in this list can access any table that the ACL allows, even if it is not explicitly allowed in the Widget table Allow List setting.
  • Widgets bypassing ACLs: Identify public widgets that have client scripts that contain API calls which may bypass the ACL’s on a table.

Obsidian continuously monitors these rules to ensure that these resources are not inadvertently exposed to public users now or in the future.

If your team identifies that this issue exists in your environment and is concerned about potential malicious behavior, Obsidian can facilitate investigations through centralized activity monitoring. Our team has added a pre-made saved search to the platform which filters through ServiceNow event data to identify user activity around these publicly exposed resources. To enable this, navigate to the Activity tab, filter by saved searches, select “Threat Campaigns”, and choose the “ServiceNow Simple List” search.