Major Security Misconfiguration Impacting ServiceNow and Other SaaS Instances Discovered
Over the past decade, SaaS products have evolved to become more security conscious. These evolutions and iterations have introduced additional security controls such as data classification, platform encryption, support for SSO-based authentication, and more. However, the fundamental concept of Role-Based Access Control (RBAC) has remained a consistent method for granting permissions to users, thus provisioning access to resources on a SaaS platform.
Earlier this year, as part of my ongoing security research into the ServiceNow platform, I discovered external interfaces exposed to the public that may be utilized by a malicious actor to extract data from records. AppOmni’s analysis of ServiceNow instances, similar to our earlier analysis of other SaaS providers like Salesforce, showed that nearly 70% of tested ServiceNow instances were vulnerable to this misconfiguration, which could allow an unauthenticated user to extract data. Further investigation into these findings highlight that the root causes for data exposure are a combination of misconfigured Access Control Lists (ACL) and overprovisioning of permissions to guest users.
An important aspect of RBAC implementations on SaaS has been the ability to provision the public with access to information within your ‘database’. This has largely been to support the popular use cases for publicly facing sites — which commonly include forums, online shops, customer support sites, and knowledge bases — and other workflows that are externally facing.
This is a prime example of the conflict between “least privilege” and “least friction” that plays out across cybersecurity. Unfortunately, failure to follow the concept of least privilege is a consistent issue that AppOmni has identified whilst working with large organizations that are leveraging SaaS solutions. As organizations introduce further on-platform customizations and onboard new users, we have noticed that these actions often have a direct impact on their security posture. To combat this, the AO Labs team is committed to the discovery and mitigation of novel threat vectors to the most business-critical SaaS platforms before bad actors can take advantage of them and wreak havoc.
Am I Vulnerable?
Option 1: Use AppOmni’s SaaS Security Analyzer to determine whether your instance is impacted by this misconfiguration.
To assist organizations that want to determine if they are impacted, AppOmni has released a web application to evaluate ServiceNow instances for this particular data exposure. To take advantage of this offering, simply fill out the form and our team will begin the request approval process. This process includes confirming that you are associated with and/or responsible for the ServiceNow instance in your request. Once approved, we will evaluate your ServiceNow instance and notify you either that you are impacted by this misconfiguration, or that you are not impacted.
It’s important to note that without access to the metadata of your organization’s ServiceNow schema, we cannot evaluate the security of custom tables and fields.
Option 2: Manually evaluate your instance and remediate
Recommended Remediation Steps
Administrators should perform the following checks on a regular basis to ensure that access to sensitive information is not being provisioned to external unauthenticated users.
- Review ACLs that are absent of conditional and script based access evaluation, which have either no role, or the public role, assigned to them.
- Review User Criteria (UC) and the resources to which those criteria are granting access. In particular, focus on any UC in which the ‘Guest’ user is assigned to or contains the ‘public’ role. This includes the ‘Any User’ and ‘Guest’ built-in UCs.
- Review resources that can be directly assigned the ‘public’ role to grant access, or indirectly made accessible to the public through another mechanism (such as publishing a report).
- Review System Properties that may dictate access to records through a provided role or list of roles.
In addition to the above, use of the Explicit Roles plugin is another option. However, this plugin directly modifies roles and ACLs, which can have adverse effects on the functionality of your instance or require considerable reconfiguration to restore existing functionality after its installation. Note that this plugin cannot be removed once activated. To check if this plugin is already installed, search for the existence of ‘com.glide.explicit_roles’ within System Definition > Plugins.
If this plugin is not installed, you can install it indirectly via the ‘Customer Service’ plugin (com.sn_customerservice) or the ‘Human Resources Management’ plugin (com.snc.hr_management).
Once installed, the snc_internal and snc_external roles provide an easier way of granting access specifically to internal users or to customers and partners respectively, without needing to also grant access to the public. Replacing instances of the public role where possible with either of these roles, depending on the use case, is highly recommended.