| 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
| ||
|
Message-ID: <C9B2DD4DEDB9214A84BB2937ACE45B6D1F4489@server05.2bsecure.co.il> Date: Tue, 11 Jul 2006 10:40:54 +0300 From: "Erez Metula" <erezmetula@...ecure.co.il> To: "Erez Metula" <erezmetula@...ecure.co.il>, <bugtraq@...urityfocus.com>, <support@...uriteam.com>, <html-list@...uriteam.com>, <full-disclosure@...ts.grok.org.uk>, <news@...uriteam.com>, <submissions@...ketstormsecurity.org>, <partners@...unia.com> Subject: RE: MIMESweeper For Web 5.X Cross Site Scripting Hi list, I've been asked the following question: "It sounds like the net impact of this vulnerability is that an attacker can steal cookies for a site the user isn't allowed to visit anyway. In other words, there aren't going to be any interesting cookies to steal. Is there more to this attack scenario?" It's a good question. Here are at least 2 attack scenarios: 1. Stealing user cookie. Since it requires that the client should already have such a cookie, it requires that the client visit the banned site first. This situation is minimized to the time window in which the user is logged in and the site got banned. Can happen in 2 situations: 1. The product blacklist file is updated (automatically, on a daily basis) with the added blacklisted site. 2. The administrator adds the specific site to the blacklist file. The attacker will make the product / administrator believe that a site should be blacklisted - even a short period is enough, to launch the XSS. 2. Phising/Defacement (using HTML Injection). In this scenario, the attacker is actually using the fact that some site is banned, and replace the page content with a forged page. Example: http://BannedSite.com/<HTML>forged_page_content_in_here</HTML> The client will think that he is in the requested site (the browser will also indicate that),but in fact he will see the forged content - sounds to me like defacement and/or phishing. Think about a banned bank web site, in which the attacker will replace the login page and send the credentials to him. There are more scenarios, but I think that this is bad enough. ________________________________ Erez Metula, CISSP Application Security Department Manager Security Software Engineer E-Mail: erezmetula@...ecure.co.il Mobile: 972-54-2108830 Office: 972-39007530 -----Original Message----- From: Erez Metula [mailto:erezmetula@...ecure.co.il] Sent: Monday, July 10, 2006 2:53 PM To: bugtraq@...urityfocus.com; support@...uriteam.com; html-list@...uriteam.com; full-disclosure@...ts.grok.org.uk; news@...uriteam.com; submissions@...ketstormsecurity.org; partners@...unia.com Subject: RE: MIMESweeper For Web 5.X Cross Site Scripting MIMESweeper For Web 5.X Cross Site Scripting I. INTRODUCTION MIMESweeper For Web is a policy-based content security for web applications. It analyzes web content and blocks pages or files that are prohibited by the organizational security policy. For more Information please refer to: http://www.clearswift.com/products/msw/msw_web/default.aspx II. DESCRIPTION A XSS vulnerability was discovered by Erez Metula. When accessing a URL which is not permitted the user is redirected to an "access denied" page that is vulnerable to XSS. The page does not input validate / HTML Encode the input and displays the data "as is". Usually this means that it enables an attacker to inject HTML or Javascript code into users's browsers, and by that bypassing the browser DOM restrictions. This javascript code can perform actions on behalf of the user, steal authentication cookies, change the appearance of web pages, perform phishing ,and generally can do everything to the original page. III. EXPLOITATION The vulnerability can be exploited by just redirecting the client to some URL that is restricted by MIMESweeper policy and adding the script at the end of the URL. Example PoC: http://SomeBlackListedSite/<script>PAYLOAD</script> IV. IMPACT Using the MIMESweeper capabilities of a central gateway to spread malicious scripts to users. An example attack scenario could be that an attacker will redirect many users (by email, posting in the organization portal, etc.) to some blocked URL and an accompanying script that will steal their authentication cookies. V. DETECTION Detection of this vulnerability involves injecting some HTML tags / scripts to a blocked URL that will be responded by the MIMESweeper with the vulnerable page. VI. WORKAROUND Clearswift released a patch for this vulnerability, following the initial contact ¬ification. The patch can be obtained from: http://www.clearswift.com/support/msw/patch_MswWeb.aspx termed as "MIMEsweeper for Web 5.1.15 Hotfix" VII. VENDOR RESPONSE Clearswift has been informed on the 27/6/06 by e-mail to their support. Clearswift released a fixed version of the software. VIII. DISCLOSURE TIMELINE 27/06/06 Identification of the flaw 27/06/06 Reporting the flaw to clearswift by email 27/06/06 Response from clearswift, asking for more description 27/06/06 Providing the full description to clearswift 28/06/06 Clearswift acknowledge of the vulnerability 06/07/06 Patch released by clearswift 09/07/06 Public advisory IX. CREDITS The vulnerability was discovered by Erez Metula. Erez Metula, CISSP Application Security Department Manager Security Software Engineer E-Mail: erezmetula@...ecure.co.il _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists