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====

  • To the best of my knowledge, OWA does not work with Basic authentication to begin with (at least not by default). Is it possible that there is a proxy in between, and that is what is requiring basic authentication?
    – AviD
    Commented Feb 23, 2012 at 18:07

3 Answers 3


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.


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").

  • 1
    Do browsers really send the credentials over HTTP if they were previously used (and cached) only over HTTPS?
    – Yoav Aner
    Commented Feb 8, 2012 at 18:13
  • Just tested it with both Chrome and Firefox and neither of them sent the cached HTTPS credentials over HTTP.
    – Yoav Aner
    Commented Feb 9, 2012 at 9:48
  • @YoavAner Yes, that has been my experience with OWA + Chrome/FF.... But what about Safari on iOS? Maybe something to test.... Commented Feb 9, 2012 at 14:08
  • 1
    @JoshBrower I don't have access to iOS currently, but I'd be extremely surprised if Safari or any major browser on any OS had such a fundamental security leakage issue as Robert David Graham described. The Same Origin Policy scope covers protocol (http/https), port (443,80...) and host (www.example.com). I'd say it's safe to assume this is done right by all browsers. Ignoring those rules for something as sensitive as HTTP Authorization headers seems highly unlikely to me.
    – Yoav Aner
    Commented Feb 9, 2012 at 14:21

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .