Configuration Matters - OWA Insecure SSL Deployment

"Any fool can know. The point is to understand." - Albert Einstein

In this post, I will discuss a fun problem with Outlook Web Application (OWA) regarding SSL and it's default configuration.


Does your organization use OWA? Maybe some employees use it because it's convenient when traveling? There's a few reasons that you probably have OWA enabled.

Good news, OWA is relatively secure. Remember kids, nothing is completely secure (anyone who says different is either selling you something or is ignorant...maybe both). Anyways, upon some basic boredom, I found that when setting up OWA with SSL (like a security-conscious person should) the default configuration is less than ideal. So, how does OWA handle secure connections over SSL?

Initial Connection

When you first navigate to a deployed instance of OWA over standard HTTP, the browser is told to redirect to the requested resource over SSL. Here's a Burp screenshot that shows this:

Redirect Again

We've requested the OWA service over HTTP and got a 302, which redirects us to /OWA/. Once /OWA/ is called, a secondary 302 response was sent to us and we are now being told to redirect over to the SSL-wrapped OWA:

Now, everything looks like normal to a standard user:

Dropping SSL

As I was bored, I found that I could just request the /owa/auth/logon.aspx resource over standard HTTP. This is what the connection over HTTP to logon.aspx looks like:

Oh look, it responds with a 200 OK. Awesome! And hey, it looks normal in the browser; other than the missing HTTPS (notice the lack of a green lock):

Attacking

If an attacker is sending a user to the non-ssl logon.aspx resource and they are in a position to sniff network traffic, will they actually see a POST request? Or just a forced-SSL redirect? Well, I'll just let Burp do the talking:

As you can see, we indeed did see the POST request being sent over standard HTTP and are able to see what values are within parameters.

The nice part, from an attacker's perspective, is that OWA will still accept valid credentials when they are submitted over HTTP. So, you can harvest a user's credentials and then they will be redirected to an SSL-wrapped session of their inbox. If a victim isn't paying enough attention to the login portion, they may completely miss that they are submitting their credentials over standard HTTP.

I've tested this on a large variety of deployed OWA instances and so far this has been there a lot. There have been some instances of OWA deployments that are behind reverse proxies or use HSTS to assist in forcing SSL.


Just to recap, Outlook Web Application (OWA) does not, by default, properly enforce SSL. Though it redirects a user to SSL, one should never rely only on redirection to protect users. Secondly, I'd like to point out something else; one should never rely on the default configuration of a service. Though convenient, you are assuming a lot about the security of said configuration.

Anyways, implementing something like HSTS is another viable option to ensure that users of your OWA instance can stay more secure both on your network or abroad. Luckily, the following site provides guides on enabling HSTS on a variety of platforms...including IIS:

https://https.cio.gov/hsts/

Doing something like a reverse proxy to setup SSL can also help to restrict connections over HTTP and force users to be using SSL instead.

The instances of OWA that I tested were running IIS 8.0 and were the default configuration enabled with SSL.


I hope this has helped someone in some way....this has just been something I found when I was bored.

Join EFF!