Thousands of orgs at risk of knowledge base data leaks via ServiceNow misconfigurations Security researchers say that thousands of companies are potentially leaking secrets from their internal knowledge base (KB) articles via ServiceNow misconfigurations. Aaron Costello and Dan Meged, of the AppOmni and Adaptive Shield security shops respectively, separately published their findings this week, concluding that …
We have mitigated this by having our KB articles written by our helpdesk new joiners as part of their induction process. the better articles are the ones written by people who've done the thing described ONCE.
As an L3/L4 sysadmin I keep finding KB pages talking about MY systems that are absolute bullshit.
So. Steal that.
After reading this article, I have the feeling that there are several issues that are at the root of this problem.
First, there's the fact that ServiceNow has had to amend its platform to bolster security. That tells me that their handling of security wasn't properly thought through in the first place.
Then there's the fact that, despite having amended the platform, customers are still getting it wrong, which points to a possible lack of clarification in the documentation. It's difficul to write good security documentation when you're tacking on a new process that changes everything.
Finally, there's the fact that customers don't have time for security, they just want things to work. Maybe some customers gave it a try and found that their new configuration broke their processes and, instead of correcting the processes, they reverted to the old, insecure configuration. Maybe some customers just didn't understand the problem and left everything as is because they had enough trouble getting it working in the first place.
In any case, this whole affair demonstrates just how important it is to establish proper security from the start. Making such corrections after the fact is always a problem in itself.
I'd say, If you were still writing articles and setting options from around a decade ago, it was probably fine under the old CMS style portal.
When they changed to the new style that uses widgets I suspect a few things were changed and people are/were unaware
The article mentions a BR that should always be enabled but doesn't specify which one. It appears to be "Restrict guest user to knowledge base", which adds the OOB guest user to the can't read/contribute lists. It only does this upon insert though, so any older KB's might not have it set already.
I'm not aware of a public/private setting on the Knowledge Bases themselves, at least nothing as simple as a field on the table. The widgets have a 'public true/false' value that can be changed. The way to do this seems to be more along verifying that the 'can read' list on each knowledge base doesn't have any user criteria that allows a public role to be used.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
