Hi, In my opinion, there are two possibilities... the injected code is executed in the context of the banned website, or the injected code is executed in the context of the "Access denied"-page served by MIMESweeper. The latter would be the case if MIMESweeper redirects to a page of its own, the former would be the case if MIMESweeper replaced the content of the reply of the webserver of the denied website with it's "Access denied"-message. Unfortunately I don't have MIMESweeper around to test this, but maybe someone else can verify this? If the latter scenario is true and the code is executed in the context of the MIMESweeper website AND there is a web-based admin-interface running on the same domain... this issue may allow attackers to obtain access to the admin-interface...
- Lise --- Erez Metula <[EMAIL PROTECTED]> wrote: > Hi Brian, > Please consider those 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. > Best regards, > Erez. > > ________________________________ > > > Erez Metula, CISSP > Application Security Department Manager > Security Software Engineer > E-Mail: [EMAIL PROTECTED] Mobile: > 972-54-2108830 > Office: 972-39007530 > > -----Original Message----- > From: Brian Eaton [mailto:[EMAIL PROTECTED] > Sent: Monday, July 10, 2006 2:06 PM > To: [email protected] > Cc: Erez Metula > Subject: Re: [Full-disclosure] MIMESweeper For Web > 5.X Cross Site > Scripting > > On 7/9/06, Erez Metula <[EMAIL PROTECTED]> > wrote: > > 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. > > 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? > > Regards, > Brian > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: > http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - > http://secunia.com/ > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
