Major Security Misconfiguration Impacting ServiceNow and Other SaaS Instances Discovered

,

Nearly 70% of Tested Instances Are Leaking Data Through Improper Customer ACL Configurations

By Aaron Costello, Principal SaaS Security Engineer @ AppOmni

Introduction

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?

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.

  1. Review ACLs that are absent of conditional and script based access evaluation, which have either no role, or the public role, assigned to them.
  2. 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.
  3. 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).
  4. 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.

If you’re interested in learning more, please email aolabs@appomni.com and we’ll get in touch with you.

Related Resources