ServiceNow Quietly Addresses Unauthenticated Data Exposure Flaw From 2015
ServiceNow is issuing a fix for a flaw that exposes data after a researcher published a method for unauthenticated attackers to steal an organization’s sensitive files.
Security researcher Aaron Costello highlighted apparent issues with the default configurations of ServiceNow’s widgets, allowing for personal data to be exposed.
ServiceNow’s widgets act as powerful APIs for the platform’s Service Portal. Despite a code change earlier this year to improve safety, the default configuration of these widgets was to set their records public, meaning that if they’re left unchanged, they will return the type of data an attacker specifies.
Before quietly issuing a fix on October 20, ServiceNow told The Register that it was aware of the research describing “a potential misconfiguration issue.” However, it didn’t say it would make any changes, adding that it works regularly with customers to ensure security configurations are properly implemented for each unique organization.
“We proactively work with customers on the ongoing safety of their security configurations, including Access Control Lists (ACLs), to ensure they are properly structured and aligned to their intended purpose,” a spokesperson said.
“We make these protocols extensible so our customers can configure them based on their unique security needs – from companies with public portals providing broad access to information to enterprise-specific use cases where access is restricted to select users.”
How data is exposed
The issue revolves around ServiceNow’s widgets that are used extensively throughout the platform.
As many Reg readers know, Widgets are like APIs that can take input parameters from a user – a table name and field name. A table is like a type of data being stored, such as user data, and field name refers to a field within that table, like first names. By passing specific table and field names into a call to a widget, an unauthenticated user could retrieve the data they want.
Access Control Lists (ACLs) govern the access for resources within ServiceNow, like tables, but not widgets themselves. These have a three-part check for roles, conditions, and scripts. If an ACL doesn’t exist for a given resource, the default implementation is to deny access, but if a resource has an ACL with each of the three checks left “empty,” access attempts resolve to true.
In his research, Costello suggested that many of the ACLs in use in ServiceNow are blank – the three checks are left empty and therefore access is granted to potential attackers.
The widget Costello used in his research as an example is Simple List, the function of which is to return record data when table and field names are supplied.
His findings revealed that an attacker who wanted to capitalize on these misconfigurations could do so by crafting a script that targeted a ServiceNow instance and iterated over a series of known table and field names, continuously calling a widget to see if any data was returned.
Personally identifiable information (PII) such as full names and email addresses are among the data that had been retrieved by researchers using this method. Internal documents and incident details were also retrieved by others.
Costello hasn’t detected any attempts to exploit these misconfigurations in data theft attempts. However, he emphasized that he only started tracking them in 2021, and the misconfigurations have been in play since 2015, when the Simple List widget was added to the platform, meaning it would be very difficult to check for historical attempts.
“It is my knowledge, not a guess, that near-identical vectors exist across other popular SaaS applications, not only ServiceNow and Salesforce,” Costello said in his writeup.
On March 3, 2023, ServiceNow made the first tweak to its resources that checked whether the public role was explicitly applied in the ACL. If it wasn’t, access would be denied. Costello suggested this didn’t go far enough as there were other ways to make a resource public.
“We know that one must satisfy the role, condition, and scripted parts of an ACL,” Costello said. “If ‘public’ is not defined as a role on the ACL, an unauthenticated user might still pass the condition or scripted parts and thus be granted access.
“Even more likely is the ACL is entirely empty of a defined role, condition, or script; allowing an unauthenticated user access to the resource.”
The researcher was keen to highlight that ServiceNow did not have any public documentation on the affected component.
He also suggested that by issuing an initial fix in March, ServiceNow demonstrated that it knew about the issue, but did little to contact customers alerting them to potential data exposure.
“The fact that this widget disaster is known by the vendor, as proven this year by their modifications, yet has existed since 2015 without any publicly facing documentation, is appalling,” he said.
There does exist a recently published, public-facing ServiceNow support page announcing the company was investigating the issue, but the customer communication that followed was limited to customer-only Knowledge Base (KB) articles.
After the research started attracting attention last week, ServiceNow quietly released a second fix for the issue that set all blank ACLs to disallow public access by default.
It announced in a non-public KB article, seen by The Register, that an update had been applied to all blank ACLs to add a script ensuring access was only granted if a user was logged in.
While the company believes this should go a long way in mitigating any unauthorized access attempts, it recommended defining the role, condition, and script checks on all ACLs used in ServiceNow.
It also warned that the update may have affected customers’ instances that intentionally allowed unauthorized users to access certain resources. In these cases, customers should remove the script that was added to each ACL by the update and either manually enable the public role or create a new ACL for the table and field and set its role to “public.”
For any table that requires public access, customers have been urged to consider reducing the number of rows the ACL grants public access to, which can be done by adding a script, as well as only applying the public role to the specific fields that require it.
Widgets should also be reviewed for “public” flags that aren’t necessary, and if external access isn’t required at all, IP access control should be applied to the ServiceNow instance to allow only trusted IP addresses. ®
READ MORE HERE
