Multiple Information exposed due to misconfigured Service-now ITSM instances
ServiceNow is a cloud-based company that provides software as a service (SaaS) for technical management support. The company specializes in IT services management (ITSM), IT operations management (ITOM) and IT business management (ITBM), allowing users to manage projects, teams and customer interactions via a variety of apps and plugins.
ServiceNow products offer a service model based on what can help users identify the root cause of the issues they encounter, as well as helps them to correct issues with self-service. The service model appears as tasks, activities and processes from ServiceNow products, separated by cloud services.
To reach your instance it will be using: https://yourcompanyname.service-now.com
The issue
One of the modules that i worked on is the Knowledge base, The ServiceNow® Knowledge Management (KM) application enables the sharing of information in knowledge bases. These knowledge bases contain articles that provide users with information such as self-help, troubleshooting, and task resolution.
Once created each KB is identified with a unique number as seen below :
and once a user opens one of those articles the endpoint called is the below :
https://company.service-now.com/kb_view_customer.do?sysparm_article=KB00xxxx
Exploitation
It was noticed a lot of companies had this endpoints reachable publicly without authentication, even though reaching the company instance itself directly will send you to Okta, onelogin, ..etc in order to login with corporate credentials, but not for the KB endpoints.
The best methodology for me was doing a normal subdomain scan for *.service-now, then using top alexa companies as list and bruteforce subdomains, lastly checking what out of those companies had a bug bounty program.
Once the misconfigured instance identified i used burp intruder to bruteforce the latest 4 digits of sysparm_article parameter, then i sorted results by size or by using burp Grep/Match options for words like (password, internal, credentials, confidential)
Results
For most of the companies tested it was identified this is was not used as intended ( Knowledge base ) , summary of findings was :
1- Internal Procedures , SOP, Diagrams , development plans.
2- Passwords, tokens for Internal corporate domains.
3- Attachments for change requests contained IP addresses, configurations.
4- Some customers PII in communications between employees.
For other companies that was an accepted risk, as there wasn’t anything sensitive or with an impact if an unauthorized person read it, but still i encouraged them to fix the permission issue.
Initial Discovery to $30,000
It took almost two days to report the findings for multiple companies externally or within H1 & bugcrowd platforms with the help and support of my close friends, that resulted so far in approximately 30K bounties and still some reports are in triage.
Servicenow is one of the top 5 cloud ITSM’s and its used by a lot of big companies worldwide.
Is this a vulnerability in servicenow product?
No. This is a common misconfiguration made by the individual companies where they didn't setup the permission properly on knowledge base and had it opened for unauthorized people publicly.
