Hey everyone, This is a blog related to my recent CVE on ServiceNow.
It was found while testing a bug bounty program that was using ServiceNow and their in-scope domain was ‘redacted.service-now.com’. I searched the ServiceNow exploits on google and found that the domain was vulnerable to CVE-2019-20768 and CVE-2021-45901. I reported them and the reports were accepted.
Then I tried to find some more bugs and came to an endpoint /logout_redirect.do. After some testing, I discovered that this endpoint reflects the value of the sysparm_url parameter in response.
Value of parameter - sysparm_url is reflected in JavaScript. You can see the reflection here:
<script data-comment="loading_page redirect">setTimeout(function() { top.location.href = 'VALUE-OF-SYSPARM_URL';}, 0);</script>
In the above code, we can clearly see that If we can add ‘javascript:alert()’ in the sysparm_url parameter then we can achieve XSS. I tried ‘javascript:alert()’ and in response ‘javascript:’ was removed.
Then I thought that If ‘javascript:’ word is getting removed then we can try ‘javajavascriptscript:’ so If ‘javascript’ will be removed then we still have a ‘javascript:’ but it didn’t work.
After playing with different types of encoding and trying different types of bypassing techniques. I found strange behavior in reflection.
So when I used ‘//aman:’ then the reflection is just ‘aman:’ without // so I replaced ‘//aman:’ with ‘//javascript:’ and I was expecting the reflection as ‘javascript:’ but I got ‘null’ in response.
So after some workaround, I replaced // with //\ and I’m not sure why I did this but it worked and the reflection was ‘javascript:’
I used the payload : //\javascript:alert(document.domain)
and I got the ‘javascript:alert(document.domain)’ in response where ‘//\’ got removed.
Opened the URL in the browser and we got a nice popup.
ServiceNow XSS 0-day in Bug Bounty Programs
I created a nuclei template and scanned the bug bounty programs with nuclei and found that many companies were vulnerable to this.
Reported this issue to ServiceNow through HackerOne. They fixed this issue and assigned CVE-2022-38463.
Recommended fix
Update ServiceNow instance to version - San Diego Patch 6, San Diego Patch 4b, Rome Patch 10a, Patch 9b, and Quebec Patch 10 HotFix 7b.
Timeline
-
26 May 2022
- - Reported to ServiceNow through HackerOne.
-
01 Jun 2022
- - Report triaged.
-
25 Aug 2022
- - CVE-2022-38463 assigned by ServiceNow.
-
29 Aug 2022
- - ServiceNow allowed me to publish the blog.
Top comments (0)