{"id":293,"date":"2024-09-17T18:58:56","date_gmt":"2024-09-17T18:58:56","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=293"},"modified":"2024-09-17T18:58:56","modified_gmt":"2024-09-17T18:58:56","slug":"warning-to-servicenow-admins-block-publicly-available-kb-articles","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=293","title":{"rendered":"Warning to ServiceNow admins: Block publicly available KB articles"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Many organizations using ServiceNow<\/a> are inadvertently exposing sensitive personal and corporate data through misconfigured Knowledge Base (KB) articles created by employees, says a security provider.<\/p>\n

ServiceNow is a cloud-based platform for automatic workflows. It\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cIn 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,\u201d he wrote in a post Tuesday<\/a>. \u201cThis could indicate a systematic misunderstanding of KB access controls or possibly the accidental replication of at least one instance\u2019s 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.\u201d<\/p>\n

In an interview with CSO, Costello said, \u201cin some of these cases, we\u2019re talking about Fortune 200 organizations that have live credentials to other [IT] systems used by the organizations that are being exposed publicly. If you\u2019re a bad actor and you\u2019re targeting these organizations, you\u2019ve really hit the jackpot. You could leverage those credentials to pivot further into the company\u2019s systems to steal information or perhaps maintain access through a backdoor.\u201d<\/p>\n

He\u2019s even seen examples of \u201cextremely intimate\u201d maps of an organization\u2019s IT network in KB articles.<\/p>\n

Mitigations<\/h2>\n

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.<\/p>\n

Last week, ServiceNow changed a security control<\/a> 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.<\/p>\n

KBs that contain sensitive data create a \u201cquite serious\u201d problem, Costello said.<\/p>\n

While there are legitimate uses for some externally facing information, ServiceNow KBs \u201ccan be a treasure trove of sensitive internal data<\/a> intended only for the eyes of an organization\u2019s staff,\u201d Costello wrote.<\/p>\n

One big problem: Public widgets that can be used to access the contents of KB articles didn\u2019t 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.<\/p>\n

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 \u2018allow public access by default\u2019 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 \u2018Can Contribute\u2019 property on a KB will still allow unauthenticated users to read insecure articles within it.<\/p>\n

In addition, the out-of-the-box User Criteria can be misleading to the untrained eye, Costello said. While there is an explicit \u2018Guest User\u2019 criteria for granting unauthenticated access, many administrators are unaware that other, less-explicitly named criteria also grant access to unauthenticated users.<\/p>\n

And more often than not, when a User Criteria is set, it\u2019s only on the allow-lists (\u2018Can Read\u2019), Costello said. The deny-list (\u2018Cannot Read\u2019) 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.<\/p>\n

Costello\u2019s article includes a list of ServiceNow KB security properties and the consequences of their misconfiguration.<\/p>\n

What can administrators do?<\/h2>\n

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. \u201cIt is imperative that administrators ensure this business rule is still activated on their platform, since User Criteria prioritizes \u2018Deny\u2019 over \u2018Allow\u2019,\u201d Costello wrote. \u201cThis has the added benefit of still preventing access in the event that the \u2018Can Read\u2019 criteria accidentally includes the Guest User;\u201d<\/p>\n

ServiceNow\u2019s built-in\u00a0User Criteria diagnostics<\/a>\u00a0tool 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 \u201c\/get_public_knowledge_bases.do\u201d of their instance;<\/p>\n

watch for ServiceNow security updates and messages. Note that in January, ServiceNow messaged customers about KBs that were accidentally exposed to the public internet.<\/p>\n

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\u2019 KB configurations itself.<\/p>\n

\u201cWe proactively work with customers on the ongoing safety of their security configurations to ensure they are properly structured and aligned to their intended purpose,\u201d the company said in a statement.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019s often used by IT help desks for creating and tracking employee or customer tickets, and also by HR, security, finance, and […]<\/p>\n","protected":false},"author":0,"featured_media":278,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-293","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/293"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=293"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/293\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/278"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}