A Technical Analysis and Lessons From The Recent Service Now Misconfiguration Risks

By Aaron Costello, Principal SaaS Security Engineer, AppOmni

Over the past several weeks, ServiceNow has made significant security changes to their platform for all customers in response to my research findings into ACL misconfiguration risks. These security measures were incremental in nature and attempted to address role-less ACLs and the behavior of specific platform Widgets. While a high level overview of the modifications was provided by ServiceNow, it is imperative that customers understand the nature of these changes at a technical level, in order to avoid regressing their organization’s data security posture in the future if they are again misconfigured.

In the interest of sharing my research with the SaaS security community, I will walk through the entire chain of events from the inception of my latest independent research on ServiceNow titled the ‘Data Exposure and ServiceNow: The Elephant in the ITSM Room’ article, to ServiceNow’s response and analysis on Nov 2, 2023.

‘Data Exposure and ServiceNow: The Elephant in the ITSM Room’ – October 14, 2023

Last month, as part of my independent, ongoing research into SaaS security, I released an article discussing capabilities within the ServiceNow platform that could be leveraged to extract record information while entirely unauthenticated. Prior to doing so, I made a best effort to contact affected organizations that had a public vulnerability program and to make them aware of the risk.

For an organization to be susceptible to this kind of data exfiltration, the following conditions must be met:

• The Simple List or Unordered List widget(s) must be marked as publicly available, which they are by default
• The organization must have misconfigured an ACL, User Criteria, or other access control in a manner that causes the information it is protecting to be publicly available. In some cases, vulnerable ACLs were provided by ServiceNow out of the box (OOB) as part of the Core platform

Once a platform configuration meets all of the above, an unauthenticated attacker can remotely query the widgets with arbitrary table and field names, and subsequently retrieve record data. Organizations who did not further secure certain ServiceNow-provided ACLs were among the worst affected as information on internal users, installed applications, service catalog items, asset items, and CMDB entries were disclosed by default. In total, of all organizations tested against, over 90% were leaking some form of sensitive information.

Within the article, I had made a number of recommendations that organizations could take to both mitigate and prevent this data exposure, and days later ServiceNow addressed this security risk for their customers and rolled out mitigatory measures to all instances.

ServiceNow Rolls Out ACL Modifications to Mitigate Risk – Oct 18 & Oct 20

Over the course of several days, ServiceNow made changes to customer ACLs which did not contain any role or condition and deployed the changes to customer instances. These changes not only included modifications to core platform ACLs, but also ACLs on customer created tables. This was to prevent the exposure of data resulting from blank ACLs provided by ServiceNow.

This change was the addition of an ACL script, and can be seen within all formerly empty ACLs. Below, is a snippet of the ACL script:

answer = gs.getSession( ) .isLoggedIn( ) ;

if (!answer) {

   answer = gs.getProperty(‘glide.security.allow_unauth_roleless_acl’, false);

}

The ACL initially checks if the user is authenticated. If not, the ACL references a system property, glide.security.allow_unauth_roleless_acl, to determine whether access should be granted or not. By default, this system property is ‘false’, and disallows unauthenticated access. In the event this property does not exist, the system will deny access to the unauthenticated user.

It is important to note that this mitigation only applies to ACLs that existed at the time of the fix, and as such ACLs created in the future are not protected. I strongly recommend that organizations create a Business Rule (BR) which adds this script to newly created ACLs. Here is an example BR that can do this.

Organizations may take this one step further and make modifications to the business rule so that ACLs that are modified to remove roles and conditions will automatically inherit this script also.

Discussion with ServiceNow Security – Oct 20

After the ACL changes were implemented, I had a discussion with a member of the ServiceNow security team during which I recommended the introduction of further access control protections at the Widget level. This was to prevent additional exposures in the future that could result from newly created ACLs on existing or new tables.

Widget Modifications – Oct 25

Stemming from my prior discussion with ServiceNow, changes to a number of default public Service Portal widgets were introduced to all customer instances. Below are the widgets that had been modified and their significance:

Widget Name	Widget Sys ID	Reason
Simple List	5b255672cb03020000f8d856634c9c28	Allowed for the extraction of record data using user-supplied table and field names
*Unordered List	489a4b1bcb13020000f8d856634c9c67	Allowed for the extraction of record data using user-supplied table and field names
Incident Standard Ticket Actions	9bd06ce173070010cbb654eb7df6a7d4	Allowed for the modification of incident tickets using user-supplied ticket ID
Variable Summarizer	3e2bcf17b7220010bcd50718ee11a956	Allowed for extraction of variable information using user-supplied table and record ID
*News Ticker	a9a0b0dec3623100c8b837659bba8f80	Allowed for the extraction of record display field data using a user-supplied table

*To remotely control the supplied parameters to GlideRecord / GlideRecordSecure used in these widgets, an actor must use a widget proxy such as widget-modal to gain access to the `options` global variable.

Crucially, in order for an unauthenticated actor to have maliciously leveraged any of the above widgets prior to the modifications, they were required to satisfy any access controls on the table and field that they are attempting to interact with through the widget, in addition to the widgets themselves being marked as ‘Public’.

