NGS00138 Technical Advisory: Websense Triton 7.6 - authentication bypass in report management UI

=======

Summary

Name: Websense (Triton 7.6) Authentication-bypass in report management UI 

Release Date: 30 April 2012

Reference: NGS00138

Discoverer: Ben Williams <ben.williams (at) ngssecure (dot) com [email concealed]>

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

-------------------------

II. BACKGROUND

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-2

2&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=664332B2D4D7ECEBBC6DC1FA92D160BFDC102E4B2F8CC983B712A0D24B631F

5CF029F7967E8C92C3F7193EABE67F652A,

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:

(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.

5CF029F7967E8C92C3F7193EABE67F652A

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