Vulnerability that could lead to full environment compromise has now been patched

ServiceNow admin credentials among hundreds of passwords exposed in cloud security blunder

UPDATED More than 600 enterprises, universities, and government agencies may have inadvertently exposed their ServiceNow login credentials – many with administrator privileges – due to a vulnerability in the IT support platform.

Now patched, the security flaw centered on how the platform’s ‘Help the Help Desk’ feature requested information from endpoints and left unencrypted passwords publicly viewable on all ServiceNow instances that used the feature.

‘Entire environment compromise’

Gaining administrative access to a ServiceNow cloud instance would give an attacker free rein over customer support tickets, employee data, internal documentation, internal IT tickets, internal HR tickets, and other potentially sensitive customer information.

“Other ServiceNow features can even provide command execution on servers and workstations enrolled in various ServiceNow integrations,” said security researcher Jordan Potti in a blog post documenting his discovery.


RELATED ServiceDesk Plus vulnerability could give attackers full access to IT support systems


“Given the amount of information and access ServiceNow has in many environments, this can lead directly to entire environment compromise.”

Hinder the Help Desk

ServiceNow, a cloud computing platform used by enterprises to manage digital workflows, has more than 17,000 customers.

Enterprise users can configure the Help the Help Desk feature to collect information, via a WMI script, from the endpoints of employees and customers.

According to Potti, however, “the credentials for the request were stored in a public JavaScript file on all ServiceNow instances” that used the feature.

The file was readily accessible at https://<customername>.servicenow.com/HelpTheHelpDesk.jsdbx, and the credentials were visible “at the top of the script for anyone’s viewing pleasure”.

Worse still, the base64-encoded passwords were not encrypted, even if the prefix encrypt: misleadingly indicated otherwise.

Potti added: “How this hadn’t been found before is interesting.”

Amplifying the risk

Many ServiceNow users exacerbated the security risk by using their administrator credentials when using SOAP [Simple Object Access Protocol] authentication for running the WMI script, overlooking the official documentation that outlines a process for creating an unprivileged role for the job.


Read more of the latest security vulnerability news


As a result, the researcher discovered numerous administrator-level usernames such as sn_admin, admin, and servicenow-admin among the exposed credentials.

“In more than one case, credentials provided full admin access to ServiceNow instances that were used by global companies with bug bounty programs,” noted Potti.

Simple to GET

The researcher said simple GET requests were sufficient to determine when a host was exposing credentials.

“Using some open source reconnaissance, a list of ServiceNow subdomains was collected and each one was issued a request for the HelpTheHelpDesk script,” he continued.

“If the httpUsername and httpPassword values were filled, the request was logged.”

The researcher unearthed the problem on August 15, 2020, and alerted ServiceNow on August 20.

The developers released a patch on October 8 and the vulnerability was publicly disclosed yesterday (February 21).

A ServiceNow spokesperson told The Daily Swig: “ServiceNow is committed to protecting its customers and, like many software companies, runs a program to catch and patch bugs before they are exploited. In this case, as soon as the bug was identified by a security researcher a patch was created to correct it.”

The Daily Swig has also contacted Jordan Potti for further comment. We will update the story if and when we receive a reply.


This article was updated on February 23 with a statement from ServiceNow.


YOU MIGHT ALSO LIKE Dependency confusion attack mounted via PyPi repo exposes flawed package installer behavior