Owning Outlook Web Access (OWA) users

Sat, 08 Dec 2007 18:56:01 GMT

What is this post about? Well, this is something that pdp and I were playing with a few years ago. As you might already know, although we also do a vulnerability research at GNUCITIZEN, what we like the best is insecurity by design. There is nothing better than finding an attack vector that won't be resolved by the vendor simply because the product is designed to follow certain behavior. Personally, from a security research point of view, I think that these attacks are the best.

In this case, we forwarded our ideas along with an attack walk-through to Microsoft but they didn't consider it an issue. "Even better!" I thought, as it's one of those things that will always work on Outlook Web Access 2003 which means that you could always flag it when doing an authenticated pentest on a OWA site. The following describes how to perform advanced phishing attacks on OWA 2K3 (might also work on older versions) without relying on any bugs.

The following is the recipe for our attack. Needless to say, if any other webmail product meets the following conditions, its users can be owned in the same manner:

  • Same-domain post authentication redirects are allowed
  • URLs that display email attachments can be predicted

Let me explain with more detail. When a user checks an email and clicks on the attachment, a URL such as the following is visited:


At first look, the URL looks non-predictable, especially when it comes to the unique long hexadecimal string. Surprisingly though, we can get rid of the hex string and the attach parameter, and still be able to access the file sent as an attachment:


> I think that the hex string is the UID value which is unique to each user, however, I have not confirmed this yet.

A more careful look at the URL reveals that all the variables can actually be predicted by the attacker:


Let's review these variables for a second:
  • username - can be extracted from the victim's email address (everything before the at @ sign)
  • email subject - chosen by the attacker who sends the email to the victim
  • attachment filename - also chosen by the attacker who sends the email to the victim

    Now we have all components for a successful attack. The idea is the following. The attacker sends an email with a HTML attachment to the victim. After that, he performs a phishing attempt against the victim via an exploit URL such as the following:


    After logging in successfully, the victim is redirected to the URL specified within the same domain (the url parameter) which actually opens the HTML attachment sent by the attacker. Such attachment is a HTML file that looks exactly like the original OWA login page. The spoofed login page displays an error such as "An error has occurred, please try logging in again". The spoof login page has been manipulated by the attacker so that the action attribute points to a third-party site, where the username and password are captured by the attacker.

    It might also be possible to use a relative path for the url parameter but I haven't tested it.

    If you ever try to probe for XSS via HTML attachments on OWA, you'll notice that the script tags are being filtered. However, plain HTML is allowed. This means that all the tags used by the spoof login form will be rendered properly by the browser, and the username and password will be sent to the attacker's site correctly. The only one thing that OWA does change in plain HTML attachments, is that forms' method attributes are changed from POST to GET. However, the form fields are still allowed to be of type password which means that the spoofed login page will look 100% legitimate. I still don't quite get why OWA doesn't filter action attributes within HTML attachments in order to stop these type of phishing attacks.

    The beauty of this attack is that the spoof login page is actually located within the legitimate site hosting the OWA application. No bugs are exploited whatsoever, but rather, the attacker has worked out a way to host the malicious login page in the OWA site where the victim checks his email remotely.

    Now, there are a few tips that can be taken into account in order to increase the chances of the attack to be successful. First of all, the victim might notice the malicious attachment and delete it before falling for the phishing attack via the exploit URL. In order to solve this problem, one could create the email to send in such a way that it's picked up by the spammer filter and moved to the "junk" folder. Another trick to avoid the victim seeing the attachment is to send the phishing email with a Date header equal to a very old date, that way the email won't appear after logging in. Also, it's beneficial to choose a unique subject in the evil email. Provided that the email sent by the attacker has a subject equals to any of the previous emails, the email subject part of the exploit URL will have a dash and a digit after it. i.e.:


    My final tip is regarding discovering if the target company' uses OWA for webmail access. Discovering such sites is trivial via subdomain bruteforcing. Checking headers like the following within emails from the target domain might also help:

    X-MimeOLE: Produced By Microsoft Exchange V6.5

Please find the POC attached to this post.

