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.