For the OWA Admins out there.

There is a vulnerability out there that allows a malicious person to redirect your users away from your trusted site to another that appears to be a "normal" login screen. The user login obviously "fails" and the user is then redirected back to the trusted server's login screen. Obviously, in the meantime, the user's login credentials have been hijacked.

Source

Since this requires a user to click on or cut and paste a malformed url the current mitigation is to instruct all users not to, under any circumstances, follow links to their OWA that are sent to them or that appear on any web page except, maybe on the corporate intranet if you link them there.

Or use server certificate for your OWA.

Ok.... Now, correct me if I am wrong.....

I just ran the following test in Firefox....

I requested the following url with Ethereal running:-

http://[email protected]

The DNS request was for www.antionline.com and the redirection was about to work but Firefox popped up and told me that this was suspicious and that I might be being redirected. If I said "Yes" it took me to AO but popped up another message telling me I'm trying to log into AO with the username www.yahoo.com and the site doesn't require auth.......

Ok, that aside.... Since it's the browser that's being conned into the redirection how would the certificate be of use? The certificate, in this case, would be for www.yahoo.com but the browser is going to www.antionline.com so, as far as the browser is concerned, the certificate would be irrelevant.

Or am I missing something?

I get invalid syntax error while I try your link with your @ in it when I use IE. I know IE block most URL with @ now. Before the @ was use to answer a login and password directly in the hyperlink.

Using that logic the certificate would be irrelevent in this case.

Does this effect all OWA installations, or just 2003 ? (Couldnt tell from the posted link).

Quote:

---

The certificate, in this case, would be for www.yahoo.com

---

The certificate would actually be for the OWA site and not yahoo.

I just tested this with my OWA implementation which uses SSL cert issued by our own internal CA. Since both my Firefox browser accepts certs from our CA, I was taken directly to the site. I tried this on a test box and IE stopped the redirection, Firefox popped up the warning about being redirected. That warning from Firefox is a good or bad thing as we all know how well most users *read* things before the simply click "OK". I like the fact that it actually said something rather than simply stopping me, again though most users don't read that stuff unfortunately. Anyway, I did not install my CA certificate on this test box and Firefox popped up a warning about not knowing who issued my OWA cert.

Thanks for the info Tiger. If I read correctly, the attacker has to know the url of the OWA server before starting the fun. This fact may actually slow down the madness and may explain why MS has not reacted very quickly. They're currently on my **** list since I reported a huge security hole in Group Policy yet they are playing a word game with me over the issue. They define something one way, blah, blah...

Anyway, now that I'm off topic completely, I better crawl back in my hole.

:)

Quote:

---

Originally posted here by Tiger Shark
http://[email protected]

---

Am I missing something? This isn't redirection but the same as ftp://username@somesite and, as SDK pointed out, is "fixed" to prevent url spoofing.

Nevermind... Unless there is a valid asp page at the target end the redirection doesn't work so the certificate would function as it was intended..... :o

Tiger was making an example, and I think going outside the context of what OWA does may have confused it a bit.

Here's my clients Internet facing OWA login URL (sanitized to protect the guilty):
https://owa.example.com/exchweb/bin/...hange&reason=0

The announcement on Insecure.org shows how if you change the redirection URL at the end, the user get's redirected to whatever is specified. They then go on to explain how if you obfuscate the changed URL, it won't look nearly as suspicious, i.e. instead of using http://example.com/ you'd use http://3221234342/

In Exchange 5.5, the owalogon.asp page doesn't exist,