OWA Keep-Alive in http, even though it should be forced https

Question

Yesterday, I got an alert from a client's IDS that a Base64 auth packet was detected. Looking at the Ascii decode, I can see that it is for their OWA (Outlook Web Access), and indeed, the auth info was Base64, easily decoded to the username/password of a user.

What is odd, is that this company's Exchange server is setup to never allow connections unencrypted (via HTTP or POP/SMTP). It will always redirect http to https before authentication is required.

Since getting this alert, I have queried for other alerts of the same kind, but cannot find much more... It seems to be an edge case.

Any ideas on what is going on?

=====Ascii Decode of packet====

GET./.HTTP/1.1
Host:.xxxxxx.com
User-Agent:.Mozilla/5.0.(iPod;.CPU.iPhone.OS.5_0_1.like.Mac.OS.X).AppleWebKit/534.46.(KHTML,.like.Gecko).Version/5.1.Mobile/9A405.Safari/7534.48.3
Accept:.text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Authorization:.Basic.xxxxxxxxxxxxxxxxx==
Accept-Language:.en-us
Accept-Encoding:.gzip,.deflate
Cookie:.UserContext=ecc88b90b86c483f89db34eb673c259c;.OwaLbe={A907E8ED-3881-4B44-B84E-F036E6485722}
Connection:.keep-alive

Answer 1

About that Base64 auth packet, it is related to this discussion in the McAffee communities here. This is because, they have set Basic Authentication mode for OWA.

The isssue is explained in detailed, some of the explanation:

Basic Authentication is a means to send usernames and passwords over the network to log into a device upstream. This form of authentication is inherently insecure because it is sent in plain text over the network, however, it is widely adopted by most clients/servers which still makes it relatively popular, especially in multi-platform environments. We strongly suggest that if you are going to use it, then you should use it over HTTPS (SSL/TLS), to prevent anyone from using a packet sniffer and picking up passwords while in transit.

Basic Authentication is simply a base64 encoded username/password sent across the wire as user_name:password

To base64 encode a username and password: echo -n "valid_user_name:valid_user_password" | openssl base64 -base64

With regards to the unencrypted HTTP communication, it could be a flaw with the ActiveSync implementation on IOS 5.0.1. Or related to this MS support ticket that said:

The new functionality sends HTTP requests even when the client is idle. The client sends a keepalive request (/owa/keepalive.owa), and then the client sends more information about the activity of the user by adding the following path of the published OWA URL: /owa/ev.owa?UA=0

I wonder why MS did not say it sends HTTPS request??? More test need to be done. And this is only related to Exchange 2010 new OWA functionalities.

Answer 2

Just because the server requires SSL doesn't stop the client from attempting HTTP.

This is a common leak of credentials across all web applications. The web browser caches the credentials to the server. The user then types the URL with http://owa.example.com. The browser then sends the cached credentials in the clear to port 80, at which point the server redirects to port 443.

In addition, automated tools (as described in other answer about ActiveSync) are broken and may try HTTP when HTTPS is intended.

The only way to prevent this from happening is to block port 80. The only way to prevent the client from disclosing the password is to prevent the client from establishing a connection.

Note that trying to improve over "Basic" authentication won't help much. Most other authentication methods that use challenge-response can be cracked using password crackers (like "Cain and Abel").

Answer 3

Is it possible / conceivable that OWA was previously configured over HTTP (even briefly) and then later switched to HTTPS? If it was used over HTTP in the past and a user connected to it back then, the browser could have cached the credentials. Then, when the user re-enters the http://... url (or uses a bookmark), the browser might send the cached credentials on the first request, which later gets redirected to HTTPS.

Otherwise, I don't believe any decent browser (in this case the request headers suggest it's an iPod with iOS 5.0.1 running Safari) will send the HTTP Authorization header over a different host name, port or protocol from the one used before. That said, you might have bumped into a (rather serious) bug. The best thing is to test it, ideally with the iPod this user was using and see what the configuration was set to if possible. If you can't access the exact same device or the configuration has changed, then you should perhaps try to simulate this condition with a similar device and see if you are able to reproduce it.