all site content copyright © chris rue. all rights reserved. any reproduction, re-use or summarization of any kind without prior written consent is prohibited.
August 6, 2006

solving a problem with remote device wipe

as good as it is that mothership released msfp, and added in such awesome new functionality…

remote device wipe leaves a lot to be desired.

to be sure, the inability of remote wipe to nuke storage cards makes it nearly impossible to store anything other than utterly insignificant data on said storage cards.

then there’s the issue of the transaction log.

rather than record all the steps of a given wipe permanently, including when the wipe was fully completed…

the transaction log only shows when a wipe, or a wipe cancel, was originally sent. which is totally insufficient as a log of activity, in my opinion

but beyond all that, there’s another huge issue with remote wipe…

ostensibly, remote device wipe should be an answer to a certain fruit-flavored competitor’s remote kill feature.

consider this typical day in the life of a help desk monkey…

wavy lines denoting start of dream sequence

phone: rrrrring

monkey: hello…help desk. how can we, errr…help you?

phb: hey, this is mr. big time ceo talking. i lost my windows mobile device which contains some super-secret info that will cost our company millions of buckaroos. can you do something about that?

monkey: no problem…

monkey sends a remote wipe command while making a suitable sound effect

monkey: bzzzzt! problem solved. the info on that device is hist-o-ree.

phb: fantastic! i’m sending my smoking hot assistant with the keys to my ferrari. go take it for a spin for the rest of the month. and feel free to drive the car as much you want.

wavy lines denoting end of dream sequence

help desk monkey fantasies aside, here’s the reality…

activesync remote administration might not automatically wipe a device

that’s right, you heard me.

remote wipe might leave that device, and any data it holds, totally & utterly compromised.

here’s how…

the very first time any security policy is applied against a device, the device displays the following prompt before applying that security policy.

cancel!? there's no cancel in remote data wiping!

that is because the device is considered new, as in…it has never had a security policy enforced on it before.

unfortunately, this prompt gives anyone using the device the opportunity to either ignore or cancel the application of that security policy.

and of course, remote device wipe is really nothing more than a security policy being immediately enforced on the device.

now, no additional data synchronization will take place until that security policy is allowed to continue, but that’s not really a problem for someone who just wants access to the data currently existing on a device.

in fact, this kind of loophole is a data thief’s dream…since it effectively means that remote wipe can be countered without any special effort.

there is always the option of configuring password lock with a local wipe option after x number of incorrect password attempts to secure the data on a mobile device.

while your friendly neighborhood happyfunboy is a big advocate of enforcing password lock for mobile devices…

he is not a big advocate of local wipe, simply because it is way too easy for someone to forget their password & simply eat up all their attempts in frustration before they ever call a help desk.

so yours truly spent some time this afternoon in the funlab cooking up a way to close this loophole in remote wipe, with the fruits of this labor being called…

happyfunboy’s super-awesome guide to priming windows mobile 5 for remote device wipe

the secret is to actually apply a security policy to each & every new device that you deploy before you put it in a user’s hands.

once a security policy has been applied & the ok given at the prompt, any subsequent security policy gets applied automatically. which is exactly the kind of behavior you want for a remote wipe command sent to a lost or compromised device.

altho remote wipe itself is a security policy, it completely and utterly reverts a device to an absolute fresh state, so much so that afterwards the device is considered new, from the perspective of security policies. so you can’t simply send a remote wipe command to a device, then set it back up again.

it takes the application of another, non-destructive security policy to actually prime a given device for automatic remote wipe.

luckily, there is just such a non-destructive security policy available in exchange system manager…

device security

altho using the device security options might require you to work out some logistical issues, as we’ll talk about in more depth in a minute…

pushing a password policy will successfully prime a device for auto wiping.

to get started, navigate to & launch exchange system manager

exchange system manager...there is no substitute

under the top-level organization, expand the Global Settings container, right-click Mobile Services, then click Properties

mobile services be da place!

on the General tab, click the Device Security button

click for more security!

at a minimum, check the Enforce password on device box

gotta check something...otherwise there's nothing to approve, right?

if you are going to heed my advice and enable passwords on mobile devices as a general policy, then you can just set this option & let it roll out to all the windows mobile devices without a care in the world, right?

well, besides obviously needing to train the device users on what to expect…

i’d also recommend taking some time to think about enabling other supporting policies that actually make enforcing passwords useful, such as:

  • minimum password length
  • password complexity
  • inactivity timer

if, however, your company is not going to require passwords on mobile devices, then you will want to make liberal use of the Exceptions button.

the reason?

even if your organization is not going to be enforcing passwords on mobile devices, you can still temporarily set password enforcement to prime a device for auto remote wipe.

however, since setting password enforcement is a global operation…

and as such can affect every device in your exchange organization…

once you’ve primed a device, you’ll want to be sure to add that user to the password exception list, so they don’t inadvertently get prompted to set a password as you toggle password enforcement on & then off.

to set a user as an exception to the password policy…

in Device Security, click the Exceptions button

an exception to every rule

click the Add button

think of it like the vip list for a trendy nightclub...except there's no velvet rope, no bouncers & no one really cares about you.

type the user name in directly, or search the directory for it

c'mon...can't tell me you can't recite every one of your users from memory? what kind of system admin are you, anyway?

once entered/found, click OK on each dialog box to get back to the Mobile Services Properties dialog box, then click Apply

the illuminati

that will keep a device from being caught up by the password enforcement policy unnecessarily.

but let’s get back to what we were doing before…

once the password policy is enabled, either permanently or temporarily…

any mobile device where the user account is not set as an exception will give the same first-timer prompt which requires you to click OK to apply the policy & proceed.

it make look the same, but it isn't...

clicking OK again will allow you to update your password settings per the security policy that you set earlier.

passwords...are good. passwords...work.

wow…you’re presented with yet another chance to click OK. who knew windows mobile 5 could also be used to train you to become a yes man extraordinaire?

ok ok ok already...enough!

you will need to set a password, obviously, & perhaps a bit more depending on the options chosen for the policy.

it's just a password...quit being a baby & set one already

and if you’re thinking about being cute & setting a blank password…

think again…

gotta be at least 1 digit, smarty-pants!

once the password options are set and accepted, consider the device primed.

obviously, don’t forget to deactivate the password policy once you’re done priming.

after a device has been primed, a remote wipe is initiated nearly as soon as it is sent via the web-based administration tool

remember...once a device is primed, it's like a grenade. pull the pin...and there's really no going back...

just as quickly as an incoming message is received via airsync, really.

first, the screen goes all white very very briefly…

white...pure crystal snow...

then black for a little while…

workin' in a coal mine...goin' down down down

then the normal windows mobile splash screen is seen as the devices restarts.

all systems nominal

logistically speaking, the ability to prime devices for auto-wipe may depend largely on the size of the environment.

regardless, at this point in time…

without priming, there is no way to reasonably assure that a device in the field will fully execute a remote wipe without leaving a loophole for the data to be compromised.

happy hunting, kiddos

|| posted by chris under funlab, mobility || comments (13) || ||

13 comments »

  1. Remote device wipe on a mobile 5 device…

    Want to see remote device wipe in action for a Mobile device 5?
    Check it out at the funcave!
    &nbsp……

    trackback by E-Bitz - SBS MVP the Official Blog of the SBS "Diva" — August 6, 2006 @ 1:49 am

  2. Remote device wipe on a mobile 5 device…

    Want to see remote device wipe in action for a Mobile device 5? Check it out at the funcave!…

    trackback by News — August 6, 2006 @ 8:47 am

  3. Nicely done Chris! The minimum system requirements are Exchange SP2 on the server with MSFP & Windows Mobile 5, correct? And the remote wipe nukes the certificate if it’s stored on the device (not the SD card) so if they find the device they’ll have to reinstall the cert, right? Thanks for the great demo!

    comment by Tim Barrett — August 6, 2006 @ 9:47 pm

  4. How to build a box…. with Chris Rue’s expert fixing…

    Okay here’s version 2 of the “How to Build a SBS 2003 server” with expert clarification and fixing from……

    trackback by E-Bitz - SBS MVP the Official Blog of the SBS "Diva" — August 8, 2006 @ 1:07 am

  5. [...] traffic coming from hungary to the funcave has been off the charts, primarily for the mobility specific content i’ve posted, such as the windows mobile 5 device emulator series & the remote wipe issue. [...]

    pingback by welcome to the funcave » the comment line is open…hungarian welcome — August 10, 2006 @ 10:53 pm

  6. [...] don’t even get me started again on remote device wipe. [...]

    pingback by welcome to the funcave » in case you missed it… — November 22, 2006 @ 5:28 am

  7. [...] regulars to the funcave might remember a little item that was posted here all the way back in august concerning what yours truly perceived to be a semi-hole in the remote wipe function of windows mobile devices. [...]

    pingback by welcome to the funcave » solving a problem with remote device wipe…deja vu! — January 11, 2007 @ 3:34 pm

  8. [...] the issues with remote wipe for windows mobile were more than documented here at the funcave… [...]

    pingback by welcome to the funcave » how to REALLY remote wipe a windows mobile device — January 19, 2007 @ 10:24 pm

  9. [...] the issues with remote wipe for windows mobile were more than documented here at the funcave, oh so many moons ago… [...]

    pingback by welcome to the funcave » how to REALLY remote wipe a windows mobile device — January 19, 2007 @ 11:12 pm

  10. [...] besides the certificate improvements, wm6 offers some much needed security functionality. encrypting content on the storage cards is great, but i’m wondering if they will finally add the ability to remote wipe those cards. heck, if nothing else…i hope they close the hole with remote wipe that was already discussed here at the funcave ages ago. [...]

    pingback by welcome to the funcave » windows mobile 6: the straight story — February 11, 2007 @ 9:28 pm

  11. [...] and writing all this up, I Googled a slightly different set of search terms and stumbled upon Chris Rue’s complete and much more thorough documentation of this same problem, which he wrote up last August. Had I found that article earlier [...]

    pingback by The Schlog » Blog Archive » Problems wiping myself — April 14, 2007 @ 2:16 am

  12. [...] It won’t. [...]

    pingback by welcome to the funcave » While You’re Working On Remote Wipe — February 25, 2008 @ 8:36 pm

  13. [...] some other thoughts Chris Rue, an SBS MVP who does lots of Windows Mobile work has a posting here http://www.chrisrue.com/funcave/2006…vice-wipe.html I’ve not read it and don’t know if it addresses your issue, but you might try looking around Chris’ [...]

    pingback by Mobile Admin wipe fails | keyongtech — January 18, 2009 @ 12:12 pm

rss feed for comments on this post. | trackback: http://www.chrisrue.com/funcave/2006/08/solving-a-problem-with-remote-device-wipe.html/trackback

leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .