Note: I apologize for the length of this post. TL;DR is that I explain in (likely too much) detail the security issues with the default functionality, and provide two methods of mitigating those issues.Enabling Client Quick Access (more specifically, unchecking the option to "Require email verification on "Check Ticket Status" page) allows a user to view ticket contents simply by providing the ticket number and the email address of the ticket owner at the Check Ticket Status page. This provides a lower level of security than I'm willing to accept.I can verify that the URLs are not single use. Users can successfully access the URL an infinite number of times.The URL provided in the Check Ticket Status email is the same URL included within all emails for the ticket (such as the "Ticket Opened", agent reply notifications, and "Message Confirmation" emails). In other words, the Check Ticket Status functionality is just providing the URL that the user would already know if they closely examined the other emails pertaining to the ticket (assuming that email notifications were turned on). Of course, we all know that users never closely examine anything ;) Seemingly the main benefit of the Check Ticket Status email is if other email notifications have been turned off -- in this case, the user would have no prior knowledge of what the ticket access URL should be.I've had some time to more closely inspect the code. The URL contains a single parameter, called "auth", which specifies the ticket to be accessed. The auth parameter is generated via getAuthToken() within include/class.client.php (line 84 in my version). Typically with this type of token-like parameter value, there are two types of security issues:value randomnessvalue reuseValue Randomness:While the value of "auth" is truncated a bit and arguably could be more robust, it does appear to be sufficiently random (proving that SECRET_SALT is truly randomly generated at install-time). This means that brute force attacks by an attacker trying to directly access the ticket would be largely ineffective,and thus this is not a problemValue Reuse:This is a problem. Since the URL can be accessed multiple times, a legitimate user who receives the ticket access URL via email (a typically unencrypted medium) could have the URL sniffed/stolen by an attacker who would from then on be able to access the ticket without the need for any other authentication. This would allow the attacker to view ticket content, as well as add new comments to the ticket impersonating the legitimate user (new comments are displayed as being added by the legitimate user).Mitigation:I've taken the following three measures to temporarily mitigate this issue: I've backed up view.php (the Check Ticket Status page), and symlinked view.php to login.php. This risks breaking some other osTicket useability or functionality, but it will disable access UI access to the form that the user would normally use to request the URL by email, and instead requires the user to login to view their tickets. My guess, however, is that this does not prevent the attacker from directly sending Check Ticket Status requests to the server to forcefully induce the Check Ticket Status email containing the URL to be sent. I haven't tested this, however, so I'll sidestep this with the following next mitigation:Remove any inclusion of the URL in ANY email notifications sent to the user. This should prevent the attacker from recovering the URL, even if she could somehow induce the Check Ticket Status email to be sent.Monitor the server logs and alert on a high volume of requests for the view.php page, since this could indicate an attempt to brute-force the auth parameter value to gain access to the ticket.It would be great if the URL reuse issue is something that the osTicket dev team could take up and re-think the implementation of, hopefully releasing as a bug fix in the future.If I've made wrong assumptions about anything, I welcome others to point it out. My goal in being so verbose with this post was so that other users can better understand the osTicket installations that they are currently using or planing, the possible security issues that exist which they would normally never consider, and a possible way to sidestep those issues to use osTicket more securely. osTicket is a great piece of software, and the team is generous to provide it to the community for free. We should all be grateful.