Great post, very informative.
Just thought I would add a note about the long hex-style string. When I tested this on my corporate OWA installation, I got the exact same string as in your post. I also tested with two other colleagues and they also received the same string. Although our installation generates an error on the server from owaauth.dll, just thought I would alert you to the string issue.
Does not work with Exchange 2007. OWA requires .html attached files be saved to disk first.
content disposition attachment can be forced to open inside object elements in some browsers
Adrian PastorAdrian Pastor
@djteller - thanks for such kind comment! @Matt - if the hex string is NOT not a unique variable, but rather a constant, then crafting the exploit URL would become even easier. I'm not sure what you mean by the error. Is this an error generated when accessing the specially-crafted URL? @maotx - it'd be cool to make it work on OWA2K7 as well. Unfortunately, I don't have access to a OWA2K7 installation to find out if there is a way to replicate this phishing attack.
@Adrian - Yes the error is returned when accessing the specially crafted URL. The process is that I get the normal Basic Auth pop-up to enter credentials, enter my valid credentials, and then I get another older looking login page. (Can send you screen shots if interested). Then after entering my creds on this new page (and verifying that the url has not changed and I am still on my companies OWA site), I get the owaauth.dll error. Let me know if you want screenshots for your review.
Adrian PastorAdrian Pastor
@Matt - If you paste the real URL (with domain name hidden for privacy) I should be able to reconstruct the exploit URL. One thing I'm thinking of is that the inbox folder's name has been customized. In that case you need to use the customized value. I'll contact you to see the screenshots. Can't understand why you get the authentication prompt after you have logged in. What's described on this post has been tested on 3 different OWA2K3 installations with no problem. It'd be quite useful if other GC readers tested it on their installations.
Thanks, Adrian. I have all the screen shots ready. I have confirmed that our OWA and Exchange servers in prod are 2003. Another thing that I have noticed though is that none of my URLs have the "1_multipart_xF8FF_2_" at the beginning of attached file names. Could this be an issue? P.S. I have tried the URL with this string in front of the attachment name,m but to no avail.
Adrian PastorAdrian Pastor
@Matt - perhaps you don't even need "1_multipart_xF8FF_2_" in your case? Best thing is just post the original path of a URL that accesses an attachment, and we'll show you what to do. Anyway, we'll be in touch via email.
I tested on a client's OWA server and removed the UID. pretty scary. If you don't have your status line in view, and looked there, you wouldn't notice that the logon button points to someplace else. holy spear phishing batman
this is exactly what we thought :)
pretty interesting discovery. Too bad, i cant test it.
Adrian PastorAdrian Pastor
Hi Raffi, this is the same result we got on 3 different OWA installations. Glad to hear to find this attack as neat as we do!
Very cool hack! I'm not surprised that Microsoft doesn't take it seriously. I think this flaw can be made even more serious by using flash and the crossdomain.xml file as described in this hack presented at Defcon 15: http://www.defcon.org/images/defcon-15/dc15-presentations/Rios/Whitepaper/dc-15-rios-WP.pdf
Adrian PastorAdrian Pastor
Hey Mike. I just read most of the paper and love it. Very simple yet effective technique. These are the kind of hacks I really love!
Ok I have been playing with this all morning and I am stuck. The server used is OWA2003. I have tried sending it to myself from my private mail doing it a few different ways. Not exactly sure what I am doing wrong. Not sure if it is because I am at home and logging into the OWA from here remotely. Would you be willing to help me out with this? After the victim enters the cred where do I view them at, I post the url, but just get the sign in sheet. Any help would be very appreciated. I am a bit new to this, but love the challange. Just stuck
Hi, Im in quite slow, but explain the get-credentials.php file please. Must I still write this and host it on my website?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
Just tested this attack again successfully on a OWA 2K3 installation during a pentest. It's good to see it still works! However, I would like to know why it doesn't work on all OWA 2K3 installations. Reading our readers' comments on this post shows that the exploit doesn't seem to work for everyone. Perhaps there is something configuration-specific that would make this attack not work?
Is this method still effective anyone?
Nitin KushwahaNitin Kushwaha
Hey Adrian, I would like to know if any other exploits in EX2k3 OWA with SP2. running on MS W2k3 Sp2. The problem i am facing is the company had implemented the fix for URL redirection: something like, making a copy of OWALogon.asp, then say Re-directing the base URL for OWA to itself. any clues??