Description

If a regular user’s username is set to a XSS payload, and then that same XSS payload is placed in the q (query) parameter of /scp/ajax.php/users/local, then reflected XSS is achieved. This XSS can lead to complete takeover of the osTicket instance.

Proof of Concept

• Set a user’s username to <svg onload='alert(1)'> (such as in the agent panel).
• Go to http://osticket.domain.com/scp/ajax.php/users/local?q=<svg%20onload=%27alert(1)%27> - you should see the alert pop up.

Photo of PoC step 1

Photo of PoC step 2

How I Discovered the Vulnerability

I was exploring osTicket and found that when creating a user, there was a search function! Wanting to probe it, I opened up the link to the search in a new tab (aka instead of inline like it’s made to do, if you open up http://osticket.domain.com/scp/ajax.php/users/local?q=your_query_here in another tab, it still works). The first thing I noticed was that the response was not of type application/json, but rather as text/html. I knew that if I could put a XSS payload in the results somewhere, I could point out a vulnerability.

The only fields returned were email, name, id number, and the search parameter q. Results were only shown if the query matched a relevant field; that meant that simply putting a XSS in the q parameter wouldn’t work. I tried creating a new user and putting a XSS in the email or name fields, but it kept filtering it out each time (which I’m sure was intentional). I looked in the source code and noticed that /include/users.ajax.php not only searched in email and name, but also username, organization, and phone number. I logged in as an agent and changed the username for the test user to the XSS payload, stuck it in the query, and it worked!

So the username must be set to the XSS payload so when the XSS payload is also put in the query, it matches a user record and the XSS payload is reflected onto the page.