Hack First, Policy Second – A Mobile Device Story

Like many of you I was extremely excited when my organization started allowing purchases of iPhones and Android devices.  With the entire buzz around “the consumerization of IT” and “Bring Your Own Device (BYOD),” it wasn’t long before these devices started becoming a necessity for business rather than simply the coolest new gadget.  Syncing my email and calendar was a great first start, although I have to admit the electronic leash has become quite long in the past few years.  When I was able to make travel reservations, submit expense reports, attend internal web conferences, review Statements of Work (SoW) and presentations all without opening my laptop, I became a huge fan. Policy never came to mind much less a hack first mentality.
If you’ve read any of my previous articles, then you will realize I come from a hacking background first and foremost.  Therefore, when I began to delve into mobile security, I didn’t start with learning best practices or how to develop secure mobile applications.  And a corporate policy was definitely the last thing on my mind. I simply wanted to start breaking things.  However, as it wouldn’t do to brick a corporate device, I explored the possibility of purchasing an iPhone/iPad/iPod without a data plan to use as a hardware testing platform.  This was not only a stroke of genius for learning mobile application security, but it led to this article.  So let’s look at a practical business decision, but, from the get-go, approach it as a hacking exercise.

Why Hack First?

I initially didn’t realize the struggle IT departments had dealing with mobile devices, because, let’s face it, ignorance is bliss.  Everything was moving at lightning speed, as business typically does, and it wasn’t long before security concerns started to be called into question.  Then the reins began to be pulled taut.  Are we securing email appropriately when we sync?  Should phones be allowed access to the corporate wireless network or only the guest network?  Do we need antivirus and firewalls on the phone?  Do we allow/support applications on our systems that allow the phones to be backed up?  Do we scan these devices as part of our vulnerability management program when they are connected to the network?  What happens if a phone is lost or the employee is terminated?  All the same issues and more can be applied to tablets as well. I can hear the collective scream of IT departments over the globe yelling, “HELP!!” If there is an app for that, shouldn’t we have a policy for that? But a policy for what? And how do we get it approved? That’s where the hacking comes into play.

My “Harajuku” Moment

Tim Ferriss, author of “The 4-Hour Body” wrote an analogy about a friend of his who had been shopping in the Harajuku area of Tokyo, Japan, and made the statement that it wouldn’t matter what he wore, he wasn’t going to look good anyway.  The story goes that the statement hung in the air like when you say something super-embarrassing in a loud room but happen to catch that one moment of silence and everyone hears you.  That moment was the tipping point for the friend to go on and lose 70+ pounds in less than 12 months.  Tim goes on to write that, “People suck at advice because most people have an insufficient reason for action.  The pain isn’t painful enough.  It’s a nice-to-have, not a must-have.  There has been no “Harajuku Moment.”  So, what was my Harajuku Moment for mobile policies?
As began exploring mobile device security, I investigated what is known as the keychain.  The keychain is a secure location inside iOS where usernames, passwords, tokens, certificates and other information is typically stored.  The data contained within this keychain is encrypted and tied to the action of locking and unlocking the device.  Check out this link to dig into this further and learn about when keychain items should be readable.
If you don’t want to go through all of that, then just keep in mind that if an attacker gains access to the device, all data in the keychain is compromised.  This really isn’t an issue if someone doesn’t have physical access to your device, but how many of us have lost a phone?  Ok, what if we don’t lose it, but simply misplace it for an unexpected amount of time (Wink, wink, nod, nod goes the attacker).
Keeping this in mind, my moment came when I used the tool keychain_dumper from https://github.com/ptoomey3/Keychain-Dumper.  Accessing my iPhone via secure shell (SSH) while it was connected to my laptop, I simply ran the command and discovered the following:

Hack First, Policy Second – Kali Linux Screenshot

Those two service headings for AirPort are account settings for wireless networks.  What I discovered is the shop I had purchased the iPhone from had connected to its local wireless networks (guest and internal), and that I now had a Service Set Identifier (SSID) and the password to connect to that network.  I verified this because scrolling down I also found my own home wireless network and password at the same time.  So, why is this such a big deal?

Gaining access to a smart phone can be rudimentary for most attackers.  In this example I could have done the same thing against a ‘borrowed’ device, replaced it, and the user would have been none the wiser.  Then I could have simply accessed the user’s wireless network to further escalate any attacks against the user, or the user’s organization.  What really struck me is the business had used the same wireless network to run my credit card for the purchase!  The potential ability to gain access to credit card information affects Payment Card Industry (PCI) compliance as well as a slew of other privacy and security concerns.

Conclusion

I’ve often argued that an effective security awareness program must have some real world experience from which users can directly relate.  In this scenario, the real world experience hit me square in the face.  Mobile application security or mobile security awareness in general went from ‘it’s a nice-to-have’ to a ‘must-have.’  I had had my “Harajuku Moment.”
The real trick is then taking this moment and relaying it to the higher ups. The beauty is that it’s not just a ‘kewl hack’ that they’ll never understand. You can tie it directly to being a compliance issue. This makes the techie not only look good for knowing the business end of things, but it also has a greater chance of leading to a real policy with management buy-in.  We all know how hard that can be.  And this can all be done by focusing on the hacking aspect first.  How cool is that?
So, based on this experience, what should we be telling upper management about mobile device security?  First and foremost, have a policy.  Then start working on the processes to address situations illustrated above.  Here are some initial guidelines these policies and processes should address:

• Your policy should remind employees that they have no expectation of privacy if a device is company owned.
• Whether a device is company owned, or not, you should point back to your standard “Acceptable Use Policies”, i.e. the device should only be used for work-related purposes while on company time or while using company resources, like your organization’s wireless infrastructure.
• Consider “data usage” restriction clauses in the policy, i.e. PCI data and applications should not be accessed from a mobile device.
• Consider support restrictions and note that the end-user is responsible for third-party or “beta” release software, unless explicitly listed as being a supported company application.
• Consider changes in your architecture, i.e. access to an organization’s VPN via a wireless interface should be segmented appropriately.
• Consider process and technology capabilities, such as:
  • enabling remote wipe of the device.
  • using encrypted containers on the device to store corporate application and data and be able to manage/backup these assets remotely.
  • limiting application loading to only corporate approved software on corporate supplied phones.
  • limiting hot-spot capability when connected to a corporate network.
  • enforcing remote usage monitoring if supported.

If we’re truly ‘ethical’ hackers, then we shouldn’t just be attacking things for the heck of it. We should always have in mind that we are finding security gaps for the purpose of trying to close them. What a better way to justify what we do to those who may not understand, than to do a real-world attack with a real-world consequence.  So rather than learning about this the hard way, I hope my experience will help drive home the point as to why we should be thinking about mobile security and in turn the policies to have in place to protect not only our corporate data, but also the individuals who access it.
I’m sure I’m not the only one that has seen mobile devices cause headaches throughout the wider IT community. By applying our unique perspectives as security professionals with a penchant for digging deeper, we can help others add to their toolbox when dealing with users and management.  It would be very helpful for me to learn from the success or failures of others and their organizations.  So please share with us your stories in the forum thread at the bottom of this article, and we can all benefit from hacking things first.