======= Summary ======= Name: Websense (Triton 7.6) Authentication-bypass in report management UI Release Date: 30 April 2012 Reference: NGS00138 Discoverer: Ben Williams Vendor: Websense Vendor Reference: Systems Affected: Risk: High Status: Published ======== TimeLine ======== Discovered: 25 October 2011 Released: 2 November 2011 Approved: 2 November 2011 Reported: 2 November 2011 Fixed: 2 December 2011 Published: 30 April 2012 =========== Description =========== Websense (Triton 7.6) Authentication-bypass in report management UI Websense is one of the world's best known web-filter products. Websense (Triton 7.6) Authentication-bypass in the report management UI enabling unauthenticated access to confidential reports. ================= Technical Details ================= I. VULNERABILITY ------------------------- Websense (Triton 7.6) Authentication-bypass in report management UI II. BACKGROUND ------------------------- Websense is one of the world's best known web-filter products. The "Triton" administrative UI allows administration of multiple Websense solutions, including their Email, Web, and DLP products http://www.websense.com/ III. DESCRIPTION ------------------------- Websense (Triton 7.6) is prone to Authentication-bypass in the report management UI enabling unauthenticated access to confidential reports. IV. PROOF OF CONCEPT ------------------------- Affected URL: Multiple, but the main index is as follows: (dates need to be adjusted to be valid) https://192.168.1.67:9443/explorer_wse/favorites.exe?startDate=2011-10-22&endDate=2011-10-23&action=def It is possible to gain access to the report section without authentication, by adding a cookie with predefined values. (This can be done with Cookie-Manager, or various other IE/Firefox plugins which can be used to edit browser cookies) This gives full access to the report section of the user interface (but not the policy-management section). The Websense reports contain confidential information such as user data, browsing history, system information, and blocked threats. Here is the cookie to add: Domain = 192.168.1.67 Name = WS_SHARED_SESSION Value = "{uid=YWRtaW4=, userRoles=664332B2D4D7ECEBBC6DC1FA92D160BFDC102E4B2F8CC983B712A0D24B631F5CF029F7967E8C92C3F7193EABE67F652A, domain=192.168.1.67}"; (set an expiry date a good while in the future) ... and then browse the following URL to get the reports: https://192.168.1.67:9443/explorer_wse/favorites.exe?startDate=2011-10-22&endDate=2011-10-23&action=def (dates in the URL need to be adjusted to be valid) The only component of the cookie which looks anything like a session token is shown below. This never seems to change, and was the same on 2 separate installations of the product, which leads me to believe that this is predefined "admin role" information. userRoles=664332B2D4D7ECEBBC6DC1FA92D160BFDC102E4B2F8CC983B712A0D24B631F5CF029F7967E8C92C3F7193EABE67F652A The "uid" is simply a base64 encoded "admin". Other cookies are set based on this value, but it does not seem to need to be "admin" or any existing user to access the reports (this uid does seem to be used when accessing "favorite" reports) =============== Fix Information =============== This issue is addressed in Hotfix 24, which can be downloaded at: https://www.websense.com/content/mywebsense-hotfixes.aspx NGS Secure Research http://www.ngssecure.com