Mobile Device Management (MDM) systems have long been hailed as a panacea for Bring Your Own Device (BYOD)/ Choose Your Own Device (CYOD) strategies. But what would happen if the very devices managed by the MDM were to be successfully compromised? Could the MDM become a single point of failure? Could the user’s device turn rogue?
MDMs aim to ensure mobile devices in the field can connect to enterprise networks and be managed securely. They facilitate Over-the-Air (OTA) provisioning, enabling these systems to remotely configure, troubleshoot, or lock and wipe lost or stolen devices. It’s no exaggeration to say the MDM has played a crucial role in the success of BYOD/CYOD, reducing business support costs and risk and enabling the user to use one device for work and recreation.
Free Download: Is An Outright Ban On Workplace Social Networking A Good Idea?
In order to prevent data loss from stolen or misplaced handsets, MDM products have the ability to enforce existing native data encryption on the device. However, if the encryption were broken, it would be possible for an attacker to capture the device’s information and, shortly thereafter, compromise the organisation’s data security. But is this feasible? Surely such an attack would prove prohibitively complex and expensive to carry out, correct? Unfortunately, the answer is “no” on both counts.
It’s relatively simple to scrape the memory of an Android phone and decrypt it, exposing sensitive information. During recent investigations, we found that it is possible to compromise a PIN-locked and encrypted Android phone using just $200 of technical equipment. Few MDM products can prevent this, meaning that compromised Android devices will surrender their secrets in a way that MDM is powerless to prevent.
We recently demonstrated a compromise of a Google Nexus 4 by accessing the “JTAG” port that is visible when the back of the handset is removed. This port is intended to allow for on-chip debugging, but it can also be used to scrape memory. Using a JTAG connector and a RIFFbox, we were able to read the Flash memory and examine the Userdata and Metadata files. The latter contained sufficient cryptographic information to brute force the encryption password / PIN to unlock the device in a few minutes. Extracting the whole Userdata partition would a little longer take longer, but it’s still possible.
Of course, knowledge of this vulnerability can prove useful to organizations. If you’ve seized an employee’s phone for legal reasons and they won’t give you the PIN, or perhaps a friend has forgotten their PIN and doesn’t want to factory reset it, being able to brute force the handset can provide an easy solution. But the same techniques can also be used for hacking stolen phones, bypassing the MDM’s control over the handset.
Thankfully, not all MDMs are the same. Although most work by simply enforcing certain policies already available on the handset, a very small number work differently, creating an encryption container independent of the handset operating system cryptography. Equally, some handset manufacturers have been more fastidious about their security, implementing improved encryption. A good example of this is the Samsung S4. (NOTE: Even so, this has been independently compromised through the Sandy framework.)
So what are you supposed to do? No doubt your business is keen to permit BYOD, but how on earth to you allow personal devices to securely interact with your business systems?
If you currently allow mobile devices (personal or not) to connect to your Exchange server or other systems and don’t have an MDM, then you should consider getting one.
If you do have a Mobile Device Management product, then you need to investigate how it operates. If it works by policy enforcement, then you are at the mercy of the handset manufacturers’ approach to security.
As illustrated above, vanilla Android encryption is pretty weak. The older the handset, generally the more insecure it will be. It may be that the handset manufacturer has implemented better encryption, but if you don’t verify this carefully, then your corporate data could be toast in the event of an attack.
The same applies to iPhones. Older devices have security flaws that simply can’t be fixed using most MDM products. Newer handsets are much more secure, but given that the lifespan of a phone or tablet is around two years nowadays, you clearly need to be watching carefully for new security issues. It’s really important to force users to have the latest version of Android or iOS on their phones too. Updates are a pain, particularly on a mobile, but they’re issued for a very good reason, i.e. the old software version has a security flaw.
Longer PINs on devices also make many attacks a great deal harder. Users may baulk, but a six or eight digit PIN can make a significant difference to the security of a device. Show them how easy it can be to compromise a device with a short PIN; they might thank you for helping them protect their (personal!) data. Pattern-based PINs can be a bad idea too, as they are easier to “shoulder surf’”, not to mention they reduce the entropy of that PIN. When drawing a pattern, one usually moves to the next adjacent number, rather than jumping around the keypad. Hence, the number of potential combinations decreases massively.
BYOD is great in terms of flexible working practice and possibly reducing costs. Don’t make it mean “Bring Your Own (Security) Disaster”.
Ken Munro can be contacted at: [email protected]. The full Android hack can be viewed here: http://www.pentestpartners.com/blog/how-to-scrape-plain-text-from-an-encrypted-android-phone-or-why-most-mdm-products-just-dont-cut-it/
By Ken Munro, Partner, Pen Test Partners
About Pen Test Partners
Pen Test Partners LLP is a limited liability partnership for one very good reason; being in a partnership means that its teams are heavily invested the company. It’s that employee ownership which inspires and drives quality in what the company does. It means that it can meet and exceed the needs of its customers who may feel underserved by their pen testing providers.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.