Siri, Tell Me About The Problem
With the inherent flaws (AKA features) offered by Apple’s new iPhone 4S with Siri, I was asked to block access to our ActiveSync services from 4S devices. Unfortunately, Exchange’s Device Access Rules don’t allow us to drill any further down than “iPhone” (Honestly I think this is the fault of Apple for not reporting device model correctly…but that’s just me).
In my environment (and most others, no doubt), “Sorry, Exchange can’t do that” isn’t really good enough, so extra troubleshooting was required. I decided to jump into Exchange Management Shell (EMS) and check out any more properties I could find. Issuing the Get-ActiveSyncDevice | Out-Gridview Exchange command yielded some useful results (some details removed from the graphic to protect the guilty). I’ve included all the properties that contain any information of use in blocking the devices. The property of particular interest is DeviceUserAgent. This seems to show some consistency, in that all iPhones are in the format “Apple-iPhonexC1”. “x” seems to be an incremented number that increases with device revisions.
By doing some user to model to Operating System spot-checks (and thanks to some helpful people on Twitter!) I was able to ascertain that DeviceUserAgent directly correlates to the hardware of the device connecting to Exchange (not necessarily the version of the iOS build, as was my initial fear). The DeviceUserAgent for the iPhone 4 is Apple-iPhone3C1, and the iPhone 4S is Apple-iPhone4C1. Knowing this, I can now update my filter to show only iPhone 4S devices (that is, where the DeviceUserAgent begins with Apple-iPhone4C1:
It appears that the string following the slash (/) in the DeviceUserAgent may relate to the iOS build on the device, but this isn’t really relevant at this stage. If Apple start to offer Siri (and this security hole) on previous versions of the hardware, I may need to adjust the queries to suit.
TLDR; Siri, Just Tell Me How to Nuke You!
Dependent on your organisational policies, you may be able to take the easy way out in blocking Siri on the iPhone 4S. We run a BYOD environment for most staff who want to, and we take a completely hands-off approach on this (no support, no assistance beyond “these are your settings”). For this reason, I’ve decided the easiest approach (since Device Access Rules aren’t going to work for me here) is to write a script that simply removes any connections to these devices every time it runs. I’ll leave the frequency up to you to decide. The one line script looks like this:
Get-ActiveSyncDevice –filter { DeviceUserAgent –like "Apple-iPhone4C1*"} | Remove-ActiveSyncDevice –Confirm:$falseWhat does this do?
| Command Segment | Description |
|---|---|
Get-ActiveSyncDevice |
Get an array of all the ActiveSync Devices |
-filter { DeviceUserAgent –like "Apple-iPhone4C1*" } |
Only return devices whose DeviceUserAgent begins with Apple-iPhone4C1/ |
| Remove-ActiveSyncDevice | Remove the devices |
| -confirm:$false | Don’t prompt for confirmation (we want this to be automated!) |
After running this script, I sat content that iPhone 4S devices would would be blocked from my Exchange environment. However it occurred to me over lunch, whilst eating my quiche, that devices could simply re-join themselves to Exchange! On to plan B (Well.. Plan A, part 2):
Within IIS, it’s a relatively trivial task to block host headers. On your CAS servers, ensure you have the role feature ‘Request Filtering’ installed for IIS. This will allow you to do some very cool filtering dependent on a number of parameters. (Edit: Belated hat tip to @jamesbannan for the IIS idea)
Jump into IIS Manager and drill down as far as you’d like. I did this at the server level; I don’t want 4S devices accessing anything! You could easily do this on just your OWA site, or even further down the tree. Under IIS, select Request Filtering. On the Rules tab, select Add Filtering Rule.
Enter a descriptive name, then under Scan Headers enter a new line User-Agent. This will tell IIS to check the “User-Agent” component of all request headers. Leave “Applies To” empty, so it will apply to all file types. Under “Deny Strings”, enter the user agent of the iPhone 4S (Apple-iPhone4C1*). You could theoretically block any user agents you want to here . My rule looks like this:
When browsing from a device with the host header specified above (i.e. the iPhone 4S), IIS will return this beautiful error message:
When browsing from an allowed device (say, an iPhone 4):
Hopefully Apple will remedy this flaw soon so that we can stop with this workaround. It’s irresponsible of a software manufacturer to release such a hole…but that’s an argument for another blog post by someone much smarter than me.
Comments/questions
There's no commenting functionality here. If you'd like to comment, please either mention me (@[email protected]) on Mastodon or email me. I don't have any logging or analytics running on this website, so if you found something useful or interesting it would mean a lot to hear from you.