Updates on the latest Outlook iOS App issues
First of all: I haven’t expected that my previous blog post would create such a buzz… As I’ve received a great number of comment, mails, re-posts, re-tweets and so forth I’m taking this to get into some more details.
Some background about me
I spent the last four years nearly exclusively in the mobile area in building products for Mobile Device Management, Mobile File Sharing and securing Mobile PIM. Not talking about my experience in several administration topics including large scale E-Mail deployments. So (to all who questioned out there) I’m pretty confident about the facts I talk about.
All ActiveSync servers are affected
The post wasn’t a shout-out about Microsoft Exchange. All services/servers that are using ActiveSync as their protocol are affected. That includes IBM Notes Traveler and loads of other server implementations. For the sake of simplicity I’m referring in this post as “ActiveSync servers” to them.
ActiveSync is not ActiveSync
That’s one of the caveats. ActiveSync server administrators deploy policies to the connected devices. That can be i. e. device passcode settings or disallowing the camera. All this is part of the ActiveSync specification. Administrators rely on this. And here lies one of the problems - in-app ActiveSync isn’t the same as native ActiveSync.
An app on iOS cannot set the device passcode. An app cannot prohibit the camera. And an app cannot be used to remotely wipe (yeah, that’s a big security feature too) a device. That all is only allowed for native ActiveSync, means the native iOS mail app.
So even if the app is from Microsoft - you cannot enforce your ActiveSync servers’ security on connected devices. It’s technically not possible (and that is good IMHO). Best would be to use a Mobile Device Management (MDM) solution for that.
An Exchange admin has posted some good findings here (more on them further below).
To cloud - or not to cloud
That’s one major issue with this kind of app. The majority of all companies run their ActiveSync servers on-premises - and not in cloud. Some are in the move (that’s fine for me), some cannot (because of regulations) and others just don’t want to put their e-mail data like HR reports, financial stuff, communication about mergers etc. into other companies hands.
Let’s summarize and explain how this app works:
- After you’ve setup your Exchange(like) account into the app it stores your data in the cloud.
- Microsofts cloud-service then connects frequently to your ActiveSync server with your ActiveSync credentials to check if you’ve new mail, new contacts, new calendar entries etc.
- If you’ve a new component on your server side your device will receive a push notification using the Apple Push Notification Service (APNS).
No 2 is a big concern for those companies who don’t (want to) use cloud. You’re giving away your credentials. But - it’s the only way how Microsoft (or previously Accompli or others) can handle it. It’s because of the “restrictions” with apps on iOS. An app, if not running in the foreground, cannot run longer than 10 minutes. So after 10 minutes an app won’t be able to check the server for new mail etc. It’s technically not possible (I like that because it helps battery life).
If an app now wants to provide a “push mail experience” like the native ActiveSync app they have to leverage APNS notifications. One way is to do that via cloud, the other way is to do that using the on-premises infrastructure. The guys from IBM i. e. use the on-premises way for their ToDo app. The local server, which is part of a companies infrastructure, sends the push notification. IBM will also leverage in the upcoming March release of IBM Notes Traveler Google Cloud Messaging to send push notifications for on-premises installations to connected mobile devices. So Microsoft has to built a way that allows that No 3 of the list can be done by a local server. That’ll change the need for storing data in the cloud.
Another option for Microsoft would be to move from “push mail” to a periodic fetch - using the background fetch starting with iOS 7. In that case only a connection device to server will be setup.
If you’re running your data nowadays in Office365? No problem with that…you’re already trusting Microsoft…
Switching to OAuth will solve all problems - or not
Currently the app (and the cloud service) needs your credentials to check the server. Microsoft’s Javier Soltero has stated that they plan to switch to other mechanisms like OAuth “when available”.
Will that solve your issues? No.
As long as they use a cloud-based service to check your ActiveSync account they’ll have access. And it doesn’t matter if they use the credentials directly or some authentication-delegation like OAuth!
Mobile Device Management can help you partly
A good MDM solution allows you to blacklist app and issue quarantine actions or something similar. Does that help? Only partly.
You cannot really prevent the installation of apps on an iOS device (except you forbid the usage of the Apple App Store). A MDM can only query the device periodically and issue an action based on this inventory data. So there will be still some gap between installation (and setup including pushing credentials to the cloud) and the point where you’ll learn that the app has been installed on a device.
A MDM is also not capable to interfere into other apps HTTP communication. The iOS sandbox model prevents that.
How to prevent all this?
There are several ways to prevent access of the app to your servers. My colleague Detlev Pöttgen has written a blog post how to prevent access on IBM Notes Traveler servers. An Exchange guy has written PowerShell cmdlets in this comment.
All this relies on the HTTP User-Agent header. So if Microsoft changes it…well…start from scratch.
Other ways are to use route all device traffic through VPN (setup via MDM) and prevent communication/disable the routes to AWS. Or Azure (Microsoft will move to Azure). But…
The safest method would be to use certificate based authentication for your ActiveSync server where you control (i. e. via MDM) the certificate distribution. You don’t have to worry any more.
One thing that all this has shown to me (again) is that YOU as a mobile administrator has really to watch what’s going on on your device. It’s just one example of how your security can be compromised (even in a theoretical way).
Update 02/03/2015
I’ve now received two comments (here and here) that I’m saying it wrong or that all this is FUD. I’m not deleting the comments as I love an open discussion. If there is a discussion…
So I have a request for all commenters:
I’m taking this app issue very serious. If you feel that I’m wrong - please explain(!) how to do it better. And everybody who will read this blog post should be able to get as much input as possible. Educating people is the most important thing.
