Many organizations using ServiceNow are inadvertently exposing sensitive personal and corporate data through misconfigured Knowledge Base (KB) articles created by employees, says a security provider.
ServiceNow is a cloud-based platform for automatic workflows. It’s often used by IT help desks for creating and tracking employee or customer tickets, and also by HR, security, finance, and other departments, in their workflows.
With the permission of internal ServiceNow administrators, departmental staff and app developers can create Knowledge Base articles that employees can use to answer common questions.
Aaron Costello, chief of SaaS security research at AppOmni, said that since April 2023, he has discovered thousands of examples of data exposed on the public internet in this way by ServiceNow customers.
“In many of these cases, it was observed that organizations that have more than one instance of ServiceNow had consistently misconfigured KB access controls across each one,” he wrote in a post Tuesday. “This could indicate a systematic misunderstanding of KB access controls or possibly the accidental replication of at least one instance’s poor controls to another through cloning. These instances were considered by the affected organizations to be sensitive in nature, [with data] such as PII [personally identifiable information], internal system details, and active credentials/tokens to live production systems.”
In an interview with CSO, Costello said, “in some of these cases, we’re talking about Fortune 200 organizations that have live credentials to other [IT] systems used by the organizations that are being exposed publicly. If you’re a bad actor and you’re targeting these organizations, you’ve really hit the jackpot. You could leverage those credentials to pivot further into the company’s systems to steal information or perhaps maintain access through a backdoor.”
He’s even seen examples of “extremely intimate” maps of an organization’s IT network in KB articles.
Mitigations
To mitigate these issues, ServiceNow admins should run regular diagnostics on KB access controls to keep security configurations updated, AppOmni says, and use business rules to deny unauthenticated access to KB content by default.
Last week, ServiceNow changed a security control so access to Knowledge Base articles created by employees is restricted to staff by default, Costello said in the interview. He has been working with ServiceNow for some time to help spread word of the problem.
KBs that contain sensitive data create a “quite serious” problem, Costello said.
While there are legitimate uses for some externally facing information, ServiceNow KBs “can be a treasure trove of sensitive internal data intended only for the eyes of an organization’s staff,” Costello wrote.
One big problem: Public widgets that can be used to access the contents of KB articles didn’t receive a change in a security attribute for out-of-the-box access control lists. This included the lack a specific check to verify if unauthenticated users can access data.
Another is that the vast majority of employee-created ServiceNow Knowledge Base articles are secured using what ServiceNow calls User Criteria. This is a security property that denies access by default to KB articles unless a User Criteria is set up that groups users to permit access. This capability was added in March, 2020. However, Costello said, most enterprise ServiceNow instances have been around for far longer, causing them to still retain the previously insecure ‘allow public access by default’ value. This was the case for around 60% of enterprise instances he analyzed. Even if this property is securely configured, he added, merely defining a ‘Can Contribute’ property on a KB will still allow unauthenticated users to read insecure articles within it.
In addition, the out-of-the-box User Criteria can be misleading to the untrained eye, Costello said. While there is an explicit ‘Guest User’ criteria for granting unauthenticated access, many administrators are unaware that other, less-explicitly named criteria also grant access to unauthenticated users.
And more often than not, when a User Criteria is set, it’s only on the allow-lists (‘Can Read’), Costello said. The deny-list (‘Cannot Read’) is ignored as a result. Because of the complicated nature of User Criteria, this can allow external users to slip through the cracks and be granted access.
Costello’s article includes a list of ServiceNow KB security properties and the consequences of their misconfiguration.
What can administrators do?
ServiceNow administrators should take advantage of the powerful customization capabilities in the suite, Costello advised. In mid-2022, the suite added a business rule that adds the Guest User to the Cannot Read and Cannot Contribute User Criteria of a KB when it is first created. “It is imperative that administrators ensure this business rule is still activated on their platform, since User Criteria prioritizes ‘Deny’ over ‘Allow’,” Costello wrote. “This has the added benefit of still preventing access in the event that the ‘Can Read’ criteria accidentally includes the Guest User;”
ServiceNow’s built-in User Criteria diagnostics tool allows administrators to quickly determine which users, both authenticated and unauthenticated, have the ability to access both KBs and individual articles. Admins can find out which KBs are public by going to “/get_public_knowledge_bases.do” of their instance;
watch for ServiceNow security updates and messages. Note that in January, ServiceNow messaged customers about KBs that were accidentally exposed to the public internet.
ServiceNow said it began contacting customers months ago with guidance on how to address this issue, and from Sept. 4 began to modify some customers’ KB configurations itself.
“We proactively work with customers on the ongoing safety of their security configurations to ensure they are properly structured and aligned to their intended purpose,” the company said in a statement.
No Responses