The mitigatory measure taken for all of the above was the introduction of a single function call within the widget’s Server Script: new SNCACLWidgetUtil( ).hasPublicAccess(param1,  param2)

 SNCACLWidgetUtil is a newly introduced globally scoped Script Include that was created for the sole purpose of providing further access control checks to widgets that have the ability to query arbitrary tables from user-input. The function, `hasPublicAccess()` is the only function called directly from these widgets and takes two parameters. The first is the sys_id of the calling Widget, and the second is the table that the widget is attempting to access. With this information, the function then attempts the following checks (in order):

As you can see in the above, there are an additional three system properties. Whilst these are referenced, they have not actually been created within customer instances. During the checks against them, they default to deny behavior if they do not exist.

• glide.service_portal.widget.enforce_public_check – When true, the following system property checks will occur. If false, will grant access to the widget immediately.
• glide.service_portal.widget.allow_list – Contains a list of widget sys_ids that have been approved by the organization as ‘accessible’. If the widget being accessed is in this list, immediately grant access to the widget. If the widget is not in this list, perform the following property check.
• glide.service_portal.widget.table_allow_list – Contains a list of table names which have been approved by the organization as ‘accessible to widgets’. If the table that the widget is attempting to query is in this list, then grant access to the widget. If not, deny access to the widget.

So unlike before, where access to data via widgets only checked the access control on the Widget itself and the access controls on the data being accessed, this script adds an additional layer of security that slots between these checks.

This layered approach is an overall positive addition to the platform as it does not make it overly difficult for organizations using widgets for legitimate business use-cases to adjust to the changes. That being said, there are some nuances and/or shortcomings that must be understood with these changes.

Shortcomings and Workarounds

The combination of mitigatory measures taken by ServiceNow spanning from Oct 14th – Oct 25th have undoubtedly resulted in an improvement to both data security and widget security. Nonetheless, I have spotted potential flaws that organizations may be unaware of that I list out below:

1. This is a point-in-time fix: As previously mentioned, the script added to ACLs is a point-in-time fix. Any ACLs created past 25th October will not have this script added. Customizations such as custom table ACLs, scoped application ACLs, and ACLs belonging to newly installed modules may re-introduce risk to your organization.
   
2. Widget instances: Each widget instance record represents an API endpoint, and when accessed they load a widget with predefined inputs. While these inputs are not user-supplied, plenty of OOB public widget instances exist that use Simple List to return record data to the user from sensitive tables. Referring back to the SNCACLWidgetUtil.hasPublicAccess() flow diagram, you may notice why this is of concern. As part of the third check, the URL path being accessed is compared to `/api/now/sp/widget’ and if it does not match, access is granted. Even if a widget instance is using Simple List, it is accessed via the widget instance API endpoint which starts with ‘/api/now/sp/rectangle’. Thus, circumventing all of the checks that follow in the script.
   
3. Knowledgebase: The knowledgebase, which from my Widget research was among the most vulnerable resources, has had no additional ServiceNow supplied mitigations implemented after extensive analysis. There are several reasons for this:
   • The kb_knowledge ACL was not updated by ServiceNow to include the script which checks against public access. This was likely due to the fact that User Criteria is the primary form of access control for knowledge base articles.
   • There are multiple public widgets currently that can be used either standalone, or chained together, to extract the contents of knowledge base articles without an unauthenticated actor needing to know any prior information. And these public widgets do not implement the SNCACLWidgetUtil.hasPublicAccess() function.

A threat actor leveraging a combination of the above, such as (1) and (2) together, could extract sensitive information from a table if an ACL was newly created for a table that has a corresponding widget instance. Even worse, capitalizing on one of the many knowledge base related widgets to circumvent all of the newly supplied ServiceNow checks.

Conclusion

The only guaranteed preventative measure to protect against data exposure is not through heavy reliance on these new system properties or access controls at the Widget / Widget Instance level. But rather, ensuring both ACLs and User Criteria are securely implemented and maintained through routine audit.

When confronted with hundreds of ACLs and Knowledge Base articles, the most efficient way to ensure data security is through the use of an SaaS Security Posture Management (SSPM) tool such as AppOmni. Daily scans against both security related flags at the resource level and the underlying access controls will grant an eagle-eye view of your entire platform’s data security. This allows your security team to focus on impact analysis and subsequently issue remediation, both of which are supplemented by AppOmni.

Furthermore, my research has made clear the need for transparent collaboration between security researchers and SaaS vendors through an open-channel. Platforms such as HackerOne have been bridging this gap successfully for many years. Yet, barriers such as the availability of SaaS vendor’s vulnerability programs to the public, and extensive time it takes for individuals unfamiliar with SaaS to triage issues, remain a common problem. It is my own opinion that if direct collaboration with SaaS vendors improves, it will only seek to benefit all parties, with their customers benefiting the most.

This research and content was conducted in adherence with AppOmni’s established Rules of Engagement.

---

Related Resources