Responsible disclosure: Multiple stored XSS vulnerabilities discovered in ServiceNow ITSM by Outpost24

Vulnerability Description

The ServiceNow product is affected by a Stored Cross-Site Scripting vulnerability on one of the parameters issued by the client when opening a new Incident Request. By taking advantage of this vulnerability, an attacker can create a malicious Incident Request which can then be sent out to users in the platform via a direct link to the Request. Trigger conditions for the injected code to be executed on the victim’s browser differ between the Kingston and London versions.

Vulnerability exploitation differs slightly from one version to another, but root cause is shared. The application fails to properly filter user input in the “sysparm_item_guid” parameter. The “sys_id” parameter’s value is set to the “sysparm_item_guid” value and then stored on the Incident Request form. By manipulating this parameter’s value in the HTTP POST request submitted to “service_catalog.do” when creating a new Incident Request, the Stored Cross-Site Scripting vulnerability can be exploited.

For exploitation on the Kingston version, the victim must be tricked into navigating to the malicious Incident Request and clicking on the “Manage Attachments” or “Toggle Activity” icons on the Incident Request main view. For exploitation on the London version, it is sufficient to trick the victim into navigating to the malicious Incident Request, although injected code can also be executed as described for the Kingston version.

It should be noted that the vulnerable parameter “sysparm_item_guid” has a limit size of characters, which could make it harder to inject lengthy code. However, exploitation within the allowed number of characters is possible. It is required that the attacker is authenticated when creating the malicious Incident Request. It is also required that the victim is authenticated with enough privileges to manage other user’s Incident Requests when accessing the malicious Incident Request’s URL.

Vulnerability Impact

Through our tests on two versions of ServiceNow available to us, we have reason to believe all customer installations are affected and possibly older ServiceNow installations as well. As the attacker needs to be authenticated when creating a malicious Incident Request and the victim needs to be authenticated when interacting with the malicious Incident Request, there are some preconditions for exploitation. However, if an attacker would succeed in exploitation of this vulnerability, it would be possible to execute custom JavaScript in the context of the victim’s browser. This means that the attacker could redirect the victim to a fake version of the ServiceNow site for social engineering purposes, hook the victim’s browser with BeEf, and others.

Recreation Flow

To allow for recreation of the identified vulnerability, we provide the precise steps taken by our security researcher. This will allow you to verify the vulnerability and test if your proposed solution is sufficient.

For all tested versions, details below:

KINGSTON

• Log in the ServiceNow application
• Navigate to “Service Catalog”
• • Select “Create Incident”
  • Press the “Submit” button
• Intercept the outgoing HTTP POST request to “/service_catalog.do”
• Modify the value of the “sysparm_item_guid” to match the following payload:
   
  1');alert('Outpost24+XSS

• Submit the malicious request
• Navigate to the newly created Incident Request by either:
  • Searching for it under the “Incidents” section in the left side list
  • Directly accessing it’s URL, which should have the following format:
    https://service-now.app/incident.do?sys_id=1%27);alert(%27Outpost24%20XSS&sysparm_view=ess

• In the Incident Request view, click either the “Manage Attachments” clipboard icon or the “Toggle Activity” arrow-down icon
• Note the alerting pop-up box, indicating that the injected JavaScript has been executed

LONDON

• Log in the ServiceNow application
• Navigate to “Security Incident Catalog”
  • Pick any Incident category and click on it
  • On the Incident form page, press the “Submit” button
• Intercept the outgoing HTTP POST request to “/service_catalog.do”
• Modify the value of the “sysparm_item_guid” parameter to match the following payload:
  
  1');alert('Outpost24+XSS

• Submit the malicious request
• Navigate to the newly created Incident Request by either:
  • Searching for it under the “My Requests” section in the left side list
  • Directly accessing its URL, which should have the following format:
  • https://service-now.app/sn_si_incident.do?sys_id=1%27);alert(%27Outpost24%20XSS&sysparm_view=my_request&sysparm_record_target=task&sysparm_record_row=4&sysparm_record_rows=4&sysparm_record_list=sys_idINjavascript%3AgetMyRequestIDs%28%29%5EORDERBYnumber

• Note the alerting pop-up box, indicating that the injected JavaScript has been executed

  Note that the application checks for “sys_id” parameters with identical values. Therefore, if and Incident Request with value 1');alert('Outpost24+XSS has already been created, trying to replicate it will fail. Instead, use a different character at the beginning of the payload, such as:
  
  2');alert('Outpost24+XSS

Screenshots

Below screenshot(s) indicate the presence of the vulnerability in the product:

KINGSTON

About Ghost Labs  Ghost Labs is the specialist security unit within Outpost24, offering enhanced security services such as advanced network penetration testing, (web)application testing, Red Teaming assessments and complex web application exploitation. In addition, the Ghost Labs team is an active contributor to the security community with vulnerability research and coordinated responsible disclosure programs.  Ghost Labs performs hundreds of success penetration tests for its customers ranging from global enterprises to SMEs. Our team consists of highly skilled ethical hackers, covering a wide range of advanced testing services to help companies keep up with evolving threats and new technologies.